第9章 Red Hat Ansible Automation Platform での水平スケーリング
Ansible Automation Platform 全体のコンポーネントのマルチノードデプロイメントを設定できます。必要な水平スケーリングの対象が、自動化実行でも、自動化決定でも、自動化メッシュでも、組織のニーズに基づいてデプロイメントを拡張できます。
9.1. Event-Driven Ansible Controller での水平スケーリング リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller では、イベント自動化の水平スケーリングを設定できます。この種のマルチノードデプロイメントでは、インストールプロセス中に必要な数のノードを定義できます。また、組織のニーズに応じて、いつでもノードの数を増減できます。
このデプロイメントでは、次のノードタイプが使用されます。
- API ノードタイプ
- Event-Driven Ansible Controller の HTTP REST API に応答します。
- ワーカーノードタイプ
- Event-Driven Ansible ワーカーを実行します。このワーカーは、プロジェクトとアクティベーションを管理するだけでなく、アクティベーション自体を実行する Event-Driven Ansible のコンポーネントです。
- ハイブリッドノードタイプ
- API ノードとワーカーノードを組み合わせたものです。
次の例は、ホストグループ名 [automationeda] とノードタイプ変数 eda_type を使用して、Red Hat Enterprise Linux 仮想マシン上の Event-Driven Ansible Controller の水平スケーリング用にインベントリーファイルを設定する方法を示しています。
9.1.1. サイジングとスケーリングのガイドライン リンクのコピーリンクがクリップボードにコピーされました!
API ノードは、ユーザーの要求 (UI または API とのやり取り) を処理します。一方、ワーカーノードは、Event-Driven Ansible が適切に機能するために必要なアクティベーションやその他のバックグラウンドタスクを処理します。必要な API ノードの数は、アプリケーションの必要なユーザー数と相関します。ワーカーノードの数は、実行するアクティベーションの必要な数と相関します。
アクティベーションは可変であり、ワーカーノードによって制御されます。そのため、スケーリング方法としてサポートされているのは、ハイブリッドノードではなく、別々の API ノードとワーカーノードを使用することです。これは、ワーカーノードによりハードウェアリソースを効率的に割り当てるためです。ノードを分けることで、特定のニーズに基づいて各タイプを個別に拡張でき、リソースの使用率とコスト効率が向上します。
ノードのデプロイメントのスケールアップを検討する事例としては、多数のアクティベーションを実行する少数のユーザーグループ向けに Event-Driven Ansible をデプロイする場合が挙げられます。この場合、1 つの API ノードで十分ですが、さらに必要な場合は、最大 3 つのワーカーノードを追加してスケールアップできます。
9.1.2. Event-Driven Ansible Controller の水平スケーリングの設定 リンクのコピーリンクがクリップボードにコピーされました!
スケールアップ (ノードを追加) またはスケールダウン (ノードを削除) するには、インベントリーファイルの内容を更新してノードを追加または削除し、インストールプログラムを再実行する必要があります。
手順
インベントリーを更新して、2 つのワーカーノードをさらに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - インストーラーを再実行します。