プライマリ・コンテンツに移動
Oracle® Real Application Clustersインストレーション・ガイド
12c リリース1 (12.1) for Microsoft Windows
B72964-07
目次へ移動
目次
索引へ移動
索引

前
次

5 Oracle RACでのサーバー・プールの使用

Oracle Real Application Clusters (Oracle RAC)環境でのサーバー・プールの概念を理解します。

5.1 ポリシー管理型のクラスタおよび容量管理

Oracle Clusterware 11gリリース2から、Oracle Clusterwareが管理するリソースは、サーバー・プールと呼ばれるサーバーの論理グループに含まれます。

リソースは共有インフラストラクチャ上でホスト指定され、サーバー・プールに格納されます。リソースは、特定のインスタンスまたはノードに属するものとして定義されなくなりました。かわりに、リソース要件の優先度が定義されます。クラスタ構成ポリシー・セットを使用して、クラスタ全体にわたってクラスタ・ポリシーを動的に管理できます。

関連項目:

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

5.1.1 サーバー・プールおよびサーバーのカテゴリ化

特定の属性で識別されているサーバーを特定することで、つまり、サーバーのカテゴリ化というプロセスによって、サーバー・プールを使用してサーバーを動的に管理できます。

このようにして、異種ノードで構成されたクラスタを管理できます。

5.1.2 サーバー・プールおよびポリシーベース管理

ポリシーベース管理では、データベース管理者は、データベース・リソースを実行するサーバー・プール(汎用および空きを除く)を指定します。

ポリシー・ベースの管理:

  • 必要時に動的な容量の割当てが可能で、ポリシーで設定した優先度に従ってサーバーの容量を指定できます。

  • 重要度ごとにリソースの割当てが可能で、アプリケーションが可能なかぎり必要最小限のリソースを取得できます。また、優先度が低いアプリケーションが、より重要なアプリケーションのリソースを消費しないようにすることもできます。

  • 必要時には分離が保証され、アプリケーションとデータベースについて、クラスタの専用サーバーを指定できます。

  • ビジネスのニーズまたはアプリケーションの要求に従ってプールを変更するようにポリシーを構成して、適切なときに適切なサービスをプールから得られるようにします。

サーバー・プールで実行しているアプリケーションとデータベースは、リソースを共有しません。サーバー・プールはリソースを共有しないため、必要に応じてリソースを分離しますが、必要に応じた動的容量割当ては可能になります。ロール別管理を併用すると、この機能は標準化されたクラスタ環境がある組織のニーズに対応しますが、複数の管理者グループが、一般的なクラスタ・インフラストラクチャを共有できるようになってしまいます。

Oracle Clusterwareは、異なるリソースをクラスタに効率的に割り当てます。ノードで実行される各リソースの重要度のレベルと組み合せて、リソースが実行できるノードの最小数および最大数のみを指定する必要があります。

関連項目:

  • Oracle Clusterware管理およびデプロイメント・ガイドのOracle Clusterwareリソース・リファレンスに関する項

  • ビジネスまたはアプリケーションの要求に対応するためのサーバー・プールの管理の詳細は、Oracle Clusterware管理およびデプロイメント・ガイドを参照してください。

5.1.3 サーバー・プールの動作

サーバー・プールによって、クラスタはシングルトンと均一のデータベース・サービスおよびアプリケーションをホストするサーバーのグループに分割されます。

サーバー・プールによって、クラスタの複数のサーバーに対し、均一のワークロード(一連のOracle Clusterwareリソース)が分散されます。たとえば、Oracle Databaseを特定のサーバー・プールでのみ実行するように制限できます。ロール別管理を有効にすると、オペレーティング・システム・ユーザーにサーバー・プールを使用する権限を付与できます。

Oracle RACデータベースを含むサーバー・プールは、サーバー制御(SRVCTL)ユーティリティを使用して管理します。他のすべてのサーバー・プールを管理するには、Oracle Clusterware制御(CRSCTL)ユーティリティを使用します。最上位のサーバー・プールを作成する権限を所有しているのは、クラスタ管理者のみです。

最上位のサーバー・プール:

  • クラスタを論理的に分割します。

  • 常に排他的です。これは、1つのサーバーが特定の時期に1つの特定のサーバー・プールにのみ存在できることを意味します。

5.1.4 デフォルト・サーバー・プール

Oracle Clusterwareがインストールされると、汎用サーバー・プールおよび空きサーバー・プールという2つのサーバー・プールが自動的に作成されます。

新規インストールのすべてのサーバーは、最初、空きサーバー・プールに割り当てられます。空きサーバー・プールにあるサーバーは、新しく定義したサーバー・プールに自動的に移動します。

5.1.4.1 空きサーバー・プール

空きサーバー・プールには、他のサーバー・プールに割り当てられていないサーバーが含まれています。

空きサーバー・プールの属性は、次のように制限されます。

  • SERVER_NAMESMIN_SIZEおよびMAX_SIZEは、ユーザーが編集することはできません。

  • IMPORTANCEおよびACLは、ユーザーが編集することができます。

5.1.4.2 汎用サーバー・プール

汎用サーバー・プールは、ポリシー管理されていない任意のOracle Databaseを格納します。

また、汎用サーバー・プールには、汎用サーバー・プールを親サーバー・プールとして示すサーバー・プールのSERVER_NAMES属性に指定された名前のサーバーが含まれます。

汎用サーバー・プールの属性は、次のように制限されています。

  • 汎用サーバー・プールの構成属性は誰も変更できません(すべての属性は読取り専用です)。

  • Oracle Clusterwareは、サーバーが次の状態の場合にのみ、Oracle Database Configuration Assistant (DBCA)またはSRVCTLがHOSTING_MEMBERSリソース属性にサーバー名を指定することを許可します。

    • オンラインで汎用サーバー・プールに存在する。

    • オンラインで空きサーバー・プールに存在する。この場合、Oracle Clusterwareによってサーバーが汎用サーバー・プールに移動されます。

    • オンラインで、他のサーバー・プールに存在し、ユーザーがクラスタ管理者であるか、またはサーバー・プールのサーバーの使用が許可されている場合(この場合、サーバーは汎用サーバー・プールに移動されます)。

    • オフラインで、ユーザーがクラスタ管理者の場合

5.2 Oracle RACデータベースとサーバー・プール

Oracle RACデータベースは、異なる2つの管理スタイルおよびデプロイメント・モデルをサポートしています。

ポリシー管理型

デプロイメントはサーバー・プールに基づきます。この場合、データベース・サービスは、サーバー・プール内でシングルトンまたは均一として、サーバー・プール内のすべてのサーバーにわたって実行されます。データベースは1つ以上のサーバー・プールにデプロイされ、サーバー・プールのサイズによってデプロイメント内のデータベース・インスタンスの数が決まります。ポリシー管理により、クラスタおよびデータベースは、要件の変更に応じて拡張または縮小できます。

ポリシー管理データベースは、カーディナリティ(通常の操作で実行する必要があるデータベース・インスタンス数)で定義されます。ポリシー管理データベースは、クラスタ管理者がクラスタに作成した1つ以上のデータベース・サーバー・プールで実行することも、別のサーバーで異なるタイミングで実行することもできます。データベース・インスタンスは、データベースに定義されたサーバー・プール内のすべてのサーバーで起動されます。

クライアントは、その時点で実行されているサーバーに関係なく、同じSCANベース接続文字列を使用してポリシー管理データベースに接続することができます。

管理者管理型

デプロイメントは、Oracle Database 11gリリース2 (11.2)の前に存在していたOracle RACデプロイメント・タイプに基づきます。また、各データベース・インスタンスをクラスタ内の特定のノードで実行するように静的に構成することが必要になるほか、preferredおよびavailableの指定を使用して、特定のデータベースに属する特定のインスタンスでデータベース・サービスを実行するように構成することが必要になります。

管理者管理データベースのデータベース・リソースを確認すると、そのOracle Databaseと同じ名前で定義されたサーバー・プールが表示されます。このサーバー・プールは、Oracleで定義される特別なサーバー・プールの一部で、Genericと呼ばれます。Oracle RACは、Genericサーバー・プールを管理して管理者管理データベースをサポートします。SRVCTLまたはOracle Database Configuration Assistant (DBCA)のいずれかを使用して管理者管理データベースを追加または削除すると、汎用サーバー・プールのメンバーであるサーバー・プールがOracle RACによって作成または削除されます。

関連項目:

  • Oracle Clusterware管理およびデプロイメント・ガイドサーバー・プールおよびポリシーベース管理の概要に関する項

  • Oracle Clusterware管理およびデプロイメント・ガイドクラスタ構成ポリシーおよびポリシー・セットの概要に関する項

5.3 Oracle RACデータベースに対するサーバー・プールの作成について

サーバー・プールは、Oracle Database Configuration AssistantでOracle RACデータベースを作成する際に作成できますが、データベース・ソフトウェアおよびデータベースのデプロイ前に、作成することをお薦めします。

また、次の手順を実行することをお薦めします。

  • クラスタに最初にサーバー・プールを作成する前にロール区分を有効にします。

  • 構成ポリシーおよび各ポリシー・セットを使用してサーバー・プールを作成および管理します。

ロール別管理は、垂直または水平のいずれかの方法で実装できます。

垂直実装(レイヤー間)

垂直実装(レイヤー間)は、技術スタック内の様々なレイヤーで使用される異なるオペレーティング・システム・ユーザーおよびグループに基づいたロール区分手法です。サーバー・プールおよびリソースに対する権限は、アクセス制御リストを使用して、スタック内の各レイヤーの異なるユーザー(およびグループ)に付与されます。Oracle Automatic Storage Management (Oracle ASM)でのロール区分の設定は、Oracle Grid Infrastructureのインストールの一部として、特定のロールのオペレーティング・システム・グループの細かい割当てに基づいて提供されます。

水平実装(1つのレイヤー内)

水平実装は、サーバー・プールおよびポリシー管理データベースまたはアプリケーションに割り当てられたアクセス制御リストを使用して付与されるリソースに対するアクセス権限を使用して、1つのレイヤー内のリソース・アクセスを制限するロール区分手法です。

たとえば、Oracle Grid Infrastructureのインストールおよび2つのデータベース・サーバー・プールの作成を実行するためのgridという名前のオペレーティング・システム・ユーザーを検討します。オペレーティング・システム・ユーザーouser1およびouser2は、サーバー・プール内で操作を行えることが必要ですが、サーバー・プールを変更できないようにして、他のサーバー・プールからハードウェア・リソースを誤って、または意図的に除去されないようにする必要があります。

関連項目:

  • Oracle Clusterware管理およびデプロイメント・ガイドクラスタ構成ポリシーおよびポリシー・セットの概要に関する項

  • Oracle Clusterware管理およびデプロイメント・ガイドロール別管理に関する項

5.4 Oracle RAC One Nodeとサーバー・プール

Oracle RAC One Nodeでは、サーバー・プールの使用がサポートされていますが、いくつかの制限があります。

Oracle RAC One Nodeとサーバー・プールについて、次の点に注意してください。

  • Oracle RAC One Nodeは、1つのサーバー・プールのみで実行されます。このサーバー・プールは、他のサーバー・プールと同じように扱われます。

  • Oracle RAC One Nodeデータベース・インスタンスのオンライン再配置によって、ノード間でのOracle RAC One Nodeデータベースを計画的に移行できます。再配置は、常に、サーバー・プール内である必要があります。