Azure 进阶攻略 | 电脑跑分你会，但虚拟机存储性能跑分的正确姿势你造吗？

想学生时代，小编最爱做的就是研究电脑硬件，然后给自己、朋友和童鞋装机。装好后呢？当然要第一时间跑分了！各种跑分软件运行一遍，不断优化，不断测试。终于得到一个满意成绩，截图分享到网上显摆一下。当年为啥就没朋友圈呢ㄟ( ▔, ▔ )ㄏ）

时至今日，研究个人电脑 DIY 的人越来越少，甚至很多电脑已变得看不见摸不着，成了云端运行的虚拟机。但传统不能丢吧，虚拟机的性能到底达标没有，能否满足要求，还是得“跑个分”才知道。

CPU、内存、网络，这些相对都比较容易进行判断和测试，今天小编想带大家了解的是：存储性能方面的问题。尤其是很多童鞋会通过 Azure 虚拟机运行 IO 密集型工作负载，存储将直接影响到整个系统的性能。

首先是几个重点，注！意！啦！

Azure 存储空间的可伸缩性和性能目标

Azure 虚拟机运行在 Azure 平台上，因此存储方面要遵守整个平台有关可伸缩性和性能的目标，如：

单个标准存储帐户总请求率上限为 20,000 IOPS，所有虚拟机磁盘的 IOPS 总数不应超过此限制。

标准层虚拟机的单个磁盘 IOPS 上限约为 500。

单个标准存储帐户中用于生产应用的磁盘不应超过 40 个。

更详细指标点这里查看。

此外对于虚拟机操作内部，不同的应用也有不同的磁盘系统优化方案，例如：

使用虚拟机允许的最大磁盘数和最大磁盘容量构建存储空间。

使用合理的 Interleave 避免 Split IO。

根据实际生产的单个 IO 数据大小规划文件系统簇的大小，例如 SQL 服务，建议使用 64K 的簇。

建个测试环境，试着测试一下

在 Windows 平台，用户常常选择通过文件管理器直接进行文件拷贝来观察磁盘性能。这种测试往往很容易进行。为方便说明，下文测试部分我们在中国东区的数据中心创建了一个服务器，具体的参数为：

服务器大小：Standard_D4

标准存储账户，该账户中仅存储该测试服务器的磁盘，以排除干扰

该服务器未运行任何生产业务。闲置时没有 CPU、内存和磁盘 IO 压力

虚拟机加载的 D 盘为本地 SSD 磁盘

服务器加载 8 块 1TB 数据盘，使用其中 4 块创建存储池并建立 Simple 的虚拟磁盘

在此虚拟磁盘上创建两个简单卷，E 卷的簇大小为 4K，G 卷的簇为 64K

另外使用一个简单磁盘创立 N 卷，簇大小为 4K

同时为了通过文件拷贝的方式进行测试，我们准备了三种不同类型的数据文件：

文件夹 MixFiles 中含有各种随机大小的文件

文件夹 SingleFile 中含有一个 6GB 大小的文件

文件夹 SmallFiles 中含有 200,000 个小文件，每个文件大小为 3KB

使用 Windows 资源管理器直接将所有数据从 N 卷复制到 E 卷，结果如下：



处理随机大小文件时，拷贝性能在 10MB/s 到 25MB/s 间变化；处理单个大文件，性能上升到 40MB/s 以上，但是即便单个文件的拷贝性能也不稳定；处理 200000 个 3KB 大小的小文件时，拷贝性能急剧下降到500KB/s 左右。

多次重复文件拷贝，随着文件系统碎片状态的变化，服务器缓存的使用情况变化等，同样的文件拷贝性能的差异性很大：



Windows 中提供了一个叫做「性能监视器」的工具（Win-R 组合键打开运行对话框，输入 Perfmon.msc 按回车即可打开），可以更详细地检测不同的性能指标，当我们使用 Perfmon 来具体分析单个磁盘的性能时，无论处理哪种类型的文件拷贝，磁盘仍未处于完全忙碌的状态，而磁盘数据吞吐量和 IOPS 都处于不稳定状态！







好奇怪，莫非使用了假的 Azure 虚拟机和存储？

异常结果的原理分析

其实这是文件拷贝操作本身的一些局限导致的，这种方法并不适合用来测试存储性能。原因是：

文件拷贝，特别是 Windows 图形界面下的拷贝过程并没有针对磁盘系统本身进行优化。为了达到磁盘系统最佳性能，需要在存储系统中积累足够的 IO 请求来促使磁盘始终处于忙碌状态。

使用 Windows 文件拷贝引擎拷贝大文件时，默认情况下系统会发起 8 个 1MB 的异步 IO 请求。而在进行小文件拷贝时，除非多线程拷贝，否则很难在存储系统中产生足够的 IO 积压。

多数文件拷贝操作是顺序操作，通常只有在一个文件拷贝完后才会处理下一个文件。这种顺序化的处理会导致文件拷贝的性能远低于存储系统的实际处理能力。

为了加快处理，文件拷贝时 Windows 会尝试使用内核文件缓存机制进行 Buffered IO 处理。这无法正常反应物理存储的处理能力，同时也会受到操作系统内存、缓存管理机制影响。

文件拷贝是一个端对端操作，任何一端的限制都会导致拷贝速率受影响，因此很难隔离瓶颈出现的具体位置。

简而言之：普通的文件拷贝操作还不足以推动存储系统发挥出全部潜力！那么……

正确的测试方法是什么

术业有专攻，存储的性能测试，也需要专门的工具。例如 DiskSPD 或 IOMeter 都是极好的。这些工具通常会使用服务器的 CPU 资源产生多个工作线程，每个线程根据设定的 IO 读或写的比例、IO 请求的大小、顺序读写或随机读写等，可以产生大量并发请求，直接作用于目标存储设备。

以同一个测试服务器为例，通过以下命令分别对于 D、E、F 和 N 卷进行 4K、8K、64K 大小的随机读写 IO压力测试（80% 读操作，20% 写操作）。这些测试运行的命令如下：



限于篇幅，完整的结果就不展示了，仅以 4K 大小的结果为例，是这样的：



根据测试时生成的 Perfmon 日志可以清晰地看到：单个磁盘在进行测试时基本保持在完全忙碌的状态下，并体现出一致的 IO 性能指标 (第一个测试为 4K 读写，第二个为 8K 读写，第三个为 64K 读写，每个测试区间前者为 E 卷，后者为 G 卷)。

IO 为 4K 时，单个磁盘吞吐量 (Disk Bytes/sec)，D 卷和 G 卷 2MB 左右，IOPS（Disk Transfer/sec）约 480。

IO 为 8K 时，单个磁盘吞吐量，D 卷 3.4MB 左右，G 卷约 4MB，IOPS 约 440。

IO 为 64K 时，单个磁盘吞吐量，D 卷 24MB 左右，G 卷约 31MB，IOPS 约 450。

对于同一类测试，G 卷（64K 簇大小）的性能要稍好于 E 卷（4K 簇大小）。






面对这个结果，应该可以安心了吧~ 重点：该记笔记啦

最重要的一点：性能测试必须使用专门的工具，才能得到最准确真实的结果。

另外，虽然 DiskSPD 和 IOMeter 可以模拟不同类型的 IO 请求，但它们同真实生产环境中的 IO 模型还是有一定区别。如果可能，尽可能使用生产环境的真实 IO 来判断当前的存储系统是否满足需求。

如果用户环境中的虚拟机出现类似存储瓶颈的问题，建议通过以下步骤快速排查：

1. 通过 Perfmon 等性能监控工具收集生产环境下的服务器数据，包括内存、CPU、磁盘、网络等。

2. 暂停所有生产压力，使用 DiskSPD 或 IOMeter 等工具进行单纯存储压力测试。

3. 使用 Microsoft Automated Troubleshooting Services 快速自动排查虚拟机内部可能影响磁盘性能的问题。

4. 检查存储账户容量、虚拟大小等配置信息，避免由于并发 IO 或容量配置导致问题。

当然，联系 Azure 24 小时随时待命的专业支持部门也是一种好办法哦！

立即访问http://market.azure.cn