[AWS vs Azure] 云计算里AWS和Azure的探究(5) ——EC2和Azure VM磁盘性能分析
云計算里AWS和Azure的探究(5)
——EC2和Azure VM磁盤性能分析
?
在虛擬機創建完成之后，CPU和內存的配置等等基本上是一目了然的。如果不考慮顯卡性能，一臺機器最重要的性能瓶頸就是硬盤。由于無論是EC2還是Azure VM都使用了虛擬機，而存儲盤也是以某種形式存放在磁盤陣列或者NAS設備中，所以磁盤的讀寫性能成為使用云計算虛擬服務器里最重要的考慮因素。這一節我們先不去考慮EC2里面的Elastic Block Store或者Azure里面的Azure Drive的具體實現，而使用免費的HD Tuner，對EC2/Azure里虛擬機的磁盤進行性能分析。
EC2 EBS定義
首先在EC2中，我們創建了一臺Large的服務器，上面運行的是Windows Server 2012。同時在服務器上附加了4塊磁盤，分別如下：
| ? | 大小 | 類型 | 備注 |
| C | 30GB | Standard | Auto-Enable Volume IO = ON，系統盤 |
| D | 50G | Standard | Auto-Enable Volume IO = OFF |
| E | 100G | Provisioned IOPS | IOPS = 1000 |
| F | 200G | Provisioned IOPS | IOPS = 2000 |
?
在這里要選擇Large的原因是因為在EC2的文檔中提到，如果使用Provisioned IOPS卷，最好要使用EBS優化的實例。EBS優化的實例使用優化的配置，提供了專用的EBS 吞吐的能力。這種優化通過最小化EBS IO和你的EC2實例其他流量之間的內容來達到最佳的性能。EBS優化可以讓實例完全用到EBS卷上的IOPS，流量大概在500Mbps到1000Mbps，取決于你使用的實例類型。提供的IOPS卷被設計為一年中99.9%的時間可以提供10%以內的性能。
EBS優化的實例其實只有M1 Large， M1 Extra Large和高內存四倍超大（M2.4xlarge），所以這里我們選擇了Large類型。
另外一個要了解的概念是EBS的類型，EBS有兩種類型，Standard和Provisioned IOPS:
標準卷提供了輕量級或者間隔的IO需求，這些卷大概平均大約提供100 IOPS，在爆發的時候大概到幾百個IOPS，適用于引導盤。
Provisioned IOPS卷設計用于滿足IO需求大的應用，特別是數據庫，在隨機IO訪問時，對存儲性能和一致性非常敏感。你可以在創建卷的時候定義IOPS的數值，當前最大支持到2000 IOPS每個卷。你可以創建多個卷，為應用程序實現成千上萬的IOPS。Provisioned IOPS卷最小10GB，IOPS的值最大為卷大小的十倍。比如1000 IOPS的卷最小是100GB。
這里有一點需要注意的是，要滿足IOPS卷的SLA，需要有一些條件
1，? 這個卷附加到EBS優化的實例上。
2，? 平均的隊列長度至少為1/200 IOPS。
3，? 讀寫操作塊為16KB或更小。例如1000 IOPS每秒可以發送1000個16KB的寫，500個32KB的寫，250個64KB的寫等等。
和標準卷一樣，第一次訪問數據時最多大約有50%的IOPS下降，當訪問之后性能會恢復，所以如果要最大化性能，最好在訪問數據前先把訪問一遍所有的塊。此外快照也會降低IOPS的性能。更詳細的內容可以參考EBS的文檔。http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html
另外還有一個地方需要注意的是Auto-Enable Volume IO，這個東西其實和磁盤性能關系不大，這個意思是如果當磁盤狀態變成”損害”(impaired),那么不要禁止IO操作，自動允許磁盤仍然可以進行IO操作。
Azure VM 定義
在Azure VM中，我們會創建2塊Azure Drive，加上Azure VM自帶的2個驅動器，一臺機器上也有4個驅動器如下：
| ? | 大小 | 緩存 | 備注 |
| C | 30GB | ReadWrite | 系統盤 |
| D | 140G | ReadWrite | 自帶存儲 |
| E | 100G | None | ? |
| F | 100G | ReadWrite | ? |
?
Azure VM由于依然是Preview，所以對磁盤的類型和性能分析的文檔和AWS沒有辦法比。我們所能得知的是，C, E, F盤都是以VHD的形式存儲在Azure的存儲賬戶中，并且附加到虛擬機上。D盤是服務器在創建虛擬機是默認添加的一塊磁盤，可以用于臨時數據的存儲。其中C,E,F都是持久化的存儲，可以創建快照，還可以跨地域備份，而D盤則沒有這些優點。當然，D盤是白送的，EC2上沒有這種D盤可以使用。
接下來，我們將使用HD Tune這個工具對Azure和EC2的磁盤性能進行一個簡單的比較，主要包括磁盤讀寫性能，不同大小文件的讀寫以及隨機讀寫進行比較。首先是將EC2的不同類型磁盤進行比較，接著對Azure VM的磁盤性能進行比較，最后將EC2和Azure的磁盤進行橫向比較。
EC2磁盤性能比較
1, Benchmark
| 磁盤 | 最小傳輸速率(MB/s) | 最大傳輸速率(MB/s) | 平均速率(MB/s) | 訪問時間(ms) | 爆發率（MB/s） | 圖例 |
| C | 42.0 | 56.0 | 50.9 | 6.62 | 57.0 | 圖1 |
| D | 12.2 | 58.9 | 52.8 | 8.00 | 51.2 | 圖2 |
| E | 31.7 | 35.2 | 33.5 | 20.3 | 40.8 | 圖3 |
| F | 32.7 | 40.8 | 33.6 | 19.4 | 40.8 | 圖4 |
?
?
圖 1 Benchmark - EC2 - C – System
?
?
圖 2 BENCHMARK - EC2 - D - Standard
?
圖 3 BENCHMARK - EC2 - E - 1000 IOPS
?
圖 4 BENCHMARK - EC2 - F - 2000 IOPS
從表中的4個驅動器性能可以看出，Standard類型的驅動器明顯要比Provisioned IOPS驅動器傳輸速率要高出許多。標準驅動器的平均傳輸速率在50MB/s左右，而IOPS驅動器只有33MB/s。所以對于要進行短暫快速傳輸的數據，還是使用標準類型會比較好。
2, File Benchmark
| 磁盤 | 順序讀(KB/s) | 順序寫(KB/s) | 4KB隨機讀IOPS | 4KB隨機寫IOPS | 32個4KB隨機讀IOPS | 32個4KB隨機寫IOPS | 圖例 |
| C | 102176 | 42056 | 1828 | 1046 | 16409 | 4316 | 圖5 |
| D | 98794 | 38097 | 2142 | 1301 | 15569 | 4440 | 圖6 |
| E | 41631 | 40365 | 1020 | 1020 | 1019 | 1019 | 圖7 |
| F | 41890 | 34581 | 2040 | 1869 | 2057 | 2040 | 圖8 |
?
?
圖 5 File BENCHMARK - EC2 - C – System
?
圖 6 FILE BENCHMARK - EC2 - D – Standard
?
圖 7 FILE BENCHMARK - EC2 - E – 1000 IOPS
?
圖 8 FILE BENCHMARK - EC2 - F – 2000 IOPS
從上表可以看出，標準類型的磁盤在讀的性能上要遠遠好于IOPS的磁盤讀性能，對于4KB的隨機讀寫，性能也是遠遠好于IOPS類型，但是它的讀寫性能受到外在的影響和干擾嚴重，波動非常巨大。此外標準類型數據的順序讀速度是順序寫速度的將近2倍，讀的速度大約是100MB/s,而寫卻只有35MB/s左右，這和剛才的測試結果也大體一致，不過標準盤號稱的是100IOPS，測試的結果卻遠遠好于他聲稱的數據。對于IOPS盤而言，它的讀寫性能比較平均，速度都在40MB/s左右，不過IOPS卻非常美好地達到了我們設置的要求。對于1000 IOPS的磁盤，讀寫基本上是1020 IOPS，對于2000 IOPS的盤，讀寫基本上是2040。雖然速度上和標準類型的盤在峰值上無法相比，但是由于性能穩定，可以靠譜地實現許多例如數據庫這樣的需求。
Azure VM磁盤性能比較
1, Benchmark
| 磁盤 | 最小傳輸速率(MB/s) | 最大傳輸速率(MB/s) | 平均速率(MB/s) | 訪問時間(ms) | 爆發率（MB/s） | 圖例 |
| C | 8.3 | 36.1 | 15.2 | 30.7 | 208.1 | 圖9 |
| D | 304.9 | 1012.9 | 922.6 | 0.059 | 744.5 | 圖10 |
| E | 9.7 | 15.8 | 15.0 | 3.44 | 10.9 | 圖11 |
| F | 26.0 | 40.5 | 31.5 | 0.962 | 77.4 | 圖12 |
?
?
圖 9 BENCHMARK - Azure - C – System
?
圖 10 BENCHMARK - AZURE - D – Temp
?
圖 11 BENCHMARK - AZURE - E – No Cache
?
圖 12 BENCHMARK - AZURE - F - ReadWrite Cache
Azure的磁盤有一個盤非常有亮點，就是附贈的D盤，這個盤的最小傳輸速率是304.9MB/s，最大速率甚至達到了1012.9MB/s,平均速率居然能達到922.6MB/s，這是2塊SSD Raid 0陣列才能達到的速度啊，這一點上完全秒殺EC2。可惜的是這個盤上的數據不是可持久化的，只能作為臨時的存儲。另外三個盤就真讓人有點捉摸不透了。首先是用作操作系統的C盤，最小傳輸速率只有8.3MB/s,最大也只有36.1MB/s，平均速率是15.2MB/s,這和沒有打開Cache的E盤速度是一致的。也就是說，在Azure storage account里面的VHD文件的訪問性能居然只有可憐的15MB/s。另外C盤的訪問時間居然達到了破天荒的30.7ms，這樣的速度在很多情況下完全無法滿足應用的要求。即使在打開了讀寫緩存的F盤上，速度只有31.5MB/s。
2, File Benchmark
| 磁盤 | 順序讀(KB/s) | 順序寫(KB/s) | 4KB隨機讀IOPS | 4KB隨機寫IOPS | 32個4KB隨機讀IOPS | 32個4KB隨機寫IOPS | 圖例 |
| C | 24003 | 12249 | 2944 | 5910 | 0 | 2041 | 圖13 |
| D | 2353760 | 1911305 | 18938 | 17802 | 70883 | 67622 | 圖14 |
| E | 58760 | 39056 | 188 | 164 | 4688 | 1519 | 圖15 |
| F | 21846 | 13701 | 1059 | 156 | 1227 | 1470 | 圖16 |
?
?
圖 13 File BENCHMARK - AZURE - C - System
?
圖 14 File BENCHMARK - AZURE - D - Temp
?
圖 15 File BENCHMARK - AZURE - E - No Cache
?
?
圖 16 File BENCHMARK - AZURE - F - ReadWrite Cache
基本上性能和之前benchmark的也沒有太大出入，最快的D盤順序讀和順序寫達到了驚人的2353760KB/s和1911305KB/s，2GB/s左右的讀寫速度是我看到過最快的硬盤讀寫了，如果不是SSD，那么肯定是類似于Memory Cache的技術了。不過用于持久化存儲的數據盤速度都非常平平，系統盤只有23MB/s的讀和11MB/s的寫，IOPS的數據還湊合，但是有一個很令人驚訝的數據是32個隨機4KB讀的IOPS居然是0。我測試了好幾遍，都是0。也就是說當我們進行32個4KB隨機讀寫時，這個磁盤應該是hang住了。我不知道這是由于操作系統的原因還是測試軟件的原因，但是事實就是磁盤不工作了。這種狀態很容易導致操作系統失去響應，程序被拖死。希望在Azure的這個feature正式release之后，不會出現這種恐怖的事情。
另外有一點需要注意的是，對于沒有Cache的磁盤，順序讀和順序寫的速度都還可以接受，大概在50MB/s和40MB/s左右，不過IOPS只有可憐的188和164，性能非常一般。對于帶緩存的磁盤，讀寫速度由于需要緩存驗證，也降低到了20M和10M左右。
EBS和Azure Drive磁盤性能比較
根據上面的數據，我們得到了下面的總表：
所謂成也蕭何，敗也蕭何。在所有的磁盤中，性能最好最優異的，就是Azure中的那塊臨時盤。而除此之外，包括系統盤，不帶Cache和帶Cache的磁盤性能，Azure的盤都比EBS要弱，甚至還出現磁盤卡死，IOPS=0的情況。?
要讓Azure VM離開Preview的階段，磁盤的性能必須的得到解決。否則在實際應用中，一定會出現大量的問題。
總結
以上是生活随笔為你收集整理的[AWS vs Azure] 云计算里AWS和Azure的探究(5) ——EC2和Azure VM磁盘性能分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： datasnap的线程池
- 下一篇： 使用Eclipse PDT + Xamp