隨著越來越多的用戶將生產系統遷移到 Azure 平臺的虛擬機服務中，Azure 虛擬機的性能愈發被關注。傳統的數據中心中，我們通常使用 CPU，內存，存儲和網絡的性能來衡量生產壓力。特別是對于 IO 密集型工作負荷，比如虛擬機內部運行的 SQL 服務，存儲系統的吞吐容量，往往成為生產系統的瓶頸所在。
Azure 提供了標準存儲和高級存儲兩種存儲服務。針對于生產環境中的 IO 密集型負荷，我們推薦使用高級存儲。標準存儲僅推薦在開發測試環境中使用。針對于具體的高級存儲的介紹，以及虛擬機存儲的最佳實踐等信息，建議完成以下閱讀：
然而在現實環境中，由于種種條件所限，很多用戶暫時無法使用高級存儲來達到最佳的存儲性能。本文的目的在于幫助目前仍然使用標準存儲的用戶如何準確理解虛擬機的存儲性能，從而在發生存儲性能問題時快速有效的從支持部門得到幫助。
首先，由于虛擬機運行在 Azure 平臺，我們需要了解Azure 存儲空間可伸縮性和性能目標：
單個標準存儲帳戶總請求率上限為 20,000 IOPS，所有虛擬機磁盤的 IOPS 總數不應超過此限制。
標準層虛擬機的單個磁盤 IOPS 上限約為 500。
單個標準存儲帳戶中用于生產應用的磁盤不應超過 40 個
其次，針對于虛擬機操作內部，不同的應用也有不同的磁盤系統優化方案。例如，對于 Windows 平臺，我們通常使用 Storage Space 來盡可能分散 IO 請求到不同的硬件設備來提升存儲帶寬：
使用虛擬機允許的最大磁盤數和最大磁盤容量構建存儲空間
使用合理的 interleave 避免 Split IO
根據實際生產的單個 IO 數據大小規劃文件系統簇的大小，例如 SQL 服務，建議使用 64K 的簇
在理解了存儲系統的一些基本概念之后，下一步我們需要通過合理的方法衡量虛擬機的磁盤性能。
在 Windows 平臺，用戶常常選擇通過文件管理器直接進行文件拷貝來觀察磁盤性能。這種測試往往很容易進行。同時，在用戶界面上也有圖形化的吞吐量顯示。然而，文件拷貝并不是一個測試存儲性能的合理的方法：
文件拷貝，特別是 Windows 圖形界面的拷貝過程并沒有針對磁盤系統本省進行優化。為了達到磁盤系統的最佳性能，我們需要在存儲系統中積累足夠的 IO 請求來促使磁盤始終處于一個忙碌狀態。
當我們使用 Windows 文件拷貝引擎拷貝大文件時，缺省情況下，系統會發起 8 個 1MB 的異步 IO 請求。而在進行小文件拷貝時，除非通過多線程拷貝的方式，否則很難在存儲系統中產生足夠的 IO 積壓。
多數的文件拷貝操作是順序操作。通常只有在一個文件拷貝完成后，才會處理下一個文件。這種順序化的處理會導致文件拷貝的性能遠遠低于實際存儲系統的處理能力。
為了加快文件處理，在進行文件拷貝時，Windows 會嘗試使用內核的文件緩存機制進行 buffered IO 處理。這一方面無法正常反應物理存儲的處理能力，同時也會收到操作系統的內存和 Cache 管理的影響。文件拷貝時，如果使用 Perfmon 等工具收集到的實際磁盤的壓力數據，和圖形中的拷貝速率曲線比較時，往往有較大的差異。
文件拷貝是一個端對端的操作。任何一端的限制都會導致拷貝的速率受影響。因此，很難隔離瓶頸出現的具體位置。
為方便說明，我在中國東區的數據中心創建了一個服務器，具體的參數為：
服務器大小: Standard_D4
標準存儲賬戶，該賬戶中僅存儲該測試服務器的磁盤以排除干擾
該服務器未運行任何生產業務。閑置時沒有 CPU ,內存和磁盤 IO 的壓力
虛擬機加載的 D 盤為本地 SSD 磁盤。
服務器加載 8 塊 1TB 數據盤，使用其中 4 塊創建存儲池并建立 Simple 的虛擬磁盤。
在此虛擬磁盤上創建兩個簡單卷，E 卷的簇大小為 4K，G 卷的簇為 64K
另外使用一個簡單磁盤創立 N 卷，簇大小為 4K。
為進行文件拷貝測試，我們創建了 3 種不同類型的數據文件：
文件夾 MixFiles 中含有各種隨機大小的文件
文件夾 SingleFile 中含有一個 6GB 大小的文件
文件夾 SmallFiles 中含有 200,000 個小文件，每個文件大小為 3KB
從下圖中可以看到根據文件的類型不同，整個過程分為三個階段，
系統在處理隨機大小文件時，拷貝的性能在 10MB/s 到 25MB/s 之間變化。
處理單個大文件的拷貝，性能上升到 40MB/s 以上，但是即便是對單個文件，拷貝性能也不穩定。
處理 200000 個 3KB 大小的小文件時，拷貝性能急劇下降到 500KB/s 左右。
如果我們多次重復文件的拷貝過程，隨著文件系統碎片狀態的變化，服務器 Cache 的使用情況變化等等，同樣的文件拷貝性能的差異性很大。
拋開用戶界面上的性能指示，當我們使用 Perfmon 來具體分析單個磁盤的性能時，很明顯，無論處理那種類型的文件拷貝，磁盤仍然未處于完全忙碌的狀態。而磁盤的數據吞吐量和 IOPS 都處于不穩定狀態
根據以上的分析和測試我們可以確定，使用文件拷貝的方式無法科學地衡量磁盤的性能。
在現實中，為了得到穩定的磁盤數據，通常建議使用 DiskSPD 或是 IOMeter 等工具。
IOMeter:http://www.iometer.org/ "http://www.iometer.org/"
這些工具大多數都是使用服務器的 CPU 資源產生多個工作線程，每個線程根據設定的 IO 讀或寫的比例，IO 請求的大小，順序讀寫或隨機讀寫等，產生大量的并發請求，直接作用于目標存儲設備。
以同一個測試服務器為例，通過以下命令分別對于 D,E,F 和 N 卷進行 4K，8K，64K 大小的隨機讀寫 IO 壓力測試（80% 讀操作，20% 寫操作）
復制
diskspd -c50G -d300 -F16 -w20 -r -b4k -o4 [X]:\DiskSpd.dat
diskspd -c50G -d300 -F16 -w20 -r -b8k -o4 [X]:\DiskSpd.dat
diskspd -c50G -d300 -F16 -w20 -r -b64k -o4 [X]:\DiskSpd.dat
由于篇幅所限，僅僅將 4K 大小的結果總結如下:
同時，根據測試時生成的 Perfmon 日志，我們可以清晰地看到單個磁盤在進行測試時基本上保持在完全忙碌的狀態，并體現出一致的 IO 性能指標(第一個測試為 4K 讀寫，第二個為 8K 讀寫，第三個為 64K 讀寫，每個測試區間前者為 E 卷，后者為 G 卷)
當 IO 為 4K 時，單個磁盤吞吐量(Disk Bytes/sec)，D 卷和 G 卷在 2MB 左右，IOPS（Disk Transfer/sec）約為 480
當 IO 為 8K 時，單個磁盤吞吐量(Disk Bytes/sec)，D 卷在 3.4MB 左右，G 卷約為 4MB，IOPS（Disk Transfer/sec）約為 440
當 IO 為 64K 時，單個磁盤吞吐量(Disk Bytes/sec)，D 卷在 24MB 左右，G 卷約為 31MB，IOPS（Disk Transfer/sec）約為 450
對于同一類測試，G 卷的性能要稍好于 E 卷。
需要指出的是，盡管 DiskSPD 和 IOMeter 等工具都可以模擬不同的類型的 IO 請求，但他們同真實的生產環境中的 IO 模型還是有一定區別的。如果可能，盡可能使用生產環境的真實 IO 來判斷當前的存儲系統是否滿足需求。
如果用戶環境中的虛擬機出現類似存儲瓶頸的問題，建議您可以通過以下步驟快速排查：
通過 Perfmon 等性能監控工具收集生產環境下的服務器數據，包括內存，CPU，磁盤，網絡等等方面。
暫停所有的生產壓力，使用 DiskSPD 或 IOMeter 等工具進行單純存儲壓力測試
使用Microsoft Automated Troubleshooting Services，來快速自動排查虛擬機內部可能影響磁盤性能的問題
檢查存儲賬戶容量，虛擬大小等配置信息，避免由于并發 IO 或是容量配置導致的問題。
如果以上步驟沒有發現明顯問題，但是壓力測試得到的磁盤數據比本文中的數據相差明顯，建議您可以聯系Azure 支持部門，我們很愿意協助您快速定位問題。
立即訪問http://market.azure.cn
