隨著越來越多的用戶將生產(chǎn)系統(tǒng)遷移到 Azure 平臺的虛擬機服務中，Azure 虛擬機的性能愈發(fā)被關注呵哨。傳統(tǒng)的數(shù)據(jù)中心中泉坐，我們通常使用 CPU，內(nèi)存，存儲和網(wǎng)絡的性能來衡量生產(chǎn)壓力溉箕。特別是對于 IO 密集型工作負荷晦墙，比如虛擬機內(nèi)部運行的 SQL 服務，存儲系統(tǒng)的吞吐容量肴茄，往往成為生產(chǎn)系統(tǒng)的瓶頸所在晌畅。
Azure 提供了標準存儲和高級存儲兩種存儲服務。針對于生產(chǎn)環(huán)境中的 IO 密集型負荷寡痰，我們推薦使用高級存儲抗楔。標準存儲僅推薦在開發(fā)測試環(huán)境中使用。針對于具體的高級存儲的介紹拦坠，以及虛擬機存儲的最佳實踐等信息谓谦，建議完成以下閱讀：
然而在現(xiàn)實環(huán)境中，由于種種條件所限贪婉，很多用戶暫時無法使用高級存儲來達到最佳的存儲性能反粥。本文的目的在于幫助目前仍然使用標準存儲的用戶如何準確理解虛擬機的存儲性能，從而在發(fā)生存儲性能問題時快速有效的從支持部門得到幫助疲迂。
首先才顿，由于虛擬機運行在 Azure 平臺，我們需要了解Azure 存儲空間可伸縮性和性能目標：
單個標準存儲帳戶總請求率上限為 20,000 IOPS尤蒿，所有虛擬機磁盤的 IOPS 總數(shù)不應超過此限制郑气。
標準層虛擬機的單個磁盤 IOPS 上限約為 500。
單個標準存儲帳戶中用于生產(chǎn)應用的磁盤不應超過 40 個
其次腰池，針對于虛擬機操作內(nèi)部尾组，不同的應用也有不同的磁盤系統(tǒng)優(yōu)化方案。例如示弓，對于 Windows 平臺讳侨，我們通常使用 Storage Space 來盡可能分散 IO 請求到不同的硬件設備來提升存儲帶寬：
使用虛擬機允許的最大磁盤數(shù)和最大磁盤容量構建存儲空間
使用合理的 interleave 避免 Split IO
根據(jù)實際生產(chǎn)的單個 IO 數(shù)據(jù)大小規(guī)劃文件系統(tǒng)簇的大小，例如 SQL 服務奏属，建議使用 64K 的簇
在理解了存儲系統(tǒng)的一些基本概念之后跨跨，下一步我們需要通過合理的方法衡量虛擬機的磁盤性能。
在 Windows 平臺囱皿，用戶常常選擇通過文件管理器直接進行文件拷貝來觀察磁盤性能勇婴。這種測試往往很容易進行。同時嘱腥，在用戶界面上也有圖形化的吞吐量顯示耕渴。然而，文件拷貝并不是一個測試存儲性能的合理的方法：
文件拷貝齿兔，特別是 Windows 圖形界面的拷貝過程并沒有針對磁盤系統(tǒng)本省進行優(yōu)化橱脸。為了達到磁盤系統(tǒng)的最佳性能窄做，我們需要在存儲系統(tǒng)中積累足夠的 IO 請求來促使磁盤始終處于一個忙碌狀態(tài)。
當我們使用 Windows 文件拷貝引擎拷貝大文件時慰技，缺省情況下，系統(tǒng)會發(fā)起 8 個 1MB 的異步 IO 請求组砚。而在進行小文件拷貝時吻商，除非通過多線程拷貝的方式，否則很難在存儲系統(tǒng)中產(chǎn)生足夠的 IO 積壓糟红。
多數(shù)的文件拷貝操作是順序操作艾帐。通常只有在一個文件拷貝完成后，才會處理下一個文件盆偿。這種順序化的處理會導致文件拷貝的性能遠遠低于實際存儲系統(tǒng)的處理能力柒爸。
為了加快文件處理，在進行文件拷貝時事扭，Windows 會嘗試使用內(nèi)核的文件緩存機制進行 buffered IO 處理捎稚。這一方面無法正常反應物理存儲的處理能力，同時也會收到操作系統(tǒng)的內(nèi)存和 Cache 管理的影響求橄。文件拷貝時今野，如果使用 Perfmon 等工具收集到的實際磁盤的壓力數(shù)據(jù)，和圖形中的拷貝速率曲線比較時罐农，往往有較大的差異条霜。
文件拷貝是一個端對端的操作。任何一端的限制都會導致拷貝的速率受影響涵亏。因此宰睡，很難隔離瓶頸出現(xiàn)的具體位置。
為方便說明气筋，我在中國東區(qū)的數(shù)據(jù)中心創(chuàng)建了一個服務器拆内，具體的參數(shù)為：
服務器大小: Standard_D4
標準存儲賬戶，該賬戶中僅存儲該測試服務器的磁盤以排除干擾
該服務器未運行任何生產(chǎn)業(yè)務宠默。閑置時沒有 CPU ,內(nèi)存和磁盤 IO 的壓力
虛擬機加載的 D 盤為本地 SSD 磁盤矛纹。
服務器加載 8 塊 1TB 數(shù)據(jù)盤，使用其中 4 塊創(chuàng)建存儲池并建立 Simple 的虛擬磁盤光稼。
在此虛擬磁盤上創(chuàng)建兩個簡單卷或南，E 卷的簇大小為 4K，G 卷的簇為 64K
另外使用一個簡單磁盤創(chuàng)立 N 卷艾君，簇大小為 4K采够。
為進行文件拷貝測試，我們創(chuàng)建了 3 種不同類型的數(shù)據(jù)文件：
文件夾 MixFiles 中含有各種隨機大小的文件
文件夾 SingleFile 中含有一個 6GB 大小的文件
文件夾 SmallFiles 中含有 200,000 個小文件冰垄，每個文件大小為 3KB
從下圖中可以看到根據(jù)文件的類型不同蹬癌，整個過程分為三個階段，
系統(tǒng)在處理隨機大小文件時，拷貝的性能在 10MB/s 到 25MB/s 之間變化逝薪。
處理單個大文件的拷貝隅要，性能上升到 40MB/s 以上，但是即便是對單個文件董济，拷貝性能也不穩(wěn)定步清。
處理 200000 個 3KB 大小的小文件時，拷貝性能急劇下降到 500KB/s 左右虏肾。
如果我們多次重復文件的拷貝過程廓啊，隨著文件系統(tǒng)碎片狀態(tài)的變化，服務器 Cache 的使用情況變化等等封豪，同樣的文件拷貝性能的差異性很大谴轮。
拋開用戶界面上的性能指示，當我們使用 Perfmon 來具體分析單個磁盤的性能時吹埠，很明顯第步，無論處理那種類型的文件拷貝，磁盤仍然未處于完全忙碌的狀態(tài)缘琅。而磁盤的數(shù)據(jù)吞吐量和 IOPS 都處于不穩(wěn)定狀態(tài)
根據(jù)以上的分析和測試我們可以確定雌续，使用文件拷貝的方式無法科學地衡量磁盤的性能。
在現(xiàn)實中胯杭，為了得到穩(wěn)定的磁盤數(shù)據(jù)驯杜，通常建議使用 DiskSPD 或是 IOMeter 等工具。
IOMeter:http://www.iometer.org/ "http://www.iometer.org/"
這些工具大多數(shù)都是使用服務器的 CPU 資源產(chǎn)生多個工作線程做个，每個線程根據(jù)設定的 IO 讀或?qū)懙谋壤胄模琁O 請求的大小，順序讀寫或隨機讀寫等居暖，產(chǎn)生大量的并發(fā)請求顽频，直接作用于目標存儲設備。
以同一個測試服務器為例太闺，通過以下命令分別對于 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 大小的結(jié)果總結(jié)如下:
同時，根據(jù)測試時生成的 Perfmon 日志钞澳，我們可以清晰地看到單個磁盤在進行測試時基本上保持在完全忙碌的狀態(tài)怠惶，并體現(xiàn)出一致的 IO 性能指標(第一個測試為 4K 讀寫，第二個為 8K 讀寫轧粟，第三個為 64K 讀寫策治，每個測試區(qū)間前者為 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 請求，但他們同真實的生產(chǎn)環(huán)境中的 IO 模型還是有一定區(qū)別的闷盔。如果可能弯洗，盡可能使用生產(chǎn)環(huán)境的真實 IO 來判斷當前的存儲系統(tǒng)是否滿足需求。
如果用戶環(huán)境中的虛擬機出現(xiàn)類似存儲瓶頸的問題逢勾，建議您可以通過以下步驟快速排查：
通過 Perfmon 等性能監(jiān)控工具收集生產(chǎn)環(huán)境下的服務器數(shù)據(jù)牡整，包括內(nèi)存，CPU溺拱，磁盤逃贝，網(wǎng)絡等等方面。
暫停所有的生產(chǎn)壓力迫摔，使用 DiskSPD 或 IOMeter 等工具進行單純存儲壓力測試
使用Microsoft Automated Troubleshooting Services沐扳，來快速自動排查虛擬機內(nèi)部可能影響磁盤性能的問題
檢查存儲賬戶容量，虛擬大小等配置信息句占，避免由于并發(fā) IO 或是容量配置導致的問題沪摄。
如果以上步驟沒有發(fā)現(xiàn)明顯問題，但是壓力測試得到的磁盤數(shù)據(jù)比本文中的數(shù)據(jù)相差明顯纱烘，建議您可以聯(lián)系Azure 支持部門杨拐，我們很愿意協(xié)助您快速定位問題。
立即訪問http://market.azure.cn
