デプロイメント・スキームの決定

アプリケーションの管理者またはポリシー管理を使用するかどうかを決定する必要があります。管理者管理は、クラスタ構成が変更される可能性が低い、小規模な2ノード構成に使用します。ポリシー管理は、クラスタが3つ以上のノードで構成されている場合に、より動的な構成に使用します。たとえば、リソースがノード1およびノード2のみで実行されている場合、これらのノードにのみ必要なファイルが存在するため、管理者管理がより適切である可能性があります。

Oracle Clusterwareでは、匿名サーバーで構成され、必要なプール・サイズに厳密に基づく、アクセス制御されたサーバー・プールでのアプリケーションのデプロイメントがサポートされています。この場合、管理者定義のクラスタ・ポリシーを使用して、必要なサイズおよび重要度のレベルで、サーバー割当てを制御する必要があります。または、厳密なサーバー割当てまたは優先サーバー割当てを使用することもでき、この場合、リソースは具体的な名前が指定されたサーバーで実行されます。これは、以前のリリースのOracle Clusterwareで使用可能な既存のモデル(現在の管理者管理)を表します。

概念上、両方のデプロイメント・スキームで開発およびデプロイされたアプリケーションをホスティングするクラスタは、サーバーの、論理的に分割された2つのグループと考えることができます。一方のサーバー・グループはサーバー・プールに使用され、ロールの分離およびサーバーの容量制御が可能になります。もう一方のサーバー・グループでは、クラスタ内の名前付きのサーバーに基づく固定割当てが想定されます。

いずれかのデプロイメント・スキームを使用してアプリケーションを管理するには、クラスタにリソースを追加する前にサーバー・プールを作成する必要があります。Genericという名前の組込みサーバー・プールは、管理者ベース管理のアプリケーションによって使用されるサーバーを常に所有します。汎用サーバー・プールは論理的な分割で、異なる管理スキームを使用してクラスタの2つの部分を分割するために使用できます。

サード・パーティの開発者がこのモデルを使用してアプリケーションをデプロイするには、サーバー・プールを使用する必要があります。名前付きのサーバーに基づく、既存のアプリケーション開発およびデプロイメント・モデルを利用するには、汎用サブプール(汎用プールが親であるサーバー・プールで、サーバー・プール属性のPARENT_POOLSで定義される)を使用する必要があります。親として汎用を使用するサブプールを作成し、サーバーをサブプール定義に名前で列挙することによって、名前付きのサーバーが、汎用内に存在すること、および名前付きのサーバー・モデルを使用するアプリケーション専用に使用されることがアプリケーションで保証されます。