你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure NetApp 文件应用程序卷组常见问题解答
本文解答有关 Azure NetApp 文件应用程序卷组的常见问题 (FAQ)。
一般常见问题解答
此部分解答有关 Azure NetApp 文件应用程序卷组的一般问题。
为什么应该为所有数据库卷使用手动 QoS 容量池？
手动 QoS 容量池可让容量与吞吐量之间实现最佳平衡，以满足数据库需求。 使用它无需过度预配就能实现日志卷或数据卷等组件的性能。 它还能为日志备份预留更大的空间，同时将性能保持为符合需求的值。 总体而言，使用手动 QoS 容量池具有成本优势。
注意
在创建应用程序卷组期间，列表中将仅显示手动 QoS 容量池以供选择。
是否可以克隆使用应用程序卷组创建的卷？
是的，可以克隆应用程序卷组创建的卷。 还可以通过选择快照以及将其恢复到新卷达到以上目标。 克隆是在应用程序卷组工作流之外的过程。 因此，请考虑以下限制：
- 克隆单个卷时，不会检查特定于卷组的依赖项。
- 克隆的卷不属于卷组。
- 克隆的卷始终放置在与源卷相同的存储终结点上。
- 若要实现克隆卷的最低延迟，需要装载与源卷相同的 IP 地址。
创建卷组需要多长时间？
创建卷组涉及许多不同的步骤，并非所有步骤都可同时完成。 尤其是在为给定的位置创建第一个卷组时，可能需要 9-12 分钟才能完成。 创建后续卷组所需的时间应该更少。
部署失败，甚至未创建一个卷。 为什么会这样？
这是正常行为。 应用程序卷组将以原子方式预配卷，并在其中一个组件部署失败的情况下回滚部署。 部署失败的原因通常是给定的位置无法提供足够的可用资源来满足要求。 检查部署日志以了解详细信息，并根据需要更正容量池配置。
为何无法编辑卷组说明？
在当前的实现中，应用程序卷组仅注重卷组的初始创建和删除。
我应为数据库卷使用哪种快照策略？
可以使用 AzAcSnap 或 Commvault 之类的产品为数据库环境提供应用程序一致性备份。 不能使用 Azure NetApp 文件内置快照策略计划的标准快照来实现一致的数据保护。
下面是针对数据库环境中的快照的一般建议：
- 密切监视数据卷快照。 长时间保留快照可能会提高容量需求。 确保监视已用容量与已分配的容量。
- 如果自动为主要数据保护创建快照，请务必监视其保留期，以避免意外的容量消耗。
有关适用于 SAP HANA 的应用程序卷组的常见问题解答
此部分解答有关适用于 SAP HANA 的 Azure NetApp 文件应用程序卷组的问题。
卷的装载说明包括 IP 地址列表。 我应该使用哪个 IP 地址？
应用程序卷组可确保一个主机的数据和日志卷始终具有使用不同 IP 地址的单独存储终结点，以获得最佳性能。 若要跨 Azure NetApp 文件存储资源来托管数据、日志和共享卷，每个已使用的 Azure NetApp 文件存储资源最多可以创建 6 个存储终结点。 因此，建议相应地调整委托子网的大小。 请参阅适用于 SAP HANA 的应用程序卷组的要求和注意事项。 尽管列出的所有 IP 地址都可用于装载，但第一个列出的 IP 地址是提供最低延迟的 IP 地址。 建议始终使用第一个 IP 地址。
是否可以使用 nconnect 作为装载选项？
Azure NetApp 文件确实支持 NFSv4.1 的 nconnect，但需要以下 Linux OS 版本：
- SLES 15SP2 和更高版本
- RHEL 8.3 和更高版本
使用 nconnect 装载选项时，读取限制最高为 4500 MiB/秒（请参阅适用于 Azure NetApp 文件的 Linux NFS 装载选项最佳做法），并且可能需要相应地调整数据卷的建议吞吐量限制。
为何即使我删除了 {Hostid} 占位符，我的名称中仍会添加 hostid（例如 00001）？
应用程序卷组要求在名称中包含占位符 {Hostid}。 如果删除该占位符，则 hostid 会自动添加回提供的字符串。
选择“查看 + 创建”后，可以看到每个卷的最终名称。
为何适用于 SAP HANA 的应用程序卷组为数据卷建议的最大吞吐量值是 1500 MiB/秒？
NFSv4.1 是 SAP HANA 和 Oracle 支持的协议。 因此，在装载单个卷时将支持一个 TCP/IP 会话。 要针对单个卷运行单个 TCP 会话（即从单个主机运行），1500 MiB/秒是已确定的典型 I/O 限制。 正因如此，适用于 SAP HANA 的应用程序卷组避免分配更多吞吐量，而你实际上可以实现更多吞吐量。 如果需要更多吞吐量，尤其是对于较大的 HANA 数据库（例如 12 TiB），应使用多个分区或使用 nconnect 装载选项。
如何调整 Azure NetApp 文件卷的大小，以便与 SAP HANA 配合使用以实现最佳性能和成本效益？
为了实现最佳大小调整，必须调整整个布局的大小，包括快照和备份。 确定用于生产、HA 和数据保护的卷布局，并使用适用于 SAP HANA 部署 的 Azure NetApp 文件大小计算器来执行大小调整。
我收到警告消息 "Not enough pool capacity"。 我该怎么办？
应用程序卷组会根据 HANA 内存输入计算所有卷的容量和吞吐量需求。 当你选择容量池时，它会立即检查容量池中是否留有足够的容量和吞吐量。
在最初的 SAP HANA 屏幕上，可以忽略此消息并单击“下一步”按钮继续执行工作流。 以后可以单独调整每个卷的建议值，使所有卷都可装入容量池。 如果在所有卷都已装入容量池之前更改每个卷，会再次出现此错误消息。
你可能还会需要增大池的大小以避免出现此警告消息。
怎样知道如何调整我的系统或整个系统格局的大小？
请联系 SAP Azure NetApp 文件大小调整专家来帮助自己规划整个 SAP 系统的大小调整。
对于每个系统，需要提供的重要信息包括以下项：SID、角色（生产、开发、预生产/QA）、HANA 内存、快照保留百分比、本地快照保留天数、基于文件的备份数、单主机/多主机和主机数，以及 HSR（主要、次要）。
可以使用 SAP HANA 大小调整估算器来优化大小调整过程。
如果你了解自己的系统（根据以前运行 HANA 的经验），则可以手动提供自己的数据而不要遵循这些一般性的假设。
是否可以使用多个分区的新 SAP HANA 功能？
适用于 SAP HANA 的应用程序卷组设计思路并未特意注重于多个分区，但你可以在调整输入的同时使用适用于 SAP HANA 的应用程序卷组。
有关多个分区的基础知识如下：
- 多个分区是指单个 SAP HANA 主机使用多个卷来存储其持久性内容。
- 多个分区需要装载到不同的路径。 例如，第一个卷位于
/hana/<SID>/data1/mnt00001，第二个卷需要不同的路径 (/hana/<SID>/data2/mnt00002)。 若要实现此目的，应手动调整命名约定。 即<SID>-DATA1-MNT00001; <SID>-DATA2-MNT00002, ...。 - 内存对于调整适用于 SAP HANA 的应用程序卷组的容量和吞吐量非常关键。 因此，需要调整大小以适应分区数。 如果有两个分区，则应该使用 50% 的内存。 如果有三个分区，则应该使用 33% 的内存，以此类推。
对于要创建的每个主机和每个分区，需要重新运行适用于 SAP HANA 的应用程序卷组，并且应该调整命名方案以满足上述建议。
有关此主题的更多详细信息，请参阅使用适用于 SAP HANA 的 Azure NetApp 文件 AVG 部署具有多个分区的 HANA。
我的 HANA 数据和日志卷的建议吞吐量是根据哪些规则提出的？
SAP 将 HANA 卷的关键绩效指标 (KPI) 定义为 400 MiB/秒（适用于数据）和 250 MiB/秒（适用于日志卷）。 此定义与 HANA 数据库的大小或工作负载无关。 应用程序卷组缩放吞吐量值所采用的方式是，即使是最小的数据库，也会满足 SAP HANA KPI，那么较大的数据库会得益于较高的吞吐量级别，即，根据输入的 HANA 数据库大小来缩放建议。
下表描述了 HANA 数据卷的内存范围和建议的吞吐量：
| 内存范围 (TB) | 建议的吞吐量（MB/秒） | |
|---|---|---|
| 最低 | 最大值 | |
| 0 | 1 | 400 |
| 1 | 2 | 600 |
| 2 | 4 | 800 |
| 4 | 6 | 1000 |
| 6 | 8 | 1200 |
| 8 | 10 | 1400 |
| 10 | 无限制 | 1500 |
下表描述了 HANA 日志卷的内存范围和建议的吞吐量：
| 内存范围 (TB) | 建议的吞吐量（MB/秒） | |
|---|---|---|
| 最低 | 最大值 | |
| 0 | 4 | 250 |
| 4 | 无限制 | 500 |
数据库卷吞吐量主要影响数据库启动时将数据读入内存所需的时间。 但是，在运行时，大多数 I/O 都是写入 I/O（即使 KPI 显示的值较低）。 用户体验表明，对于较小的数据库而言，HANA KPI 值可能会高于大多数时间需要的值。
可以在运行时调整每个卷的 Azure NetApp 文件性能。 这样，随时你都可以根据特定要求来调整数据和日志卷吞吐量，从而调整数据库的性能。 例如，可以在启动时允许较高的吞吐量，而在普通操作期间降低至 KPI，从而微调性能并降低成本。
是否在靠近我的 SAP HANA 服务器的位置预配所有卷？
使用为 SAP HANA 服务器创建的邻近放置组 (PPG) 可确保在靠近 SAP HANA 服务器的位置创建数据、日志和共享卷，以实现最佳延迟和吞吐量。 但是，日志备份卷和数据备份卷不需要低延迟。 从保护的角度讲，将这些备份卷存储在与数据、日志和共享卷不同的位置会有帮助。 因此，应用程序卷组会将备份卷放置在区域中具有足够容量和吞吐量的其他存储位置。
AVset、VM、PPG 和 Azure NetApp 文件卷之间的关系是什么？
邻近放置组 (PPG) 至少需要分配有一台 VM，可以直接分配，也可以通过 AVset 分配。 PPG 的目的是提取 VM 的确切位置，并将此信息传递给应用程序卷组，以在同一数据中心中搜索 Azure NetApp 文件资源。 仅当 PPG 中至少有一个 VM 启动时，此设置才有效。 通常，可以将数据库服务器添加到该 PPG。
PPG 具有副作用，即，如果关闭所有 VM，接下来重启 VM 并不保证它们会在与之前相同的数据中心内启动。 为防止这种情况发生，强烈建议使用一个关联了所有 VM 和 PPG 的 AVset，并使用 HANA 固定工作流。 该工作流不仅可确保 VM 在重启时不会移动，而且还可确保选择具有足够计算资源和 Azure NetApp 文件资源的位置。
对于多主机 SAP HANA 系统，当我添加更多的 HANA 主机时，共享卷是否会调整大小？
否。 目前，这是需要手动调整大小的极少见情况之一。 SAP 建议为每四个 HANA 主机将共享卷的大小调整为 1 x RAM。 由于共享卷创建为第一个 SAP HANA 主机的一部分，因此它的大小已调整为 1 TB。 可使用两个选项正确调整 SAP HANA 的共享卷大小。
- 例如，如果你事先知道需要 6 个主机，则可以在最初为 SAP HANA 创建应用程序卷组期间修改 1 TB 建议。 此时，还可以增加吞吐量（即 QoS）以适应 6 个主机的需求。
- 创建卷后，始终可以单独编辑共享卷并更改大小和吞吐量。 可以在卷放置组中执行此操作，也可以使用 Azure 资源提供程序或 GUI 直接在卷中执行此操作。
我不仅想要为单个实例创建数据备份卷，还想为多个 SAP HANA 数据库创建数据备份卷。 如何执行此操作？
日志备份卷和数据备份卷是可选的，它们不必要相互靠近。 实现预期结果的最佳方式是在从适用于 SAP HANA 的应用程序卷组创建第一个卷时删除数据备份卷或日志备份卷。 然后，你可以使用标准卷预配并选择符合需求的适当容量和吞吐量，将自己的卷创建为单个独立卷。 应使用指明了数据备份卷并将其用于多个 SID 的命名约定。
有关适用于 Oracle 的应用程序卷组的常见问题解答
此部分解答有关适用于 Oracle 的 Azure NetApp 文件应用程序卷组的问题。
是否会将所有卷预配到与适用于 Oracle 的数据库服务器相同的可用性区域中？
部署工作流可确保所有卷都放置在创建时选择的可用性区域中，它应该与 Oracle 虚拟机的可用性区域相一致。 对于不支持可用性区域的区域，卷将放置在区域范围内。
如何调整 Azure NetApp 文件卷的大小，以便与 Oracle 配合使用以实现最佳性能和成本效益？
为了实现最佳大小调整，必须调整整个数据库布局的大小，包括 HA、快照和备份。 确定用于生产、HA 和数据保护的卷布局，根据“在 Azure 中运行要求最苛刻的 Oracle 工作负载，而无需牺牲性能或可伸缩性”和“用于将 Oracle 工作负载大小调整为 Azure IaaS VM 的估算工具”中的说明，执行大小调整操作。 也可以通过选择“添加单个卷”输入选项，使用 Azure NetApp 文件上的 SAP 大小调整估算器。
为调整每个卷的大小需要提供的重要信息包括：SID、角色（生产、开发、预生产/QA）、快照保留百分比、本地快照保留天数、基于文件的备份数、单主机/多主机和主机数，以及数据防护要求（主要、次要）。 请联系 SAP Azure NetApp 文件上的 Oracle 大小调整专家来帮助自己规划整个 Oracle 系统的大小调整。
卷的装载说明包括 IP 地址列表。 我应该为 Oracle 使用哪个 IP 地址？
应用程序卷组可确保数据、重做日志、存档日志和备份卷具有使用不同 IP 地址的单独存储终结点，以获得最佳性能。 尽管列出的所有 IP 地址都可用于装载，但第一个列出的 IP 地址是提供最低延迟的 IP 地址。 建议始终使用第一个 IP 地址。
我应该为 Oracle 卷使用哪个版本的 NFS？
在客户端上使用 Oracle dNFS 装载卷。 虽然使用 dNFS 进行装载适用于使用 NFSv3 和 NFSv4.1 创建的卷，但我们建议使用 NFSv3 来部署卷。 有关更多详细信息和版本依赖关系，请参阅客户端操作系统和 Oracle 说明。 你还可以在“将 Azure NetApp 文件与 Oracle Database 配合使用的好处”和“Azure NetApp 文件多个卷上的 Oracle 数据库性能”中找到更多详细信息。
若要为大型数据库实现最佳性能，建议在数据库服务器上使用 dNFS 装载卷。 为了简化 dNFS 配置，建议使用 NFSv3 创建卷。
我应该为 Oracle 卷使用哪种快照策略？
此问题与适用于 Oracle 的应用程序卷组不直接相关。 可以使用 AzAcSnap 或 Commvault 之类的产品为 Oracle 数据库提供应用程序一致性备份。 不能使用 Azure NetApp 文件内置快照策略计划的标准快照来实现针对 Oracle 数据库的一致数据保护。
下面是针对 Oracle 环境中的快照的一般建议：
- 使用数据库感知型快照工具，确保创建数据库一致性快照。
- 密切监视数据卷快照。 长时间保留快照可能会提高容量需求。 确保监视已用容量与已分配的容量。
- 如果为备份卷自动创建快照，请务必监视其保留期，以避免意外的卷增长。
Oracle ASM 能否与 AVG 一起用于 Oracle 创建的卷？
支持将 Oracle ASM 与适用于 Oracle 的 Azure NetApp 文件应用程序卷组结合使用，但不支持在应用程序卷组中的卷之间实现快照一致性。 建议客户在使用 ASM 时使用其他兼容的数据保护选项，直至另行通知。
为什么可以选择将邻近放置组 (PPG) 用于 Oracle 部署？
在资源可用性有限的区域中部署时，可能无法在最佳位置部署卷。 在这种情况下，可以选择使用邻近放置组函数来部署卷，以在给定条件下实现具有最佳卷放置的部署。 作为默认设置，PPG 的使用已被禁用。 需要通过支持渠道请求启用邻近放置组。
后续步骤
- 有关适用于 SAP HANA 的应用程序卷组：
- 有关适用于 Oracle 的应用程序卷组：
- 删除应用程序卷组
- 排查应用程序卷组错误