Red Hat Summit第3章 作業を開始する前の注意事項
AAP を Red Hat OpenShift にデプロイする前に、インストール前に対処する必要がある重要な考慮事項を理解することが重要です。これらの要因により、AAP 環境のライフサイクル全体の正常性とスケーラビリティーが決まります。
このセクションでは、次のような重要な考慮事項の内訳を示します。
- Red Hat OpenShift リソース管理
- Automation controller Pod コンテナーのサイジングに関する推奨事項
- Postgres Pod のサイジングに関する推奨事項
- 自動化ジョブ Pod のサイジングに関する推奨事項
- Automation Hub Pod のサイジングに関する推奨事項
デプロイを成功させるための重要な側面の 1 つとして、Pod とコンテナーの適切なリソース管理が挙げられます。適切にリソース管理を行うことで Red Hat OpenShift クラスターの AAP アプリケーションの最適なパフォーマンスと可用性を確保します。
3.1. Pod とコンテナーのリソース管理
リソース管理に関する 2 つの重要なリソースは、CPU とメモリー (RAM) です。Red Hat OpenShift は、リソース要求とリソース制限を使用して、コンテナーが Pod で消費できるリソースの量を制御します。
3.1.1. リソース要求とは
リソース要求は、コンテナーが適切に実行および機能するために最小限必要なリソースの量です。Kubernetes スケジューラーは、この値を使用して、コンテナーに使用できる十分なリソースがあることを確認します。
3.1.2. リソース制限とは
一方、リソース制限は、コンテナーが最大限消費できるリソースの量です。リソース制限を設定すると、コンテナーが必要以上のリソースを消費することがなくなり、他のコンテナーがリソース不足に陥る可能性があります。
3.1.3. リソース管理が重要な理由
AAP に関しては、正しいリソースリクエストと制限を設定することが重要です。リソースの割り当てが不十分な場合、制御 Pod が終了し、Automation controller 内のすべての自動化ジョブが失われる可能性があります。
3.1.4. リソースの計画
適切なリソース管理値を設定する一方で、組織は利用可能なリソースに基づいて、どのアーキテクチャーがニーズに最も適しているかを検討する必要があります。たとえば、自動化ジョブを実行する容量を最大化することよりも、Ansible Automation Platform 環境の高可用性が重要かどうかを判断します。
このリファレンスアーキテクチャーで使用されている既存の Red Hat OpenShift 環境を取り上げて、詳細に説明します。設定は次のとおりです。
- 3 コントロールプレーンノード
- 3 つのワーカーノード
これらの各ノードは、4 つの vCPU と 16 GiB の RAM で設定されています。
Red Hat OpenShift クラスターのコントロールプレーンノードはアプリケーションを実行しないため、この例では使用可能な 3 つのワーカーノードに焦点を当てています。
これら 3 つのワーカーノードを使用して、Ansible Automation Platform の可用性を最大化するか、できるだけ多くの自動化ジョブを実行するか、あるいはその両方か、どちらがより重要であるかを判断する必要があります。
可用性が最も重要な場合は、2 つの制御 Pod が別々のワーカーノード (例: worker0 と worker1) で実行され、すべての自動化ジョブが残りのワーカーノード (例: worker2) 内で実行されるようにすることに重点が置かれます。
ただし、これにより、自動化ジョブの実行に使用できるリソースが半分に減少します。推奨の方法として、制御 Pod と自動化 Pod を分離して、同じワーカーノードで実行されないようにします。
実行する自動化ジョブの量を最大化することが主な目標である場合、制御 Pod に 1 つのワーカーノード (例: worker0) を使用し、残りの 2 つのワーカーノード (例: worker1 と worker2) を自動化ジョブの実行に使用すると、使用可能なリソースが 2 倍になります。ジョブの実行はできますが、代わりに制御 Pod に冗長性がなくなります。
当然、どちらも同様に重要である場合があります。そういった場合には、解決策として、両方の要件を満たすには、追加のリソース (ワーカーノードを追加するなど) が必要になる場合があります。
