サイズ設定のガイダンス

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

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

• Compute
• [メモリ]
• Storage

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

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

Azure Arc 対応データ サービスは 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 要求の既定値と制限を示しています。

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 マネージド インスタンスには、次の最小リソース要求と制限が必要です。

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

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

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

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

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

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

累積的なサイズ設定

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