云计算里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的阶段，磁盘的性能必须的得到解决。否则在实际应用中，一定会出现大量的问题。