7. クラスタリング¶

7.1. 設定の留意事項¶

本セクションは、クラスターの初期設定のみを対象とします。既存のクラスターのアップグレードについては、『Ansible Tower Upgrade and Migration Guide』の「Upgrade Planning」を参照してください。

新規クラスタリング環境における重要な留意事項:

• PostgreSQL はまだスタンドアロンのインスタンスで、クラスター化されていません。Tower はレプリカ設定やデータベースのフェイルオーバーを管理しません (ユーザーが待機レプリカを設定した場合)。

• クラスターを起動する場合は、データベースノードをスタンドアロン構成にすることとし、PostgreSQL は Tower ノードの 1 つにインストールしないでください。

• クラスターには少なくても 3 つの Tower インスタンスがあり、サポートされている最大値は 20 であることが 強く推奨 されています。

• 全インスタンスは、他のすべてのインスタンスから到達でき、データベースにアクセスできる必要があります。ホストに安定したアドレスおよび/またはホスト名を指定することも重要です (Tower ホストの設定方法により異なる)。

• 全インスタンスは、地理的に近い場所に配置する必要があります。インスタンス間はレイテンシーが低く信頼性のある接続を使用します。

• クラスター環境にアップグレードするには、プライマリーのインスタンスがインベントリーの tower グループに所属し、さらに tower グループの最初のホストとしてリストされる必要があります。

• 手動のプロジェクトでは、顧客が手動で全インスタンスを同期して、一度に全インスタンスを更新する必要があります。

• 新しい Tower システムにはプライマリー/セカンダリーのコンセプトはありません。システムはすべてプライマリーです。

• Tower デプロイメントの inventory ファイルは保存/永続化する必要があります。新規インスタンスをプロビジョニングする場合は、パスワード、設定オプション、ホスト名をインストーラーで利用できるようにしなければなりません。

7.2. インストールおよび設定¶

新規インスタンスのプロビジョニングは、inventory ファイルを更新して、設定 Playbook を再実行します。この inventory ファイルには、クラスターのインストール時に使用するすべてのパスワードと情報が含まれていることが重要です。含まれていない場合には、他のインスタンスが再設定される場合があります。inventory ファイルインベントリーには、単一のインベントリーグループ tower が含まれています。

[tower]
hostA
hostB
hostC

[instance_group_east]
hostB
hostC

[instance_group_west]
hostC
hostD

database グループは、外部の PostgreSQL を指定します。データベースホストが別にプロビジョニングされる場合には、このグループは空にしておく必要があります。

[tower]
hostA
hostB
hostC

[database]
hostDB

Playbook がクラスター内の個別の Tower インスタンスで実行すると、その Playbook の出力は、Tower の websocket ベースのストリーミング出力機能の一部として他のすべてのノードにブロードキャストされます。インベントリー内の各ノードにプライベートルーティング可能アドレスを指定して、内部アドレスを使用してこのデータブロードキャストを処理するのが最適です。

[tower]
hostA routable_hostname=10.1.0.2
hostB routable_hostname=10.1.0.3
hostC routable_hostname=10.1.0.4

HTTP PATCH /api/v2/settings/jobs/ {'AWX_ISOLATED_PRIVATE_KEY': '', 'AWX_ISOLATED_PUBLIC_KEY': ''}

7.3. ブラウザーの API を使用したステータスの確認およびモニタリング¶

Tower は、/api/v2/ping で、クラスターのヘルスを検証するために Browsable API を使用してステータスをできるだけレポートします。以下に例を示します。

• HTTP 要求にサービスを提供するインスタンス

• クラスター内にある他の全インスタンスが出した最後のハートビートのタイムスタンプ

• これらのグループのインスタンスグループおよびインスタンスのメンバーシップ

実行中のジョブやメンバー情報など、インスタンスおよびインスタンスグループに関する詳細情報は、/api/v2/instances/ および /api/v2/instance_groups/ を参照してください。

7.4. インスタンスサービスおよび障害時の動作¶

各 Tower インスタンスは、複数の異なるサービスで構成されており、これらのサービスは連携しています。

• HTTP サービス: これには、Tower アプリケーション自体と外部の Web サービスが含まれます。

• Callback Receiver: 実行中の Ansible ジョブからジョブイベントを受信します。

• ディスパッチャー: 全ジョブを処理して実行するワーカーキュー

• Redis: このキー値ストアは、ansible-playbook からアプリケーションに伝搬されるイベントデータのキューとして使用されます。

• Rsyslog: ログをさまざまな外部ロギングサービスに配信するために使用されるログ処理サービス。

サービスやコンポーネントに障害が発生すると、全サービスが再起動されるように Tower は構成されています。サービスやコンポーネントが短期間で何度も機能しなくなった場合には、予期せぬ動作を起こさずに修正できるように自動的に全インスタンスがオフラインに切り替えられます。

クラスター環境のバックアップおよび復元については、「クラスター環境のバックアップおよび復元」のセクションを参照してください。

7.5. ジョブランタイムの動作¶

ジョブの実行や、Tower の「通常」ユーザーへレポートする方法は変更されません。システム側には、注目すべき相違点が複数あります。

• ジョブが API インターフェースから送信されると、ディスパッチャーキューにプッシュされます。各 Tower インスタンスは特定のスケジュールアルゴリズムを使用してキューに接続し、そのキューからジョブを受信します。クラスター内のいずれのインスタンスも、同じ確率でジョブを受信してタスクを実行します。ジョブの実行時にインスタンスが失敗すると、ジョブは永続的に「失敗」とマークされます。

• プロジェクトの更新は、ジョブを実行する可能性のあるすべてのインスタンスで正常に実行されます。プロジェクトは、ジョブを実行する直前に、インスタンス上の正しいバージョンに自分自身を同期します。必要なリビジョンがすでにローカルでチェックアウトされており、Galaxy またはコレクションの更新が不要な場合、同期は実行されない可能性があります。

• 同期が行われると、launch_type = sync と job_type =  run のプロジェクトの更新として記録されます。プロジェクトの同期によってステータスやプロジェクトのバージョンが変更されることはありません。代わりに、プロジェクトが実行されているインスタンスのソースツリー*のみ*が更新されます。

• Galaxy またはコレクションから更新が必要な場合は、必要なロールをダウンロードし、/tmp ファイルでより多くの領域を消費する同期が実行されます。大規模なプロジェクト (約 10 GB) があると、/tmp のディスク容量が問題になる可能性があります。

7.6. インスタンスのプロビジョニング解除¶

Playbook の設定を再実行しても、自動的にインスタンスのプロビジョニングが解除されるわけではありません。これは現在、インスタンスがオフラインになった理由が意図的なのか、障害が原因なのかをクラスターでは識別できないためです。代わりに、Tower インスタンスの全サービスをシャットダウンしてから、他のインスタンスからプロビジョニング解除ツールを実行します。

1. ansible-tower-service stop のコマンドで、インスタンスをシャットダウンするか、サービスを停止します。

2. 別のノードから $ awx-manage deprovision_instance --hostname=<name used in inventory file> のプロビジョニング解除のコマンドを実行して、Tower のクラスターから削除します。

   例: awx-manage deprovision_instance --hostname=hostB

同様に、Tower でインスタンスグループのプロビジョニングを解除しても、インスタンスグループは自動的にプロビジョニング解除されたり、削除されたりしません。詳細は、「インスタンスグループのプロビジョニング解除」のセクションを参照してください。