Date: 5月 16, 2022
具有区域冗余存储 (ZRS) 的 Azure 共享磁盘的性能
2021 年 9 月 9 日，微软宣布的普遍可用性Azure 磁盘存储的区域冗余存储 (ZRS) ，包括 Azure 共享磁盘。
有趣的是，您现在可以构建跨可用区 (AZ) 的基于共享存储的故障转移集群实例。由于集群节点位于不同的 AZ，用户现在可以获得 99.99% 的可用性 SLA。 在支持区域冗余存储之前，Azure 共享磁盘仅支持本地冗余存储 (LRS)，将集群部署限制在单个 AZ，如果 AZ 脱机，用户很容易受到中断的影响。
但是，使用 ZRS 部署 Azure 共享磁盘时需要注意一些限制。
- 仅支持高级固态驱动器 (SSD) 和标准 SSD。 不支持 Azure 超级磁盘。
- 带有 ZRS 的 Azure 共享磁盘目前仅在美国西部 2、西欧、北欧和法国中部区域可用
- 高级 SSD Azure 共享磁盘不支持读取和写入磁盘缓存
- 磁盘突发不适用于高级 SSD
- Azure Site Recovery 支持尚不可用。
- Azure 备份仅可通过 Azure 磁盘备份获得。
- 仅支持服务器端加密，目前不支持 Azure 磁盘加密。
我还发现了一个有趣的注释文件.
“除了更多的写入延迟之外，使用 ZRS 的磁盘与使用 LRS 的磁盘相同，它们具有相同的扩展目标。 对磁盘进行基准测试以模拟应用程序的工作负载并比较 LRS 和 ZRS 磁盘之间的延迟。”虽然文档表明 ZRS 会产生一些额外的写入延迟，但由用户决定他们可以预期多少额外的延迟。 一个链接磁盘基准提供文档以帮助指导您进行性能测试。
按照文档中的指导，我使用 DiskSpd 来测量您可能遇到的额外写入延迟。 当然，结果会因工作负载、磁盘类型、实例大小等而异，但这是我的结果。
| 本地冗余存储 (LRS) | 区域冗余存储 (ZRS) | |
| 写 IOPS | 5099.82 | 4994.63 |
| 平均延迟 | 7.830 | 7.998 |
我运行的 DiskSpd 测试使用了以下参数。
diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat 我写到一个带有 ZRS 的 P30 磁盘和一个带有 LRS 的 P30 连接到标准 DS3 v2（4 vcpus，14 GiB 内存) 实例类型。 共享 ZRS P30 还附加到不同 AZ 中的相同实例，并作为共享存储添加到空集群应用程序。
2% 的开销似乎是让您的数据在两个 AZ 上同步分布的合理价格。 但是，我确实想知道如果您将集群应用程序移动到远程节点会发生什么，有效地将您的磁盘放在一个 AZ 中，而将您的实例放在另一个 AZ 中。
这是结果。
| 本地冗余存储 (LRS) | 区域冗余存储 (ZRS) | 从远程 AZ 写入时的 ZRS | |
| 写 IOPS | 5099.82 | 4994.63 | 4079.72 |
| 平均延迟 | 7.830 | 7.998 | 9.800 |
在那种情况下，我测量了 25% 的写入延迟增加。 如果您遇到 AZ 完全故障，存储和实例都将故障转移到辅助 AZ，您根本不应该遇到这种延迟增加。 但是，其他不属于 AZ 范围的故障场景很可能让您的集群应用程序在一个 AZ 中运行，而您的 Azure 共享磁盘在另一个 AZ 中运行。 在这些情况下，您需要尽快将集群工作负载移回与存储位于同一可用区的节点，以避免额外的开销。
微软文档如何启动存储帐户故障转移使用 GRS 时到不同的区域，但在使用区域冗余存储时无法手动启动存储帐户到不同 AZ 的故障转移。 您应该监控您的故障转移集群实例，以确保在集群工作负载移动到其他服务器时收到警报，并计划在安全的情况下尽快将其移回。
您可能会意外地发现自己处于这种情况，但在您执行滚动更新时，在集群应用程序服务器的计划维护期间肯定也会发生这种情况。 意识是帮助您最大限度地减少存储在降级状态下执行的时间的关键。
我希望将来微软允许用户像使用 GRS 一样启动 ZRS 磁盘的手动故障转移。 他们向 GRS 添加该功能的原因是将权力交到用户手中，以防自动故障转移没有按预期发生。 在区域冗余存储的情况下，我可以看到人们希望尝试将存储和应用程序捆绑在一起，确保它们始终在同一个 AZ 中运行，类似于 SIOS DataKeeper 等基于主机的复制解决方案的做法。