7. クラスタリング¶

7.1. 設定の留意事項¶

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

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

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

• クラスターのインスタンス数は常に奇数でなければならず、クラスター内には Tower インスタンスを最低でも 3 つ用意し、最大サポート数を 20 にすることを 強く推奨します。最大サポート数がそれだけ高いと、ノードの数を奇数にする要件の重要性が低くなります。

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

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

• RabbitMQ は、Tower のクラスタリングシステムには不可欠です。設定要件や動作の多くは、それぞれのニーズにより決まるので、Tower の設定 Playbook に含まれないカスタマイズには制約があります。各 Tower インスタンスには、RabbitMQ のデプロイメントが含まれており、他のインスタンスの RabbitMQ インスタンスと合わせてクラスタリングされます。

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

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

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

• 設定 Playbook は RabbitMQ を設定したり、ホストが使用するネットワークタイプを提供したり変化します。

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

• instance_group_tower という名前のグループは作成しないでください。

• インスタンスにグループ名と同じ名前を指定しないでください。

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

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

• プライマリー/セカンダリーの設定がないので、このようなインベントリーグループはなくなり、単一のインベントリーグループ tower に置き換えられました。

• オプションで、これらのグループで他のグループやグループインスタンスを定義することができます。これらのグループには、instance_group_ のプレフィックスを指定する必要があります。インスタンスは、instance_group_ グループ以外に Tower のグループに所属する必要はありませんが、tower グループには必ず 1 つインスタンスが存在している 必要があります。特定のグループが特定のリソースに関連付けられていない場合には、ジョブの実行は必ず tower グループに戻ります。3.3 では、tower のインスタンスグループは常に存在します (削除することも、名前を変更することもできません)。

[tower]
hostA
hostB
hostC

[instance_group_east]
hostB
hostC

[instance_group_west]
hostC
hostD

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

[tower]
hostA
hostB
hostC

[database]
hostDB

外部の Tower インスタンスをプロビジョニングにするのは一般的ですが、内部のアドレスで参照するのが最適です。これは、特に外部インターフェースでサービスが利用できない RabbitMQ クラスタリングにおいては最も重要です。そのため、RabittMQ に内部アドレスを割り当てる必要があります。

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

• redis_password フィールドは [all:vars] から削除されています。

• RabbitMQ のフィールドは以下のとおりです。

  • rabbitmq_port=5672: RabbitMQ は、各インスタンスにインストールされ、オプションではありません。またこれは外部に設定することはできません。この設定により、どのポートをリッスンするのかを指定します。

  • rabbitmq_vhost=tower: Tower が RabbitMQ virtualhost を構成して分離するための設定を制御します。

  • rabbitmq_username=tower および rabbitmq_password=tower: 各インスタンスおよびインスタンス毎の Tower インスタンスがこれらの値で設定されます。これは、Tower で他に使用するユーザー名/パスワードと似ています。

  • rabbitmq_cookie=<somevalue>: この値は、スタンドアロンのデプロイメントでは使用されませんが、クラスターのデプロイメントには必要不可欠です。これは、RabbitMQ クラスターのメンバーがお互いを識別できるように、シークレットキーとして機能します。

  • rabbitmq_enable_manager: RabbitMQ 管理 Web コンソールを各インスタンスに公開するには、これを true に設定します。

rabbitmq_port=5672
rabbitmq_vhost=tower
rabbitmq_username=tower
rabbitmq_password=''
rabbitmq_cookie=cookiemonster

7.3. API からのインスタンスおよびインスタンスグループの設定¶

インスタンスグループは、システム管理者として /api/v2/instance_groups に POST 要求を出すことで作成できます。

インスタンスグループを作成したら、インスタンスをインスタンスグループに関連付けることができます。

HTTP POST /api/v2/instance_groups/x/instances/ {'id': y}`

インスタンスグループに追加したインスタンスは、自動的にグループの作業キューをリッスンするように再設定されます。詳細は、以下の「 インスタンスグループのポリシー 」セクションを参照してください。

7.4. インスタンスグループのポリシー¶

Ansible Tower 3.3 以降、ユーザーは policy を定義することでオンラインになると自動的にインスタンスグループに参加するように Tower インスタンスを設定することができるようになりました。これらのポリシーは、新しいインスタンスがオンラインになるたびに評価されます。

インスタンスグループポリシーは、Instance Group の 3 つの任意フィールドにより制御されます。

• policy_instance_percentage: これは、0 - 100 の間の数字で指定します。これにより、確実に、アクティブな Tower インスタンスの割合が対象のインスタンスグループに追加されるようになります。新しいインスタンスがオンラインになると、このグループのインスタンス数が、インスタンスの全体数に対して、指定の割合より少ない場合には、指定の割合の条件を満たすまで、新しいインスタンスが追加されます。

• policy_instance_minimum: このポリシーは、インスタンスグループに配置するように試行する最小インスタンス数を指定します。利用可能なインスタンス数がこの最小数よりも少ない場合には、すべてのインスタンスがこのインスタンスグループに配置されます。

• policy_instance_list: これは、このインスタンスグループに常に含めるインスタンス名の固定一覧です。

Ansible Tower ユーザーインターフェースのインスタンスグループ一覧ビューでは、インスタンスグループのポリシーをもとにした各インスタンスグループのキャパシティーレベルの概要がわかります。

HTTP PATCH /api/v2/instance_groups/N/
{
"policy_instance_list": ["special-instance"]
}

HTTP PATCH /api/v2/instances/X/
{
"managed_by_policy": False
}

7.5. 分離インスタンスグループ¶

Ansible Tower バージョン 3.2 以降では、オプションでセキュリティーの制限があるネットワークゾーン内に分離グループを定義して、そのゾーンからジョブやアドホックのコマンドを実行する機能が追加されました。これらのグループ内のインスタンスには、Tower のシステム環境は完全ではなく、ジョブ実行に使用するユーティリティーが最小限となっています。分離グループは、プレフィックスが isolated_group_ のインベントリーファイルに指定する必要があります。以下は、分離インスタンスグループのインベントリーファイルの例です。

[tower]
towerA
towerB
towerC

[instance_group_security]
towerB
towerC

[isolated_group_govcloud]
isolatedA
isolatedB

[isolated_group_govcloud:vars]
controller=security

分離グループモデルでは、「コントローラー」インスタンスは、SSH 経由で一連の Ansible Playbook を使用して「分離」インスタンスと対話します。インストール時には、デフォルトで RSA 鍵が無作為に作成され、認証キーとしてすべての「分離」インスタンスに配布されます。その鍵に対応する秘密鍵は暗号化され、Tower データベースに保存されます。この鍵はジョブの実行時に、「コントローラー」インスタンスから「分離」インスタンスへの認証を行う際に使用します。

ジョブが「分離」インスタンスで実行されるように予定されている場合:

• 「コントローラー」インスタンスは、ジョブの実行に必要なメタデータをコンパイルし、「分離」インスタンスにコピーします。

• メタデータが、分離ホストに同期されたら、「コントローラー」インスタンスは「分離」インスタンスでプロセスを開始し、メタデータを使って ansible/ansible-playbook の実行を開始します。Playbook が実行されると、(標準出力やジョブインベントなど) ジョブのアーティファクトが「分離」インスタンスのディスクに書き込まれます。

• ジョブが「分離」インスタンスで実行されると、「コントローラー」インスタンスは「分離」インスタンスから定期的に (標準出力やジョブイベントなど) ジョブのアーティファクトをコピーし、「分離」インスタンスでジョブが完了するまで、ジョブのアーティファクトを使用します。

分離グループ (ノード) は、コントローラーグループに所属するインスタンスだけのアクセスを許可するセキュリティールールを持つ VPC の内部でのみ存在できるように作成されます。「コントローラー」インスタンスから「分離」インスタンスへの SSH 経由の受信トラフィックのみが必要です。分離ノードをプロビジョニングする場合は、インストールマシンは分離ノードに接続できる必要があります。分離ノードに直接アクセスできないが、他のホスト経由で間接的に到達できる場合には、SSH 設定で ProxyCommand を使用して「ジャンプホスト」を指定して、インストーラーを実行してください。

分離グループの推奨のシステム設定は以下のとおりです。

• isolated_group_tower という名前のグループは作成しないでください。

• Tower グループや他の一般的なインスタンスグループに分離インスタンスを配置しないでください。

• コントローラー変数を分離グループの全インスタンスのグループ変数またはホスト変数として定義します。この変数については、同じグループ内にある分離インスタンスに異なる値を割り当てられないようにしてください。割り当ててしまうと、予期せぬ動作が発生する可能性があります。

• 複数の分離グループに分離インスタンスを配置しないでください。

• 通常のグループや分離グループにはインスタンスを配置しないでください。

• 分離インスタンスでファクトのキャッシュを使用しないでください。

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

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

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

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

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

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

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

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

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

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

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

• Celery: 全ジョブを処理、実行するワーカーキュー

• RabbitMQ: このメッセージブローカーは、Celery のシグナルメカニズムおよびアプリケーションに伝搬するイベントデータとして使用されます。

• Memcached: サービスが配置されているインスタンスのローカルキャッシュサービス

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

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

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

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

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

• クラスターを複数のインスタンスグループに分類する場合は、クラスター全体の動作と類似します。インスタンス 2 台がグループに割り当てられると、同じグループ内の他のインスタンスと同様に、いずれかのインスタンスがジョブを受信する可能性が高いです。

• Tower インスタンスがオンラインになると、Tower システムの作業容量が効率的に拡張されます。これらのインスタンスがインスタンスグループにも配置されている場合には、グループの容量も拡張されます。複数のグループの所属するインスタンスが作業を実行する場合は、所属する全グループから容量が減少します。インスタンスのプロビジョニングを解除すると、インスタンスの割当先のクラスターから容量がなくなります。詳細は、次のセクションの「インスタンスおよびインスタンスグループのプロビジョニング解除 」を参照してください。

  注釈

  すべてのインスタンスを同じ容量でプロビジョニングする必要はありません。

• プロジェクトの更新は、以前とは動作が異なります。以前のリリースでは、単一のインスタンスで実行される通常のジョブでした。今回のリリースでは、ジョブを実行可能なインスタンスであればどこでも正常に実行できることが重要です。プロジェクトは、ジョブの実行直前に、インスタンス上で正しいバージョンに同期されます。

• インスタンスグループが設定されているにも拘らず、そのグループ内のインスタンスがすべてオフラインまたは利用不可の場合には、そのグループのみを対象として起動されたジョブは、インスタンスが利用できるようになるまで待機状態となります。このようなシナリオが発生した場合の作業を処理できるように、フォールバックまたはバックアップ用のリソースをプロビジョニングする必要があります。

7.9. インスタンスおよびインスタンスグループのプロビジョニング解除¶

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

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

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

   例: awx-manage deprovision_instance --hostname=hostB

同様に、再プロビジョニングの際には通常、Tower のインスタンスグループが使用されないにも拘らず、Tower のインスタンスグループのプロビジョニングを解除しても、インスタンスグループが自動的に削除されたり、プロビジョニングが解除されたりしません。そのまま API エンドポイントに表示されたり、統計が監視されたりする可能性があります。これらのグループは、以下のコマンドを使用すると、削除することができます。

例: awx-manage unregister_queue --queuename=<name>

このインベントリーファイルのインスタンスグループから、インスタンスのメンバーシップを削除して、Playbook の設定を再実行しても、インスタンスがグループに再度追加されないようになるわけではありません。インスタンスがグループに追加されないようにするには、API 経由で削除し、インベントリーファイルからも削除するか、インベントリーファイルでインスタンスグループの定義をなくします。Ansible Tower ユーザーインターフェースでインスタンスグループのトポロジーを管理することも可能です。UI でのインスタンスグループの管理に関する詳細は、『 Ansible Tower User Guide 』の「 インスタンスグループ 」を参照してください。