Documentation

7. クラスタリング

クラスタリングは冗長化の代わりのアプローチであり、プライマリーインスタンスとセカンダリーインスタンスを使用する active-passive ノードで設定されていた冗長化ソリューションの後継となります。3.1 より前のバージョンは、以前のバージョンの Ansible Tower Administration Guide のクラスタリングの章を参照してください。

クラスタリングでは、ホスト間で負荷が共有されます。各インスタンスは、UI および API アクセスのエントリーポイントとして機能します。これにより、Tower の管理者が複数のインスタンスの手前でロードバランサーを使用できるようになり、データの可視性が向上されるはずです。

注釈

負荷分散はオプションで、必要に応じて 1 つまたはすべてのインスタンスで受信することも可能です。

各インスタンスは、Tower のクラスターに参加して、ジョブの実行機能を拡張することができます。これは、ジョブの実行場所を指定するのではなく、ジョブをどこでも実行できる簡単なシステムです。また、クラスターインスタンスは異なるプール/キューにグループ化すること (インスタンスグループ) が可能です。

Tower は、OpenShift または Kubernetes を使用するコンテナーベースのクラスターをサポートしています。つまり、これらのプラットフォームに新しい Tower インスタンスを、機能の変更や転換を行うことなくインストールできます。ただし、いくつか OpenShift のデプロイメントおよび設定 に違いがあり、考慮が必要です。Ansible Tower バージョン 3.6 では、Kubernetes コンテナーを指すインスタンスグループを作成できます。詳細については、「実行環境」のセクションを参照してください。

サポート対象のオペレーティングシステム

クラスター環境の確立には、以下のオペレーティングシステムがサポートされます。

  • Red Hat Enterprise Linux 7 以降 (RHEL8 を推奨。RHEL 7 または Centos 7 インスタンスも可)

  • Ubunto 16 (Ubunto は非推奨となり、今後のリリースで削除されます)

注釈

OpenShift での分離インスタンスと Ansible Tower の実行の組み合わせはサポートされません。

7.1. 設定の留意事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注釈

インスタンスはすべて、ジョブの起動先や Playbook イベントの処理、定期的なクリーンアップなど、タスクのスケジュールに関連するハウスキーピングタスクを担当します。

[tower]
hostA
hostB
hostC

[instance_group_east]
hostB
hostC

[instance_group_west]
hostC
hostD

注釈

リソースにグループが選択されていない場合には、tower グループが使用されますが、他のグループが選択されている場合は tower グループは使用されません。

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

[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

注釈

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

  • 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 に設定します。

7.2.1. RabbitMQ デフォルト設定

以下の設定は、RabbitMQ のデフォルト設定です。

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

注釈

rabbitmq_cookie は機密の値です。Tower では secret key のように取り扱うようにしてください。

7.2.2. Tower が使用するインスタンスおよびポート

Tower が使用するポートとインスタンスは以下のとおりです。

  • 80、443 (通常の Tower ポート)

  • 22 (ssh)

  • 5432 (データベースインスタンス: データベースが外部インスタンスにインストールされた場合は、Tower インスタンスに対してこのポートを開放する必要があります。)

クラスタリング/RabbitMQ ポート:

  • 4369、25672 (クラスターの管理に RabbitMQ 専用で使用するポート。各インスタンス間でこのポートを開放する必要があります)

  • 15672 (RabbitMQ 管理インターフェースが有効化されている場合には、このポートを開放する必要があります (任意))

7.2.3. オプションの SSH 認証

(内部で管理するパスワードなしの SSH 鍵など) Tower 以外のシステムを介して、「コントローラー」ノードから「分離ノード」への SSH 認証を管理する場合、Tower API の設定値 2 つの設定を解除して、この動作を無効化します。

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 ジョブからジョブイベントを受信します。

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

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

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

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

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

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

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

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

Tower Cluster example

  • Ansible Tower 3.6 では、プロジェクトの更新の動作が異なります。以前のバージョンでは、プロジェクトの更新は単一のインスタンスで実行される通常のジョブでした。現在のバージョンでは、ジョブを実行する可能性がある任意のインスタンスで正常に実行できるということが重要です。プロジェクトは、インスタンス上の正しいバージョンと自身を即時に同期してからジョブを実行します。必要なリビジョンがすでにローカルでチェックアウトされており、Galaxy またはコレクションの更新が必要ない場合、同期は実行されません。

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

7.5.1. ジョブの実行

デフォルトでは、ジョブが Tower のキューに送信されると、どのワーカーでもジョブを取得できます。ただし、ジョブの実行元となるインスタンスを制限するなど、特定のジョブを実行する場所を制御できます。

一時的にインスタンスをオフラインにするため、インスタンスごとにプロパティーを有効に定義します。このプロパティーが無効の場合は、対象のインスタンスにジョブは割り当てられません。既存のジョブが完了しますが、新しいジョブは割り当てられません。

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

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 でインスタンスグループのプロビジョニングを解除しても、インスタンスグループは自動的にプロビジョニング解除されたり、削除されたりしません。詳細については、「Deprovision Instance Groups」のセクションを参照してください。