az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'
数据控制器存储配置
Azure Arc 中用于数据服务的某些服务需要配置为使用远程共享存储，因为这些服务不能复制数据。 这些服务位于数据控制器 Pod 的集合中：
Service
永久性卷声明
预配数据控制器时，用于其中每个永久性卷的存储类通过以下方式之一进行指定：将 --storage-class | -sc 参数传递到 az arcdata dc create 命令，或者在所用的 control.json 部署模板文件中设置存储类。 如果使用 Azure 门户在直接连接模式下创建数据控制器，则所选的部署模板将在模板中预定义存储类，或者可以选择没有预定义的存储类的模板。 如果模板未定义存储类，门户会提示你输入一个。 如果使用自定义部署模板，则可以指定存储类。
部署模板是现成可用的，为其指定的默认存储类适用于目标环境，但可以在部署过程中重写该默认存储类。 请参阅创建自定义配置模板的详细步骤，以在部署时更改数据控制器 Pod 的存储类配置。
如果使用 --storage-class 或 -sc 参数设置存储类，则该存储类将用于日志和数据存储类。 如果在部署模板文件中设置存储类，则可以为日志和数据指定不同的存储类。
为数据控制器 Pod 选择存储类时要考虑的重要因素：
You must use a remote, shared storage class in order to ensure data durability and so that if a pod or node dies that when the pod is brought back up it can connect again to the persistent volume.
写入控制器 SQL 实例、指标 DB 和日志 DB 的数据的容量通常非常低，对延迟不敏感，因此超快性能存储并不重要。 如果你的用户频繁使用 Grafana 和 Kibana 接口，并且你有大量的数据库实例，则你的用户可能从更快的存储中获益。
所需的存储容量随已部署的数据库实例数量而变化，因为针对每个数据库实例收集日志和指标。 数据在日志和指标 DB 中保留两 (2) 周，然后才被清除。
更改存储类后期部署很困难，并且不会对其进行记录，也不支持这么做。 请确保在部署时正确选择存储类。
如果未指定存储类，将使用默认的存储类。 每个 Kubernetes 群集只能有一个默认的存储类。 你可以更改默认的存储类。
数据库实例存储配置
每个数据库实例都包含数据、日志和备份永久性卷。 可以在部署时指定这些永久性卷的存储类。 如果未指定存储类，将使用默认的存储类。
使用 az sql mi-arc create 或 az postgres server-arc create 创建实例时，可以使用四个参数来设置存储类：
参数名称，简短名称
Used for
对于数据文件、日志和备份，每个数据库实例都有一个单独的永久性卷。 这意味着根据卷配置程序预配存储的方式，将为每种文件类型分离 I/O。 每个数据库实例都有其自己的永久性卷声明和永久性卷。
如果给定数据库实例上有多个数据库，则所有数据库都将使用相同的永久卷声明、永久性卷和存储类。 所有备份（差异日志备份和完整备份）都将使用相同的永久卷声明和永久性卷。 数据库实例 Pod 的永久性卷声明如下所示：
Instance
永久性卷声明
为数据库实例 Pod 选择存储类时要考虑的重要因素：
Starting with the February, 2022 release of Azure Arc data services, you need to specify a ReadWriteMany (RWX) capable storage class for backups. Learn more about access modes. 如果没有为备份指定存储类，则使用 Kubernetes 中的默认存储类；如果该类不支持 RWX，则 Azure SQL 托管实例部署可能不会成功。
可以在单个 Pod 模式或多个 Pod 模式下部署数据库实例。 单个 Pod 模式的示例是常规用途定价层 Azure SQL 托管实例。 多个 Pod 模式的示例是高度可用的业务关键型定价层 Azure SQL 托管实例。 Database instances deployed with the single pod pattern must use a remote, shared storage class in order to ensure data durability and so that if a pod or node dies that when the pod is brought back up it can connect again to the persistent volume. 与此相反，高度可用 Azure SQL 托管实例使用 Always On 可用性组，以同步或异步方式将数据从一个实例复制到另一个实例。 尤其是在同步复制数据的情况下，更是如此，届时始终会存在多个数据副本（通常为三个副本）。 因此可以为数据和日志文件使用本地存储或远程共享存储类。 如果利用本地存储，即使 Pod、节点或存储硬件发生故障，仍会保留数据，因为有多个数据副本。 由于这种灵活性，你可以选择使用本地存储来提高性能。
数据库性能很大程度上取决于给定存储设备的 I/O 吞吐量。 如果数据库进行大量读取或大量写入，则选择的存储类应具有为该类型工作负荷设计的硬件。 例如，如果数据库主要用于写入，建议选择使用 RAID 0 的本地存储。 如果数据库主要用于读取少量“热数据”，但总体上冷数据存储量很大，则可以选择支持分层存储的 SAN 设备。 选择适当的存储类与选择用于任何数据库的存储类型的差别不大。
如果使用本地存储卷配置程序，请确保为数据、日志和备份预配的本地卷各自登录到不同的基础存储设备，以避免磁盘 I/O 争用。 OS 还应位于装载到单独磁盘的卷上。 这实质上是物理硬件上数据库实例应遵循的相同指导原则。
由于给定实例上的所有数据库共享永久性卷声明和永久性卷，因此请确保不要将繁忙数据库实例同时放在同一数据库实例上。 如果可能，请将繁忙数据库单独置于其自己的数据库实例中以避免 I/O 争用。 此外，使用节点标签以将数据库实例置于不同节点上，以便在多个节点之间分配总体 I/O 流量。 如果使用虚拟化，则务必要考虑不只是在节点级别分配 I/O 流量，还要在给定物理主机上所有节点 VM 所产生的组合 I/O 活动级别进行分配。
预估存储要求
每个包含有状态数据的 Pod 都使用至少两个永久性卷：一个永久性卷用于数据，另一个永久性卷用于日志。 下表列出了单个数据控制器和 Azure SQL 托管实例所需的永久性卷数：
Resource Type
有状态 Pod 数量
所需的永久性卷数量
此计算可用于基于存储配置程序或环境为 Kubernetes 群集规划存储。 例如，如果本地存储配置程序用于具有五 (5) 个节点的 Kubernetes 群集，那么对于上述示例部署，每个节点至少需要 10 个永久性卷的存储。 同样地，在预配具有五 (5) 个节点的 Azure Kubernetes 服务 (AKS) 群集时，为可以附加 10 个数据磁盘的节点池挑选合适的 VM 大小是非常重要的。 More details on how to size the nodes for storage needs for AKS nodes can be found here.
选择适当的存储类
本地和边缘站点
Microsoft 及其 OEM、OS 和 Kubernetes 合作伙伴为 Azure Arc 数据服务提供认证计划。 此计划提供与认证测试工具包的结果相似的测试结果。 这些测试评估功能兼容性、压力测试结果以及性能和可伸缩性。 测试结果将指出已使用的 OS、已使用的 Kubernetes 分发、已使用的 HW、已使用的 CSI 附加产品以及已使用的存储类。 这将帮助客户选择符合其要求的最佳存储类、OS、Kubernetes 分发软件和硬件。 More information on this program and test results can be found here.
公有云，托管 Kubernetes 服务
对于基于公有云的托管 Kubernetes 服务，我们提出以下建议：
公有云服务
Recommendation
Azure Kubernetes 服务 (AKS)
Azure Kubernetes 服务 (AKS) 有两种类型的存储 - Azure 文件存储和 Azure 托管磁盘。 每种类型的存储有两个定价/性能层 - 标准 (HDD) 和高级 (SSD)。 因此，在 AKS 中提供四个存储类：azurefile（Azure 文件存储标准层）、azurefile-premium（Azure 文件存储高级层）、default（Azure 磁盘标准层）和 managed-premium（Azure 磁盘高级层）。 默认存储类是 default（Azure 磁盘标准层）。 There are substantial pricing differences between the types and tiers that you should consider. 对于具有高性能要求的生产工作负荷，我们建议对所有存储类使用 managed-premium。 对于需要考虑成本的开发/测试工作负荷、概念证明等，azurefile 是成本最低的选项。 所有这四种选项都可用于需要远程共享存储的情况，因为它们都是 Azure 中网络附加存储设备。 Read more about AKS Storage.
)AWS 弹性 Kubernetes 服务 (EKS
亚马逊的 Elastic Kubernetes Service 有一个基于 EBS CSI 存储驱动程序的主存储类。 建议对于生产工作负荷使用该存储类。 可将新的存储驱动程序 - EFS CSI 存储驱动程序添加到 EKS 群集，但它目前处于 beta 阶段，可能会有所更改。 尽管 AWS 指出此存储驱动程序支持用于生产，但我们不建议使用它，因为它仍处于 beta 阶段并且可能有所更改。 EBS 存储类为默认值，它称为 gp2。 Read more about EKS Storage.
Google Kubernetes 引擎 (GKE)
Google Kubernetes Engine (GKE) 只包含一个名为 standard 的存储类。 此类用于 GCE 永久性磁盘。 它是唯一的，也是默认的。 虽然为 GKE 提供了一个可用于直连式 SSD 的本地静态卷配置程序，但我们不建议使用它，因为它不是由 Google 维护或提供支持的。 Read more about GKE storage.
