2 インストールの計画
この章では、インストールの計画について説明します。
Oracle Linux Automation Managerノードのアーキテクチャ
- 制御ノード: これらのノードは、システム・ジョブの起動、インベントリの更新、プロジェクトの同期などの管理機能を提供します。 制御ノードは、Podmanを使用して「コントロール・プレーン実行環境」実行環境内のジョブを実行する、実行可能なランナーを使用します。 「コントロール・プレーン実行環境」実行環境は、Oracle Linuxコンテナ・レジストリにある
olam-eeコンテナ・イメージを参照します。 制御ノードは標準ジョブを実行しません。 - 実行ノード: これらのノードは、Podmanを使用してプレイブックをOLAM EE実行環境で実行する、実行可能なランナーを使用して標準ジョブを実行します。 OLAM EE実行環境は、Oracle Linuxコンテナ・レジストリにある
olam-eeコンテナ・イメージを参照します。 実行ノードは管理ジョブを実行しません。 実行ノードは、ビルダー・ユーティリティを使用して作成できるカスタム実行環境を実行することもできます。 カスタム実行環境の詳細は、「Oracle Linux Automation Manager 2.1: Private Automation Hubインストレーション・ガイド」を参照してください。 PodmanおよびOracle Linuxコンテナ・レジストリの使用方法の詳細は、「Oracle Linux: Podmanユーザーズ・ガイド」を参照してください。 - ハイブリッド・ノード: ハイブリッド・ノードは、制御ノードと実行ノードの両方の機能を1つのノードに結合します。 ハイブリッド・ノードは、単一ホストのOracle Linux Automation Managerデプロイメントではサポートされますが、クラスタ化されたマルチ・ホスト・デプロイメントではサポートされません。
- ホップ・ノード: ホップ・ノードを使用して、制御ノードをクラスタ内の実行ノードに接続できます。 Hopノードはプレイブックを実行できず、インスタンス・グループには表示されません。 ただし、これらはサービス・メッシュの一部として表示されます。
- 直接管理インスタンス: 直接管理インスタンス(ノード)は、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ジョブのみが実行プレーン・インスタンス・グループに送信されます。 これを行うには、
DEFAULT_EXECUTION_QUEUE_NAMEおよびDEFAULT_CONTROL_PLANE_QUEUE_NAMEパラメータを使用して/etc/tower/settings.pyファイルを編集する必要があります。
これらのステップの詳細は、「制御ノード、実行ノードおよびホップ・ノードの構成」を参照してください。
- 各ホストIPアドレスまたはホスト名をプロビジョニングし、それをコントロール・プレーンまたは実行プレーン・ノード・タイプとして指定します。 たとえば、次のコマンドは、前述の図に示すように、2つのコントロール・プレーンと2つの実行プレーン・ノードをプロビジョニングします:
- コントロール・プレーン・ノードに直接接続できない実行ノードがある場合もあります。 そのような場合は、制御ノードに接続されている別の実行ノードに実行ノードを接続できます。 これにより、中間実行ノードに障害が発生すると、接続された実行ノードが制御ノードからアクセスできなくなるリスクが発生します。
- コントロール・プレーン・ノードに直接接続できない実行ノードがある場合もあります。 そのような場合は、制御ノードに接続されているホップ・ノードに実行ノードを接続できます。 これにより、中間ホップ・ノードに障害が発生すると、接続された実行ノードが制御ノードからアクセスできなくなるリスクが生じます。
- コントロール・プレーン・ノード間のピア関係を確立します。 これにより、コントロール・プレーン・ノードに常に相互に直接アクセスできるようになります。 このような関係が確立されていない場合、コントロール・プレーン・ノードは接続された実行プレーン・ノードを介して相互に認識されます。 たとえば、制御Aは、両方に接続されている実行Aを介して制御Bに接続されます。
プレイブック期間のインスタンスのチューニング
Oracle Linux Automation Managerは、ジョブのステータス変更を監視します。 たとえば、ジョブ・ステータスには、「実行中」、「成功」、「失敗」、「待機中」などがあります。 通常、実行されているプレイブックは、様々な方法で進行するとステータスが変更されます。 ただし、場合によっては、プレイブックが「実行中」または「待機中」状態でスタックすることがあります。 この場合、リーパー・プロセスによって、タスクの状態が「実行中」または「待機中」から「失敗」に自動的に変更されます。 リーパーがスタック・ジョブのステータスを「失敗」状態に変更したときのデフォルト・タイマーは60秒です。
60秒より長く実行するように設計されたジョブがある場合は、REAPER_TIMEOUT_SECパラメータを/etc/tower/settings.pyファイルに変更します。 期間が最も長いプレイブックの実行が予想される期間よりも長い時間を秒単位で指定します。 これにより、REAPER_TIMEOUT_SEC値の有効期限が切れているため、リーパーが長時間実行されているプレイブックを誤って「失敗」状態に設定するシナリオが回避されます。
タイムアウト値が長いリーパーとともに短時間および長時間のプレイブックを多数実行すると、考えられるシナリオが発生する可能性があります。 1つまたは複数の短時間プレイブックが予想以上に長く実行された場合(たとえば、ネットワークの停止によってこれらのプレイブックを完了できないため)リーパーは、スタックした短時間プレイブックのステータスを追跡し続け、スタック解除して「成功」状態に移行するか、リーパー・タイムアウト値に達するまで続きます。 このシナリオでは、そのような障害がわずかしか発生しなかった場合、パフォーマンス上の問題は発生しません。 ただし、このような何百もの障害が同時に発生した場合、Oracle Linux Automation Managerはこれらのスタック・ジョブのトラッキングにリソースを浪費し、ジョブを処理するホストのパフォーマンスを低下させる可能性があります。
REAPER_TIMEOUT_SECパラメータの設定の詳細は、「ホストの設定」を参照してください。