你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
当虚拟机连接到弹性 SAN 卷时性能的工作原理
本文旨在说明 Azure 弹性 SAN性能的工作原理，以及弹性 SAN 限制和 Azure 虚拟机 (VM) 限制两者结合后会对工作负载的性能产生怎样的影响。
性能的工作原理
Azure 虚拟机具有每秒输入/输出操作数 (IOPS) 和吞吐量性能限制，这些限制由虚拟机的类型和大小决定。 弹性 SAN 具有性能池，可以分配给它的每个卷。 弹性 SAN 卷可以附加到虚拟机，且每个卷都拥有自己的 IOPS 和吞吐量限制。
当应用程序所请求的 IOPS 或吞吐量大于为虚拟机或附加卷分配的 IOPS 或吞吐量时，应用程序的性能会达到瓶颈。 达到瓶颈后，应用程序将性能欠佳，并可能会遇到延迟时间增加等负面后果。 弹性 SAN 的主要优势之一是能够按需自动预配 IOPS。 SAN 的所有卷之间会共享其 IOPS，因此当工作负载达到峰值时，即可不受限制或产生额外成本来进行处理。 本文介绍此预配的工作原理。
Azure 弹性 SAN性能
弹性 SAN 的三个属性决定了其性能：总容量、IOPS 和吞吐量。 为了获得最佳性能，SAN 应与预配的 VM 位于同一区域。
容量
弹性 SAN 的总容量由两种不同的容量确定：基本容量和附加容量。 增大基本容量也会增大 SAN 的 IOPS 和吞吐量，但比增大附加容量的成本更高。 增大附加容量不会增大 IOPS 或吞吐量。
IOPS
每增加 1 TiB 基本容量，弹性 SAN 的 IOPS 就会增大 5,000。 因此，如果你有一个基本容量为 6 TiB 的弹性 SAN，该 SAN 仍可提供高达 30,000 的 IOPS。 无论该 SAN 是有 50 TiB 的附加容量还是 500 TiB 的附加容量，它始终会提供 30,000 IOPS，因为 SAN 的性能只取决于基本容量。 弹性 SAN 的 IOPS 分布在其所有卷中。
吞吐量
每增加 1 TiB 基本容量，弹性 SAN 的吞吐量就会增大 200 MB/秒。 因此，如果你有一个基本容量为 6 TiB 的弹性 SAN，该 SAN 仍可提供高达 1200 MB/秒的吞吐量。 无论该 SAN 是有 50 TiB 还是 500 TiB 的附加容量，它始终会提供 1200 MB/秒的吞吐量，因为 SAN 的性能只取决于基本容量。 弹性 SAN 的吞吐量分布在其所有卷中。
弹性 SAN 卷
单个卷的性能取决于其容量。 每增加 1 GiB 容量，卷的最大 IOPS 就会增大 750，最高可达 80,000 IOPS。 每增加 1 GiB 容量，最大吞吐量就会增大 60 MB/秒，最高可达 1,280 MB/秒。 卷至少需要 107 GiB 容量才能使用 80,000 IOPS。 卷至少需要 22 GiB 容量才能使用最大 1,280 MB/秒的吞吐量。 所有卷的组合 IOPS 和吞吐量不能超过 SAN 的 IOPS 和吞吐量。
配置示例
本文每个示例场景中的弹性 SAN 均使用以下配置：
| 资源 | 容量 | IOPS |
|---|---|---|
| 弹性 SAN | 27 TiB | 135,000（已预配） |
| AKS SAN 卷 | 3 TiB | 最大 80,000 |
| 工作负载 1 SAN 卷 | 10 TiB | 最大 80,000 |
| 工作负载 2 SAN 卷 | 4 TiB | 最大 80,000 |
| 工作负载 3 SAN 卷 | 2 TiB | 最大 80,000 |
示例方案
以下示例场景描述了弹性 SAN 如何处理性能分配。 为了获得最佳性能，VM 和 SAN 需要位于同一区域中。
典型工作负载
| 工作负荷 | 请求的 IOPS | 提供的 IOPS |
|---|---|---|
| AKS 工作负载 | 3,000 | 3,000 |
| 工作负载 1 | 10,000 | 10,000 |
| 工作负载 2 | 8,000 | 8,000 |
| 工作负载 3 | 20,000 | 20,000 |
在此场景中，无论是在虚拟机还是 SAN 级别都没有出现限制。 SAN 本身有 135,000 IOPS，每个卷的空间足以提供 80,000 IOPS，因此 SAN 可提供足够多的 IOPS，没有超过虚拟机的 IOPS 限制，请求的 IOPS 总数为 41,000。 因此，工作负载全部执行，没有任何限制。
单个工作负荷峰值
| 工作负荷 | 请求的 IOPS | 提供的 IOPS | 峰值时间 |
|---|---|---|---|
| AKS 工作负载 | 2,000 | 2,000 | 空值 |
| 工作负载 1 | 10,000 | 10,000 | 空值 |
| 工作负载 2 | 10,000 | 10,000 | 空值 |
| 工作负载 3 | 80,000 | 80,000 | 上午 9:00 |
这种情况下不会出现限制。 工作负载 3 在上午 9 点达到峰值，请求 80,000 IOPS。 其他工作负荷均未达到峰值，并且 SAN 具有足够的可用 IOPS 来分发到工作负荷，因此没有出现性能限制。
通常，这是 SAN 共享工作负载的理想配置。 最好有足够的性能来处理工作负载的正常操作以及偶尔出现的峰值。
所有工作负荷峰值
| 工作负荷 | 请求的 IOPS | 提供的 IOPS | 峰值时间 |
|---|---|---|---|
| AKS 工作负载 | 5,000 | 5,000 | 上午 9:00 |
| 工作负载 1 | 40,000 | 21,000 | 上午 9:01 |
| 工作负载 2 | 45,000 | 45,000 | 上午 9:00 |
| 工作负载 3 | 64,000 | 64,000 | 上午 9:00 |
了解在最糟糕的场景下，即所有工作负载同时达到峰值时，SAN 的行为模式很重要。
在此场景中，所有工作负载几乎在同时达到峰值。 此时，所有工作负载共计请求的 IOPS (64,000 + 45,000 + 40,000 + 5,000) 超过了 SAN 级别预配的 IOPS (135,000)。 因此，工作负载性能受限。 限制采取谁先到达峰值先限制谁的原则，因此当已达到最大容量后，无论哪个工作负载再请求 IOPS 也不会得到更多性能。 在此场景中，工作负载 1 在其他工作负载之后请求了 40,000 IOPS，此时 SAN 已将其可用的大多数 IOPS 都分配了出去，因此只提供了剩余的 IOPS。
