理解及快速測定 Azure 虛擬機器的磁碟效能

隨著越來越多的使用者將生產系統遷移到 Azure 平臺的虛擬機器服務中，Azure 虛擬機器的效能愈發被關注。傳統的資料中心中，我們通常使用 CPU，記憶體，儲存和網路的效能來衡量生產壓力。特別是對於 IO 密集型工作負荷，比如虛擬機器內部執行的 SQL 服務，儲存系統的吞吐容量，往往成為生產系統的瓶頸所在。

Azure 提供了標準儲存和高階儲存兩種儲存服務。針對於生產環境中的 IO 密集型負荷，我們推薦使用高階儲存。標準儲存僅推薦在開發測試環境中使用。針對於具體的高階儲存的介紹，以及虛擬機器儲存的最佳實踐等資訊，建議完成以下閱讀：

高階儲存簡介

Azure 虛擬執行 SQL 服務的最佳實踐

在 SQL 虛擬機器中使用 Azure 高階儲存

然而在現實環境中，由於種種條件所限，很多使用者暫時無法使用高階儲存來達到最佳的儲存效能。本文的目的在於幫助目前仍然使用標準儲存的使用者如何準確理解虛擬機器的儲存效能，從而在發生儲存效能問題時快速有效的從支援部門得到幫助。

首先，由於虛擬機器執行在 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 等工具。

DiskSPD:https://gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223 "https://gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223"

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