| Oracle® Real Application Clusters管理およびデプロイメント・ガイド 12cリリース1 (12.1) B71323-07 |
|
 前 |
 次 |
この項では、次のサーバー・プールの使用例を示します。
サーバーの最小数および最大数
onlineとbackofficeという2つのサーバー・プールに4ノード・クラスタが構成されているとします。onlineサーバー・プールではdbsalesというデータベースが実行され、browse、searchおよびsalescartサービスを提供しています。backofficeサーバー・プールではdberpというデータベースが実行され、図1-2に示すとおり、inventoryおよびshippingサービスを提供しています。通常の営業時間中、企業は通常の要求に対応するために、dbsalesデータベースの最低2つのインスタンスと、dberpデータベースの1つのインスタンスを必要とします。
このポリシー管理デプロイメントでは、onlineサーバー・プールのMIN_SIZEサーバー・プール属性の値は2で、backofficeサーバー・プールのMIN_SIZEサーバー・プール属性の値は1です。このように構成されたOracle Clusterwareでは、常にonlineサーバー・プールに2つのサーバーがあり、backofficeサーバー・プールに1つのサーバーがあります。これは4ノード・クラスタであるため、いずれのサーバー・プールにも割り当てられていないサーバーが1つ残ります。最後のサーバーがデプロイされる場所は、各サーバー・プールのMAX_SIZEサーバー・プール・パラメータによって決まります。各サーバー・プールのMAX_SIZEサーバー・プール属性の値の合計がクラスタ内のサーバーの総数より小さい場合、残りのサーバーは、デプロイされたノードの障害を待つ空きサーバー・プールにとどまります。
MAX_SIZEの値がMIN_SIZEの値より大きい場合、図1-2で示すとおり、また、次の項で詳細に説明するとおり、残りのサーバーは、重要度の値が最大のサーバー・プールにデプロイされます。この場合、サーバーは、サーバーが必要とされるサーバー・プールを結合するためにオンラインで再配置できる共有可能なリソースになります。たとえば、営業時間中は、サーバーをonlineサーバー・プールに与えて、dbsalesデータベースのインスタンスを追加できますが、営業時間後は、backofficeサーバー・プールに再配置して、dberpデータベース・インスタンスを追加できます。このような動作はすべてオンラインであり、インスタンスはトランザクション的に停止されます。
これらの2つのポリシー管理データベースは、必要とされるインスタンスのみを実行し、要求またはビジネス要件を満たすように動的に増減できます。
サーバー・プールのIMPORTANCE属性
IMPORTANCEサーバー・プール属性は、クラスタの起動時、およびノードの障害または削除に応じて使用されます。管理者管理データベースとは対照的に、最初に起動するデータベースを決めるように、また、マルチノードの停止時にオンラインのままにしておくデータベースを決めるように、様々な重要度でサーバー・プールを構成できます。
salesおよびbackofficeという2つのサーバー・プール内で、dbappsというデータベースをホストする4ノード・クラスタを考えてみます。図1-3に示すとおり、2つのサービスorderentryおよびbillingは、salesサーバー・プールで実行され、他の2つのサービスerpおよびreportsは、backofficeサーバー・プールで実行されます。backofficeサーバー・プールの値より大きいsalesサーバー・プールのIMPORTANCEサーバー・プール属性の値を構成することによって、マルチノードの障害の後に残って実行されているサーバーが1つのみでも、クラスタが起動すると、salesのサービスは最初に起動して常に使用可能になります。IMPORTANCEサーバー・プール属性を使用すると、サービスをランク付けすることができ、常に使用可能にするためにクラスタ内のすべてのノードでサービスを実行する必要もなくなります。
データベースの統合
いくつかの様々なアプローチを個別にまたは組み合せて使用すると、Oracle Databasesを統合できます。ポリシー管理デプロイメントでは統合は容易です。スキーマ統合の場合、複数のアプリケーションは、個別スキーマまたはプラガブル・データベース(PDB)に分離された単一データベースによってホストされているため、サーバー・プールを使用して必要な容量を満たすことができます。サーバー・プールの動的スケーリング・プロパティのため、現在の要求またはビジネス要件に合うようにデータベース・インスタンスの数を増減できます。サーバー・プールによって、一緒にまたは別個に実行されるサービスも決定されるため、必要なアフィニティまたは分離を構成および維持できます。
たとえば、バージョン要件のためにスキーマ統合を使用できない場合、単一セットのサーバー上で複数のデータベースをホストできます。ポリシー管理データベースを使用すると、ポリシー管理データベースはインスタンス・ケージングを利用することによって同じサーバー・プールを共有できるため、このデータベース統合が容易になります。これにより、要求またはビジネス・ポリシーとスケジュールに合うように、水平方向(サーバー・プール・サイズを使用)と垂直方向(CPU_COUNTサーバー構成属性を使用)の両方にデータベースを動的に増減できます。
関連項目:
CPU_COUNTサーバー構成属性の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
対照的に、管理者管理データベースでは、データベース・インスタンスまたはサーバーに障害が発生した場合、ワークロードのフェイルオーバーを吸収するために各サーバーに容量を確保する必要があります。ただし、ポリシー管理データベースの場合、MIN_SIZE、MAX_SIZEおよびIMPORTANCEサーバー・プール属性を使用して、実行中のワークロードのビジネスの必要性別にサーバー・プールを効果的にランク付けできます。
サーバーの障害によってサーバー・プールがサーバーの構成済最小数を下回ると、重要性の少ないサーバー・プールからの別のサーバーがそのかわりにるため、サーバーの数は構成済最小数に戻ります。これにより、残りのサーバーのオーバーロードによるカスケード障害のリスクがなくなり、処理障害のために容量を確保する必要性を大幅に減らしたり、その必要性をなくすことさえできます。
ポリシー管理データベースに移行または変換すると、クラスタの統合も可能になり、より大きなクラスタを作成することで、データベースのホストおよび拡張に使用可能なサーバー数が増加するため可用性およびスケーラビリティの向上が実現されます。ポリシー管理データベースでは、インスタンス名を特定のサーバーにバインディングすること、およびサービスを特定のインスタンスにバインディングすることが不要なため、大きなクラスタを構成および管理する際の複雑さが大幅に軽減されます。
図1-4に、デプロイメント例を示します。ここでは、前の2つのクラスタ例(図1-2および図1-3)は、単一クラスタに統合され、構成されたデータベース統合(インスタンス・ケージングを使用)とクラスタ統合(サーバー・プールを使用)の両方を利用して、ワークロードのサイズ設定および優先度付けが適切に行われるようにします。
