3 ポリシーベースでのクラスタおよび容量の管理
この章の内容は次のとおりです。
サーバー・プールおよびポリシー・ベース管理の概要
Oracle Clusterwareによって管理されるリソースは、サーバー・プールというサーバーの論理グループに含まれます。これは、Oracle Clusterware 11gリリース2 (11.2)で導入されました。
リソースは、共有インフラストラクチャでホスティングされ、サーバー・プール内に含まれます。Oracle Clusterwareが管理するリソースの例は、データベース・インスタンス、データベース・サービス、アプリケーションVIPおよびアプリケーション・コンポーネントです。
Oracle Clusterでは、サーバー・プールを使用してクラスタ・メンバー・ノードで特定のタイプのワークロードを実行できるようになり、その一方で管理オプションが簡素化されています。クラスタ構成ポリシー・セットを使用して、クラスタ全体にわたってクラスタ・ポリシーを動的に管理できます。
Oracle Clusterware 11g リリース2 (11.2)のサーバー・プール・モデルを使用して、Oracle Clusterwareの標準クラスタでリソースの管理を継続することも、サーバー・プールを使用しない従来どおりの方法でリソースを手動で管理することもできます。
この項には次のトピックが含まれます:
サーバー・プールおよびサーバーのカテゴリ化
管理者は、特定の属性で区別されるサーバーを識別することによって(サーバーのカテゴリ化というプロセス)、サーバー・プールを使用してサーバーを動的にデプロイおよび管理できます。このようにして、異機種環境のノードで構成されるクラスタを作成できます。
関連トピック
サーバー・プールおよびポリシーベース管理
管理者は、ポリシーベース管理で、サーバーを実行するサーバー・プールを指定します(汎用または空きプールを除く)。
たとえば、データベース管理者はSRVCTLを使用して、データベースまたはデータベース・サービスをホスティングしているサーバーのサーバー・プールを作成します。クラスタウェア管理者はCRSCTLを使用して、アプリケーションをホストするサーバーのサーバー・プールの作成など、データベース以外の用途のサーバー・プールを作成します。
ポリシーベース管理:
-
定義済のポリシーに基づいたオンライン・サーバーの再割当てを有効にして、ワークロード容量の要件を満たします。
-
ポリシーの定義どおりに、重要な作業に必要なリソースの割当てが保証されます。
-
必要時には分離が保証され、アプリケーションとデータベースについて、クラスタの専用サーバーを指定できます。
-
ビジネス・ニーズまたはアプリケーションの要求に応じてプールが変更されるようにポリシーを構成して、適切なときに必要な容量がプールから提供されるようにできます。
サーバー・プールはリソースを分離して、1つのサーバー・プールで実行されているアプリケーションが、別のサーバー・プールで実行されているリソースにアクセスできないようにします。Oracle Clusterwareでは、サーバー・プール間のロール区分を詳細に設定できます。この機能では、組織で別々のグループによって管理される環境をクラスタ化する場合に、これらのグループ間で必要となる管理ロール区分が維持されます。
Oracle Clusterwareは、クラスタ内のサーバーを効率的に割り当てます。サーバー・プールの作成時に定義されるサーバー・プール属性は、サーバーの配置および優先順位付けを、IMPORTANCEサーバー・プール属性に基づいて決定します。
サーバー・プールの動作
サーバー・プールは、クラスタをシングルトン・アプリケーションおよび共通アプリケーションの両方をホスティングしているサーバーの論理グループに分割します。アプリケーションは、データベース・サービスまたはデータベース以外のアプリケーションに分類できます。アプリケーション・ワークロードをサーバー・プールのすべてのサーバーに分散させる場合、アプリケーションは共通です。アプリケーションがサーバー・プール内の1つのサーバーで実行される場合、アプリケーションはシングルトンです。Oracle Clusterwareのロール別管理では、サーバー・プールへのアクセスおよびサーバー・プールの使用が決定されます。
Oracle RACデータベースを含むサーバー・プールは、サーバー制御(SRVCTL)ユーティリティを使用して管理します。他のすべてのサーバー・プールを管理するには、Oracle Clusterware制御(CRSCTL)ユーティリティを使用します。最上位のサーバー・プールを作成する権限を所有しているのは、クラスタ管理者のみです。
データベース管理者は、サーバー制御(SRVCTL)ユーティリティを使用して、Oracle RACデータベースを含むサーバー・プールを作成して管理します。クラスタ管理者は、Oracle Clusterware制御(CRSCTL)ユーティリティを使用して、データベース以外のアプリケーションのサーバー・プールなど、他のサーバー・プールすべてを作成して管理します。最上位のサーバー・プールを作成する権限を所有しているのは、クラスタ管理者のみです。
最上位のサーバー・プールの特徴は、次のとおりです。
-
クラスタを論理的に分割します。
-
常に排他的です。これは、1つのサーバーが特定の時期に1つの特定のサーバー・プールにのみ存在できることを意味します。
デフォルト・サーバー・プール
Oracle Clusterwareがインストールされると、汎用および空きという2つの内部サーバー・プールが自動的に作成されます。新規インストールのすべてのサーバーは、最初、空きサーバー・プールに割り当てられます。空きサーバー・プールにあるサーバーは、新しく定義したサーバー・プールに自動的に移動します。
汎用サーバー・プール
汎用サーバー・プールには、最上位のサーバー・プールには含まれておらず、ポリシー管理されていないサーバーが格納されます。ポリシー管理されていないアプリケーション(管理者管理データベースなど)をホスティングするサーバーは、汎用サーバー・プールに静的に割り当てられます。
汎用サーバー・プールの属性は、次のように制限されています。
-
汎用サーバー・プールの構成属性は誰も変更できません(すべての属性は読取り専用です)。
-
管理者管理データベースは、データベースの作成先のサーバーが次のいずれかである場合にのみ、汎用サーバー・プールに作成できます。
-
オンラインで汎用サーバー・プールに存在する。
-
オンラインで空きサーバー・プールに存在する。この場合、Oracle Clusterwareによってサーバーが汎用サーバー・プールに移動されます。
-
オンラインで、他のサーバー・プールに存在し、ユーザーがクラスタ管理者であるか、またはサーバー・プールのサーバーの使用が許可されている場合(この場合、サーバーは汎用サーバー・プールに移動されます)。
-
オフラインで、ユーザーがクラスタ管理者の場合
-
サーバー・プール属性
SRVCTLまたはCRSCTLを使用して、データベースおよびその他のアプリケーションのそれぞれにサーバー・プールを作成できます。
SRVCTLを使用してサーバー・プールを作成する場合、この項で説明されているサーバー・プール属性のサブセットのみを使用できます。CRSCTLを使用してサーバー・プールを作成する場合、一連のサーバー・プール属性すべてを使用できます。
サーバー・プール属性は、サーバー・プールを作成および管理するために定義する属性です。
使用するユーティリティは、サーバー・プールでホスティングされているリソースのタイプによって決まります。Oracle Databaseをホスティングするサーバー・プールを作成するには、SRVCTLを使用する必要があります。中間層および中間アプリケーションなどのデータベース以外のリソースをホスティングするサーバー・プールを作成するには、CRSCTLを使用する必要があります。
SRVCTLを使用してサーバー・プールを作成するときに利用できるサーバー・プール属性は、次のとおりです。
-category-importance-min-max-serverpool-servers
SRVCTLは、サーバー・プールの名前にora.を付加します。
CRSCTLを使用してサーバー・プールを作成する場合、次の表のリストで説明されているすべての属性を利用できます。
表3-1 サーバー・プール属性
| 属性 | 説明 |
|---|---|
ACL |
次の書式の文字列を使用します。 サーバー・プールの所有者、および様々なオペレーティング・システムのユーザーとグループに付与する権限を定義します。サーバー・プールの所有者には、所有者になるオペレーティング・システム・ユーザーとそのユーザーに付与する権限を定義します。 このオプション属性の値は、明示的に上書きされないかぎり、サーバー・プールを作成するユーザーのACLに基づいてサーバー・プールの作成時に移入されます。その後、サーバー・プールの既存の権限に基づいて変更を行うことができる場合、この値は変更できます。 文字列は次のように指定します。
デフォルトでは、サーバー・プールを作成するクライアントのIDは サーバー・プールを作成するオペレーティング・システム・ユーザーはサーバー・プールの所有者であり、このサーバー・プールの |
ACTIVE_SERVERS |
サーバー名の文字列には次の書式を使用します。 Oracle Clusterwareは、この属性を自動的に管理します。この属性には、現在サーバー・プールに割り当てられているサーバーの空白区切りのリストが含まれています。 |
EXCLUSIVE_POOLS |
このオプション属性は、このサーバー・プールに割り当てられたサーバーが他のサーバー・プールと共有されるかどうかを示します。サーバー・プールは、この属性に同じ値を持つその他のサーバー・プールに対して相互に排他的であることを明示的に示すことができます。サーバー・プールに割り当てられたサーバーのセットに共通の単一サーバーがない場合、2つ以上のサーバー・プールは相互に排他的です。たとえば、サーバー・プールAおよびBの両方でこの属性の値が 最上位のサーバー・プールは、デフォルトでは、相互に排他的です。 |
IMPORTANCE |
サーバー・プールの相対的な重要度で、0から1000までの整数で表されます。0が最低レベルの重要度、1000が最高レベルの重要度です。このオプション属性は、ノードがクラスタに追加されるか、またはクラスタから削除された場合にサーバー・プールを再構成する方法を判別するために使用されます。デフォルトの値は0。 |
MIN_SIZE |
サーバー・プールの最小サイズで、負でない整数で表されます。サーバー・プールに含まれるサーバーの数がこの属性で指定する数を下回る場合、Oracle Clusterwareは、この数が満たされるまで他のサーバー・プールからこのサーバー・プールにサーバーを自動的に移動します。 ノート: このオプション属性の値によって、ハード制限は設定されません。クラスタが再構成されるたびにサーバー割当ての優先順位が制御されます。デフォルト値は |
MAX_SIZE |
サーバー・プールに含めることができるサーバーの最大数で、負でない整数で表されます。この属性はオプションで、デフォルトでは、 ノート: この属性の |
NAME |
サーバー・プールの名前で、これはサーバー・プールの作成時に指定する必要があります。サーバー・プール名は、ユーザーが作成したエンティティ(リソース、タイプ、サーバーなど)の名前のドメイン内で一意である必要があります。サーバー・プール名には、254文字の制限があり、プラットフォームでサポートされているすべての文字(感嘆符(!)、チルダ(~)および空白を除く)を使用できます。サーバー・プール名の先頭をピリオドまたはoraにすることはできません。 ノート: SRVCTLを使用してサーバー・プールを作成すると、ユーティリティによってサーバー・プールの名前の先頭に「ora.」が追加されます。 |
PARENT_POOLS |
この属性を使用して、ネストされたサーバー・プールを作成することができます。この属性内に空白区切りのサーバー・プール名の文字列として示されたサーバー・プールは、親サーバー・プールと呼ばれます。親サーバー・プールに含まれているサーバー・プールは、子サーバー・プールと呼ばれます。 ノート: SRVCTLを使用してサーバー・プールを作成する場合、この属性は指定できません。 |
SERVER_CATEGORY |
登録されているサーバー・カテゴリの名前で、サーバーのカテゴリ化の一部として使用されます。Oracle Clusterwareの標準クラスタおよびOracle Flex Clusterには、デフォルトで サーバー・プールに割り当てられるサーバーを、サーバー属性に基づいて分類するには、 |
SERVER_NAMES |
サーバー・プールとの関連付けが可能な候補ノード名のリストで、空白区切りのサーバー名の文字列として表されます。このオプションの属性に対して一連のサーバー名を指定しない場合、 候補ノード名として識別されるサーバー名は、現在アクティブなクラスタ・メンバーであることを確認する検証が行われません。この属性を使用して、クラスタにまだ追加されていない候補としてサーバーを定義します。
ノート: |
サーバー・プールを使用した、Oracle Clusterwareでの新しいサーバーの割当て方法
Oracle Clusterwareは、次の順序でサーバー・プールに新しいサーバーを割り当てます。
-
汎用サーバー・プール
-
ユーザー作成のサーバー・プール
-
空きサーバー・プール
次の条件が満たされるまで、Oracle Clusterwareはサーバー・プールへのサーバーの割当てを続行します。
-
重要度順にすべてのサーバー・プールが最小値まで一杯になるまで(
MIN_SIZE)。 -
重要度順にすべてのサーバー・プールが最大値まで一杯になるまで(
MAX_SIZE)。 -
デフォルトでは、サーバー・プールに配置されていないサーバーは、空きサーバー・プールに割り当てられます。
空きサーバー・プールの
IMPORTANCE属性は変更できます。空きサーバー・プールのIMPORTANCE属性の値が、その他の1つ以上のサーバー・プールよりも大きく、これらのMIN_SIZE属性の値が満たされた時点で、残りのサーバーは空きサーバー・プールに割り当てられます。
サーバーをクラスタに追加する場合、いくつかの問題が発生します。
表3-2で構成されているサーバー・プールについて考えてみます。
表3-2 サーバー・プール属性の構成例
| NAME | IMPORTANCE | MIN_SIZE | MAX_SIZE | PARENT_POOLS | EXCLUSIVE_POOLS |
|---|---|---|---|---|---|
sp1 |
1 |
1 |
10 |
|
|
sp2 |
3 |
1 |
6 |
|
|
sp3 |
2 |
1 |
2 |
|
|
sp2_1 |
2 |
1 |
5 |
sp2 |
S123 |
sp2_2 |
1 |
1 |
5 |
sp2 |
S123 |
たとえば、クラスタ内にサーバーがなく、すべてのサーバー・プールが空であるとします。
server1というサーバーをクラスタに追加するには、次の手順を実行します。
-
サーバーからプールへの割当てを開始します。
-
Oracle Clusterwareは、最上位のサーバー・プール(親サーバー・プールがないサーバー・プール)のみを最初に処理します。この例では、最上位のサーバー・プールは
sp1、sp2およびsp3です。 -
Oracle Clusterwareは、
IMPORTANCEの順位に従ってsp2、sp3、sp1のようにサーバー・プールを表示します。 -
sp2のIMPORTANCEが最大値で、MIN_SIZE値は満たされていないため、Oracle Clusterwareはserver1をsp2に割り当てます。 -
Oracle Clusterwareは、残り2つのサーバー・プール(
sp2_1およびsp2_2)を処理します。両方のサーバー・プールのサイズはMIN_SIZE属性の値(サーバー・プールは両方とも空で、MIN_SIZE値は1)を下回っています。 -
Oracle Clusterwareは、
IMPORTANCEの順位に従ってsp2_1、sp2_2のように残り2つのサーバー・プールを表示します。 -
Oracle Clusterwareは、
server1をsp2_1に割り当てますが、sp2_1はsp2_2に対して排他的であるように構成されているため、server1をsp2_2に割り当てることはできません。
処理後、クラスタ構成は次のように表示されます。
表3-3 処理後のサーバー・プール構成
| サーバー・プール名 | 割り当てられたサーバー |
|---|---|
sp1 |
|
sp2 |
server1 |
sp3 |
|
sp2_1 |
server1 |
sp2_2 |
|
サーバー・プールからサーバー・プールへのサーバーの移動
サーバー・プール内のサーバーの数がサーバー・プールのMIN_SIZE属性の値を下回る場合(サーバーで障害が発生した場合など)、Oracle Clusterwareは、すべてのサーバー・プールのMIN_SIZEおよびIMPORTANCE属性に設定した値に基づいて、他のサーバー・プールのサーバーをサーバーの数がMIN_SIZE値を下回るサーバー・プールに移動できます。Oracle Clusterwareは、他のサーバー・プールからサーバーを選択して、次の基準に該当する不十分なサーバー・プールに移動します。
-
不十分なサーバー・プールより
IMPORTANCEの値が低いサーバー・プールに対して、Oracle Clusterwareは、サーバーの数がMIN_SIZE属性の値を下回る場合でもそのサーバー・プールからサーバーを取得します。 -
IMPORTANCEの値が同一以上のサーバー・プールに対して、Oracle Clusterwareは、サーバー・プール内のサーバーの数がMIN_SIZE属性の値より大きい場合にのみそのサーバー・プールからサーバーを取得します。
デフォルト属性を使用したサーバー・プールの管理
デフォルトでは各サーバー・プールは、サーバー・プールを管理するための次の属性オプションを使用して構成されます。
-
MIN_SIZE: サーバー・プールに含まれるサーバーの最小数。サーバー・プールのサーバーの数がこの属性の値を下回る場合、サーバーの数が属性の値になるまで、Oracle Clusterwareによって自動的に他の場所からサーバー・プールにサーバーが移動されます。
-
MAX_SIZE: サーバー・プールに含まれるサーバーの最大数。 -
IMPORTANCE: クラスタ内の他のすべてのサーバー・プール間でサーバー・プールをランク付けする0から1000(0の重要度が最低)の数値。
また、クラスタ構成ポリシーの一部として、サーバー・プールをより詳細に管理するために追加の属性を割り当てることもできます。EXCLUSIVE_POOLSやSERVER_CATEGORYなどの属性は、パフォーマンスを向上させるサーバー・プール用のポリシーを作成し、チューニング設計管理をサーバー・プールに組み込む場合に役立ちます。
サーバーのカテゴリ化の概要
サーバーのカテゴリ化では、プロセッサ・タイプ、メモリー、他の顕著なシステム機能などの属性を使用して、サーバーを特定のカテゴリに分類できます。
プールの適格なメンバーを、特定の一連の属性を共有するサーバーのカテゴリに制限するようにサーバー・プールを構成できます。元々、サーバー・プールは、特定のプールに属するようにサーバーを特徴付ける一連の基本属性に制限されており、サーバーのタイプを区別する方法はなく、すべてのサーバーは、プロセッサ、物理メモリーおよび他の特性に関して等しいとみなされていました。サーバーのカテゴリ化によって、これらのサーバーを区別する方法が提供されるようになりました。
ノート:
Oracle Database Quality of Service Management (Oracle Database QoS Management)でポリシーを作成する場合、サーバー・プールのディレクティブ・オーバーライドを設定することでサーバーを分類し、policyおよびpolicysetという語を使用するCRSCTLコマンドは無効になります。また、Oracle Clusterwareポリシーの使用からOracle Database QoS Managementポリシーの使用に切り替える場合、Oracle Clusterwareポリシーは置き換えられます。2つのポリシー・タイプは共存できないためです。ポリシーを切り替える前に、crsctl status policyset -file file_nameを使用してバックアップを作成することをお薦めします。
クラスタ構成ポリシーおよびポリシー・セットの概要
クラスタ構成ポリシーとは、クラスタ構成ポリシー・セットが管理する各サーバー・プールに1つのみの定義を含むドキュメントです。クラスタ構成ポリシー・セットとは、クラスタ用に構成されているすべてのサーバー・プールの名前と、すべてのポリシーの定義を定義しているドキュメントです。
Oracle Clusterware 12c以降のリリースでは、サーバー・プールの指定および管理用のクラスタ構成ポリシー・セットで定義されているポリシーを使用し、Oracle Clusterwareは、ポリシー・セットのポリシーに従ってサーバー・プールを管理します。クラスタ構成ポリシー・セットの場合、たとえば、電子メールの要求に対応するため、週の業務時間中により多くのサーバーをOLTPワークロードに割り当てることができ、週末および夜間はより多くのサーバーをバッチ・ワークロードに割り当てることができ、サーバー・プール構成またはサーバー割当てのトランジションをアトミックに実行できます。
いつの時点においても、クラスタに対して有効なポリシーは1つのみです。ただし、いくつかの異なるポリシーを作成できます。このため、ビジネスのニーズや要求に基づいて、または暦日や時刻に基づいてクラスタの要件に違いを反映させるように、パラメータを使用してサーバーのプールを構成できます。
関連トピック
ロード対応のリソース配置
Oracle ClusterwareがデータベースのCPU要件および制限を認識するようにそのデータベースを構成できます。
Oracle Clusterwareでは、この情報を使用して、十分なCPU数またはメモリー量(あるいはその両方)があるサーバーにのみデータベース・リソースを配置します。
Oracle ClusterwareでリソースをCPU要件またはメモリー要件とともに構成した場合、Oracle Clusterwareは、これらの要件を満たすサーバーでのみこれらのリソースの起動を試行します。特にデータベース・リソースの場合は、CPUの値をCPU_COUNTインスタンス・パラメータに、メモリーの値をMEMORY_TARGETインスタンス・パラメータ内に構成できます。
ノート:
インスタンス・パラメータを構成する場合、次のことが必要です。-
CPU (インスタンス・ケージング)について、リソース・マネージャが有効になっている必要があります。
-
メモリーについては、データベースに自動メモリー管理が使用されている必要があります。
データベース・インスタンスを追加または変更するとき、次のようにして、ロード対応のリソース配置を構成できます。
$ srvctl modify database -db db_unique_name -cpucount cpu_count -memorytarget memory_target前述の例において、cpu_countはワークロードCPUの数を表し、memory_targetは、リソースにより使用されるターゲット・メモリー(MB)を表します。
データベースでリソース・マネージャが有効になっている場合、Oracle ClusterwareはCPU_COUNTパラメータを-cpucountの値に設定します。また、データベースで自動メモリー管理が有効になっている場合、Oracle ClusterwareはMEMORY_TARGETデータベース・パラメータを-memorytargetの値に設定します。
サーバー構成およびサーバー状態の属性
サーバーをクラスタに追加するとすぐに、Oracle Clusterwareは、各サーバーに属性セットを割り当てます。
サーバーの物理特性を記述する属性もあれば、サーバーの状態を記述する属性もあります。また、サーバーをさらに分類するために役立つ変更可能な他のサーバー属性もあります。クラスタからサーバーを削除すると、Oracle Clusterwareはサーバー・オブジェクトを削除します。
サーバーのカテゴリ化管理ポリシーの一部として、サーバー構成属性を使用してサーバーを分類します。
次の表に、サーバー構成属性を示します。
表3-4 サーバー構成属性
| 属性 | 説明 |
|---|---|
ACTIVE_CSS_ROLE |
サーバーによって実行されるロール。サーバーに ノート: この属性は構成できません。 |
CONFIGURED_CSS_ROLE |
サーバー用に構成されたロール。サーバーに ノート: この属性は構成できません。 |
CPU_CLOCK_RATE |
メガヘルツ(MHz)単位のCPUクロック速度。 |
CPU_COUNT |
プロセッサ数。 |
CPU_EQUIVALENCY |
サーバーで提供されるCPUパワーが、ベースライン(1000など)による物理的表現から正または負の方向に逸脱する可能性があることを説明するために、Oracle Clusterwareが使用する相対値(1以上の正の整数として表される)。値が1000より小さい場合は、 ローカル・サーバーで次のコマンドを使用して、この属性をそれぞれ表示または変更します。 |
CPU_HYPERTHREADING |
CPUのハイパー・スレッドのステータス。値 |
MEMORY_SIZE |
メガバイト(MB)単位のメモリー・サイズ。 |
NAME |
サーバーの名前。 |
RESOURCE_USE_ENABLED |
サーバー・プール・リソース管理パラメータ。この属性の値が1の場合(デフォルト)、サーバーをリソースの配置に使用できます。値が0の場合、Oracle Clusterwareによってサーバーでのサーバー・プール・リソースの起動が禁止されます。サーバーが空きプールに残っています。
|
SERVER_LABEL |
サーバーにラベルを付けるために使用できる任意の値。サーバー・カテゴリを設定する場合にこの属性を使用できます。たとえば、場所(building_A、building_Bなど)を指定することが可能であり、これにより、場所が要件になっているプールにサーバーを配置することができます(適切なサーバー・カテゴリを作成し、それをサーバー・プールに使用します)。 ローカル・サーバーで次のコマンドを使用して、この属性をそれぞれ表示または変更します。 |
次の表に、読取り専用のサーバー状態および構成属性を示します。
表3-5 サーバー状態の属性
| 属性 | 説明 |
|---|---|
ACTIVE_POOLS |
サーバーが属しているサーバー・プールの名前の空白区切りのリストです。Oracle Clusterwareはこのリストを自動的に管理します。 |
STATE |
サーバーは、次のいずれかの状態になります。
|
STATE_DETAILS |
これは、Oracle Clusterwareで管理される読取り専用の属性です。属性ではサーバーの状態に関する追加の詳細が提供されます。サーバーの状態に関する追加の詳細には、次のものが含まれる場合があります。 サーバーの状態:
サーバーの状態:
サーバーの状態:
|
データベース・サーバーのメモリー不足の管理
オープン・セッションまたはランナウェイ・ワークロードが多すぎるため、エンタープライズ・データベース・サーバーが使用可能メモリーをすべて使用することがあります。メモリーが不足すると、トランザクションが失敗することがあります。極端な場合には、サーバーが再起動し、アプリケーションの貴重なリソースが失われることもあります。Oracle Database QoS Managementは、サーバー上のメモリー不足をリアルタイムで検出し、新しいセッションを他のサーバーにリダイレクトして、メモリーが不足しているサーバー上のすべての使用可能メモリーが使用されることを防ぎます。
Oracle Database QoS Managementが有効になっていて、Oracle Clusterwareサーバー・プールを管理している場合、Cluster Health Monitorは、クラスタ・サーバーのメモリー・リソースに関するリアルタイム情報を提供するメトリック・ストリームをOracle Database QoS Managementに送信します。この情報の内容は次のとおりです。
-
使用可能メモリーの量
-
現在使用されているメモリーの量
ノードのメモリーが不足しているとOracle Database QoS Managementが判断した場合は、新しい接続が作成されないように、そのノード上のOracle Clusterwareで管理されているデータベース・サービスが停止されます。メモリー不足が緩和されると、そのノードのサービスが自動的に再開し、リスナーはそのサーバーへの新規接続の送信を開始します。メモリー不足は、いくつかの方法で緩和できます(たとえば、既存のセッションの終了やユーザーの介入など)。
新しいセッションを別のサーバーに再ルートすると、メモリーが不足しているサーバー上の既存のワークロードが保護され、サーバーを使用可能な状態に保つことができます。サーバーのメモリー不足の管理によって、Oracle RACデータベースにホストされているアプリケーションのサービス・レベルの管理に新しいリソース保護機能が追加されます。
サーバー・カテゴリ属性
サーバーを名前付きカテゴリに定義し、サーバーをカテゴリのメンバーとして定義する属性を割り当てます。
カテゴリのメンバーを定義するために使用可能で、サーバーの状態を記述する属性もあれば、サーバーの物理特性を記述する属性もあります。独自の特性を作成して、特定カテゴリのメンバーとしてサーバーを定義することもできます。
ノート:
EXPRESSIONサーバー・カテゴリ属性に表示されるサーバー属性の値を変更する場合、新しい値を有効にする前に影響を受けるサーバーのOracle Clusterware技術スタックを再起動する必要があります。
次の表に、使用可能なサーバー・カテゴリ属性を示します。
表3-6 サーバー・カテゴリ属性
| 属性 | 説明 |
|---|---|
NAME |
サーバー・カテゴリの名前で、これはサーバー・カテゴリの作成時に指定する必要があります。サーバー・カテゴリ名は、ユーザーが作成したエンティティ(リソース、タイプ、サーバーなど)の名前のドメイン内で一意である必要があります。サーバー・プール名には、254文字の制限があり、プラットフォームでサポートされているすべての文字(感嘆符(!)およびチルダ(~)を除く)を使用できます。サーバー・プール名の先頭をピリオドまたはoraにすることはできません。 |
ACTIVE_CSS_ROLE |
サーバーのアクティブ・ロール。これは、Oracle Flex ClusterまたはOracle Clusterware標準クラスタでハブ・ノードになっているサーバーの |
EXPRESSION |
サーバーがカテゴリに属するかどうかを判断するために、各サーバーに対して評価できる一連のサーバー属性名、値および状態。表3-4に、サーバー属性を示します。 受け入れ可能な比較演算子は、次のとおりです。
受け入れ可能なブール演算子は、次のとおりです。
ノート: たとえば: EXPRESSION='((NAME = server1) OR (NAME = server2))'" |
ポリシー・セット構成の例
この例では、3つの異なるアプリケーションapp1、app2およびapp3によって使用される4ノードのクラスタがあり、3つのサーバー・プールpool1、pool2およびpool3を作成しました。各アプリケーションは専用のサーバー・プールで動作するように割り当て、app1は2つのサーバーを希望し、app2とapp3はそれぞれ1つのサーバーを希望するように、サーバー・プールを構成します。
サーバー・プールの構成は、次のようになります。
$ crsctl status serverpool pool1 -p
NAME=pool1
IMPORTANCE=0
MIN_SIZE=2
MAX_SIZE=2
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:mjk:rwx,pgrp:g900:rwx,other::r--
SERVER_CATEGORY=
$ crsctl status serverpool pool2 -p
NAME=pool2
IMPORTANCE=0
MIN_SIZE=1
MAX_SIZE=1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:mjk:rwx,pgrp:g900:rwx,other::r--
SERVER_CATEGORY=
$ crsctl status serverpool pool3 -p
NAME=pool3
IMPORTANCE=0
MIN_SIZE=1
MAX_SIZE=1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:mjk:rwx,pgrp:g900:rwx,other::r--
SERVER_CATEGORY=ノート:
前述の例に示すcrsctl status serverpoolコマンドは、CRSCTLを使用してサーバー・プールを作成した場合にのみ機能します。
ただし、この構成では、一部のアプリケーションは日、週または月の様々なときにサーバー時間を必要とする事実を考慮しません。たとえば、電子メール・アプリケーションは通常、業務時間中はより多くのリソースを使用して、夜間および週末は使用するリソースは少なくて済みます。
また、app1は、業務時間中は2つのサーバーを必要とし、夜間は1つのみのサーバーを必要とし、週末はサーバーを必要としないと想定します。同時に、app2とapp3はそれぞれ、業務時間中は1つのサーバーを必要とし、夜間はapp2は2つのサーバーを必要とし、app3は1つのサーバーを必要とします。週末は、app2は1つのサーバーを必要とし、app3は3つのサーバーを必要とします。このシナリオは、クラスタに対して構成する必要がある3つの構成を示しています。
-
昼間:
- app1は2つのサーバーを使用します。
- app2とapp3はそれぞれ1つのサーバーを使用します。
-
夜間:
- app1は1つのサーバーを使用します。
- app2は2つのサーバーを使用します。
- app3は1つのサーバーを使用します。
-
週末:
- app1は実行されません(0のサーバー)。
- app2は1つのサーバーを使用します。
- app3は3つのサーバーを使用します。
ポリシー・セットの作成
これらの前提を考えた場合、crsctl create policysetコマンドを実行して、Defaultという単一ポリシーを使用してポリシー・セットを作成します。これは、crsctl status serverpoolコマンドによって表示される構成を反映します。Defaultポリシーを使用すると、この例で想定されたニーズに対応するために他のポリシーを作成できます。crsctl create policysetコマンドによって、例3-1のようなテキスト・ファイルが作成されます。
例3-1 ポリシー・セットのテキスト・ファイル
SERVER_POOL_NAMES=Free pool1 pool2 pool3
POLICY
NAME=Default
SERVERPOOL
NAME=pool1
IMPORTANCE=0
MAX_SIZE=2
MIN_SIZE=2
SERVER_CATEGORY=
SERVERPOOL
NAME=pool2
IMPORTANCE=0
MAX_SIZE=1
MIN_SIZE=1
SERVER_CATEGORY=
SERVERPOOL
NAME=pool3
IMPORTANCE=0
MAX_SIZE=1
MIN_SIZE=1
SERVER_CATEGORY=ポリシーの変更
この例で想定されているニーズに対応するように前述のポリシー・セットを変更するには、ポリシーの名前をDefaultからDayTimeに変更することによってテキスト・ファイルを編集し、すでに説明した3つのシナリオに対してポリシーを定義します。次に、ポリシーをコピーして2回貼付けを行って、2つのポリシーを作成します。これらには、例3-2に示すように、NightTimeとWeekendという名前を付けます。
例3-2 変更されたポリシー・セットのテキスト・ファイル
SERVER_POOL_NAMES=Free pool1 pool2 pool3
POLICY
NAME=DayTime
SERVERPOOL
NAME=pool1
IMPORTANCE=0
MAX_SIZE=2
MIN_SIZE=2
SERVER_CATEGORY=
SERVERPOOL
NAME=pool2
IMPORTANCE=0
MAX_SIZE=1
MIN_SIZE=1
SERVER_CATEGORY=
SERVERPOOL
NAME=pool3
IMPORTANCE=0
MAX_SIZE=1
MIN_SIZE=1
SERVER_CATEGORY=
POLICY
NAME=NightTime
SERVERPOOL
NAME=pool1
IMPORTANCE=0
MAX_SIZE=1
MIN_SIZE=1
SERVER_CATEGORY=
SERVERPOOL
NAME=pool2
IMPORTANCE=0
MAX_SIZE=2
MIN_SIZE=2
SERVER_CATEGORY=
SERVERPOOL
NAME=pool3
IMPORTANCE=0
MAX_SIZE=1
MIN_SIZE=1
SERVER_CATEGORY=
POLICY
NAME=Weekend
SERVERPOOL
NAME=pool1
IMPORTANCE=0
MAX_SIZE=0
MIN_SIZE=0
SERVER_CATEGORY=
SERVERPOOL
NAME=pool2
IMPORTANCE=0
MAX_SIZE=1
MIN_SIZE=1
SERVER_CATEGORY=
SERVERPOOL
NAME=pool3
IMPORTANCE=0
MAX_SIZE=3
MIN_SIZE=3
SERVER_CATEGORY=個々のポリシーの名前の変更に加えて、各ポリシーの各サーバー・プールのMAX_SIZEポリシー属性とMIN_SIZEポリシー属性も、アプリケーションのニーズに従って変更されたことに注意してください。
次のコマンドによって、ファイルに格納されているポリシー・セットがOracle Clusterwareに登録されます。
$ crsctl modify policyset -file file_name前述の例に示すのと同じ結果を得るには、crsctl modify policysetコマンドを使用してDefaultポリシー・セット全体を編集し、crsctl modify serverpoolコマンドを使用して、特定のポリシーに対する個々のサーバー・プール属性を変更します。
次のコマンドでは、3つのサーバー・プールを管理するようにDefaultポリシー・セットを変更します。
$ crsctl modify policyset -attr "SERVER_POOL_NAMES=Free pool1 pool2 pool3"
次のコマンドでは、3つのポリシーを追加します。
$ crsctl add policy DayTime
$ crsctl add policy NightTime
$ crsctl add policy Weekend次のコマンドでは、ポリシーの要件に従って3つのサーバー・プールを構成します。
$ crsctl modify serverpool pool1 -attr "MIN_SIZE=2,MAX_SIZE=2" -policy DayTime
$ crsctl modify serverpool pool1 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy NightTime
$ crsctl modify serverpool pool1 -attr "MIN_SIZE=0,MAX_SIZE=0" -policy Weekend
$ crsctl modify serverpool pool2 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy DayTime
$ crsctl modify serverpool pool2 -attr "MIN_SIZE=2,MAX_SIZE=2" -policy NightTime
$ crsctl modify serverpool pool2 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy Weekend
$ crsctl modify serverpool pool3 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy DayTime
$ crsctl modify serverpool pool3 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy NightTime
$ crsctl modify serverpool pool3 -attr "MIN_SIZE=3,MAX_SIZE=3" -policy Weekendこれで、3つのアプリケーションの要件に対応するためにサーバー・プールを管理する3つの個々のポリシーができます。
ポリシーのアクティブ化
これでポリシー・セットが構成され、3つの異なるポリシーを使用して3つのサーバー・プールを制御します。必要に応じてポリシーをアクティブ化でき、各ポリシーの構成に従ってOracle Clusterwareでサーバー・プールを再構成するように指示することができます。
次のコマンドでは、DayTimeポリシーをアクティブ化します。
$ crsctl modify policyset -attr "LAST_ACTIVATED_POLICY=DayTime"リソースの現在のステータスは、次のとおりです。
$ crsctl status resource -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
app1
1 ONLINE ONLINE mjk_has3_2 STABLE
2 ONLINE ONLINE mjk_has3_0 STABLE
app2
1 ONLINE ONLINE mjk_has3_1 STABLE
app3
1 ONLINE ONLINE mjk_has3_3 STABLEサーバー・プールのステータスは、次のとおりです。
$ crsctl stat serverpool
NAME=Free
ACTIVE_SERVERS=
NAME=Generic
ACTIVE_SERVERS=
NAME=pool1
ACTIVE_SERVERS=mjk_has3_0 mjk_has3_2
NAME=pool2
ACTIVE_SERVERS=mjk_has3_1
NAME=pool3
ACTIVE_SERVERS=mjk_has3_3サーバーはDayTimeポリシーに従って割り当てられ、アプリケーションはそれぞれのサーバーで実行されます。
次のコマンドでは、Weekendポリシーをアクティブ化します(サーバー・プールには様々なサイズがあるため、サーバーがサーバー・プール間を移動するにつれて、停止するアプリケーションもあれば、起動するアプリケーションもあります)。
$ crsctl modify policyset -attr "LAST_ACTIVATED_POLICY=Weekend"
CRS-2673: Attempting to stop 'app1' on 'mjk_has3_2'
CRS-2673: Attempting to stop 'app1' on 'mjk_has3_0'
CRS-2677: Stop of 'app1' on 'mjk_has3_0' succeeded
CRS-2672: Attempting to start 'app3' on 'mjk_has3_0'
CRS-2677: Stop of 'app1' on 'mjk_has3_2' succeeded
CRS-2672: Attempting to start 'app3' on 'mjk_has3_2'
CRS-2676: Start of 'app3' on 'mjk_has3_2' succeeded
CRS-2676: Start of 'app3' on 'mjk_has3_0' succeededリソースの現在のステータスは、次のとおりです。
$ crsctl status resource -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
app1
1 ONLINE OFFLINE STABLE
2 ONLINE OFFLINE STABLE
app2
1 ONLINE ONLINE mjk_has3_1 STABLE
app3
1 ONLINE ONLINE mjk_has3_0 STABLE
2 ONLINE ONLINE mjk_has3_2 STABLE
3 ONLINE ONLINE mjk_has3_3 STABLE
--------------------------------------------------------------------------------
サーバー・プールのステータスは、次のとおりです。
$ crsctl status serverpool
NAME=Free
ACTIVE_SERVERS=
NAME=Generic
ACTIVE_SERVERS=
NAME=pool1
ACTIVE_SERVERS=
NAME=pool2
ACTIVE_SERVERS=mjk_has3_1
NAME=pool3
ACTIVE_SERVERS=mjk_has3_0 mjk_has3_2 mjk_has3_3crsctl modify policysetコマンドを使用して、Oracle Clusterwareは、サーバー・プール構成を変更し、ポリシーの要件に従ってサーバーを移動し、アプリケーションの停止と起動を行いました。