3.2. Automation controller Pod コンテナーの推奨サイズ

概要セクションの 図1.1「Automation Controller のアーキテクチャー」 を確認すると、制御 Pod にコンテナーが 4 台含まれていることがわかります。

これらのコンテナーはそれぞれ、Ansible Automation コントローラーで独自の機能を実行するため、リソース設定が制御 Pod にどのように影響するかを理解することが重要です。デフォルトでは、Red Hat OpenShift にはテストとしてインストールする最低条件を満たす程度の低いリソース値が含まれていますが、実稼働環境で Ansible Automation Platform を実行するには最適ではありません。

Ansible Automation Platform の Red Hat OpenShift のデフォルトは次のとおりです。

デフォルトでは、Red Hat OpenShift は最大リソース制限を設定せず、Ansible Automation Platform 制御 Pod によって要求されたすべての可能なリソースを割り当てようとします。この設定は、リソースの枯渇を引き起こし、Red Hat OpenShift クラスターで実行されている他のアプリケーションに影響を与える可能性があります。

制御 Pod 内のコンテナーのリソースリクエストと制限に関するスタート地点を示すため、以下の前提条件を使用します。

制御 Pod 内のコンテナーのサイジングに関しては、ワークロードの詳細を考慮することが重要です。このリファレンス環境に固有の推奨事項に沿ったパフォーマンステストを実施しましたが、これらの推奨事項はすべてのタイプのワークロードに適用できるわけではありません。

スタート地点として、Performance Collection playbooks (具体的には chatty_tasks.yml) を利用することにしました。

パフォーマンスベンチマークは、以下のとおりです。

chatty_tasks ジョブテンプレートは、ansible.builtin.debug モジュールを利用して、ホストごとに設定された数のデバッグメッセージを生成し、必要なインベントリーを生成します。ansible.builtin.debug モジュールを利用することで、追加のオーバーヘッドを導入することなく、Automation controller のパフォーマンスを正確に表現できます。

ジョブテンプレートは、ジョブテンプレートの同時呼び出しの数を示す 10 ~ 50 の範囲の指定された同時実行レベルで実行されました。

以下に記載されている リソース要求 および リソース制限 は、パフォーマンスベンチマークの結果で、同様のリソースを使用する Red Hat OpenShift クラスターで AAP を実行する際の開始ベースラインとして使用できます。

spec:
...
  ee_resource_requirements:
    limits:
      cpu: 500m
      memory: 400Mi
    requests:
      cpu: 100m
      memory: 400Mi
  task_resource_requirements:
    limits:
      cpu: 4000m
      memory: 8Gi
    requests:
      cpu: 1000m
      memory: 8Gi
  web_resource_requirements:
    limits:
      cpu: 2000m
      memory: 1.5Gi
    requests:
      cpu: 500m
      memory: 1.5Gi
  redis_resource_requirements:
    limits:
      cpu: 500m
      memory: 1.5Gi
    requests:
      cpu: 250m
      memory: 1.5Gi