2 インストールの計画
この章では、インストールの計画について説明します。
Oracle Linux Automation Managerノードのアーキテクチャ
- 制御ノード: これらのノードは、システム・ジョブの起動、インベントリの更新、プロジェクトの同期などの管理機能を提供します。 制御ノードはansible-runnerを使用しており、これによってPodmanを使用して「コントロール・プレーン実行環境」内のジョブが実行されます。 「コントロール・プレーン実行環境」は、Oracle Linuxコンテナ・レジストリにある
olam-eeコンテナ・イメージを参照します。 制御ノードは標準ジョブを実行しません。 - 実行ノード: これらのノードは、Podmanを使用してプレイブックをOLAM EE実行環境で実行する、実行可能なランナーを使用して標準ジョブを実行します。 OLAM EE実行環境は、Oracle Linuxコンテナ・レジストリにある
olam-eeコンテナ・イメージを参照します。 実行ノードは管理ジョブを実行しません。 実行ノードは、ビルダー・ユーティリティを使用して作成できるカスタム実行環境を実行することもできます。 カスタム実行環境の詳細は、「Oracle Linux Automation Manager 2.2: Private Automation Hubインストレーション・ガイド」を参照してください。 PodmanおよびOracle Linuxコンテナ・レジストリの使用方法の詳細は、「Oracle Linux: Podmanユーザーズ・ガイド」を参照してください。 - ハイブリッド・ノード: ハイブリッド・ノードは、制御ノードと実行ノードの両方の機能を1つのノードに結合します。 ハイブリッド・ノードは、単一ホストのOracle Linux Automation Managerデプロイメントではサポートされますが、クラスタ化されたマルチ・ホスト・デプロイメントではサポートされません。
- ホップ・ノード: ホップ・ノードを使用して、制御ノードをクラスタ内の実行ノードに接続できます。 ホップ・ノードはプレイブックを実行できず、インスタンス・グループに表示されません。 ただし、これらはサービス・メッシュの一部として表示されます。
- 直接管理インスタンス: 直接管理インスタンス(ノード)は、Oracle Linux Automation Managerがssh接続を介して管理する仮想インスタンス、物理インスタンスまたはソフトウェア・インスタンスです。
- 間接的に管理されるインスタンス: 間接的に管理されるインスタンス(ノード)には、Oracle Linux Automation Managerに直接接続されていないが、Oracle Linux Automation Managerに直接接続されているデバイスによって管理されている識別可能なインスタンスが含まれます。
たとえば、次の図は、すべてのノード・タイプとインスタンス・タイプ、およびそれらが相互に関連付けることができるいくつかの方法を示しています。
インストール・オプション
- スタンドアロン・インストール: データベースを含め、すべてのコンポーネントが同じホスト上にあります。
図2-1 ローカル・データベースを使用したスタンドアロン・インストール
- リモート・データベースを使用したスタンドアロン・インストール: リモート・ホスト上のデータベースを除き、すべてのコンポーネントは同じホスト上にあります。
図2-2 リモート・データベースを使用したスタンドアロン・インストール
- リモート・データベースを使用したクラスタ化インストール: クラスタ・インストールには、1つ以上の制御ノード、1つ以上の実行ノード、および1つ以上のホップ・ノードがすべて1つのデータベースに接続された最大20個のノードを含めることができます。 たとえば、2つのコントロール・プレーン・ノードと2つの実行プレーン・ノードがあり、それぞれが別々のホストにあり、すべてリモート・データベースに接続されているクラスタを次に示します。
図2-3 リモート・データベースを使用したクラスタ化インストール
サービス・メッシュ・トポロジの例
Oracle Linux Automation Managerサービス・メッシュ・トポロジは様々な方法で構成できます。
例1: 少なくとも1つのバックアップ・コントロール・プレーン・ノードと1つのバックアップ実行プレーン・ノードを持つようにサービス・メッシュを設計します。 たとえば、2つの制御ノードと2つの実行ノードがあります。 コントロール・プレーン・ノードの1つに障害が発生した場合、各実行プレーン・ノードは両方のコントロール・プレーン・ノードと通信します。 最初の実行プレーン・ノードに障害が発生した場合、コントロール・プレーン・ノードは2番目の実行プレーン・ノードに切り替わります。
図2-4 リモート・データベースを使用したクラスタ化インストール
- ノードごとに必要に応じて、ノードID、tcp-listenerおよびtcp-peerアドレスを使用して
/etc/receptor/receptor.confファイルを構成します。 このタスクの詳細は、「コントロール・プレーン・サービス・メッシュの構成および起動」および「実行プレーン・サービス・メッシュの構成および起動」を参照してください。 - コントロール・プレーン・ノードから、awxユーザーとしてログインし、awx-manageコマンドを実行して次を実行します:
- 各ホストIPアドレスまたはホスト名をプロビジョニングし、それをコントロール・プレーンまたは実行プレーン・ノード・タイプとして指定します。 たとえば、次のコマンドは、前述の図に示すように、2つのコントロール・プレーンと2つの実行プレーン・ノードをプロビジョニングします:
awx-manage provision_instance --hostname=192.0.121.28 --node_type=control awx-manage provision_instance --hostname=192.0.126.72 --node_type=control awx-manage provision_instance --hostname=192.0.113.178 --node_type=execution awx-manage provision_instance --hostname=192.0.127.70 --node_type=execution - 各ノードに指定したノードのタイプに基づいて、各ノードを
controlplaneまたはexecutionインスタンス・グループのいずれかに登録します。 awx-manageコマンドは、インスタンス・グループをキュー名として参照します。 たとえば、次のコマンドは、コントロール・プレーンと実行インスタンス・グループを作成し、上の図に示すように、2つのコントロール・プレーンと2つの実行プレーン・ノードを各インスタンス・グループに関連付けます:awx-manage register_queue --queuename=controlplane --hostnames=192.0.121.28 awx-manage register_queue --queuename=controlplane --hostnames=192.0.126.72 awx-manage register_queue --queuename=execution --hostnames=192.0.113.178 awx-manage register_queue --queuename=execution --hostnames=192.0.127.70 - 各ノード間のピア関係を登録します。 ソースIPアドレスとターゲットIPアドレス間のピア関係を登録すると、ピア関係によって双方向通信が確立されることに注意してください。 たとえば、次のコマンドは実行ノードのホストIPアドレスをソースとして登録し、各tcp-peer接続はターゲット(コントロール・プレーン・ノード)です:
awx-manage register_peers 192.0.113.178 --peers 192.0.121.28 awx-manage register_peers 192.0.113.178 --peers 192.0.126.172 awx-manage register_peers 192.0.127.70 --peers 192.0.121.28 awx-manage register_peers 192.0.127.70 --peers 192.0.126.172このコマンドは、ノード間で確立するリンクごとに実行する必要があります。
- 各インスタンス・グループをコントロール・プレーンまたは実行プレーンのデフォルトのキュー名として登録します。 これにより、コントロール・タイプのジョブのみがコントロール・プレーン・インスタンス・グループに送信され、Oracle Linux Automation Engineジョブのみが実行プレーン・インスタンス・グループに送信されます。 これを行うには、
/etc/tower/conf.d/filename.pyにカスタム設定ファイルを作成し、次のパラメータを追加する必要があります:DEFAULT_EXECUTION_QUEUE_NAME = 'execution' DEFAULT_CONTROL_PLANE_QUEUE_NAME = 'controlplane'
これらのステップの詳細は、「制御ノード、実行ノードおよびホップ・ノードの構成」を参照してください。
- 各ホストIPアドレスまたはホスト名をプロビジョニングし、それをコントロール・プレーンまたは実行プレーン・ノード・タイプとして指定します。 たとえば、次のコマンドは、前述の図に示すように、2つのコントロール・プレーンと2つの実行プレーン・ノードをプロビジョニングします:
- コントロール・プレーン・ノードに直接接続できない実行ノードがある場合があります。 このような場合、実行ノードを制御ノードに接続している別の実行ノードに接続できます。 これにより、中間実行ノードに障害が発生すると、接続された実行ノードが制御ノードからアクセスできなくなるリスクが発生します。
- コントロール・プレーン・ノードに直接接続できない実行ノードがある場合があります。 このような場合、実行ノードを制御ノードに接続しているホップ・ノードに接続できます。 これにより、中間ホップ・ノードに障害が発生すると、接続された実行ノードが制御ノードからアクセスできなくなるリスクが生じます。
- コントロール・プレーン・ノード間のピア関係を確立します。 これにより、コントロール・プレーン・ノードに常に相互に直接アクセスできるようになります。 このような関係が確立されていない場合、コントロール・プレーン・ノードは接続された実行プレーン・ノードを介して相互に認識されます。 たとえば、制御Aは、両方に接続されている実行Aを介して制御Bに接続されます。
プレイブック期間のインスタンスのチューニング
Oracle Linux Automation Managerは、ジョブのステータス変更を監視します。 たとえば、ジョブ・ステータスには、「実行中」、「成功」、「失敗」、「待機中」などがあります。 通常、プレイブックは実行時にステータスを変更します。 ただし、プレイブックが「実行中」または「待機中」状態でスタックすることがあります。 この場合、リーパー・プロセスによって、タスクの状態が「実行中」または「待機中」から「失敗」に自動的に変更されます。 リーパーがスタック・ジョブのステータスを「失敗」状態に変更したときのデフォルト・タイマーは60秒です。
60秒を超えて実行するように設計されたジョブがある場合は、/etc/tower/conf.d/filename.pyでカスタム設定ファイルを作成または編集し、REAPER_TIMEOUT_SECパラメータを設定します。 期間が最も長いプレイブックの実行が予想される期間よりも長い時間を秒単位で指定します。 これにより、REAPER_TIMEOUT_SEC値の期限が切れているため、リーパーが長時間実行プレイブックを「失敗」状態に誤って設定するシナリオを回避できます。
タイムアウト値が長いリーパーを使用して、短期間および長期間のプレイブックを多数実行すると、考えられるシナリオが発生する可能性があります。 1つまたは複数の短時間プレイブックが予想以上に長く実行された場合(たとえば、ネットワークの停止によってこれらのプレイブックを完了できないため)リーパーは、スタックした短時間プレイブックのステータスを追跡し続け、スタック解除して「成功」状態に移行するか、リーパー・タイムアウト値に達するまで続きます。 このシナリオでは、そのような障害がわずかしか発生しなかった場合、パフォーマンス上の問題は発生しません。 ただし、このような何百もの障害が同時に発生した場合、Oracle Linux Automation Managerはこれらのスタック・ジョブのトラッキングにリソースを浪費し、ジョブを処理するホストのパフォーマンスを低下させる可能性があります。
REAPER_TIMEOUT_SECパラメータの設定の詳細は、「ホストの設定」を参照してください。