サイズ設定のガイダンス

  • [アーティクル]

サイズ設定のガイダンスの概要

Azure Arc データ サービスのデプロイを計画するときは、以下のものの正しい量を計画します:

  • Compute
  • [メモリ]
  • Storage

以下には、これらのリソースが必要です:

  • データ コントローラー
  • SQL マネージド インスタンス
  • PostgreSQL サーバー

Azure Arc 対応データ サービスは Kubernetes にデプロイされるため、コンピューティング ノードまたはストレージによって時間の経過と同時に Kubernetes クラスターに容量を追加できる柔軟性があります。 このガイドでは、最小要件について説明し、いくつかの一般的な要件のサイズをおすすめします。

サイズ設定の一般的な要件

Note

この記事で説明する概念になじみがない場合は、Kubernetes リソースのガバナンスおよび Kubernetes のサイズ表記の詳細を参照できます。

コア数の値は 1 以上の整数値である必要があります。

Azure CLI (az) を使用してデプロイする場合は、2 つの数値の累乗を使用してメモリ値を設定します。 具体的には、サフィックスを使用します:

  • Ki
  • Mi
  • Gi

制限値は常に、要求値 (指定されている場合) を超えている必要があります。

コアの制限値は、SQL Managed Instance と PostgreSQL サーバーに対する課金可能なメトリックです。

最小のデプロイ要件

Azure Arc 対応データ サービスの最小デプロイ サイズは、Azure Arc データ コントローラーに加えて、1 つの SQL Managed Instance と 1 つの PostgreSQL サーバーと考えることができます。 この構成では、Kubernetes クラスター上で少なくとも 16 GB RAM と 4 コアの容量が使用可能である必要があります。 8 GB RAM と 4 コアという最小の Kubernetes ノード サイズと、すべての Kubernetes ノードにわたって使用可能な 16 GB RAM の合計容量があることを確認する必要があります。 たとえば、32 GB RAM と 4 コアのノードを 1 つ使用することも、それぞれが 16 GB RAM と 4 コアのノードを 2 つ使用することもできます。

ストレージのサイズ設定の詳細については、ストレージ構成に関する記事を参照してください。

データ コントローラーのサイズ設定の詳細

データ コントローラーは、API、コントローラー サービス、ブートストラップ、監視データベースおよびダッシュボードを提供するために Kubernetes クラスターにデプロイされるポッドのコレクションです。 次の表は、メモリおよび CPU 要求の既定値と制限を示しています。

ポッド名 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 と制御ポッドの既定の設定をオーバーライドできます。 例:

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

ストレージのサイズ設定の詳細については、ストレージ構成に関する記事を参照してください。

SQL Managed Instance のサイズ設定の詳細

各 SQL マネージド インスタンスには、次の最小リソース要求と制限が必要です。

サービス レベル General Purpose Business Critical
CPU 要求 最小値: 1
最大: 24
既定値: 2		 最小: 3
最大: 無制限
既定値: 4
CPU 制限 最小値: 1
最大: 24
既定値: 2		 最小: 3
最大: 無制限
既定値: 4
メモリ要求 最小値: 2Gi
最大値: 128Gi
既定値: 4Gi		 最小値: 2Gi
最大: 無制限
既定値: 4Gi
メモリ制限 最小値: 2Gi
最大値: 128Gi
既定値: 4Gi		 最小値: 2Gi
最大: 無制限
既定値: 4Gi

作成される各 SQL Managed Instance ポッドには、次の 3 つのコンテナーがあります。

コンテナー名 CPU 要求 メモリ要求 CPU の制限 メモリの制限 メモ
fluentbit 100m 100Mi 指定なし 指定なし fluentbit コンテナー リソース要求は、SQL Managed Instance に対して指定された要求に追加されます。
arc-sqlmi ユーザー指定または指定なし。 ユーザー指定または指定なし。 ユーザー指定または指定なし。 ユーザー指定または指定なし。
collectd 指定なし 指定なし 指定なし 指定なし

すべての永続ボリュームの既定のボリューム サイズは 5Gi です。

PostgreSQL サーバーのサイズ設定の詳細

各 PostgreSQL サーバー ノードには、次の最小リソース要求が必要です。

  • メモリ: 256Mi
  • コア: 1

作成される各 PostgreSQL サーバー ポッドには、次の 3 つのコンテナーがあります。

コンテナー名 CPU 要求 メモリ要求 CPU の制限 メモリの制限 メモ
fluentbit 100m 100Mi 指定なし 指定なし fluentbit コンテナー リソース要求は、PostgreSQL サーバーに対して指定された要求に追加されます。
postgres ユーザー指定または指定なし。 ユーザー指定または 256Mi (既定値)。 ユーザー指定または指定なし。 ユーザー指定または指定なし。
arc-postgresql-agent 指定なし 指定なし 指定なし 指定なし

累積的なサイズ設定

Azure Arc 対応データ サービスに必要な環境の全体的なサイズは、主にデータベース インスタンスの数とサイズの関数です。 インスタンスの数が増えたり減ったりするほか、各データベース インスタンスに必要なリソースの量も変化することがわかっているため、全体的なサイズを事前に予測することは困難な場合があります。

特定の Azure Arc 対応データ サービス環境のベースライン サイズは、4 コアと 16 GB RAM を必要とするデータ コントローラーのサイズです。 そこから、データベース インスタンスに必要なコアとメモリの累積合計を追加します。 SQL Managed Instance には、インスタンスごとに 1 つのポッドが必要です。 PostgreSQL サーバーは、サーバーごとに 1 つのポッドを作成します。

各データベース インスタンスに対して要求するコアとメモリに加えて、エージェント コンテナーの 250m のコアと 250Mi の RAM を追加する必要があります。

サイズ設定の計算例

要件:

  • "SQL1": 16 GB の RAM を持つ 1 つの SQL マネージド インスタンス、4 コア
  • "SQL2": 256 GB の RAM を備えた 1 つの SQL マネージド インスタンス、16 コア
  • "Postgres1": 12 GB RAM で 1 PostgreSQL サーバー、4 コア

サイズ計算:

  • "SQL1" のサイズは 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]) です。 ポッドあたりのエージェントには、16.25 Gi RAM と 4.25 コアを使用します。

  • "SQL2" のサイズは 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]) です。 ポッドあたりのエージェントには、256.25 Gi RAM と 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]) です。 ポッドあたりのエージェントには、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 は次のことができます:

  • ポッドの作成スケジュールを効率的に設定する
  • エラスティック スケーリングを有効にする
  • Kubernetes ノードのローリング アップグレードをサポートします
  • 需要に応じて長期的な成長を促進します

サイズ計算では、Kubernetes システム ポッドのリソース要件や、同じ Kubernetes クラスター上で Azure Arc 対応データ サービスと容量を共有している可能性があるその他のすべてのワークロードを追加します。

計画メンテナンス中や障害が継続している間も高可用性を維持するには、特定の時点でクラスター内の Kubernetes ノードの少なくとも 1 つが使用不可になるよう計画します。 Kubernetes は、メンテナンスまたは障害のために停止された特定のノードで実行されていたポッドのスケジュールを変更しようとします。 残りのノードで使用可能な容量がない場合、それらのポッドは、使用可能な容量が再び存在するまで、作成のための再スケジュールは行われません。 大規模なデータベース インスタンスの場合は、特に注意してください。 たとえば、大規模なデータベース インスタンスのリソース要件を満たすだけの十分な大きさを持つ Kubernetes ノードが 1 つしか存在しない場合、そのノードに障害が発生すると、Kubernetes はそのデータベース インスタンス ポッドを別の Kubernetes ノードにスケジュールできません。

常に Kubernetes クラスター サイズの最大制限を念頭においてください。

Kubernetes 管理者が名前空間/プロジェクトにリソース クォータを設定している可能性があります。 データベース インスタンスのサイズを計画する場合には、これらのクォータを念頭においてください。