你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

调整大小指南

  • 项目

调整大小指南概述

规划 Azure Arc 数据服务的部署时，请规划正确数量的以下项：

  • 计算
  • 内存
  • 存储

这些资源需要用于：

  • 数据控制器
  • SQL 托管实例
  • PostgreSQL 服务器

由于由 Azure Arc 启用的数据服务部署在 Kubernetes 上，因此随着时间的推移，可以通过计算节点或存储灵活地为 Kubernetes 群集添加更多容量。 本指南说明了最低要求并针对一些常见要求推荐了大小。

一般调整大小要求

注意

如果不熟悉本文中的概念，可以阅读有关 Kubernetes 资源治理和 Kubernetes 大小表示法的详细信息。

内核数必须是大于或等于一的整数值。

使用 Azure CLI (az) 进行部署时，请使用 2 的幂来设置内存值。 具体来说，请使用后缀：

  • Ki
  • Mi
  • Gi

限制值必须始终大于请求值（如果指定）。

在 SQL 托管实例和 PostgreSQL 服务器上，内核的限制值是计费指标。

最低部署要求

已启用 Azure Arc 的数据服务的最低部署大小可以视为：Azure Arc 数据控制器加一个 SQL 托管实例，再加一个 PostgreSQL 服务器。 对于这种配置，Kubernetes 群集上至少需要提供 16 GB RAM 和 4 个核心的可用容量。 应确保所用 Kubernetes 节点大小至少提供 8 GB RAM 和 4 个核心，并且所有 Kubernetes 节点总共有 16 GB RAM 可用容量。 例如，可以使用 1 个节点，具有 32 GB RAM 和 4 个核心；或者使用 2 个节点，分别具有 16 GB RAM 和 4 个核心。

有关存储调整大小的详细信息，请参阅“存储配置”一文。

数据控制器调整大小详细信息

数据控制器是部署到 Kubernetes 群集的 pod 集合，用于提供 API、控制器服务、引导程序以及监视数据库和仪表板。 下表描述了内存和 CPU 请求及限制的默认值。

Pod 名称 CPU 请求 内存请求 CPU 限制 内存限制
bootstrapper 100m 100Mi 200m 200Mi
control 400m 2Gi 1800m 2Gi
controldb 200m 4Gi 800m 6Gi
logsdb 200m 1600Mi 2 1600Mi
logsui 100m 500Mi 2 2Gi
metricsdb 200m 800Mi 400m 2Gi
metricsdc 100m 200Mi 200m 300Mi
metricsui 20m 200Mi 500m 200Mi

metricsdc 是在群集中的每个 Kubernetes 节点上创建的 daemonset。 表中的数字按节点列出。 如果创建数据控制器之前在部署配置文件中设置了 allowNodeMetricsCollection = false，则不会创建这个 daemonset。

可以在数据控制器 YAML 文件中替代 controldb 和控制 Pod 的默认设置。 示例：

  resources:
    controller:
      limits:
        cpu: "1000m"
        memory: "3Gi"
      requests:
        cpu: "800m"
        memory: "2Gi"
    controllerDb:
      limits:
        cpu: "800m"
        memory: "8Gi"
      requests:
        cpu: "200m"
        memory: "4Gi"

有关存储调整大小的详细信息，请参阅“存储配置”一文。

SQL 托管实例调整大小详细信息

每个 SQL 托管实例都必须具有以下最低资源请求和限制：

服务层 常规用途 业务关键
CPU 请求 最小值：1
最大值：24
默认值：2		 最小值：3
最大值：无限制
默认值：4
CPU 限制 最小值：1
最大值：24
默认值：2		 最小值：3
最大值：无限制
默认值：4
内存请求 最小值：2Gi
最大值：128Gi
默认值：4Gi		 最小值：2Gi
最大值：无限制
默认值：4Gi
内存限制 最小值：2Gi
最大值：128Gi
默认值：4Gi		 最小值：2Gi
最大值：无限制
默认值：4Gi

创建的每个 SQL 托管实例 Pod 都有三个容器：

容器名称 CPU 请求 内存请求 CPU 限制 内存限制 说明
fluentbit 100m 100Mi 未指定 未指定 fluentbit 容器资源请求是除了为 SQL 托管实例指定的请求之外的请求。
arc-sqlmi 用户指定或未指定。 用户指定或未指定。 用户指定或未指定。 用户指定或未指定。
collectd 未指定 未指定 未指定 未指定

所有永久性卷的默认卷大小均为 5Gi。

PostgreSQL 服务器大小详细信息

每个 PostgreSQL 服务器节点都必须满足以下最低资源请求：

  • 内存：256Mi
  • 内核数：1 个

创建的每个 PostgreSQL 服务器 Pod 都有三个容器：

容器名称 CPU 请求 内存请求 CPU 限制 内存限制 说明
fluentbit 100m 100Mi 未指定 未指定 fluentbit 容器资源请求是除了为 PostgreSQL 服务器指定的请求之外的请求。
postgres 用户指定或未指定。 用户指定或 256Mi（默认）。 用户指定或未指定。 用户指定或未指定。
arc-postgresql-agent 未指定 未指定 未指定 未指定

累计调整大小

由 Azure Arc 启用的数据服务所需的环境整体大小主要取决于数据库实例的数量和大小。 整体大小可能很难提前预测，我们知道实例数量可能会不断增加和减少，每个数据库实例所需的资源量也可能会变化。

给定的由 Azure Arc 启用的数据服务环境的基线大小为需要 4 个核心和 16 GB RAM 的数据控制器的大小。 在此基础之上添加数据库实例所需的累计总核心数和总内存。 SQL 托管实例要求一个实例一个 Pod。 PostgreSQL 服务器为每台服务器创建一个 Pod。

除为每个数据库实例请求的核心和内存之外，还应为代理容器添加 250m 核心和 250Mi RAM 容量。

调整大小计算示例

要求：

  • “SQL1”：1 个 SQL 托管实例，具有 16 GB RAM、4 个核心
  • “SQL2”：1 个 SQL 托管实例，具有 256 GB RAM、16 个核心
  • “Postgres1”：1 PostgreSQL 服务器，具有 12 GB RAM、4 个核心

大小计算方式：

  • “SQL1”的大小为 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores])。 对于每个 Pod 的代理，请使用 16.25 Gi RAM 和 4.25 个核心。

  • “SQL2”的大小为 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores])。 对于每个 Pod 的代理，请使用 256.25 Gi RAM 和 16.25 个核心。

  • SQL1 和 SQL2 的总大小为：

    • (16.25 GB + 256.25 Gi) = 272.5-GB RAM
    • (4.25 cores + 16.25 cores) = 20.5 cores

  • “Postgres1”的大小为 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores])。 对于每个 Pod 的代理，请使用 12.25 Gi RAM 和 4.25 个核心。

  • 所需的总容量：

    • 数据库实例：
      • 272.5 GB RAM
      • 20.5 个核心
    • 对于 SQL：
      • 12.25 GB RAM
      • 4.25 个核心
    • PostgreSQL 服务器：
      • 284.75 GB RAM
      • 24.75 个核心

  • 数据库实例和数据控制器所需的总容量为：

    • 数据库实例：
      • 284.75 GB RAM
      • 24.75 个核心
    • 数据控制器：
      • 16-GB RAM
      • 4 核
    • 总计：
      • 300.75 GB RAM
      • 28.75 个核心。

有关存储调整大小的详细信息，请参阅“存储配置”一文。

其他注意事项

切记，对于内核或 RAM 指定的数据库实例请求大小不能超过群集中 Kubernetes 节点的可用容量。 例如，如果 Kubernetes 群集中的最大 Kubernetes 节点为 256 GB RAM 和 24 个核心，则无法创建请求 512 GB RAM 和 48 个核心的数据库实例。

跨 Kubernetes 节点保持至少 25% 的可用容量。 此容量使 Kubernetes 能够：

  • 高效调度要创建的 Pod
  • 启用弹性缩放
  • 支持 Kubernetes 节点的滚动升级
  • 促进长期的按需增长

在计算大小时，请添加 Kubernetes 系统 Pod 和任何其他工作负载的资源需求，它们可能与同一 Kubernetes 群集中由 Azure Arc 启用的数据服务共享容量。

如果要在进行计划内维护和灾难持续期间保持高可用性，请针对群集中至少一个 Kubernetes 节点在任何指定时间点都无法使用的情况做好计划。 Kubernetes 会尝试重新安排因维护或故障而停止的节点上运行的 Pod。 如果剩余的节点上没有可用容量，则在重新具有可用容量之前不会重新计划创建这些 Pod。 对于大型数据库实例要特别小心。 例如，如果只有一个大型 Kubernetes 节点可以满足大型数据库实例的资源需求，但该节点发生故障，则 Kubernetes 不会再将该数据库实例 Pod 调度到其他 Kubernetes 节点上。

切记 Kubernetes 群集大小的上限。

Kubernetes 管理员可能已对你的命名空间/项目设置资源配额。 在规划数据库实例大小时，切记这些配额。