Red Hat Ansible Automation オファリングの一部として「管理対象ノード」はどのように定義されていますか?

Red Hat Ansible Automation Platform は、お客様の環境内の「管理対象ノード」数をカウントして販売およびサポートされています。この記事では、管理対象ノードとは何か、また、この概念を取り巻くビジネスルールとは何かを定義します。

注記: 以下は、公式の Red Hat Enterprise Agreements (具体的には Appendix 1, Software Support and Subscriptions) から転載されたものです。

「管理対象ノード」は、上記の付録 1 に従って次のように定義されます。

Each Node managed by the Software. “Node” means a Virtual Node, Physical Node or other instance of software. 

この定義は、すべての Red Hat 製品に適用可能なほど広範囲なものですが、Red Hat Ansible Automation Platform に適用される場合、管理対象ノードは、Red Hat Ansible Automation Platform ソフトウェアによって管理される任意のノードを指します。

「管理対象ノード」とは、Red Hat Ansible Automation Platform が直接的または間接的に管理する仮想ノード、物理ノード、またはソフトウェアや設定のその他の識別可能な* インスタンスを指します。

以下は、管理対象ノードの例になります (ただし、以下に限定されません)。

• サーバー、仮想マシン、その他の物理デバイス (ストレージアレイなど)

• コンテナー、アプライアンス、ソフトウェアインスタンス (データベース、ミドルウェア、アプリケーション) およびその他の仮想デバイス

• SDN、ワイヤレス、およびその他のネットワークコントローラー

管理対象ノードのユースケース:

1. クラスター化されたテクノロジープラットフォームが直接管理されるか、API を介して間接的に管理される場合、管理対象クラスター内のテクノロジーの各インスタンスは、管理対象ノードとしてカウントされます。

2. Ansible によって直接管理されている物理インスタンスまたは仮想インスタンスで、Ansible がインスタンスを識別して接続する場合、各インスタンスは単一の管理対象ノードとしてカウントされます。

3. API の背後で Ansible によって間接的に管理されている識別可能な* 物理または仮想インスタンスの場合、各インスタンスは単一の管理対象ノードとしてカウントされます。

4. インフラストラクチャーまたはアプリケーションソフトウェアインスタンスが直接管理されているか、API を介して管理されている場合、各インスタンスは管理対象ノードとしてカウントされます。

「識別可能」とは、Ansible コントロールノードに直接認識されない可能性がある管理対象ノードとして定義されますが、指示により、中間管理コントローラーからのデバイスまたはインスタンス名を介して間接的に認識されます。

Ansible は、上記のユースケースに基づいて、複数の異なるアクセスパスからノードを管理することができます。 これにより、Ansible インベントリー内の特定のホストに複数のホスト識別子が生じた場合、お客様に必要なホストエンタイトルメント数が増加することはありません。つまり、管理対象ホストは、そのホストをターゲットとする複数の自動化アクションまたはメソッドに基づいて複数回「課金」されることはありません。

Ansible Automation Platform ユーザーは、エンタイトルメントのある管理対象ノード数を超過するエステート総数を管理することはできません。この例としては、Ansible Tower/自動化コントローラーソフトウェアを介してサブパートの増分で、または Tower/コントローラーデータベースからのデータの削除またはクリアを介して、管理対象ノードを循環、回転、またはプルすることが含まれます。