| Oracle® Real Application Clustersインストレーション・ガイド 12c リリース1 (12.1) for Linux and UNIX Systems B71325-07 |
|
 前 |
 次 |
| Oracle® Real Application Clustersインストレーション・ガイド 12c リリース1 (12.1) for Linux and UNIX Systems B71325-07 |
|
前 |
次 |
この章では、Oracle Real Application Clusters (Oracle RAC)環境でのサーバー・プールの概念について説明します。この章の内容は次のとおりです。
Oracle Clusterware 11gリリース2 (11.2)には、Oracle Clusterwareが管理するリソースであるサーバー・プールという論理グループが導入されています。リソースは共有インフラストラクチャ上でホスト指定され、サーバー・プールに格納されます。リソースは、特定のインスタンスまたはノードに属するものとして定義されなくなりました。かわりに、リソース要件の優先順位を定義します。Oracle Flex Clusterでは、簡素化された管理オプションを持つサーバー・プールを使用し、クラスタ・メンバー・ノードで、ハブ・ノードおよびリーフ・ノードを使用し、特定のタイプのワークロードが実行できます。クラスタ構成ポリシー・セットを使用して、クラスタ全体にわたってクラスタ・ポリシーを動的に管理できます。
次の項では、サーバー・プールに関するその他の概念を説明します。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
特定の属性で区別されているサーバーを特定することで (サーバーのカテゴリ化というプロセス)、サーバー・プールを使用してサーバーを動的に管理できます。このようにして、異種ノードで構成されたクラスタを管理できます。
ポリシーベース管理では、データベース管理者は、データベース・リソースを実行するサーバー・プール(汎用および空きを除く)を指定します。
ポリシーベース管理の特徴は次のとおりです。
必要時に動的な容量の割当てが可能で、ポリシーで設定した優先度に従ってサーバーの容量を指定できます。
重要度ごとにリソースの割当てが可能で、アプリケーションが可能なかぎり必要最小限のリソースを取得できます。また、優先度が低いアプリケーションが、より重要なアプリケーションのリソースを消費しないようにすることもできます。
必要時には分離が保証され、アプリケーションとデータベースについて、クラスタの専用サーバーを指定できます。
ビジネスのニーズまたはアプリケーションの要求に従ってプールを変更するようにポリシーを構成して、適切なときに適切なサービスをプールから得られるようにします。
サーバー・プールで実行しているアプリケーションとデータベースは、リソースを共有しません。サーバー・プールはリソースを共有しないため、必要に応じてリソースを分離しますが、必要に応じた動的容量割当ては可能になります。ロール別管理を併用すると、この機能は標準化されたクラスタ環境がある組織のニーズに対応しますが、複数の管理者グループが、一般的なクラスタ・インフラストラクチャを共有できるようになってしまいます。
Oracle Clusterwareは、異なるリソースをクラスタに効率的に割り当てます。ノードで実行される各リソースの重要度のレベルと組み合せて、リソースが実行できるノードの最小数および最大数のみを指定する必要があります。
|
関連項目:
|
サーバー・プールは、クラスタを、シングルトンおよび均一データベース・サービス、およびアプリケーションをホストするサーバーのグループに分割します。サーバー・プールによって、クラスタの複数のサーバーに対し、統一されたワークロード(一連のOracle Clusterwareリソース)が分散されます。たとえば、Oracle Databaseを特定のサーバー・プールでのみ実行するように制限できます。ロール別管理を有効にすると、オペレーティング・システム・ユーザーにサーバー・プールを使用する権限を付与できます。
Oracle RACデータベースを含むサーバー・プールは、サーバー制御(SRVCTL)ユーティリティを使用して管理します。他のすべてのサーバー・プールを管理するには、Oracle Clusterware制御(CRSCTL)ユーティリティを使用します。最上位のサーバー・プールを作成する権限を所有しているのは、クラスタ管理者のみです。
クラスタを論理的に分割します。
常に排他的です。これは、1つのサーバーが特定の時期に1つの特定のサーバー・プールにのみ存在できることを意味します。
Oracle Clusterwareがインストールされると、汎用サーバー・プールおよび空きサーバー・プールという2つのサーバー・プールが自動的に作成されます。新規インストールのすべてのサーバーは、最初、空きサーバー・プールに割り当てられます。空きサーバー・プールにあるサーバーは、新しく定義したサーバー・プールに自動的に移動します。
空きサーバー・プールには、他のサーバー・プールに割り当てられていないサーバーが含まれています。空きサーバー・プールの属性は、次のように制限されます。
SERVER_NAMES、MIN_SIZEおよびMAX_SIZEは、ユーザーが編集することはできません。
IMPORTANCEおよびACLは、ユーザーが編集することができます。
汎用サーバー・プールは、ポリシー管理されていない任意のOracle Databaseを格納します。また、汎用サーバー・プールには、汎用サーバー・プールを親サーバー・プールとするSERVER_NAMES属性に名前を指定したサーバー一覧が含まれます。
汎用サーバー・プールの属性は、次のように制限されています。
汎用サーバー・プールの構成属性は誰も変更できません(すべての属性は読取り専用です)。
DBCAまたはSRVCTLによってHOSTING_MEMBERSリソース属性にサーバー名が指定された場合、サーバーが次の状態の場合にのみOracle Clusterwareはそれを許可します。
オンラインで汎用サーバー・プールに存在する。
オンラインで空きサーバー・プールに存在する。この場合、Oracle Clusterwareによってサーバーが汎用サーバー・プールに移動されます。
オンラインで、他のサーバー・プールに存在し、ユーザーがクラスタ管理者であるか、またはサーバー・プールのサーバーの使用が許可されている場合(この場合、サーバーは汎用サーバー・プールに移動されます)。
オフラインで、ユーザーがクラスタ管理者の場合
Oracle RACデータベースは、異なる2つの管理スタイルおよびデプロイメント・モデルをサポートしています。
ポリシー管理: デプロイメントはサーバー・プールに基づき、この場合、データベース・サービスは、サーバー・プール内でシングルトンまたは均一として、サーバー・プール内のすべてのサーバーにわたって実行されます。データベースは1つ以上のサーバー・プールにデプロイされ、サーバー・プールのサイズによってデプロイメント内のデータベース・インスタンスの数が決まります。ポリシー管理により、クラスタおよびデータベースは、要件の変更に応じて拡張または縮小できます。
ポリシー管理データベースは、カーディナリティ(通常の操作で実行する必要があるデータベース・インスタンス数)で定義されます。ポリシー管理データベースは、クラスタ管理者がクラスタに作成した1つ以上のデータベース・サーバー・プールで実行することも、別のサーバーで異なるタイミングで実行することもできます。データベース・インスタンスは、データベースに定義されたサーバー・プール内のすべてのサーバーで起動されます。
クライアントは、その時点で実行されているサーバーに関係なく、同じSCANベース接続文字列を使用してポリシー管理データベースに接続することができます。
管理者管理: デプロイメントは、Oracle Database 11gリリース2 (11.2)の前に存在していたOracle RACデプロイメント・タイプに基づき、クラスタ内の特定のノードで実行されるように各データベース・インスタンスを静的に構成する必要があり、また、preferredおよびavailable宛先を使用して、特定のデータベースに属する特定のインスタンスで実行されるようにデータベース・サービスを構成する必要があります。
管理者管理データベースのデータベース・リソースを確認すると、そのOracle Databaseと同じ名前で定義されたサーバー・プールが表示されます。このサーバー・プールは、Oracleで定義される特別なサーバー・プールの一部で、Genericと呼ばれます。Oracle RACは、Genericサーバー・プールを管理して管理者管理データベースをサポートします。SRVCTLまたはDBCAのいずれかを使用して管理者管理データベースを追加または削除すると、Genericのメンバーであるサーバー・プールがOracle RACによって作成または削除されます。
|
関連項目:
|
サーバー・プールは、DBCAでOracle RACデータベースを作成する際に作成できますが、データベース・ソフトウェアおよびデータベースのデプロイ前に、作成することをお薦めします。次もお薦めします。
クラスタに最初にサーバー・プールを作成する前にロール区分を有効にします。
構成ポリシーおよび各ポリシー・セットを使用してサーバー・プールを作成および管理します。
次の2つの方法のいずれかで、ロール別管理を実装できます。
垂直実装(レイヤー間)は、技術スタック内の様々なレイヤーで使用される異なるオペレーティング・システム・ユーザーおよびグループに基づいたロール区分手法です。サーバー・プールおよびリソースに対する権限は、アクセス制御リストを使用して、スタック内の各レイヤーの異なるユーザー(およびグループ)に付与されます。Oracle Automatic Storage Management(ASM)でのロール区分の設定は、Oracle Grid Infrastructureのインストールの一部として、特定のロールのオペレーティング・システム・グループの細かい割当てに基づいて提供されます。
水平実装(1つのレイヤー内)は、サーバー・プールおよびポリシー管理データベースまたはアプリケーションに割り当てられたアクセス制御リストを使用して付与されるリソースに対するアクセス権限を使用して、1つのレイヤー内のリソース・アクセスを制限するロール区分手法です。
たとえば、Oracle Grid Infrastructureのインストールおよび2つのデータベース・サーバー・プールの作成を実行するための、gridという名前のオペレーティング・システム・ユーザーと、プライマリ・オペレーティング・システム・グループoinstallを検討します。オペレーティング・システム・ユーザーouser1およびouser2は、サーバー・プール内で操作できる必要がありますが、サーバー・プールを変更できないようにして、他のサーバー・プールからハードウェア・リソースを誤って、または意図的に除去されないようにします。
|
関連項目:
|
Oracle RAC One Nodeとサーバー・プールについて次の点に注意してください。
Oracle RAC One Nodeは、1つのサーバー・プールのみで実行されます。このサーバー・プールは、他のサーバー・プールと同様に処理されます。
Oracle RAC One Nodeデータベース・インスタンスのオンライン再配置では、Oracle RAC One Nodeデータベースのあるノードから別のノードへの計画的な移行が可能です。再配置は、常にサーバー・プール内で行う必要があります。
