2インストールの計画

この章では、インストールの計画について説明します。

Oracle Linux Automation Managerノード・アーキテクチャ

Oracle Linux Automation Managerは、セキュアなメッシュ内のノードをリンクするマルチサービス・ネットワークを提供するサービス・メッシュと連携します。サービス・メッシュには、次のノード・タイプのノードを最大20個含めることができます:
  • コントロール・ノード: これらのノードは、システム・ジョブの起動、インベントリの更新、プロジェクトの同期などの管理機能を提供します。コントロール・ノードはansible-runnerを使用します。これはPodmanを使用してコントロール・プレーン実行環境内でジョブを実行します。コントロール・プレーン実行環境は、Oracle Linux Container Registryにあるolam-eeコンテナ・イメージを参照します。コントロール・ノードは標準ジョブを実行しません。
  • 実行ノード: これらのノードはansible-runnerを使用して標準ジョブを実行し、ansible-runnerはPodmanを使用してOLAM EE実行環境内でプレイブックを実行します。OLAM EE実行環境は、Oracle Linux Container Registryにあるolam-eeコンテナ・イメージを参照します。実行ノードは管理ジョブを実行しません。実行ノードは、ビルダー・ユーティリティを使用して作成できるカスタム実行環境も実行できます。カスタム実行環境の詳細は、Oracle Linux Automation Manager 2.3: Private Automation Hubインストレーション・ガイドを参照してください。PodmanおよびOracle Linux Container Registryの使用の詳細は、Oracle Linux: Podmanユーザー・ガイドを参照してください。
  • ハイブリッド・ノード: ハイブリッド・ノードは、コントロール・ノードと実行ノードの両方の機能を1つのノードに統合します。ハイブリッド・ノードは、単一ホストのOracle Linux Automation Managerデプロイメントではサポートされますが、クラスタ化されたマルチホスト・デプロイメントではサポートされません。
  • ホップ・ノード: ホップ・ノードを使用して、コントロール・ノードをクラスタ内の実行ノードに接続できます。ホップ・ノードはプレイブックを実行できず、インスタンス・グループには表示されません。ただし、サービス・メッシュの一部として表示されます。
Oracle Linux Automation Managerは、デバイス、サーバー、データベース、ネットワーク機器など、様々なインスタンス・タイプを管理できます。一般的に、Oracle Linux Automation Managerは次のインスタンス・タイプを管理します:
  • 直接管理対象インスタンス: 直接管理対象インスタンス(ノード)は、Oracle Linux Automation ManagerがSSH接続を介して管理する仮想インスタンス、物理インスタンス、またはソフトウェア・インスタンスです。
  • 間接管理対象インスタンス: 間接管理対象インスタンス(ノード)には、Oracle Linux Automation Managerに直接接続されていませんが、Oracle Linux Automation Managerに直接接続されているデバイスによって管理されている識別可能なインスタンスが含まれます。

たとえば、次の図は、すべてのノードとインスタンス・タイプ、およびそれらが互いに関連するいくつかの方法を示しています。


この図は、2つのコントロール・ノードを持つコントロールプレーン・インスタンス・グループが、2つの実行ノードを持つ別のインスタンス・グループに接続されていることを示しています。各実行ノードは、管理対象インスタンスに直接接続され、他の管理対象インスタンスには間接的に接続されています。3つ目のインスタンス・グループには、コントロール・プレーン・ノードと実行プレーン・ノードのハイブリッドが含まれており、これも管理対象インスタンスに直接的および間接的に接続されています。

インストール・オプション

Oracle Linux Automation Managerには、3つのインストール・オプションがあります:
  • スタンドアロン・インストール: データベースを含むすべてのコンポーネントが同じホスト上に配置されます。

    図2-1 ローカル・データベースを使用したスタンドアロン・インストール


    この図は、ローカル・データベースが同じホスト上に配置されているOracle Linux Automation Managerを示しています。
  • リモート・データベースを使用したスタンドアロン・インストール: データベースのみがリモート・ホスト上に配置されている場合を除き、すべてのコンポーネントが同じホスト上に配置されます。

    図2-2 リモート・データベースを使用したスタンドアロン・インストール


    この図は、リモート・データベースが異なるホスト上に配置されているOracle Linux Automation Managerを示しています。
  • リモート・データベースを使用したクラスタ・インストール: クラスタ・インストールには、1つ以上のコントロール・ノード、1つ以上の実行ノード、および1つ以上のホップ・ノードを含むノードを最大20個含めることができ、これらはすべて1つのデータベースに接続されます。たとえば、次の図は、2つのコントロール・プレーン・ノードと2つの実行プレーン・ノードがそれぞれ別のホスト上にあり、すべてリモート・データベースに接続されているクラスタを示しています。

    図2-3 リモート・データベースを使用したクラスタ・インストール


    この図は、2つのコントロール・プレーン・ノード、2つの実行ノード、および異なるホスト上に配置されているリモート・データベースを備えたOracle Linux Automation Managerのクラスタ化されたインスタンスを示しています。

サービス・メッシュ・トポロジの例

Oracle Linux Automation Managerのサービス・メッシュ・トポロジは、様々な方法で構成できます:

例1: 少なくとも1つのバックアップ・コントロール・プレーン・ノードと1つのバックアップ実行プレーン・ノード(例: コントロール・ノード2つと実行ノード2つ)を持つようにサービス・メッシュを設計します。各実行プレーン・ノードは、コントロール・プレーン・ノードの1つに障害が発生した場合に備えて、両方のコントロール・プレーン・ノードと通信できます。最初の実行プレーン・ノードに障害が発生した場合、コントロール・プレーン・ノードは2番目の実行プレーン・ノードに切り替えます。

図2-4 リモート・データベースを使用したクラスタ・インストール


この図は、2つのコントロール・プレーン・ノード、2つの実行ノード、および異なるホスト上に配置されているリモート・データベースを備えたOracle Linux Automation Managerのクラスタ化されたインスタンスを示しています。すべてのノードは相互に接続されています。
サービス・メッシュを構成するための大まかな手順は次のとおりです:
  1. 各ノードの必要に応じて、/etc/receptor/receptor.confファイルにノードID、tcp-listener、tcp-peerアドレスを構成します。このタスクの詳細は、「コントロール・プレーン・サービス・メッシュの構成と起動」および「実行プレーン・サービス・メッシュの構成と起動」を参照してください。
  2. コントロール・プレーン・ノードからawxユーザーとしてログインし、awx-manageコマンドを実行して次を実行します:
    1. 各ホストの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
    2. 各ノードに指定したノード・タイプに基づいて、各ノードを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
    3. controlplaneノードおよびexecutionノードのレセプタ・アドレス・レコードを追加します。たとえば、次のコマンドは、前述の図に示すように、コントロール・プレーンと実行ノードのアドレスを追加します:
      awx-manage add_receptor_address --instance=192.0.121.28 --address=192.0.121.28 --port=27199 --canonical
awx-manage add_receptor_address --instance=192.0.126.72 --address=192.0.126.72 --port=27199 --canonical
awx-manage add_receptor_address --instance=192.0.113.178 --address=192.0.113.178 --port=27199 --canonical
awx-manage add_receptor_address --instance=192.0.127.70 --address=192.0.127.70 --port=27199 --canonical
    4. 各ノード間のピア関係を登録します。ソースIPアドレスとターゲットIPアドレス間のピア関係を登録すると、ピア関係により双方向通信が確立されることに注意してください。たとえば、次のコマンドは、実行ノードのホストIPアドレスをソースとして登録し、各TCPピア接続がターゲット(コントロール・プレーン・ノード)となります:
      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

      このコマンドは、ノード間で確立するリンクごとに実行する必要があります。

    5. 各インスタンス・グループを、コントロール・プレーンまたは実行プレーンのデフォルトのキュー名として登録します。これにより、コントロール・プレーン・インスタンス・グループにはコントロール・タイプのジョブのみが、実行プレーン・インスタンス・グループにはOracle Linux Automation Engineジョブのみが実行されるようになります。これを実行するには、/etc/tower/conf.d/filename.pyにカスタム設定ファイルを作成し、次のパラメータを追加する必要があります: 
      DEFAULT_EXECUTION_QUEUE_NAME = 'execution'
DEFAULT_CONTROL_PLANE_QUEUE_NAME = 'controlplane'

    これらの手順の詳細は、「コントロール・ノード、実行ノードおよびホップ・ノードの構成」を参照してください。

例2: コントロール・プレーン・ノードまたは実行プレーン・ノードのいずれかに障害が発生した場合に備えてフェイルオーバーを組み込むために、必要な数のコントロール・プレーン・ノードと実行プレーン・ノードをデプロイします。クラスタのノード制限である20を超えないようにしてください。検討できるオプションには次が含まれます:
  • 場合によっては、コントロール・プレーン・ノードに直接接続できない実行ノードがある可能性があります。このような場合、実行ノードを、コントロール・ノードに接続されている別の実行ノードに接続できます。これにより、中間実行ノードに障害が発生した場合、接続されている実行ノードがコントロール・ノードにアクセスできなくなるというリスクが発生します。
  • 場合によっては、コントロール・プレーン・ノードに直接接続できない実行ノードがある可能性があります。そのような場合は、実行ノードをコントロール・ノードに接続されているホップ・ノードに接続できます。これにより、中間ホップ・ノードに障害が発生した場合、接続されている実行ノードがコントロール・ノードにアクセスできなくなるというリスクが発生します。
  • コントロール・プレーン・ノード間にピア関係を確立します。これにより、コントロール・プレーン・ノードは常に互いに直接アクセスできるようになります。このような関係が確立されていない場合、コントロール・プレーン・ノードは接続された実行プレーン・ノードを介して互いを認識します。たとえば、コントロール・ノード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パラメータの設定の詳細は、「ホストの設定」を参照してください。