3.3. 容量プランニングの演習例

この容量プランニングの演習例では、次のワークロード要件を使用します。

実行容量

制御容量

必要な実行ノードとコントロールノードの数の決定

必要な実行ノードとコントロールノードの数を決定するには、次の表に示す実験結果を参照してください。この表は、1 つのコントロールノードに対して同サイズの実行ノードが 5 つある場合に確認されたイベント処理速度を示しています (API 容量の列)。ジョブテンプレートのデフォルトの “フォーク” 設定は 5 です。そのため、このデフォルト値を使用すると制御容量と実行容量の比率が前述の 1:5 になり、ディスパッチ可能な最大数のジョブをコントロールノードが実行ノードにディスパッチした場合に、CPU/RAM が等しい 5 つの実行ノードが容量を 100% 使用することになります。

ジョブの制御はコントロールノード上のジョブイベント処理と競合するため、制御容量をオーバープロビジョニングすると処理時間が短縮される可能性があります。処理時間が長い場合、ジョブの実行から API または UI で出力を表示できるようになるまでに遅延が発生する可能性があります。

この例において、300 台の管理対象ホストのワークロードがあり、ホストごとに 1 時間あたり 1000 個のタスクを実行し、Playbook でフォークを 5 に設定した 10 個の同時実行ジョブがあり、平均イベントサイズが 1 MB の場合、次の手順を使用します。

高レベルの API インタラクションを伴うワークロードの詳細は、Scaling Automation Controller for API Driven Workloads を参照してください。インスタンスによる容量の管理に関する詳細は、インスタンスによる容量の管理 を参照してください。Operator ベースのデプロイメントの詳細は、Operator 環境に関する Red Hat Ansible Automation Platform の考慮事項 を参照してください。