你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
已启用 Azure Arc 的 SQL 托管实例的存储规则
存储是已启用 Azure Arc 的 SQL 托管实例（已启用 Arc 的 SQL 托管实例）部署中的关键组成部分。 在存储设计选择和管理中，了解本文档中所述的与存储相关的概念如何影响 Kubernetes 群集的功能非常重要。
Kubernetes 不直接与基础存储交互，而是通过存储类向各种存储技术提供一个抽象层。 云提供商、硬件供应商和其他 Kubernetes 托管平台提供不同的 StorageClass 选项来满足特定环境和实现方案的需求。
已启用 Arc 的 SQL 托管实例不会限制或强制使用任何存储类，因此必须选择正确的存储设计和配置。 关于已启用 Arc 的 SQL 托管实例的存储设计与在裸机或虚拟机上运行时为 SQL Server 选择后备存储设备一样重要。 这些选择最终表示了你在恢复点目标 (RPO)、恢复时间目标 (RTO)、容量和性能方面的要求。
对于已启用 Arc 的 SQL 托管实例部署，有效规划存储容量和配置是成功运行的关键。 请阅读了解要考虑的与存储相关的因素，然后了解有关配置已启用 Arc 的 SQL 托管实例的建议。
体系结构
以下体系结构图显示了已启用 Azure Arc 的数据服务组件的逻辑设计。 这些组件包含一个必需的 Azure Arc 数据控制器和一个或多个已启用 Arc 的 SQL 托管实例（其中包含已预配供引用的数据库）。 Azure Arc 数据控制器和已启用 Arc 的 SQL 托管实例都提供面向后备存储设备的选项，这些设备依赖于 Kubernetes 分发和存储基础结构提供程序。
设计注意事项
下面是存储设计和配置的注意事项。
存储类
对于数据存储性能、复原能力和容量来说，为已启用 Azure Arc 的数据服务组件选择适当的 Kubernetes StorageClass 和配置非常重要。
StorageClass、PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 是系统在预配已启用 Azure Arc 的数据服务组件时在 Kubernetes 群集中创建的 Kubernetes 资源对象。
StorageClass 选项因云提供商、硬件供应商提供的内容以及 Kubernetes 管理员配置的内容而异。 PersistentVolumeClaim 会请求为 StorageClass 和所请求的大小创建一个 PersistentVolume。 下图是这些 Kubernetes 资源与存储类的潜在选项之间的关系参考。
在分别预配已启用 Azure Arc 的数据控制器和已启用 Arc 的 SQL 托管实例时，会配置 PV 和 PVC Kubernetes 资源。
有两种不同的存储类型可供选择：
- 本地：一个装载到本地存储设备的卷，而该设备附加到正在运行 Pod 的 Kubernetes 节点。 与远程/共享存储相比，这种类型的存储通常提供更低的延迟和更高的每秒输入/输出操作 (IOPS) 与吞吐量。
- 远程/共享存储：通常附带内置冗余的网络连接存储设备。 常见的存储选项是 NAS 和 SAN 设备。
选择 StorageClass 时，请考虑以下标准。 对于要生成的任何数据库服务器，也需要满足这些条件：
- 性能：存储设备的输入/输出 (I/O) 吞吐量和 IOPS 应满足你的数据库需求。
- 读/写比率：了解工作负载有助于你选择能最好地满足你的需求并产生适当成本的后备硬件。 具有大量写入操作的工作负载可利用 RAID 0 配置，而经常访问的数据可能最好由 SAN 设备存储提供服务。
- 数据库隔离和归置：已启用 Arc 的 SQL 托管实例的实例上的所有数据库都共享 PV，因此你可选择将数据库移动到已启用 Arc 的 SQL 托管实例的单独实例，并避免存储资源争用。
- 容量：为了避免重设 PVC 大小，定义的存储大小应满足数据控制器和数据库实例的未来容量。 请考虑所选 StorageClass 可能具有的任何存储限制。
- 访问模式：存储类提供程序具有不同的访问模式，对于 Pod 可如何装载和读取/写入存储支持使用不同的容量。 SQL 备份卷需要 RWX（多次读写）。
- 冗余：如果发生硬件磁盘故障，则复制物理存储层 (RAID) 中的数据来支持无缝故障转移，这独立于由可用性组 (AG) 操作的数据库级别冗余。
Azure Arc 数据控制器和已启用 Arc 的 SQL 托管实例 Arc 数据服务都提供了用于为数据库数据配置不同存储类的精细选项。 这些数据服务还提供日志，便于你灵活地选择存储类来满足需求。
数据控制器
Kubernetes 群集需要单个 Azure Arc 数据控制器，这是创建已启用 Arc 的 SQL 托管实例的实例的先决条件。 不支持在一个群集中运行多个数据控制器。
Azure Arc 数据控制器将在 Kubernetes 群集中运行 4 个不同的有状态 Pod：控制器 SQL、控制器 API、日志 DB 和指标 DB。 每个 Pod 都需要 2 个永久性卷，它们分别用于数据卷和日志卷。 所有数据控制器组件都需要远程 StorageClass 来确保数据持续性，因为数据控制器组件本身本身并不提供数据持续性。
请务必考虑 Azure Arc 数据控制器所需的计算和内存资源。 下图表示数据控制器存储、PV 和 PVC Kubernetes 资源。
数据控制器的默认卷大小是推荐的最小值。 使用的存储由数据库数目、数据库使用方式和生成的日志数来决定。 Azure Arc 数据控制器 StorageClass 对低延迟不敏感。 即便如此，如果你在群集中有很多已启用 Arc 的 SQL 托管实例部署，那么用户在 Grafana 和 Kibana 接口中可能会看到性能更快的存储优势。 Grafana 和 Kibana 是开源监视可视化工具，它们部署了数据控制器，还预配了仪表板用于查看已启用 Arc 的 SQL 托管实例的指标和日志。
数据控制器预配
预配 Azure Arc 数据控制器时，请为日志和数据配置 StorageClass 和存储容量。 然后，为日志和数据配置存储，这适用于你为数据控制器 Pod 创建的全部 8 个 PV。 在预配期间，可指定一个自定义部署模板用于替代默认参数，例如容量、日志保留和与安全性相关的项（如 Kubernetes 服务类型）。 预配完成后，会创建 PV 和 PVC Kubernetes 对象。
请务必了解，数据控制器的 StorageClass 一旦预配就无法更改。 如果未指定 StorageClass，数据控制器将使用 Kubernetes 的默认 StorageClass，这可能因 Kubernetes 实例或提供程序而异。
卸载 Azure Arc 数据控制器时，会删除与其关联的所有永久性卷。 在卸载数据控制器之前，请存档组织需要保存的任何已启用 Azure Arc 的数据服务控制平面级别日志。
已启用 Azure Arc 的 SQL 托管实例
已启用 Arc 的 SQL 托管实例根据业务需求提供两个不同的层：“常规用途”层和“业务关键”层。 对于这两个层，请务必查看已启用 Arc 的 SQL 托管实例的最小和最大限制，这些限制是可配置的，它们用于确保已部署的 Kubernetes 群集具有适当的计算和内存容量。
如果给定数据库实例上具有多个数据库，则所有数据库都使用为已启用 Arc 的 SQL 托管实例指定的相同 StorageClass、PVC 和 PV。 一个 Kubernetes 群集中可以有已启用 Arc 的 SQL 托管实例的多个实例。 此配置允许使用独立的永久性卷，并可通过将数据库部署到已启用 Arc 的 SQL 托管实例的不同实例来帮助将 IO 争用与不同的数据库分开。
下表描述了每个已启用 Arc 的 SQL 托管实例 Pod 所使用的不同的永久性卷及其用途。
| 永久性卷 | 说明 | 存储类要求 |
|---|---|---|
| 数据 | SQL 数据库数据文件（.mdf 文件） | 取决于层 |
| DataLogs | SQL 数据库日志文件（.ldf 文件） | 取决于层 |
| 日志 | SQL 代理、错误日志、跟踪文件、运行状况日志 | 取决于层 |
| 备份 | SQL Server 备份文件，包括完整、差异、事务日志 | 远程、ReadWriteMany 访问模式 |
“常规用途”服务层级
已启用 Arc 的 SQL 托管实例的常规用途层必须对数据库实例使用远程存储，以便在 Pod 发生故障时，数据仍可供新创建的 Pod 使用。 故障转移由 Kubernetes Pod 和节点业务流程进行管理。 此配置与业务关键层相比更加简单，后者使用 SQL 可用性组和多个已启用 Arc 的 SQL 托管实例副本。 常规用途层的单个 Pod 配置意味着可最大程度地减少存储量，因为不必为其他副本复制存储容量。
“业务关键”服务层级
业务关键层使用多 Pod 模型，其中数据和日志卷可存储在本地或远程存储类上。 本地存储类通常在延迟和吞吐量方面表现更好，因为存储设备直接附加到节点。 远程存储通常提供内置冗余，但与本地存储相比，延迟和吞吐量通常较低。 请记住，要使用更多的业务关键数据库副本，需要有额外的永久性卷用于 Data、Logs 和 DataLogs。 所需的总存储容量要高得多。
下图显示了已启用 Arc 的 SQL 托管实例的业务关键存储配置，该实例具有两个副本。
通过业务关键层，可配置两个或三个次要副本。 故障转移由 SQL Always On 可用性组进行管理，这与常规用途层相比升级时停机时间更短、故障更少。
使用同步提交模式数据复制来配置多个副本可确保更好地防范故障，例如失败的 Pod、节点或存储硬件。 它可防范故障，因为副本上有数据的多个副本。 请考虑将次要副本配置为读取扩展实例，在使用辅助侦听器终结点时客户端可连接到这些实例。
Azure Arc SQL 托管实例预配和卸载
预配已启用 Arc 的 SQL 托管实例时，可灵活地将不同的存储类分配给每个所需的已启用 Arc 的 SQL 托管实例永久性卷。 你可能希望对 Data 和 DataLogs 使用更高性能的存储选项，但 Logs 和 Backup 卷可使用更具成本效益的 StorageClass 选项来节省成本。 如果你使用本地存储，请确保卷能够登陆不同的节点和物理存储设备，以避免在磁盘 I/O 上出现争用。 将 Data 和 DataLogs 放置在同一物理驱动器上可能会导致该存储驱动器出现争用情况，从而导致性能不佳。 请转而考虑将 Data 和 DataLogs 放在单独的存储驱动器上，为数据库数据和日志实现 I/O 并行化。
删除已启用 Arc 的 SQL 托管实例时，不会删除其关联的 PV 和 PVC。 该行为确保你可在意外删除的情况下访问数据库文件。
设计建议
下面是有关存储设计和配置的建议。
用于生产工作负载的存储类
对于特定的公有云，建议用于生产工作负载的存储类如下表所示。
| 提供程序 | 已验证且推荐的存储 |
|---|---|
| Azure Kubernetes 服务 (AKS) | Azure 托管磁盘（高级层） |
| Amazon Elastic Kubernetes Service (EKS) | EBS CSI 存储驱动程序 |
| Google (GKE) | GCE 永久性磁盘 |
在本地或多云方案中选择生产 StorageClass 时，请确保它能够满足你的预期存储容量、IOPS、冗余和吞吐量需求。 下列各部分提供了有关这些方案的更多建议。
数据控制器设计
选择远程共享 StorageClass 来确保数据持续性。 如果删除 Pod 或节点，可将 Pod 备份并再次连接到永久性卷。 带下划线的 StorageClass 必须提供冗余和高可用性。
建议在创建已启用 Arc 的数据服务数据控制器时使用自定义部署模板。 使用自定义模板可微调存储类、数据和日志的存储大小、安全性和 Kubernetes 服务类型。 可根据你的环境和企业需求来自定义它们。 Azure Arc 数据控制器总共需要 8 个永久性卷。 如果是默认最小配置，则可对 PV 上的数据使用 15Gi，对日志使用 10Gi。 配置的容量不仅要满足最低推荐容量，还要支持在群集中运行许多已启用 Arc 的 SQL 托管实例实现而带来的更高增长。 此配置让你将来无需重设 PVC 的大小。
如果你的群集具有许多数据库和已启用 Arc 的 SQL 托管实例部署，我们建议选择延迟更低的 StorageClass。 延迟更低，则 Grafana 和 Kibana 接口中的用户体验更好。
已启用 Azure Arc 的 SQL 托管实例迁移
建议规划和考虑在迁移和部署已启用 Arc 的 SQL 托管实例时所涉及的所有新的数据库和现有数据库。 规划免除了以后在实例之间移动数据库的需求。
根据你的 Kubernetes 群集组织，按照需要将已启用 Arc 的 SQL 托管实例部署预配到不同的 Kubernetes 群集，来将环境（非专业、专业）、区域和其他业务因素分开。 要获取更多建议，请查看 资源组织设计区域。 在群集上配置多个数据库实例时，请务必将忙碌的数据库分隔到其自己的实例中，以避免 I/O 争用。
使用节点标签来确保将数据库实例放置在单独的节点上，以便跨多个节点分配整个 I/O 流量。具体请参阅 Kubernetes 节点标签；若要配置标签，请参阅 Kubernetes 节点关联和反关联标签。 如果在虚拟化环境中运行，请确保 I/O 在物理主机级别适当分布。
规划已启用 Arc 的 SQL 托管实例的容量，包含足够的存储大小供 Data、Logs、DataLogs 和 Backups 使用。 如果规划容量，使其既满足当前的需求，又满足已启用 Arc 的 SQL 托管实例的实例上存在的所有数据库的预计增长，那么将来无需重设 PVC 的大小。 为 Data 和 DataLogs 选择单独的物理驱动器，来实现并行 I/O 活动。 并行 I/O 活动可避免使用共享驱动器时可能引起的争用情况，从而提高性能。
虽然有几个因素可能决定是部署已启用 Arc 的 SQL 托管实例的业务关键层还是常规用途层，但使用本地存储的业务关键层可提供最低的延迟和最高的可用性。 要了解有关时间点还原、高可用性和灾难恢复的建议，请查看已启用 Arc 的 SQL 托管实例业务连续性设计区域。 此外，请查看已启用 Arc 的 SQL 托管实例成本治理设计区域，详细了解不同层之间的成本影响。
下面的子部分为每个层提供了更具体的建议：
“常规用途”服务层级建议
为了获得最佳性能，建议为 Data 和 DataLogs 永久性卷选择低延迟远程 StorageClass。 避免使用引入网络分区的 StorageClass，例如将本地群集配置为对 Backup 和 Logs 永久性卷使用 Internet 提供的 StorageClass。
“业务关键”服务层级建议
建议查看可用性模式差异，这要求对每个选定模式使用不同的配置。
对于要求尽量降低延迟的方案，请选择本地存储（如果你的 Kubernetes 基础结构可使用它）。 本地存储卷应位于不同的基础存储设备上，以避免磁盘 I/O 上出现争用并最大程度地提高性能。 存储设备不得具有托管操作系统分区等多个功能。
对于读取密集型工作负载和高可用性，请配置多个副本，并将应用程序或客户端配置为将次要副本用作读取扩展实例。 次要副本默认不可读，你可配置此设置。
监视
建议监视已启用 Arc 的数据服务创建的所有 PVC，包括 Azure Arc 数据控制器和群集中已启用 Arc 的 SQL 托管实例的所有实例。 设置警报，以便在 PVC 接近容量上限时收到通知。 有了通知，你可在达到容量上限之前重设 PVC 的大小。 对于直接连接的群集，由 Azure Monitor 和容器见解来监视 PVC 和发出警报。 使用间接连接的群集时，在 Grafana 和 Kibana 中执行监视和警报。 Grafana 安装项包括用于已启用 Arc 的 SQL 托管实例指标和 Kubernetes 资源的仪表板。
有关监视已启用 Arc 的 SQL 托管实例的更多建议，请查看已启用 Arc 的 SQL 托管实例治理规则。
后续步骤
有关混合和多云云旅程的详细信息，请参阅以下文章：
- 查看已启用 Azure Arc 的数据服务的存储配置。
- 查看已启用 Azure Arc 的数据服务的已验证 Kubernetes 发行版。
- 查看已启用 Azure Arc 的数据服的大小调整指南。
- 使用已启用 Arc 的 SQL 托管实例的使用 Grafana 和 Kibana 进行监视。
- 使用 Azure Arc Jumpstart 体验已启用 Arc 的 SQL 托管实例自动化方案。
- 若要详细了解 Azure Arc，请查看 Microsoft Learn 上的 Azure Arc 学习路径。