你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文提供有关 Azure VMware 解决方案数据存储设计和大小调整（与 Azure NetApp 文件配合使用时）的性能注意事项。 此内容适用于虚拟化管理员、云架构师或存储架构师。
本文中概述的注意事项有助于通过优化成本效益从应用程序实现最高级别的性能。
Azure NetApp 文件为 Azure VMware 解决方案提供即时可缩放、高性能和高度可靠的存储服务。 这些测试包括 Azure VMware 解决方案和 Azure NetApp 文件之间的各种不同配置。 这些测试能够实现每秒超过 10,500 MiB/s 的吞吐量，并达到超过 585,000 个输入/输出操作（IOPS），仅使用四个 Azure VMware 方案/ESXi 主机和一个 Azure NetApp 文件容量池。
使用 Azure NetApp 文件为 Azure VMware 解决方案实现更高的存储性能
在一个服务级别预配多个可能更大的数据存储可能会降低成本，同时提供更高的性能。 原因是来自 Azure VMware 解决方案的主机通过多个 TCP 流将负载分布到多个数据存储上。 可以使用 Azure VMware 解决方案 TCO 估算器的 Azure NetApp 文件数据存储，通过上传 RVTools 报表或输入手动平均 VM 大小来计算潜在的成本节省。
确定如何配置数据存储时，从管理的角度来看，最简单的解决方案是创建单个 Azure NetApp 文件数据存储,装载数据存储，并将所有 VM 放入其中。 此策略适用于许多情况，直到需要更多吞吐量或 IOPS。 为了识别不同的边界，测试使用了综合工作负荷生成器（程序 fio）来评估其中每个方案的工作负荷范围。 此分析可帮助确定如何将 Azure NetApp 文件卷预配为数据存储，以最大程度地提高性能和优化成本。
开始之前
关于 Azure NetApp 文件性能数据，请参阅：
-
在 Azure VMware 解决方案主机上，每个 NFS 数据存储都会建立一个单一的网络连接，就像在第 6 节中引用的 Linux 测试中使用
nconnect=1优化选项那样。 这一事实是了解 Azure VMware 解决方案如何在跨多个数据存储时很好地提升性能的关键。
测试方法
本部分介绍用于测试的方法。
测试方案和迭代
此测试遵循“四角”方法，该方法包括每个顺序和随机输入/输出 (IO) 的读取操作和写入操作。 测试的变量包括一对多 Azure VMware 解决方案主机、Azure NetApp 文件数据存储、VM（每个主机）和每个 VM 的 VM 磁盘 (VMDK)。 已选择以下缩放数据点来查找给定方案的最大吞吐量和 IOPS：
- 调整每个 VMDK 的规模，每个都位于其自己的数据存储上，供单个 VM 使用。
- 在单个 Azure NetApp 文件数据存储上缩放每个主机的 VM 数。
- 缩放 Azure VMware 解决方案主机的数量，每个主机带有共享单个 Azure NetApp 文件数据存储的 VM。
- 缩放 Azure NetApp 文件数据存储的数量，每个数据存储带有在 Azure VMware 解决方案主机中平均分布的一个 VMDK。
通过测试小型与大型块操作，并遍历顺序和随机工作负载，确保对计算、存储和网络堆栈中的所有组件进行直至"边缘"的全面测试。 为通过块大小与随机化覆盖四个边界条件，采用以下常见组合：
- 64 KB 顺序测试
- 在大型文件流式处理任务中，读取和写入通常使用大块大小，此外，这也是 MSSQL 默认的区块大小。
- 大型块测试通常生成最高吞吐量（以 MiB/s 为单位）。
- 8 KB 随机测试
- 此设置是数据库软件的常用块大小，包括来自 Microsoft、Oracle 和 PostgreSQL 的软件。
- 小块测试通常生成最高数量的 IOPS。
注意
本文仅介绍 Azure NetApp 文件的测试。 不包括 Azure VMware 解决方案随附的 vSAN 存储。
环境详细信息
本文的结果是使用以下环境配置实现的：
- Azure VMware 解决方案主机：
- 大小：AV36
- 主机计数：4
- VMware ESXi 版本 7u3
- Azure VMware 解决方案私有云连接：UltraPerformance 网关，支持 FastPath
- 来宾 VM：
- 操作系统：Ubuntu 20.04
- CPU/内存：16 vCPU/64 GB 内存
- Azure VMware 解决方案 vSAN 数据存储上具有 16 GB OS 磁盘的虚拟 LSI SAS SCSI 控制器
- 测试 VMDK 的准虚拟 SCSI 控制器
- LVM/磁盘配置：
- 每个磁盘一个物理卷
- 每个物理卷一个卷组
- 在每个卷组中设置一个逻辑分区
- 每个逻辑分区一个 XFS 文件系统
- Azure VMware 解决方案到 Azure NetApp 文件协议：NFS 版本 3
- 工作负荷生成器：
fio版本 3.16 - Fio 脚本：
fio-parser
测试结果
本部分介绍所执行测试的结果。
单 VM 缩放
在 Azure VMware 解决方案虚拟机上配置由数据存储提供的存储时，您应考虑文件系统布局的影响。 配置分布在多个数据存储中的多个 VMDK 可提供最高可用带宽量。 配置放置在单个数据存储上的一对多 VMDK 可确保在备份和 DR 操作方面最简单，但代价是降低性能上限。 本文中提供的经验数据可帮助你做出决策。
为了最大限度地提高性能，通常跨多个 VMDK 缩放单个 VM，并将这些 VMDK 放置在多个数据存储中。 当单个虚拟机（仅含有一个或两个 VMDK）通过单一 TCP 连接挂载至特定 Azure VMware 解决方案主机时，其性能可能受单个 NFS 数据存储的限制。
例如，工程师通常会为数据库日志预配一个 VMDK，然后为数据库文件预配多个 VMDK。 使用多个 VMDK 时，有两个选项。 第一个选项是将每个 VDMK 用作单个文件系统。 第二种方案是采用 LVM、MSSQL 文件组或 Oracle ASM 等存储管理工具，通过跨 VMDK 的条带化实现 I/O 均衡。 当 VMDK 用作单个文件系统时，跨多个数据存储分配工作负荷是手动工作，可能很麻烦。 使用存储管理实用工具将文件分散到 VMDK，可实现工作负荷伸缩性。
如果在多个磁盘上进行条带化，请确保备份软件或灾难恢复软件支持同时备份多个虚拟磁盘。 由于单个写入分布在多个磁盘上，文件系统需要在快照或备份操作期间确保磁盘处于“冻结”状态。 大多数现代文件系统包括冻结或快照操作，例如 xfs（xfs_freeze）和 NTFS（卷影副本），备份软件可以利用这些操作。
为了了解单个 Azure VMware 解决方案 VM 在添加更多虚拟磁盘时的缩放情况，使用一个、两个、四个和八个数据存储（每个数据存储包含单个 VMDK）执行测试。 下图显示了单个磁盘平均约为 73,040 IOPS（从 100% 写入/0% 读取缩放到 0% 写入/100% 读取）。 当此测试增加到两个驱动器时，性能提高了 75.8%，达到 128,420 IOPS。 当驱动器数量增至四个时，开始出现收益递减现象，即单个按测试规模配置的虚拟机所能达到的推送性能开始降低。 观察到的峰值 IOPS 为 147,000 IOPS，随机读取 100%。
单主机缩放 – 单数据存储
从单一主机向单一数据存储增加执行 I/O 操作的 VM 数量时，扩展性表现不佳。 这一事实是由于单个网络流造成的。 当特定工作负载达到性能峰值时，其成因往往是：通过单一 TCP 连接访问主机上的单个 NFS 数据存储时，全程仅使用单一队列进行数据传输。 当采用 8KB 块大小时，从单个含单块 VMDK 的 VM 扩展至四台含 16 块 VMDK 的 VM（每台 4 块，全部位于同一数据存储），总 IOPS 提升 3%-16%。
将大型块工作负荷的块大小增加到 64 KB 后，结果相当可观，在单个 VM 和单个 VMDK 的情况下，达到了 2148 MiB/s 的峰值，而在 4 个 VM 和 16 个 VMDK 的情况下，则达到了 2138 MiB/s。
单主机扩展 – 多数据存储库
从单个 Azure VMware 解决方案主机的上下文中，单个数据存储允许 VM 驱动约 76,000 IOPS，将工作负荷分散在两个数据存储之间使平均总吞吐量增加了 76%。 当从两个数据存储扩展至四个时，性能提升 163%（相较于单个数据存储，从两个扩展至四个时提升 49%），具体增长趋势见下图。 尽管仍有性能提升，但增长到超过八个数据存储显示回报会减少。
多主机扩展 – 单个数据存储库
单个主机上的单个数据存储实现了超过 2000 MiB/s 的 64KB 顺序读写吞吐量。 在所有四台主机上分配相同的工作负荷会产生 135% 的峰值增益，从而驱动超过 5000 MiB/s。 此结果可能表示单个 Azure NetApp 文件卷吞吐量性能的上限。
将块大小从 64 KB 减少到 8 KB，并重新运行相同的迭代会导致 4 个 VM 生成 195,000 IOPS，如下图所示。 主机数量和数据存储数量的增加导致网络流的数量增加，因此性能也随之扩展。 通过把主机数量与数据存储数量相乘来缩放，提升性能，因为网络流量的数量是主机数量与数据存储数量的乘积因素。
多主机扩展 – 多数据存储库
单个数据存储配合分布在四个主机上的四台 VM，实现了超过 5000 MiB/s 的 64K 顺序 I/O 吞吐量。 对于更苛刻的工作负荷，每个 VM 将移动到专用数据存储，总共产生超过 10,500 MiB/s，如下图所示。
对于小块随机工作负荷，单个数据存储生成了 195,000 个随机 8 KB IOPS。 扩展到四个数据存储库，产生了超过 530,000 个随机 8K IOPS。
影响和建议
本部分讨论为何将 VM 分散到多个数据存储具有显著的性能优势。
如测试结果所示，Azure NetApp 文件的性能功能非常丰富：
- 测试表明，单个数据存储可从四主机配置中驱动平均约 148,980 次 8KB IOPS，或实现约 4147 MiB/s 的 64KB IOPS 吞吐量（该数值为所有读写比例测试的平均值）。
- 一个数据存储上一个 VM –
- 如果单个 VM 可能需要超过约 75K 8 KB IOPS 或约 1700 MiB/s，可将文件系统分散到多个 VMDK 上，以缩放 VM 存储性能。
- 多个数据存储的一个 VM – 跨 8 个数据存储的单个 VM 最多实现约 147,000 8 KB IOPS 或约 2786 MiB/s，块大小为 64 KB。
- 一个主机 - 如果每个主机至少使用 4 个 VM，以及至少 4 个 Azure NetApp 文件数据存储，则每个主机能够支持平均约 198,060 8 KB IOPS 或大约 2351 MiB/s。 因此，您可以选择在为最大化潜力爆发的性能预配足够数据存储与管理和成本的复杂性之间进行权衡。
建议
如果单个数据存储的性能功能不足，请将 VM 分散到多个数据存储，以进一步扩展。 简单性通常是最好的，但有时性能和可伸缩性会使有限的复杂性变得合理。
四个 Azure NetApp 文件数据存储为大型顺序 IO 提供最多 10 GBps 的可用带宽，或者提供高达 500K 8K 随机 IOPS 的功能。 尽管一个数据存储可能足以满足许多性能需求，但为了获得最佳性能，请从至少四个数据存储开始。
为实现精细化的性能调优，Windows 和 Linux 客户操作系统均支持跨多磁盘的条带化配置。 因此，应将文件系统条带化到分布在多个数据存储中的多个 VMDK。 但是，如果应用程序快照一致性是个问题，并且无法使用 LVM 或存储空间来克服，请考虑从客户操作系统装载 Azure NetApp Files 或调查应用级别的扩展，其中 Azure 有许多出色的选项。
如果在多个磁盘上进行条带化，请确保备份软件或灾难恢复软件支持同时备份多个虚拟磁盘。 由于单个写入的数据分布在多个磁盘上，文件系统需要在快照或备份操作期间确保磁盘被“冻结”。 大多数现代文件系统包括冻结或快照操作，例如 xfs (xfs_freeze) 和 NTFS（卷影副本），备份软件可以利用这些操作。
由于 Azure NetApp Files 按容量池中的预配容量而非分配的容量（数据存储）进行计费，因此，例如对于 4x20TB 的数据存储或 20x4TB 的数据存储，您将支付相同的费用。 如果需要，可以按需调整数据存储的容量和性能，通过 Azure API/控制台动态进行。
例如，在接近财年结束时，你会发现在标准数据存储上需要更多的存储性能。 可以将数据存储的服务级别增加一个月，使这些数据存储上的所有 VM 都具有更高的性能，同时在较低的服务级别维护其他数据存储。 不仅节省成本，而且通过在每个数据存储与每个 AVS 主机之间的更多 TCP 连接之间分散工作负荷来获得更高的性能。
可以通过 vCenter Server 或 Azure API/控制台监视数据存储指标。 在 vCenter Server 中，只要在数据存储上启用存储 IO 控制指标集合，就可以在性能/高级图表中监视数据存储的聚合平均 IOPS。 Azure API 和控制台提供用于在数据存储级别衡量工作负荷的 WriteIops、ReadIops、ReadThroughput 和 WriteThroughput 等指标。 使用 Azure 指标，您可以设置带有操作的警报规则，以便通过 Azure 函数、网络钩子或其他方式自动调整数据存储大小。