Research in the cloud and Azure AWS (5)
--EC2 and Azure VM disk performance analysis
After the virtual machine is created, CPU and memory configuration, etc. is basically straightforward. If you do not consider the graphics performance, a machine most important performance bottleneck is the hard drive. Since both EC2 or Azure VM uses a virtual machine, while the disk is stored in a storage disk array or NAS devices in some form, so the disk read and write performance of virtual server cloud computing has become the most important consideration. In this section we first do not consider EC2's Elastic Block Store inside or inside the concrete realization Azure Azure Drive, and use the free HD Tuner, on the EC2 / Azure in the virtual machine's disk performance analysis.
EC2 EBS defined
First, EC2, we have created a Large servers, running above is Windows Server 2012. While four additional disks on the server, are as follows:
|
|
size |
Types of |
Remark |
| C |
30GB |
Standard |
Auto-Enable Volume IO = ON, system disk |
| D |
50G |
Standard |
Auto-Enable Volume IO = OFF |
| E |
100G |
Provisioned IOPS |
IOPS = 1000 |
| F |
200G |
Provisioned IOPS |
IOPS = 2000 |
The reason here is because you want to select Large EC2 mentioned in the document, if Provisioned IOPS volumes, it is best to use an instance EBS optimization. Examples of optimization EBS using an optimized configuration, provides a dedicated EBS throughput capacity. This optimization to achieve the best performance by minimizing content between EBS IO EC2 instance and your other traffic. EBS optimization can make full use IOPS instance on an EBS volume, flow rate at about 500Mbps to 1000Mbps, depending on the instance type you are using. IOPS volumes are designed to provide a 99.9% of the time of year can provide performance within 10%.
EBS-optimized instances in fact, only M1 Large, M1 Extra Large four times as large and high memory (M2.4xlarge), so here we have chosen the Large type.
Another concept is to understand the type of EBS, EBS, there are two types, Standard and Provisioned IOPS:
Standard volume provides a lightweight or IO demand interval, the volumes probably provide an average of about 100 IOPS, at the time of the outbreak probably to several hundred IOPS, applicable to the boot disk.
Provisioned IOPS volumes are designed to meet the needs of large IO applications, particularly databases, when accessed at random IO, very sensitive to storage performance and consistency. You can define the value of the IOPS volume creation time, the current maximum support to 2000 IOPS per volume. You can create multiple volumes, to achieve tens of thousands of IOPS for the application. Provisioned IOPS minimum volume 10GB, the maximum value of ten times the volume size IOPS. 1000 IOPS such minimum volume is 100GB.
One thing to note here is that, to meet the SLA IOPS volumes, need to have some conditions
1, attached to this volume instance EBS optimization.
2, the average queue length of at least 1/200 IOPS.
3, a block read and write operations 16KB or less. 1000 IOPS per second can be transmitted, for example, to write the 1000 16KB, 32KB write 500 and write 250 64KB like.
And standard volume as up to about 50% of IOPS fell for the first time access to data, when access will be restored performance, so if you want to maximize performance, the best first visit again before accessing the data of all the blocks. In addition snapshots will reduce IOPS performance. More details can refer to the EBS documents. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html
There is also a place to note that the Auto-Enable Volume IO, and disk performance this thing is actually little to do, this means that if and when the disk status to " harm " ( impaired), then do not prohibit IO operation, the disk is automatically allowed IO can still operate.
Azure VM definitions
In Azure VM, we will create two Azure Drive, Azure VM comes together with two drives, a machine has four drives are as follows:
|
|
size |
Cache |
Remark |
| C |
30GB |
ReadWrite |
system disk |
| D |
140G |
ReadWrite |
It comes with storage |
| E |
100G |
None |
|
| F |
100G |
ReadWrite |
|
Azure VM is still due Preview, so there is no way to compare documents and AWS type and disk performance analysis. We can learn is that, C, E, F disk is stored in the form of VHD to Azure storage account, and attached to the virtual machine. D drive is to create a virtual machine server is added to a disk by default, it can be used to store temporary data. Where C, E, F are persistent storage, you can create a snapshot, you can also back up cross-regional, and D drive do not have these advantages. Of course, the disc D is given away, this is not the EC2 disc D may be used.
Next, we will use this tool HD Tune disk performance on Azure and EC2 are a simple comparison, including read and write and random read and write disk read and write performance, different size of the file comparison. First, the different types of disks EC2 comparing Next, Azure VM running disk performance is compared, the final disk EC2 and Azure horizontal comparison.
EC2 disk performance comparison
1, Benchmark
| Disk |
Minimum transmission rate (MB / s) |
The maximum transfer rate (MB / s) |
The average rate (MB / s) |
Access time (ms) |
Outbreak rate (MB / S ) |
legend |
| C |
42.0 |
56.0 |
50.9 |
6.62 |
57.0 |
figure 1 |
| D |
12.2 |
58.9 |
52.8 |
8.00 |
51.2 |
figure 2 |
| E |
31.7 |
35.2 |
33.5 |
20.3 |
40.8 |
image 3 |
| F |
32.7 |
40.8 |
33.6 |
19.4 |
40.8 |
Figure 4 |
FIG 1 Benchmark - EC2 - C - System
FIG 2 BENCHMARK - EC2 - D - Standard
FIG 3 BENCHMARK - EC2 - E - 1000 IOPS
FIG 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的阶段，磁盘的性能必须的得到解决。否则在实际应用中，一定会出现大量的问题。
转载于:https://www.cnblogs.com/licheng/p/3538483.html