Red Hat OpenShift への Ansible Automation Platform 2 のデプロイ

リソース管理に関する 2 つの重要なリソースは、CPU とメモリー (RAM) です。Red Hat OpenShift は、リソース要求とリソース制限を使用して、コンテナーが 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

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

chatty_task Playbook を使用してパフォーマンスベンチマークテストを実施した後、CPU リソース要求が 500m 未満になると、リソース制限よりも低いものの、初期リソース要求よりも多い場合には、追加のリソースが Pod に対して確保することが保証されないので、Postgres Pod で CPU スロットリングを引き起こす可能性があります。ただし、テスト中に 500m 要求を超えるバーストがあったため、CPU 制限は 1000m (1 vCPU) に設定されました。

メモリーに関しては、メモリーは圧縮可能なリソースではないため、chatty_task パフォーマンステスト中に、テストの最高レベルの Postgres Pod が 650Mi をわずかに超える RAM を消費したことがわかります。

したがって、このような結果をもとにすると、このリファレンス環境で推奨されるメモリーリソースの要求および制限は1Gi で、この程度あれば、十分なバッファーを提供し、Postgres Pod で Out Of Memory (OOM) Kill が発生する可能性を回避します。

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

spec:
...
  postgres_resource_requirements:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 500m
      memory: 1Gi

spec:
...
  postgres_resource_requirements:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 500m
      memory: 1Gi

Ansible Automation Platform ジョブは、ホストのインベントリーに対して Ansible Playbook を起動する Automation controller のインスタンスです。Ansible Automation Platform が Red Hat OpenShift で実行される場合、デフォルトの実行キューは、インストール時にOperator によって作成されたコンテナーグループです。

コンテナーグループは、Kubernetes 認証情報とデフォルトの Pod 仕様で設定されます。コンテナーグループに対してジョブが起動されると、Automation controller によって、コンテナーグループ Pod 仕様で指定された名前空間に Pod が作成されます。これらの Pod は、自動化ジョブ Pod と呼ばれます。

自動化ジョブ Pod の適切なサイズを決定するには、まず、Automation controller コントロールプレーンが同時に起動できるジョブ数の機能を理解する必要があります。

この例では、3 つのワーカーノードがあります (それぞれ 4 つの vCPU と 16GiB の RAM)。1 つのワーカーノードは制御 Pod をホストし、他の 2 つのワーカーノードは自動化ジョブに使用されます。

これらの値に基づいて、Automation controller コントロールプレーンが実行できる制御容量を決定できます。

次の式で、内訳がわかります。

合計制御容量 = 合計メモリー (MB)/フォークサイズ (MB)

ワーカーノードに基づいて、これは次のように表現できます。

総制御容量 = 16,000 MB/100 MB = 160

これは、Automation controller が 160 個のジョブを同時に起動するように設定されていることを意味します。ただし、後ほど説明するコンテナーグループ/実行プレーンの容量に合わせて、この値を調整する必要があります。

使用可能な制御容量を計算したので、同時自動化ジョブの最大数を決定できます。

これを判断するには、コンテナーグループ/実行プレーン内の自動化ジョブ Pod の仕様に、vCPU 250m および 100Mi の RAM のデフォルトの要求があることに注意する必要があります。

1 つのワーカーノードの合計メモリーの使用:

16,000 MB/100 MiB = 160 の同時ジョブ

1 つのワーカーノードの合計 CPU の使用:

4000 ミリ cpu / 250 ミリ cpu = 16 の同時ジョブ

上記の値に基づいて、ノード上の最大同時ジョブ数を 2 つの同時ジョブ値の最小値である 16 に設定する必要があります。この例では、自動化ジョブの実行に 2 つのワーカーノードが割り当てられているため、この数は 2 倍の 32 (ワーカーノードあたり 16 の同時ジョブ) になります。

Automation controller の設定は現在 160 の同時ジョブに設定されており、使用可能なワーカーノードの容量では 32 の同時ジョブしか許可されていません。数が偏っているため、これは問題です。

つまり、Automation controller のコントロールプレーンは、同時に 160 のジョブを起動できると認識しているにも拘らず、Kubernetes スケジューラーでは、コンテナーグループの名前空間で最大 32個の自動化ジョブ Pod しか同時にスケジュールされていません。

コントロールプレーンとコンテナーグループ/実行プレーンの間の値が不均衡であると、次のような問題が発生する可能性があります。

中止されたジョブや未使用のリソースのリスクを回避するために、有効な制御容量と、デフォルトのコンテナーグループがサポートできる同時実行ジョブの最大数とのバランスを取ることを推奨します。

コントロールプレーンが起動するジョブの最大数は AWX_CONTROL_NODE_TASK_IMPACT と呼ばれる設定の影響を受けるため、有効な制御容量という用語が使用されます。AWX_CONTROL_NODE_TASK_IMPACT 変数は、自動化ジョブごとに制御 Pod で使用可能な容量を定義し、実質的に、制御 Pod が起動を試すことのできる自動化ジョブ数を制御しています。

有効な制御能力と、利用可能な実行能力のバランスをとるには、AWX_CONTROL_NODE_TASK_IMPACT 変数を、Automation Controller コントロールプレーンで実行する同時ジョブ数を制限する値に設定して、コンテナーグループ/実行プレーンで起動される自動化ジョブ Pod 数と同じ数にします。

コンテナーグループがサポートできるよりも多くの同時自動化ジョブの起動を避けるために、AWX_CONTROL_NODE_TASK_IMPACT の最適値を計算するには、次の式を使用できます。

AWX_CONTROL_NODE_TASK_IMPACT = 制御容量/コンテナーグループが起動できる最大同時ジョブ

リファレンス環境の場合、これは次のとおりです。

AWX_CONTROL_NODE_TASK_IMPACT = 160 / 32 = 5

結論として、このリファレンス環境では、AWX_CONTROL_NODE_TASK_IMPACT は 5 に等しくなるはずである事がわかります。この値は 6章Automation controller のインストール の章の extra_setting で設定します。これについては、このドキュメントの後半で説明します。

コントロールプレーン (制御 Pod) とコンテナーグループ/実行プレーン (自動化ジョブ Pod) のリソース要求と制限を適切に設定することは、制御と実行の容量のバランスを取るために必要です。正しい設定は、次の方法で判断できます。

概要セクションの 図1.2「Automation Hub のアーキテクチャー」 にあるように、デプロイは 7 つの Pod で設定され、それぞれがコンテナーをホストしていることがわかります。

Pod のリストには、以下が含まれます。

Automation Hub アーキテクチャーを設定する 7 つの Pod は連携して機能し、コンテンツを効率的に管理および配布します。これらは、Automation Hub 環境の全体的なパフォーマンスとスケーラビリティにとって重要です。

このような Pod の中でも、ワーカー Pod はコンテンツの処理、同期、および配布を行うので、特に重要です。このような理由から、適切な量のリソースをワーカー Pod に設定して、確実にタスクを実行できるようにすることが重要です。

このリファレンス環境では、Pod のサイズを決定するために、Automation Hub 環境で実行できるメモリー消費量が最も多いタスクの 1 つであるリモートリポジトリーの同期を使用して予備テストが行われました。

調査結果から、Automation Hub 内のリモートリポジトリーを正常に同期するには、次のリソースリクエストとリソース制限を各 Pod に設定する必要があることがわかりました。

spec:
...
content:
  resource_requirements:
    limits:
      cpu: 250mm
      memory: 400Mi
    requests:
      cpu: 100m
      memory: 400Mi

redis:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 200Mi
    requests:
      cpu: 100m
      memory: 200Mi

api:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 400Mi
    requests:
      cpu: 150m
      memory: 400Mi

postgres_resource_requirements:
  resource_requirements:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 200m
      memory: 1Gi

worker:
  resource_requirements:
    limits:
      cpu: 1000m
      memory: 3Gi
    requests:
      cpu: 400m
      memory: 3Gi

spec:
...
content:
  resource_requirements:
    limits:
      cpu: 250mm
      memory: 400Mi
    requests:
      cpu: 100m
      memory: 400Mi

redis:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 200Mi
    requests:
      cpu: 100m
      memory: 200Mi

api:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 400Mi
    requests:
      cpu: 150m
      memory: 400Mi

postgres_resource_requirements:
  resource_requirements:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 200m
      memory: 1Gi

worker:
  resource_requirements:
    limits:
      cpu: 1000m
      memory: 3Gi
    requests:
      cpu: 400m
      memory: 3Gi

専用ノードで制御 Pod を実行することは、制御 Pod と自動化ジョブ Pod を分離し、これら 2 種類の Pod 間のリソース競合を防ぐために重要です。このように分離することで、リソースの制約が原因となるサービスの低下リスクなしに、制御 Pod とそれらの提供するサービスの安定性と信頼性を確保できます。

このリファレンス環境では、実行できる自動化ジョブの数を最大化することに重点が置かれています。つまり、Red Hat OpenShift 環境内で使用可能な 3 つのワーカーノードのうち、1 つのワーカーノードが制御 Pod の実行専用であり、他の 2 つのワーカーノードが自動化ジョブの実行に使用されます。

spec:
...
  node_selector: |
    aap_node_type: control

spec:
...
  node_selector: |
    aap_node_type: control

spec:
...
  topology_spread_constraints: |
    - maxSkew: 1
      topologyKey: "kubernetes.io/hostname"
      whenUnsatisfiable: "ScheduleAnyway"
      labelSelector:
        matchLabels:
          aap_node_type: control
  tolerations: |
    - key: "dedicated"
      operator: "Equal"
      value: "AutomationController"
      effect: "NoSchedule"

spec:
...
  topology_spread_constraints: |
    - maxSkew: 1
      topologyKey: "kubernetes.io/hostname"
      whenUnsatisfiable: "ScheduleAnyway"
      labelSelector:
        matchLabels:
          aap_node_type: control
  tolerations: |
    - key: "dedicated"
      operator: "Equal"
      value: "AutomationController"
      effect: "NoSchedule"

Ansible Automation Platform 内の Automation controller および Automation Hub コンポーネントのデプロイでは、PostgreSQL データベースの PVC を利用します。実行中の Ansible Automation Platform の安定性を保つには、これらの PVC の可用性を確保することが極めて重要です。

Postgres Operator (PGO) および OpenShift Data Foundation (ODF) を介して Crunchy Data によって提供されるストラテジーなど、Red Hat OpenShift クラスター内で PVC の可用性を処理するために使用できるいくつかのストラテジーがあります。

Crunchy Data は、PGO (PostgreSQL クラスター) を自動管理する宣言型 PostgreSQL ソリューションを提案する Postgre Operator を提供します。PGO を使用すると、Postgres クラスターを作成し、高可用性 (HA) Postgres クラスターをスケーリングして作成し、Ansible Automation Platform などのアプリケーションに接続できます。

OpenShift Data Foundation (ODF) は、コンテナー化されたアプリケーションの永続ストレージを管理できる高可用性ストレージソリューションです。これは、Ceph、NooBaa、Rook など、複数のオープンソース Operator とテクノロジーで設定されています。これらのさまざまな Operator を使用すると、Ansible Automation Platform などのアプリケーションに接続できるファイル、ブロック、およびオブジェクトストレージをプロビジョニングおよび管理できます。

Prometheus および Grafana

Prometheus は、メトリックを収集および集計するためのオープンソースの監視ソリューションです。カスタマイズ可能なダッシュボードでデータ分析の実行やメトリックの取得を行うオープンソースソリューションである Grafana と、Prometheus のモニタリング機能を連携すると、メトリックをリアルタイムで視覚化して、Ansible Automation Platform のステータスと正常性を追跡できます。

Grafana の事前構築済みダッシュボードには、次のものが表示されます。

この Grafana ダッシュボードは、関心のある他のメトリックを取得するようにカスタマイズできます。ただし、Grafana ダッシュボードのカスタマイズは、このリファレンスアーキテクチャーの範囲外です。

カスタマイズされた Grafana ダッシュボードを使用して、Prometheus を介して Ansible Automation Platform を監視するプロセスは、数分でインストールできます。以下は、ビルド済みの Ansible Playbook を利用した Grafana ダッシュボードのカスタマイズ手順を示しています。

Ansible Playbook を正常に実行するには、次の手順が必要です。