調整大小指導
調整大小指導的概觀
規劃 Azure Arc 資料服務的部署時，請規劃正確的數量：
- 計算
- 記憶體
- 儲存體
需要下列資源：
- 資料控制器
- SQL 受管理的執行個體
- PostgreSQL 伺服器
由於已啟用 Azure Arc 的資料服務部署在 Kubernetes 上，因此隨著時間的推移，您可依計算節點或儲存體，彈性地將更多容量新增至 Kubernetes 叢集。 本指南說明最低需求，並建議一些常見需求的大小。
一般調整大小需求
注意
如果您不熟悉本文中的概念，您可以深入瞭解 Kubernetes 資源治理和 Kubernetes 大小標記法。
核心數必須是大於或等於一的整數值。
當您使用 Azure CLI (az) 進行部署時，請使用 2 的次方來設定記憶體值。 具體而言，請使用尾碼：
KiMiGi
如果指定，限制值一律必須大於要求值。
核心值上限是 SQL 受控執行個體和 PostgreSQL 伺服器上的可計費計量。
部署需求下限
已啟用 Azure Arc 的資料服務部署大小下限，可視為 Azure Arc 資料控制器加上一個 SQL 受控執行個體，再加上一個 PostgreSQL 伺服器。 針對此設定，您在 Kubernetes 叢集上需要至少 16 GB 的 RAM 和 4 個可用容量核心。 您應該確定 Kubernetes 節點大小下限為 8 GB RAM 和 4 個核心，而所有 Kubernetes 節點可用的容量總計為 16 GB RAM。 例如，您可以在 32 GB RAM 和 4 個核心有 1 個節點，或者在 16 GB RAM 和 4 個核心有 2 個節點。
如需儲存體調整大小的詳細資訊，請參閱儲存體設定一文。
資料控制器調整大小詳細資料
資料控制器是部署至 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 為 daemonset，這是在叢集中每個 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
每個建立的 SQL 伺服器 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 個具有 16 GB RAM，4 個核心的 SQL 受控執行個體
- "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 GiRAM 和 4.25 個核心。“SQL2” 的大小為：
1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores])。 針對每個 Pod 的代理程式，使用256.25 GiRAM 和 16.25 個核心。SQL 1 和 SQL 2 的總大小為：
(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 GiRAM 和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 管理員可能已在命名空間/專案上設定資源配額。 規劃資料庫執行個體大小時，請記住這些配額。