Azure NetApp 文件服务卷硬配额方式的更改

Azure NetApp 文件服务从最初开始就一直使用容量池预配和自动增长机制。 Azure NetApp 文件卷是在所选层和大小的、客户预配的底层容量池中精简预配的。 卷大小（配额）用于提供性能和容量，配额可随时动态调整。 此行为意味着，卷配额目前是用于控制卷带宽的性能杠杆。 目前，当容量占满时，底层容量池会自动增长。

更改卷硬配额的原因

许多客户指出初始行为存在三个主要挑战：

• 使用 OS 空间或容量监视工具时，VM 客户端看到的是任何给定卷的精简预配 (100 TiB) 容量，也就是说，我们看到的客户端或应用程序端容量并不准确。
• 由于容量池的自动增长行为，应用程序所有者无法控制预配的容量池空间（和关联的成本）。 在可能快速填满“失控进程”和增大预配容量与成本的环境中，这种情况会带来麻烦。
• 客户希望看到并维持卷大小（配额）与性能之间的直接关联。 在当前的（隐式）过度订阅卷（容量范围）和池自动增长的行为下，只有在主动设置或重置卷配额之后，客户才能获得直接关联。

许多客户已请求直接控制预配的容量。 他们想要控制和平衡存储容量与利用率。 他们还想要控制成本，及其应用程序卷的可用、已用和预配容量与性能的应用程序端和客户端可见性。

什么是卷硬配额更改

随着卷硬配额的更改，Azure NetApp 文件卷将不再精简预配为（最大）100 TiB。 卷将预配为实际的配置大小（配额）。 此外，底层容量池的使用量达到全容量时，将不再自动增长。 此项更改反映了类似于 Azure 托管磁盘的行为，这种磁盘也是按原样预配的，而不会自动增大容量。

例如，假设在 4-TiB 的超级服务级别容量池中配置了一个 1-TiB 大小（配额）的 Azure NetApp 文件卷。 某个应用程序持续向该卷写入数据。

初始行为：

• 预期带宽：128 MiB/秒
• 总可用（和客户端可见的）容量：100 TiB
  你无法在该卷上写入超过此大小的更多数据。
• 容量池：已满时，以 1 TiB 为增量自动增长。
• 卷配额更改：仅更改卷的性能（带宽）。 它不会更改客户端可见的容量或可用容量。

更改后的行为：

• 预期带宽：128 MiB/秒
• 总可用（和客户端可见的）容量：1 TiB。你无法在该卷上写入超过此大小的更多数据。
• 容量池：大小保持为 4 TiB，不会自动增长。
• 卷配额更改：更改卷的性能（带宽），以及客户端可见的容量或可用容量。

你需要主动监视 Azure NetApp 文件卷和容量池的利用率。 你需要有针对性地更改卷和池的利用率，以实现接近全容量使用。 Azure NetApp 文件将继续允许动态卷和容量池大小调整操作。

如何操作化卷硬配额更改

本部分提供有关如何操作化卷硬配额的更改以实现平稳过渡的指导。 本部分还将提供有关处理当前预配的卷和容量池、持续监视和警报以及容量管理选项的见解。

当前预配的卷和容量池

由于卷硬配额更改，你应该更改自己的操作模型。 预配的卷和容量池需要持续的容量管理。 由于更改后的行为会即刻发生，Azure NetApp 文件团队针对现有的以及以前预配的卷和容量池建议了一系列一次性纠正措施，具体如本部分中所述。

一次性纠正或预防措施建议

卷硬配额更改导致以前预配的卷和池的预配容量和可用容量发生变化。 因此，可能会出现一些容量分配挑战。 为了避免客户遇到短期的空间不足情况，Azure NetApp 文件团队建议了以下一次性纠正/预防措施：

• 预配的卷大小：
  调整每个预配卷的大小，使其中的适当缓冲区基于更改率和警报或大小调整周转时间（例如，20% 的缓冲区基于典型工作负载考虑因素），最大大小为 100 TiB（即常规卷大小限制）。 此新卷大小（包括缓冲区容量）应基于以下因素：

  • 预配的卷容量（如果已用的容量小于预配的卷配额）。
  • 已用的卷容量（如果已用的容量大于预配的卷配额）。
    如果底层容量池无需增长，则卷级别的容量不会额外收费。 作为此项更改的效果，你可能发现卷的带宽限制提高了（如果使用自动 QoS 容量池类型）。

• 预配的容量池大小：
  调整卷大小后，如果卷大小的总和大于宿主容量池的大小，则容量池必须增大至大于或等于卷总和的大小，最大值为 500 TiB。 有关限制的信息，请参阅 Azure NetApp 文件资源限制。 增加的容量池容量将如常收取 ACR 费用。

在按照以下部分中所述设置监视或警报时如需帮助，请咨询 Azure NetApp 文件专家以验证你的环境。

持续容量管理

在执行一次性纠正措施后，应实施持续性的流程来监视和管理容量。 以下部分提供有关容量监视和管理的建议与替代做法。

监视容量利用率

可以在不同的级别监视容量利用率。

VM 级别的监视

最高级别的监视（与应用程序最靠近）是从应用程序虚拟机内部进行监视。 这将导致从 VM 客户端 OS 内部提供的容量报告中的行为发生可观测的更改。

在以下两个场景中，假设在 4-TiB 的超级服务级别容量池中配置了一个 1-TiB 大小（配额）的 Azure NetApp 文件卷。

Windows

Windows 客户端可以使用网络映射驱动器属性来检查卷的已用容量和可用容量。 你可以使用“资源管理器”->“驱动器”->“属性”选项。

以下示例显示了在行为更改之前 Windows 中的卷容量报告：

还可以如下所示在命令提示符下使用 dir 命令：

以下示例显示了在行为更改之后 Windows 中的卷容量报告：

以下示例显示 dir 命令的输出：

Linux

Linux 客户端可以使用 df 命令检查卷的已用容量和可用容量。 -h 选项以用户可读的格式显示大小、已用空间和可用空间，大小单位为 M、G 和 T。

以下示例显示了在行为更改之前 Linux 中的卷容量报告：

以下示例显示了在行为更改之后 Linux 中的卷容量报告：

使用 ANFCapacityManager 配置警报

可以使用社区支持的逻辑应用 ANFCapacityManager 工具来监视 Azure NetApp 文件容量并接收定制的警报。 ANFCapacityManager 工具已在 ANFCapacityManager GitHub 页上提供。

ANFCapacityManager 是一个 Azure 逻辑应用，用于管理基于容量的警报规则。 它会自动增大卷大小，以防止 Azure NetApp 文件卷耗尽空间。 此工具易于部署，可提供以下警报管理功能：

• 创建 Azure NetApp 文件容量池或卷时，ANFCapacityManager 会根据指定的已用百分比阈值创建指标警报规则。
• 调整 Azure NetApp 文件容量池或卷的大小时，ANFCapacityManager 会根据指定的已用容量百分比阈值修改指标警报规则。 如果警报规则不存在，将会创建它。
• 删除 Azure NetApp 文件容量池或卷时，将删除相应的指标警报规则。

可配置以下关键警报设置：

• 容量池已满阈值(百分比) - 此设置确定触发容量池警报的已用量阈值。 如果值为 90，则会在容量池使用率达到 90% 时触发警报。
• 卷已满阈值(百分比) - 此设置确定触发卷警报的已用量阈值。 如果值为 80，则会在卷使用率达到 80% 时触发警报。
• 用于处理容量通知的现有操作组 - 此设置是针对基于容量的警报触发的操作组。 系统应该已预先创建此设置。 操作组可以发送电子邮件、短信或其他格式。

以下插图显示了警报配置：

安装 ANFCapacityManager 后，预期可能会出现以下行为：创建、修改或删除 Azure NetApp 文件容量池或卷时，逻辑应用将自动创建、修改或删除名为 ANF_Pool_poolname 或 ANF_Volume_poolname_volname 的基于容量的指标警报规则。

管理容量

除了监视和警报外，还应结合应用程序容量管理做法来管理 Azure NetApp 文件（增大的）容量使用率。 当 Azure NetApp 文件卷或容量池已填满时，可以动态提供额外的容量，而无需中断应用程序。 本部分介绍按需增大卷和容量池预配空间的各种手动和自动方法。

手动

可以使用门户或 CLI 来手动增大卷或容量池的大小。

门户

可根据需要更改卷的大小。 卷的容量消耗是依据其池的预配容量计数的。

1. 在你的 NetApp 帐户中，选择“卷”。

2. 右键单击要调整大小的卷的名称，或选择卷所在行末尾的 … 图标以显示上下文菜单。

3. 使用上下文菜单选项来重设卷大小或删除卷。

   

   

在某些情况下，宿主容量池不提供足够的容量用于调整卷的大小。 但是，可以以 1-TiB 为增量或减量更改容量池大小。 容量池大小不能小于 4 TiB。 重设容量池大小会更改购买的 Azure NetApp 文件容量。

1. 在“管理 NetApp 帐户”边栏选项卡中，选择要重设大小的容量池。

2. 右键单击容量池名称，或选择容量池所在行末尾的 … 图标以显示上下文菜单。

3. 使用上下文菜单选项来重设容量池大小或删除容量池。

   

   

CLI 或 PowerShell

可以使用 Azure NetApp 文件 CLI 工具（包括 Azure CLI 和 Azure PowerShell）手动更改卷或容量池的大小。 可使用以下两个命令来管理 Azure NetApp 文件卷和池资源：

• az netappfiles pool
• az netappfiles volume

若要使用 Azure CLI 管理 Azure NetApp 文件资源，可以打开 Azure 门户，并在菜单栏顶部选择 Azure“Cloud Shell”链接：

此操作将打开 Azure Cloud Shell：

以下示例使用命令来显示和更新卷的大小：

以下示例使用命令来显示和更新容量池的大小：

自动化

可以构建自动化流程来管理更改后的行为。

REST API

适用于 Azure NetApp 文件服务的 REST API 定义了针对 NetApp 帐户、容量池、卷和快照等资源执行的 HTTP 操作。 Azure NetApp 文件的 REST API 规范已通过 Azure NetApp 文件资源管理器 GitHub 页发布。 可以在 GitHub 中找到 与 REST API 配合使用的示例代码。

请参阅使用 REST API 进行 Azure NetApp 文件开发。

通过 PowerShell 使用 REST API

适用于 Azure NetApp 文件服务的 REST API 定义了针对 NetApp 帐户、容量池、卷和快照等资源执行的 HTTP 操作。 Azure NetApp 文件的 REST API 规范已通过 GitHub 发布。

请参阅使用 PowerShell 通过 REST API 进行 Azure NetApp 文件开发。

使用 ANFCapacityManager 进行容量管理

ANFCapacityManager 是一个 Azure 逻辑应用，用于管理基于容量的警报规则。 它会自动增大卷大小，以防止 Azure NetApp 文件卷耗尽空间。 除了发送警报以外，它还可以启用卷和容量池大小的自动增大，以防止 Azure NetApp 文件卷耗尽空间：

• （可选）当 Azure NetApp 文件卷达到指定的已用百分比阈值时，卷配额（大小）将增大指定的百分比 (10-100)。
• 如果卷大小在增大后超过了其所在容量池的容量，则容量池的大小将增大，以适应新的卷大小。

可以配置以下关键容量管理设置：

• 自动增长百分比 - 当现有卷达到了指定的已满百分比阈值时，要将该卷自动增长的百分比。 0（零）值将禁用自动增长功能。 建议使用介于 10 和 100 之间的值。

  

常见问题解答

本部分解答有关卷硬配额更改的一些问题。

快照空间是否计入卷的可用容量或预配容量？

是，已用快照容量将计入卷中预配的空间。 当卷已满时，请考虑以下两个修正选项：

• 按本文所述调整卷的大小。
• 删除较旧的快照，以释放宿主卷中的空间。

此项更改是否意味着卷自动增长行为将从 Azure NetApp 文件中消失？

一个常见的错误认知是，Azure NetApp 文件卷在填满后会自动增长。 不管实际设置的配额是什么，卷都精简预配为 100 TiB 大小，而底层容量池将以 1-TiB 增量自动增长。 此更改会将（可视和可用）卷大小存入集配额，并且容量池因此不再自动增长。 此项更改可以提供用户通常所期望的准确客户端空间和容量报告。 它避免了“失控的”容量消耗。

此项更改是否对使用跨区域复制（预览版）复制的卷造成任何影响？

不会对复制目标卷强制实施硬性的卷配额。

此项更改是否对 Azure Monitor 中当前提供的指标造成任何影响？

门户指标和 Azure Monitor 统计信息准确反映了新的分配和使用模型。

此项更改是否对 Azure NetApp 文件的资源限制造成任何影响？

除了本文中所述的配额更改以外，Azure NetApp 文件的资源限制没有任何变化。

你们是否提供了示例 ANFCapacityManager 工作流？

是的。 请参阅 卷自动增长工作流示例 GitHub 页。

ANFCapacityManager 是否由 Microsoft 提供支持？

ANFCapacityManager 逻辑应用是按原样提供的，NetApp 或 Microsoft 不负责为其提供支持。 我们建议你根据具体的环境或要求对其进行修改。 将此功能部署到任何业务关键型环境或生产环境之前，应该对其进行测试。

如何报告 ANFCapacityManger 的 bug 或提交其功能请求？

可以在 ANFCapacityManager GitHub 页上选择“新问题”来提交 bug 和功能请求。

后续步骤

• 调整容量池或卷的大小
• Azure NetApp 文件的指标