| Oracle® Clusterware管理およびデプロイメント・ガイド 11gリリース2 (11.2) B56289-08 |
|
 前 |
 次 |
この章では、Oracle Clusterwareの管理について説明します。内容は次のとおりです。
Oracle Clusterware 11gリリース2(11.2)では、データベースが使用するノードおよびリソースの異なる管理方法が導入されており、ポリシー・ベース管理と呼ばれます。
この項の内容は次のとおりです。
Oracle Clusterware 11gリリース2(11.2)以上では、Oracle Clusterwareで管理されるリソースは、サーバー・プールと呼ばれるサーバーの論理グループに含まれています。リソースは共有インフラストラクチャ上でホスト指定され、サーバー・プールに格納されます。リソースは、ポリシーによってハードウェア・リソース(CPUやメモリーなど)の使用量にのみ制限され、単一システム環境にデプロイされているように動作します。
リソースは、サーバー・プールを使用して動的に管理することで、クラスタ内のリソースをポリシー・ベースで管理することができます。また、特定のノードで実行するように物理的にリソースを割り当てる従来の方法で管理することもできます。
ポリシー・ベース管理の特徴は次のとおりです。
必要時に動的な容量の割当てが可能で、ポリシーで設定した優先度に従ってサーバーの容量を指定できます。
重要度ごとにリソースの割当てが可能で、アプリケーションが可能なかぎり必要最小限のリソースを取得できます。また、優先度が低いアプリケーションが、より重要なアプリケーションのリソースを消費しないようにすることもできます。
必要時には分離が保証され、アプリケーションとデータベースについて、クラスタの専用サーバーを指定できます。
サーバー・プールで実行しているアプリケーションとデータベースは、リソースを共有しません。このため、サーバー・プールは必要に応じてリソースを分離しますが、必要時は動的な容量の割当てが可能です。ロール別管理を併用すると、この機能は標準化されたクラスタ環境がある組織のニーズに対応しますが、複数の管理者グループが、一般的なクラスタ・インフラストラクチャを共有できるようになってしまいます。
Oracle Clusterwareは、異なるリソースをクラスタに効率的に割り当てます。ノードで実行される各リソースの重要度のレベルと組み合せて、リソースが実行できるノードの最小数および最大数のみを指定する必要があります。
サーバーをクラスタに追加するとすぐに、Oracle Clusterwareは、各サーバーに属性セットを割り当てます。サーバーをクラスタから削除すると、Oracle Clusterwareはそれらの設定を削除します。表2-1に、サーバー属性を示します。
表2-1 サーバー属性
| 属性 | 説明 |
|---|---|
NAME |
サーバーのノード名です。サーバー名には、プラットフォームでサポートされているすべての文字(感嘆符(!)およびチルダ(~)を除く)を使用できます。サーバー名の先頭をピリオド(.)またはoraにすることはできません。この属性は必須です。 |
ACTIVE_POOLS |
サーバーが属しているサーバー・プールの名前の空白区切りのリストです。Oracle Clusterwareはこのリストを自動的に管理します。 |
STATE |
サーバーは、次のいずれかの状態になります。 ONLINE サーバーは、クラスタのメンバーであり、リソースの配置に使用できます。 OFFLINE サーバーは、現在クラスタのメンバーではありません。したがって、リソースの配置に使用できません。 JOINING サーバーがクラスタに追加されると、Oracle Clusterwareは、サーバーを処理し、リソースの配置に有効であることを確認します。また、Oracle Clusterwareは、サーバーで実行されるように構成されているリソースの状態をチェックします。サーバーの妥当性およびリソースの状態が確認されると、サーバーはこの状態から遷移します。 LEAVING サーバーの計画停止が開始すると、サーバーの状態は VISIBLE Oracle Clusterwareは実行されており、クラスタ・レディ・サービス・デーモン( RECONFIGURING サーバー・プールの再構成のためにサーバーがサーバー・プール間で移動する場合、現行のサーバー・プールのそのサーバー上で実行されるリソースを停止または再配置する必要があると、サーバーはこの状態になります。これは、サーバーで実行されるリソースは、サーバーの移動先サーバー・プールで実行されるように構成されない可能性があるためです。リソースが正常に再配置されるとすぐに、サーバーは
|
STATE_DETAILS |
これは、Oracle Clusterwareで管理される読取り専用の属性です。属性ではサーバーの状態に関する追加の詳細が提供されます。サーバーの状態に関する追加の詳細には、次のものが含まれる場合があります。 サーバーの状態:
サーバーの状態:
サーバーの状態:
|
この項の内容は次のとおりです。
サーバー・プールは、クラスタを同じまたは類似したリソースのホスティングするサーバーのグループに分割します。サーバー・プールによって、クラスタの複数のサーバーに対し、統一されたワークロード(一連のOracle Clusterwareリソース)が分散されます。たとえば、Oracle Databaseを特定のサーバー・プールでのみ実行するように制限できます。役割区分管理を有効にすると、特定のサーバー・プールの属性を変更する権限をオペレーティング・システム・ユーザーに明示的に付与できます。
クラスタを論理的に分割します。
常に排他的です。これは、1つのサーバーが特定の時期に1つの特定のサーバー・プールにのみ存在できることを意味します。
各サーバー・プールには、作成時に割り当てられる3つの属性があります。
MIN_SIZE: サーバー・プールに含まれるサーバーの最小数。サーバー・プールのサーバーの数がこの属性の値を下回る場合、サーバーの数が属性の値になるまで、Oracle Clusterwareによって自動的に他の場所からサーバー・プールにサーバーが移動されます。
MAX_SIZE: サーバー・プールに含まれるサーバーの最大数。
IMPORTANCE: クラスタ内の他のすべてのサーバー・プール間でサーバー・プールをランク付けする0から1000(0の重要度が最低)の数値。
表2-2に、すべてのサーバー・プール属性を示します。
表2-2 サーバー・プール属性
| 属性 | 値および書式 | 説明 |
|---|---|---|
ACL |
次の書式の文字列を使用します。 owner:user:rwx,pgrp:group:rwx,other::r— |
サーバー・プールの所有者、および様々なオペレーティング・システムのユーザーとグループに付与する権限を定義します。サーバー・プールの所有者には、所有者になるオペレーティング・システム・ユーザーとそのユーザーに付与する権限を定義します。 このオプション属性の値は、明示的に上書きする場合を除き、サーバー・プールを作成するプロセスのIDに基づいてサーバー・プールの作成時に移入されます。その後、サーバー・プールの既存の権限に基づいて変更を行うことができる場合、この値は変更できます。 文字列は次のように指定します。
デフォルトでは、サーバー・プールを作成するクライアントのIDは user:username:rwx group:group_name:rwx |
ACTIVE_SERVERS |
サーバー名の文字列には次の書式を使用します。 server_name1 server_name2 ... |
Oracle Clusterwareは、この属性を自動的に管理します。この属性には、現在サーバー・プールに割り当てられているサーバーの空白区切りのリストが含まれています。 |
EXCLUSIVE_POOLS |
文字列 |
このオプション属性は、このサーバー・プールに割り当てられたサーバーが他のサーバー・プールと共有されるかどうかを示します。サーバー・プールは、この属性に同じ値を持つその他のサーバー・プールに対して排他的であることを明示的に示すことができます。サーバー・プールに割り当てられたサーバーのセットに共通の単一サーバーがない場合、2つ以上のサーバー・プールは相互に排他的です。たとえば、サーバー・プールAおよびBの両方でこの属性の値が 最上位のサーバー・プールは、デフォルトでは、相互に排他的です。 |
IMPORTANCE |
0から1000の任意の整数 |
サーバー・プールの相対的な重要度で、 |
MAX_SIZE |
任意の負でない整数または |
サーバー・プールに含めることができるサーバーの最大数です。この属性はオプションで、デフォルトでは、 注意: この属性の |
MIN_SIZE |
任意の負でない整数 |
サーバー・プールの最小サイズです。サーバー・プールに含まれるサーバーの数がこの属性で指定する数を下回る場合、Oracle Clusterwareは、この数が満たされるまで他のサーバー・プールからこのサーバー・プールにサーバーを自動的に移動します。 注意: このオプション属性の値によって、ハード制限は設定されません。クラスタが再構成されるたびにサーバー割当ての優先順位が制御されます。デフォルト値は、 |
NAME |
文字列 |
サーバー・プールの名前で、これはサーバー・プールの作成時に指定する必要があります。サーバー・プール名は、ユーザーが作成したエンティティ(リソース、タイプ、サーバーなど)の名前のドメイン内で一意である必要があります。サーバー・プール名には、プラットフォームでサポートされているすべての文字(感嘆符(!)およびチルダ(~)を除く)を使用できます。サーバー・プール名の先頭をピリオドまたはoraにすることはできません。 |
PARENT_POOLS |
空白区切りのサーバー・プール名の文字列には次の書式を使用します。 sp1 sp2 ... |
この属性を使用して、ネストされたサーバー・プールを作成することができます。この属性に示されているサーバー・プールは、親サーバー・プールと呼ばれます。親サーバー・プールに含まれているサーバー・プールは、子サーバー・プールと呼ばれます。 |
SERVER_NAMES |
空白区切りのサーバー名の文字列には次の書式を使用します。 server1 server2 ... |
サーバー・プールに関連付けられている可能性がある候補ノード名のリスト。このオプション属性が空の場合、Oracle Clusterwareは、その他の属性の値( 候補ノード名として識別されるサーバー名は、現在アクティブなクラスタ・メンバーであることを確認する検証が行われません。クラスタ管理者はこの属性を使用して、クラスタにまだ追加されていない候補としてサーバーを定義できます。 |
Oracle RACデータベースを管理しているサーバー・プールは、サーバー制御(SRVCTL)ユーティリティを使用して管理します。他のすべてのサーバー・プールを管理するには、Oracle Clusterware制御(CRSCTL)ユーティリティを使用します。最上位のサーバー・プールを作成する権限を所有しているのは、クラスタ管理者のみです。
Oracle Clusterwareがインストールされると、汎用サーバー・プールおよび空きサーバー・プールという2つのサーバー・プールが自動的に作成されます。新規インストールのすべてのサーバーは、最初、空きサーバー・プールに割り当てられます。サーバーは、空きサーバー・プールから新しく定義したサーバー・プールに自動的に移動します。Oracle Clusterwareを以前のリリースからアップグレードすると、Oracle Database 11gリリース2(11.2)以前のデータベース・リリースとの互換性を確保するために、すべてのノードは汎用サーバー・プールに割り当てられます。
空きサーバー・プールには、他のサーバー・プールに割り当てられていないサーバーが含まれています。空きサーバー・プールの属性は、次のように制限されます。
SERVER_NAMES、MIN_SIZEおよびMAX_SIZEは、ユーザーが編集することはできません。
IMPORTANCEおよびACLは、ユーザーが編集することができます。
汎用サーバー・プールには、11gリリース2(11.2)よりも前のOracle Database、および構成を固定した管理者管理型データベースが格納されます。また、次のいずれかを満たすサーバーも含まれます。
applicationリソース・タイプのすべてのリソースのHOSTING_MEMBERSリソース属性に指定されているサーバー
汎用サーバー・プールを親サーバー・プールとして示すサーバー・プールのSERVER_NAMES属性に指定された名前のサーバー
汎用サーバー・プールの属性は、次のように制限されています。
汎用サーバー・プールの構成属性は変更できません(すべての属性が読取り専用です)。
サーバーが次の状態の場合にのみ、Oracle Clusterwareは、HOSTING_MEMBERSリソース属性にサーバー名を指定することができます。
オンラインで汎用サーバー・プールに存在する。
オンラインで空きサーバー・プールに存在する。この場合、Oracle Clusterwareによってサーバーが汎用サーバー・プールに移動されます。
オンラインで、他のサーバー・プールに存在し、クライアントがクラスタ管理者であるか、またはサーバー・プールのサーバーを使用することが許可されている(この場合、サーバーは汎用サーバー・プールに移動されます)。
オフラインで、クライアントがクラスタ管理者。
子サーバー・プールを汎用サーバー・プールに登録した場合、リソースに対して以前に指定したものと同じ要件をサーバー名が満たす場合にのみ、Oracle Clusterwareはその子サーバー・プールを許可します。
サーバーは、クラスタの起動時またはサーバーがクラスタに追加されるときに汎用サーバー・プールに割り当てられ、その後で、他のサーバー・プールに割り当てられます。
Oracle Clusterwareは、次の順序でサーバー・プールに新しいサーバーを割り当てます。
汎用サーバー・プール
ユーザー作成のサーバー・プール
空きサーバー・プール
次の条件が満たされるまで、Oracle Clusterwareはサーバー・プールへのサーバーの割当てを続行します。
重要度順にすべてのサーバー・プールが最小値まで一杯になるまで(MIN_SIZE)。
重要度順にすべてのサーバー・プールが最大値まで一杯になるまで(MAX_SIZE)。
デフォルトでは、サーバー・プールに配置されていないサーバーは、空きサーバー・プールに割り当てられます。
空きサーバー・プールのIMPORTANCE属性は変更できます。
サーバーをクラスタに追加する場合、いくつかの問題が発生します。
表2-3で構成されているサーバー・プールについて考えてみます。
表2-3 サーバー・プール属性の構成例
| 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に割り当てることはできません。
処理後、クラスタ構成は次のように表示されます。
サーバー・プール内のサーバーの数がサーバー・プールのMIN_SIZE属性の値を下回る場合(サーバーで障害が発生した場合など)、Oracle Clusterwareは、すべてのサーバー・プールのMIN_SIZEおよびIMPORTANCE属性に設定した値に基づいて、他のサーバー・プールのサーバーをサーバーの数がMIN_SIZE値を下回るサーバー・プールに移動できます。Oracle Clusterwareは、他のサーバー・プールからサーバーを選択して、次の基準に該当する不十分なサーバー・プールに移動します。
不十分なサーバー・プールよりIMPORTANCEの値が低いサーバー・プールに対して、Oracle Clusterwareは、サーバーの数がMIN_SIZE属性の値を下回る場合でもそのサーバー・プールからサーバーを取得します。
IMPORTANCEの値が同一以上のサーバー・プールに対して、Oracle Clusterwareは、サーバー・プール内のサーバーの数がMIN_SIZE属性の値より大きい場合にのみそのサーバー・プールからサーバーを取得します。
この項の項目は次のとおりです。
ロール別管理とは、複数のリソースで同じクラスタ・リソースおよびハードウェア・リソースを共有できる実装可能な機能です。これは、サーバー・プールまたはリソースの権限を設定してから、アクセス制御リスト(ACL)を使用してアクセスを提供することでできます。デフォルトでは、この機能はインストール時に有効化されません。リソースの割当ては、CRS管理者ロールを割り当てられたユーザーによって制御されます。次のいずれかの方法で、ロール別管理を実装できます。
垂直実装: サーバー・プールまたはリソースへのアクセス権限は、それらの所有権をエンタープライズ・アーキテクチャの各層で様々なユーザーに割り当てることによって、およびそれらのユーザーに割り当てられたACLを使用することによって付与されます。Oracle ASMでは、グループを使用した、よりきめ細かい方法が提供されます。タスクの重複を有効にするには、綿密な計画が必要です。
|
関連項目: グループの使用の詳細は、『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』を参照してください。 |
水平実装: リソースに対するアクセス権限は、割り当てられたACLを使用して、サーバー・プールおよびポリシー管理型データベースまたはアプリケーションに付与されます。
|
注意: この権限を持つオペレーティング・システム・ユーザーを制限するには、特定のユーザーをCRS管理者リストに追加することをお薦めします。 |
CRS管理者は、サーバー・プールの作成を制御するOracle Clusterwareの事前定義済管理者ロールです。CRS管理者ロールを付与されたユーザーは、サーバー・プールのみのシステム・リソースへのアクセスを付与または取消しできます。CRS管理者ロールは、サーバーの管理権限に影響を与えません。
また、CRS管理者は、アスタリスク(*)をSERVER_POOLS属性の値として使用して配置を制御するrestrictedの配置でリソースを作成し、Oracle Clusterwareによって管理されるこれらのリソースへのアクセスを付与および取消しすることができます。
オペレーティング・システム・グループのメンバーである一連のユーザーではなく、CRS管理者ロールを持つ一連のユーザーは、Oracle Clusterware内の名前付きCRS管理者のリストによって管理されます。サーバー・プールの作成により、CRS管理者は、組織の異なるユーザーのグループによって使用されるサーバーのグループにクラスタを分けることができ(前述の項で説明した水平実装)、これによってロール別管理が可能になります。
デフォルトでは、クラスタ用のOracle Grid Infrastructureのインストール後またはアップグレード後に、すべてのユーザーはクラスタ管理者となり(CRS管理者のリストにアスタリスク(*)で示されます)、同じインフラストラクチャを共有するすべてのユーザーは、クラスタを管理する権限が平等にあると想定されます。このデフォルトの構成では、すべての名前付きオペレーティング・システム・ユーザーがOracle Clusterware内でサーバー・プールを作成することができます。
CRS管理者権限をグリッド・ユーザーおよびrootに制限すると、後で作成されるポリシー管理データベースが新しく作成されたサーバー・プールに自動的に作成されることを防止します。ロール別管理を有効にする場合、CRS管理者は事前に必要なサーバー・プールを作成しておく必要があります。
グリッド・インフラストラクチャ・ホーム(Gridホーム)にOracle Clusterwareをインストールしたユーザー(グリッド・ユーザー)およびシステム・スーパーユーザー(LinuxおよびUNIXではroot、Windowsでは管理者)は、永続的なクラスタ管理者となり、これらの2種類のユーザーのみがCRS管理者のリストにユーザーを追加または削除でき、ロール別管理を有効にします。
クラスタが様々なユーザーによって共有されている場合、CRS管理者は特定のサーバー・プールへのアクセスを制限できるため、クラスタ内の特定のユーザーに対する特定のハードウェア・リソースへのアクセスも制限できます。ACL属性の各サーバー・プールに格納されている権限の詳細は、表2-2を参照してください。
次のコマンドを使用して、クラスタ内のCRS管理者を管理します。
CRS管理者であるユーザーのリストを問い合せるには、次のコマンドを使用します。
$ crsctl query crs administrator
ロール別管理を有効にして、非永続的なCRS管理者に権限を付与するには、特定のユーザーをCRS管理者のリストに追加する必要があります。永続的なCRS管理者として、次のコマンドを実行します。
# crsctl add crs administrator -u user_name
デフォルトのアスタリスク(*)値は、このコマンドを使用して追加するユーザーで置換されます。
CRS管理者のグループから特定のユーザーを削除するには、次のコマンドを使用します。
# crsctl delete crs administrator -u user_name
すべてのユーザーをCRS管理者にするには、次のようにリストの後にアスタリスク(*)値を追加します。
# crsctl add crs administrator -u "*"
アスタリスク(*)値は二重引用符("")で囲む必要があります。この値は、CRS管理者のリストで以前に指定されたユーザーを置換します。
crsctl setpermコマンドを使用して、サーバー・プール、リソースまたはその両方に割り当てられるACLを使用した水平ロール区分を構成します。CRSCTLユーティリティは、パスGrid_home/binにあります(Grid_homeは、Oracle Grid Infrastructureのホームです)。
コマンドでは次の構文を使用して、リソース、リソース・タイプまたはサーバー・プールのいずれに権限を設定するかを選択できます。
crsctl setperm {resource | type | serverpool} {-u acl_string |
-x acl_string | -o user_name | -g group_name}
フラグ・オプションは、次のとおりです。
-u: エンティティACLの更新
-x: エンティティACLの削除
-o: エンティティ所有者の変更
-g: エンティティ・プライマリ・グループの変更
ACL文字列は、次のとおりです。
{ user:user_name[:readPermwritePermexecPerm] |
group:group_name[:readPermwritePermexecPerm] |
other[::readPermwritePermexecPerm] }
説明:
user: ユーザーACL(指定したユーザーに付与されるアクセス権限)を指定します。
group: グループACL(指定したグループ・メンバーに付与される権限)を指定します。
other: 他のACL(特定のアクセス権限は付与されないユーザーまたはグループに付与されるアクセス権)を指定します。
readperm: 読取り権限の場所(rは権限を付与、-は権限を禁止)
writeperm: 書込み権限の場所(wは権限を付与、-は権限を禁止)
execperm: 実行権限の場所(xは権限を付与、-は権限を禁止)
たとえば、CRS管理者(所有者)のみが読取り、書込みおよび実行権限を持ち、ユーザーおよびoinstallグループのメンバーが読取りおよび実行権限のみを持つ場合、CRS管理者として、oracleユーザーおよびoinstallグループのtestadminというデータベース・サーバー・プールの権限を設定できます。グループ外のすべてのユーザーにはアクセス権がありません。次のコマンドをCRS管理者として実行すると、次のようになります。
# crsctl setperm serverpool ora.testadmin -u user:oracle:r-x,group:oinstall:r-x, other::---
|
注意: 前述の例は、水平ロール区分の有効化を目的としてOracle (ora.*)リソース(ora.testadminサーバー・プール)でCRSCTLコマンドを使用する明示的な付与の例外です。 |
Oracle Grid Infrastructureのソフトウェアのみのインストールを実行した後、構成ウィザードを使用してソフトウェアを構成できます。このウィザードでは、crsconfig_params構成ファイルを簡単に編集できます。構成ウィザードでは、Oracle Grid Infrastructureのインストーラと同様に、ユーザーがウィザードで操作を行う前後にGridホームと入力の様々な検証が実行されます。
構成ウィザードを使用すると、1つ以上のノードで新しいグリッド・インフラストラクチャを構成したり、アップグレード済のグリッド・インフラストラクチャを構成できます。また、構成ウィザードはサイレント・モードでも実行できます。
|
注意:
|
この項には次のトピックが含まれます:
構成ウィザードを使用して単一ノードを構成するには、次の手順を実行します。
次のように、構成ウィザードを起動します。
$ Oracle_home/crs/config/config.sh
「インストール・オプションの選択」ページで、「クラスタ用のGrid Infrastructureの構成」を選択します。
「クラスタ・ノードの情報」ページで、ローカル・ノードと、それに対応するVIP名のみを選択します。
残りのウィザード・ページで、引き続き情報を追加します。
「サマリー」ページで入力を確認して、「終了」をクリックします。
構成ウィザードの指示に従って、root.shスクリプトを実行します。
構成ウィザードを使用して複数ノードを構成するには、次の手順を実行します。
次のように、構成ウィザードを起動します。
$ Oracle_home/crs/config/config.sh
「インストール・オプションの選択」ページで、「クラスタ用のGrid Infrastructureの構成」を選択します。
「クラスタ・ノードの情報」ページで、構成するノードと、それに対応するVIP名を選択します。構成ウィザードは、選択されたノードを検証し、その準備が整っていることを確認します。
残りのウィザード・ページで、引き続き情報を追加します。
「サマリー」ページで入力を確認して、「終了」をクリックします。
構成ウィザードの指示に従って、root.shスクリプトを実行します。
構成ウィザードを使用してグリッド・インフラストラクチャをアップグレードするには、次の手順を実行します。
次のように、構成ウィザードを起動します。
$ Oracle_home/crs/config/config.sh
「インストール・オプションの選択」ページで、「Grid Infrastructureのアップグレード」を選択します。
「Grid Infrastructureノードの選択」ページで、アップグレードするノードを選択します。
残りのウィザード・ページで、引き続き情報を追加します。
「サマリー」ページで入力を確認して、「終了」をクリックします。
構成ウィザードの指示に従って、rootupgrade.shスクリプトを実行します。
構成ウィザードをサイレント・モードで使用してノードを構成またはアップグレードするには、コマンドラインで-silent -responseFile file_nameを指定して構成ウィザードを起動します。ウィザードは、レスポンス・ファイルを検証して構成を行います。レスポンス・ファイルで無効な入力を検出すると、構成ウィザードはエラーを表示して終了します。指示に従って、rootおよびconfigToolAllCommandsスクリプトを実行します。
この項の内容は次のとおりです。
障害分離は、障害が発生したノードをクラスタの残りのノードから分離させ、障害が発生したノードでデータが失われるのを防ぐプロセスです。理想的なフェンシングには、Oracle Clusterwareまたはそのノードで実行されているオペレーティング・システムとの連携がなくても問題のノードを再起動できる外部メカニズムが含まれます。この機能を提供するために、Oracle Clusterware 11gリリース2(11.2)では、業界標準の管理プロトコルであるIntelligent Management Platform Interface仕様(IPMI)(Baseboard Management Controller(BMC)とも呼ばれる)をサポートしています。
通常、IPMIを使用する障害分離は、グリッド・インフラストラクチャのインストール時の「障害の分離のサポート」画面でIPMI構成のオプションが提示されたときに構成します。インストール時にIPMIを構成しない場合は、Oracle Clusterware制御ユーティリティ(CRSCTL)を使用してインストール後に構成できます(「CRSCTLを使用したIPMIベース障害分離のインストール後の構成」を参照)。
障害分離用にIPMIを使用するには、各クラスタ・メンバー・ノードに、IPMIバージョン1.5(Local Area Network (LAN)を介してIPMIがサポートされます)に対応するファームウェアが動作するIPMIデバイスを装備する必要があります。データベースの操作中、障害分離は、削除を行うクラスタ同期サービス・デーモンから障害が発生したノードのIPMIデバイスへのLANを介した通信によって行われます。IPMI-over-LANプロトコルは、インストール時に管理者から取得したユーザー名およびパスワードで保護される認証セッションに引き継がれます。
DHCPを使用してIPMIの動的IPアドレス割当てをサポートするために、クラスタ同期サービス・デーモンは、クラスタ同期サービスの起動時にローカルのIPMIデバイスと直接通信を行いIPMIデバイスのIPアドレスを取得する必要があります。(ただし、これはHP-UXおよびSolarisプラットフォームにはあてはまりません。これらのプラットフォームでは、IPMIデバイスに静的IPアドレスを割り当てる必要があります。)これは、各クラスタ・システムにインストールする必要があるIPMIドライバを介してIPMIデバイスと通信するIPMIプローブ・コマンド(OSD)を使用して行われます。
IPMIデバイスに静的IPアドレスを割り当てた場合、IPMIドライバは、クラスタ同期サービス・デーモンにとって必須ではありません。ただし、ipmitoolまたはipmiutilを使用してIPMIデバイスを構成するにはドライバが必要ですが、一部のプラットフォームでは管理コンソールを使用してこれを行うこともできます。
IPMIドライバをインストールして有効にし、IPMIデバイスを構成します(ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照)。
この項の内容は次のとおりです。
Oracle Clusterwareのインストール時にIPMIをインストールする場合は、障害分離を2つのフェーズで構成します。インストールを開始する前に、サーバー・オペレーティング・システムにIPMIドライバをインストールして有効にし、各ノードでIPMIハードウェア(IPアドレス・モード、管理資格証明など)を構成する必要があります(『Oracle Grid Infrastructureインストレーション・ガイド』を参照)。Oracle Clusterwareをインストールすると、インストーラによって、IPMI管理者のユーザーIDおよびパスワードが収集され、ノードのローカル記憶域の(OLRにある)Oracle Walletに格納されます。
サーバーの構成が完了したら、各クラスタ・ノードで次の手順を実行し、ノードにIPMI管理者およびパスワードを登録します。
|
注意: IPMIがDHCPを使用してIPアドレスを取得するように構成されている場合は、IPMIをリセットするか、またはノードを再起動して、アドレスを取得するようにする必要がある可能性があります。 |
Oracle Clusterwareを起動します(起動すると、IPMIから現在のIPアドレスを取得できます)。これにより、起動時に必要となるクラスタウェアとIPMIの通信が可能であることが確認されます。
IPMIが構成される前にOracle Clusterwareが実行されていた場合は、Oracle Clusterwareを停止して再起動できます。または、IPMI管理ユーティリティを使用してIPMIのIPアドレスを取得してから、CRSCTLを使用して次のようなコマンドを実行することで、OLRにIPアドレスを格納します。
crsctl set css ipmiaddr 192.168.10.45
CRSCTLを使用して、crsctl set css ipmiadminコマンドを実行し、プロンプトにパスワードを指定することで、装備されているIPMI用に以前に作成したユーザーIDおよびパスワードをOLRに格納します。次に例を示します。
crsctl set css ipmiadmin administrator_name IPMI BMC password: password
このコマンドでは、指定した資格証明が検証され、これを使用して別のクラスタ・ノードがローカルIPMIにアクセスできない場合は失敗します。
ハードウェアおよびオペレーティング・システムの構成を完了し、Oracle ClusterwareにIPMI管理者を登録した後、IPMIベースの障害分離は完全に機能します。
既存のIPMIベースの障害分離構成を変更するには(IPMIパスワードを変更したり、既存のインストールで障害分離用にIPMIを構成する場合など)、ご使用のプラットフォームに適したIPMI構成ツールでCRSCTLを使用します。たとえば、IPMIの管理者パスワードを変更するには、まず『Oracle Grid Infrastructureインストレーション・ガイド』で説明しているようにIMPI構成を変更してから、CRSCTLを使用してOLR内のパスワードを変更します。
Oracle Clusterwareで必要なIPMIの構成データはOCRのOracle Walletに保存されています。構成情報はセキュアなストアに保持されるため、この情報はOracle Clusterwareインストールの所有者アカウント(グリッド・ユーザー)が書き込む必要があり、このインストールのユーザーとしてログインする必要があります。
既存のIPMI構成を変更するには、次の手順を実行します。
crsctl set css ipmiadmin administrator_nameコマンドを入力します。たとえば、ユーザーIPMIadmの場合は、次のようになります。
crsctl set css ipmiadmin IPMIadm
管理者パスワードを指定します。Oracle Clusterwareでは、ローカルIPMIの管理者の名前およびパスワードがOLRに格納されます。
新しい資格証明が格納されると、Oracle Clusterwareは新しい資格証明を取得し、必要に応じて配布することができます。
crsctl set css ipmiaddr bmc_ip_addressコマンドを入力します。次に例を示します。
crsctl set css ipmiaddr 192.0.2.244
このコマンドでは、ローカルIPMIの新しいIPMI IPアドレスがOLRに格納され、IPアドレスの格納後、Oracle Clusterwareは、新しい構成を取得し、必要に応じて配布することができます。
crsctl get css ipmiaddrコマンドを入力します。次に例を示します。
crsctl get css ipmiaddr
このコマンドでは、ローカルIPMIのIPアドレスがOLRから取得され、コンソールに表示されます。
次のように、OLRからローカルIPMIのIPMI構成情報を削除して、レジストリ・エントリを削除します。
crsctl unset css ipmiconfig
IPMIの使用を完全に停止する場合、またはIPMIの最初の構成がOracle Clusterwareをインストールしたユーザー以外のユーザーによって行われていた場合は、CRSCTLを使用してクラスタからIPMI構成を削除できます。後者に該当する場合、Oracle ClusterwareはIPMI構成データにアクセスできず、Oracle ClusterwareソフトウェアはIPMIを使用できないため、Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成する必要があります。
IPMIを完全に削除するには、次の手順を実行します。Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成するには、手順3および4を実行し、「CRSCTLを使用したIPMI構成の変更」の手順2および3を繰り返します。
次のように、IPMIドライバを無効にして、起動時のインストールを回避します。
/sbin/modprobe –r
|
関連項目: IPMIドライバの詳細は、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
LAN経由でのアクセスを防ぐためにipmitoolまたはipmiutilを使用してローカルIPMIのIPMI-over-LANを無効にするか、またはIPMI管理者のユーザーIDとパスワードを変更します。
Oracle Clusterwareが実行中であることを確認し、次のコマンドでCRSCTLを使用し、OLRからIPMI構成データを削除します。
crsctl unset css ipmiconfig
rootとして次のコマンドを実行し、Oracle Clusterwareを再起動して、IPMI構成なしで実行するようにします。
# crsctl stop crs # crsctl start crs
クラスタ時刻同期化サービス(CTSS)は、Oracle Clusterwareの一部としてインストールされ、システムで時刻同期サービスまたは時刻同期サービス構成が有効になっているか、または中断されていることが検出されるとオブザーバ・モードで実行されます。クラスタ内のどのノードにも時刻同期サービスまたは時刻同期サービス構成がCTSSによって検出されない場合、CTSSはアクティブ・モードになり、クラスタの時間管理を行います。
ノードがクラスタに追加されると、CTSSではアクティブ・モードの場合、これらのノードの時刻がクラスタ内の1つのノードにある参照クロックと比較されます。2つの時刻の間に不一致があり、その不一致が特定の段階制限内である場合、CTSSによって時刻の同期化(Step)が行われ、クラスタに追加されたノードの時刻は参照クロックと同期するように進められます。
Oracle Clusterwareを起動したときに、CTSSがアクティブ・モードで実行されており、時刻の不一致が段階制限(制限は24時間)を超えている場合、CTSSはアラート・ログにアラートを生成して終了し、Oracle Clusterwareの起動は失敗します。クラスタに追加したノードの時刻をクラスタと同期するように手動で調整する必要があり、その後、Oracle Clusterwareを起動してCTSSでノードの時刻を管理することができます。
クラスタ内のノードのクロックは、様々な理由のために定期的に参照クロック(時刻CTSSが基準として使用し、クラスタ内で最初に起動するノードのクロック)と非同期になります。この場合、CTSSは時刻の同期化(Slew)を実行し、参照システムの時刻と同期するまで、ノードのシステムの時刻を速めたり、遅くします。この時刻の同期方法では、CTSSによって時刻が戻されることがないため、システムの時刻における単調増加が保証されます。
時刻の同期化(Slew)を実行する場合、CTSSでは参照クロックと同期するために時刻が戻されることはありません。CTSSによって定期的にアラート・ログにアラートが書き込まれ、これには、ノードが参照クロックと同期し続けるようにCTSSによって時刻が調整される頻度に関する情報が含まれます。
クラスタのCTSSをアクティブ化するには、クラスタ内のすべてのノードでベンダーの時刻同期サービスを停止し、構成を解除する必要があります。CTSSは、この操作を検出し、クラスタの時間管理を引き受けます。
たとえば、NTPの構成を解除するには、ntp.confファイルを削除するか、名前を変更する必要があります。
|
注意: Windowsの場合、CTSSはntp.confファイルが存在するかどうかチェックせず、時刻同期サービスがあるかどうかのみをチェックします。 |
同様に、クラスタのCTSSを非アクティブ化する場合は、次の操作を実行します。
クラスタ内のすべてのノードでベンダーの時刻同期サービスを構成します。CTSSは、この変更を検出し、オブザーバ・モードに戻ります。
crsctl check ctssコマンドを使用して、CTSSがオブザーバ・モードで動作していることを確認します。
クラスタ内のすべてのノードでベンダーの時刻同期サービスを起動します。
cluvfy comp clocksync -n allコマンドを使用して、時刻同期サービスが動作していることを検証します。
|
関連項目: Oracle ClusterwareのNTP構成またはCTSSを使用するための無効化の詳細は、ご使用のプラットフォーム固有の『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
この項の内容は次のとおりです。
Oracle Clusterware構成には次の2つ以上のインタフェースが必要です。
ユーザーとアプリケーション・サーバーがデータベース・サーバー上のデータにアクセスするために接続するパブリック・ネットワーク・インタフェース
ノード間の通信用のプライベート・ネットワーク・インタフェース。
グリッド・ネーミング・サービスおよびDHCPを使用してネットワーク接続を管理する場合は、クラスタのアドレス情報を構成する必要がない場合があります。GNSを使用すると、パブリック仮想インターネット・プロトコル(VIP)・アドレスを、DHCPが提供する動的なアドレスにすることができます。クライアントでは、名前解決リクエストがネットワークのドメイン名サービス(DNS)に送信され、DNSでは、クラスタ内で管理されているグリッド・ネーミング・サービス(GNS)にリクエストが転送されます。GNSでは、これらのリクエストがクラスタ内のノードに解決されます。
GNSを使用せず、かわりにネットワークを手動で構成する場合は、パブリックVIPアドレスはDNSで静的に構成する必要があります。VIPはDNSおよびhostsファイルで静的に構成される必要があり、プライベートIPアドレスでは静的構成が必須です。
パブリック・ネットワーク・アドレスはクライアントにサービスを提供するために使用します。クライアントで単一クライアント・アクセス名(SCAN)アドレスに接続している場合は、クラスタに対してノードを追加または削除する際にパブリックおよび仮想IPアドレスを変更する必要がある場合がありますが、クライアントを新しいクラスタ・アドレスで更新する必要はありません。
SCANはクラスタの別名のように機能します。ただし、SCANはクラスタ内の任意のノードで解決され、ノードのVIPアドレスとは異なり、SCANに接続するクライアントでは、クラスタに対してノードを追加または削除する際に、更新されたVIPアドレスは必要なくなります。SCANアドレスはクラスタ内のノード・アドレスではなくクラスタに解決されるため、SCANアドレス構成に影響を与えることなく、クラスタでノードを追加または削除できます。
SCANは完全修飾名(ホスト名+ドメイン)で、SCANに割り当てられたすべてのアドレスに解決するように構成されています。アドレスは、DNSサーバー上またはGNS構成のクラスタ内で、ラウンドロビンDNSによって解決します。SCANリスナーはクラスタ内の任意のノードで実行できます。SCANは、クライアント構成が特定のデータベースを実行するノードに依存する必要がないように、データベースに位置の独立性を提供します。
Oracle Database 11gリリース2(11.2)以上のインスタンスは、SCANリスナーにのみリモート・リスナーとして登録されます。アップグレードしたデータベースは、リモート・リスナーとしてSCANリスナーに登録されるとともに、引き続きすべてのノード・リスナーにも登録されています。
|
注意: インストール時にSCAN名を指定するというOracle Clusterwareのインストール要件により、サーバーの/etc/hostsファイルを使用して1つ以上のIPアドレスを解決してこのインストール要件を回避し、SCANに必要なインフラストラクチャがない場合は、インストール後、SCANを無視し、VIPを使用してクラスタ内のデータベースに接続できます。
Oracleでは、SCANアドレスの削除はサポートされていません。 |
Oracle Database 11gリリース2(11.2)より前のOracle DatabaseリリースのパブリックVIPアドレスを使用するように構成されたクライアントは、既存の接続アドレスを引き続き使用できます。SCANを使用するようにクライアントを構成することをお薦めしますが、ユーザーがSCANを使用する必要はありません。以前のバージョンのOracle Databaseは、アップグレードされるとSCANに登録され、クライアントでは、SCANを使用してこのデータベースへの接続を開始するか、接続用のVIPアドレスの使用を継続することができます。
クライアント接続用のVIPアドレスの使用を継続する場合、Oracle DatabaseおよびOracle ASMの実行が継続している間にVIPアドレスを変更できます。ただし、アドレスを変更する間は、サービスを停止する必要があります。VIPアドレスを再起動すると、サービスもノードで再起動します。
この手順を使用して、静的パブリック・サブネットでDHCPを使用するように変更することはできません。srvctl add network -Sコマンドのみで、DHCPネットワークが作成されます。
|
注意: 次の説明は、VIPアドレスのみを変更する方法を示すもので、VIPアドレスに関連付けられたホスト名は変更しないことを想定しています。GNSを使用していて、VIPがDHCPを使用して割り当てられている場合は、VIPアドレスを手動で更新する必要はありません。VIPアドレスのみを変更する場合、DNSおよびクライアントのhostsファイルを更新します。また、サーバーのhostsファイルがVIPアドレスに対して使用されている場合は、それも更新します。 |
VIPアドレスを変更するには、次の手順を実行します。
次のコマンド構文を使用して、変更するVIPアドレスのノードで実行されているすべてのサービスを停止します。database_nameはデータベースの名前、service_name_listは停止するサービスのリスト、およびmy_nodeは変更するVIPアドレスのノードの名前です。
srvctl stop service -d database_name -s service_name_list -n my_node
この例では、データベース名(grid)を-dオプションで指定し、適切なノード(mynode)上のサービス(sales,oltp)を指定しています。
$ srvctl stop service -d grid -s sales,oltp -n mynode
srvctl config vipコマンドを実行して、VIPアドレスの現在のIPアドレスを確認します。このコマンドにより、ネットワーク・インタフェースの1つにバインドされた現在のVIPアドレスが表示されます。構成したVIPアドレスの例を次に示します。
$ srvctl config vip -n stbdp03 VIP exists.:stbdp03 VIP exists.: /stbdp03-vip/192.168.2.20/255.255.255.0/eth0
srvctl stop vipコマンドを使用してVIPリソースを停止します。
$ srvctl stop vip -n mynode
LinuxまたはUNIXシステムでifconfig -aコマンドを実行(Windowsシステムの場合はipconfig /allコマンドを発行)して、VIPリソースが実行されていないことを確認し、インタフェース(この例ではeth0:1)が出力に表示されていないことを確認します。
LinuxおよびUNIXシステムではすべてのノードの/etc/hostsファイルに、Windowsシステムでは%windir%\system32\drivers\etc\hostsファイルに、必要なすべての変更を加え、DNSを適切に変更して、新しいIPアドレスを古いホスト名に関連付けます。
VIPリソースを変更する前に、デフォルトのネットワークに異なるサブネットまたはNICを使用するには、srvctl modify network -S subnet/netmask/interfaceコマンドをrootとして使用して、ネットワーク・リソースを変更する必要があります(subnetは新しいサブネット・アドレス、netmaskは新しいネットマスク、interfaceは新しいインタフェースです)。サブネットの変更後、次の手順で説明するとおり、各ノードのVIPを新しいサブネットのIPアドレスに変更する必要があります。
次のsrvctl modify nodeapps構文を使用して、ノード・アプリケーションを変更し、新しいVIPアドレスを指定します。
$ srvctl modify nodeapps -n node_name -A new_vip_address
コマンドには次のフラグおよび値が含まれます。
-n node_nameはノード名です。
-A new_vip_addressはノード・レベルのVIPアドレスで、次のようになります。name|ip/netmask/[if1[|if2|...]]
たとえば、rootユーザーとして次のコマンドを発行します。
srvctl modify nodeapps -n mynode -A 192.168.2.125/255.255.255.0/eth0
インストール所有者アカウントとしてこのコマンドを発行しようとすると、エラーが発生する場合があります。たとえば、インストール所有者がoracleの場合は、エラー「PRCN-2018: Current user oracle is not a privileged user」が表示される場合があります。このエラーを回避するには、rootまたはシステム管理者アカウントとしてコマンドを実行します。
次のようにして、srvctl start vipコマンドを実行し、ノードVIPを起動します。
$ srvctl start vip -n node_name
次のコマンドの例では、mynodeという名前のノードでVIPを起動します。
$ srvctl start vip -n mynode
クラスタ内の各ノードでこの手順を繰り返します。
SRVCTLユーティリティはクラスタ全体の管理ツールであるため、各クラスタ・ノードにログインせずに、クラスタ内の任意のノードから特定のノードに対し、これらのタスクを完了することができます。
次のコマンドを実行して、クラスタが構成されているすべてのノード間の接続性を確認します。このコマンドは、クラスタ・ノード上で使用可能なすべてのネットワーク・インタフェースを検出し、検出されたインタフェースからすべてのノードへの接続性を確認します。また、ノードで使用可能な、VIPアドレスとしての使用に適したすべてのインタフェースを表示します。
$ cluvfy comp nodecon -n all -verbose
この項の内容は次のとおりです。
Oracle Clusterwareでは、各ノードが、(パブリック・ネットワークに加えて)プライベート・ネットワークに接続されている必要があります。プライベート・ネットワーク接続は、クラスタ・インターコネクトとも呼ばれます。表2-5に、ネットワーク・インタフェース・カード(NIC)およびプライベートIPアドレスがどのように格納されるかを示します。
すべてのノードが、同一のサブネットに接続された同一のネットワーク・インタフェース(oifcfgコマンドによりグローバル・インタフェースとして定義済)を使用しているクラスタのみをサポートしています。ノードごとに異なるネットワーク・インタフェース(ノード固有のインタフェース)を使用することはできません。グローバル・インタフェースおよびノード固有のインタフェースの詳細は、付録D「Oracle Interface Configurationツール(OIFCFG)のコマンド・リファレンス」を参照してください。
表2-5 ネットワーク・インタフェース、プライベートIPアドレスおよびプライベート・ホスト名の記憶域
| エンティティ | 格納先 | コメント |
|---|---|---|
|
ネットワーク・インタフェース名 |
オペレーティング・システム。 たとえば、 |
ネットワーク・インタフェース名を指定する場合、ワイルドカードを使用できます。 たとえば、 |
|
プライベート・ネットワーク・インタフェース |
Oracle Clusterwareのグリッド・プラグ・アンド・プレイ(GPnP)・プロファイル内 |
インストール時にインタフェースを「プライベート」とすることによって、使用するインタフェースをプライベート・インタフェースとして構成するか、 関連項目: oifcfg setifコマンドの詳細は、 |
インストール時、またはインストール後にoifcfg setifコマンドを使用してインタフェースをプライベートとして分類することによって、冗長なインターコネクトの使用に対して複数のインタフェースを定義できます。このようにすると、定義したインタフェースの数に応じて1つから4つの高可用性IP(HAIP)アドレスがOracle Clusterwareによって作成され、Oracle DatabaseおよびOracle ASMインスタンスは、これらのアドレスを使用して高可用性のロード・バランスされた通信を実現します。
デフォルトでは、Oracleソフトウェア(11gリリース2(11.2.0.2)以上のOracle RAC、Oracle ASMおよびOracle ACFSなど)は、そのすべてのトラフィックにHAIPアドレスを使用し、提供されたクラスタ・インターコネクト・インタフェースのセット全体でロード・バランシングが可能になります。定義済のクラスタ・インターコネクト・インタフェースのいずれかに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースのいずれかに対応するHAIPアドレスを透過的に移動します。
|
注意: Oracle Clusterwareが使用するインタフェースは、定義されているインタフェースの数に関係なく、常に最大で4つです。あるインタフェースに障害が発生すると、HAIPアドレスは、定義されたセット内の別の構成済インタフェースに移動します。HAIPアドレスが1つのみで、選択するインタフェースが複数ある場合、HAIPアドレスの移動先のインタフェースは、そのアドレスが構成された元のインタフェースではなくなります。Oracle Clusterwareは、HAIPアドレスの追加先として、数が最も小さいサブネットのインタフェースを選択します。 |
|
関連項目: インタフェースの定義については、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
インタフェース名の変更結果は、どの名前を変更するか、またIPアドレスも変更するかどうかによって異なります。インタフェース名のみを変更する場合、結果は、それほど重要ではありません。OCR内に格納されたパブリック・インタフェースの名前を変更する場合、クラスタのノード・アプリケーションも変更する必要があります。したがって、この変更を有効にするために、ノード・アプリケーションを停止する必要があります。
|
関連項目: 新しいパブリック・インタフェース名を使用するためのノード・アプリケーションの変更の詳細は、My Oracle Support(以前のOracleMetaLink)のNote 276434.1を参照してください。次のURLから入手できます。
|
次の手順を実行して、ネットワーク・インタフェースおよびそれに関連するサブネット・アドレスを変更できます。クラスタのすべてのノードでこの変更を実行する必要があります。
この手順では、Oracle ClusterwareおよびOracle Databaseが以前使用していたクラスタ内の各ノードで、ネットワーク・インタフェースおよびIPアドレスを変更します。
|
注意: Oracle RAC(RDBMS)インターコネクトで使用されるインタフェースは、Oracle Clusterwareでホスト名に使用されるインタフェースと同じである必要があります。Oracle Clusterwareで監視されない別のインタフェースで、Oracle RACのプライベート・インターコネクトを構成しないでください。 |
次のコマンドを実行し、Oracle Clusterwareがすべてのクラスタ・ノードで実行されていることを確認します。
$ olsnodes -s
このコマンドでは、次のような出力が戻され、Oracle Clusterwareがクラスタ内のすべてのノードで実行されていることが表示されます。
./olsnodes -s myclustera Active myclusterc Active myclusterb Active
代替インタフェースが構成され、すべてのノードのオペレーティング・システムで操作可能であることを確認します。ご使用のプラットフォームのifconfigコマンド(Windowsではipconfig)を使用します。たとえば、Linuxでは次のように使用します。
$ /sbin/ifconfig..
次のコマンドを使用して、新しいインタフェースの名前およびサブネット・アドレスを指定して、新しいインタフェースをクラスタに追加します。
$ oifcfg setif -global if_name/subnet:cluster_interconnect
インタフェース名にはワイルドカードを使用できます。たとえば、oifcfg setif -global "eth*/192.168.0.0:cluster_interconnectは有効な構文です。ただし、他のクラスタ・インタフェースで使用している他のアドレスやマスクとまぎらわしくならないように注意してください。ワイルドカードを使用すると、コマンドでは次のような警告が戻されます。
eth*/192.168.0.0 global cluster_interconnect PRIF-29: Warning: wildcard in network parameters can cause mismatch among GPnP profile, OCR, and system
|
注意: 従来型ネットワーク構成ではワイルドカードがサポートされないため、ワイルドカードは更新の時点で現行のノード構成を使用して解決されます。 |
前の手順が完了したら、次のように、以前のインタフェースの名前およびサブネット・アドレスを指定して、以前のサブネットを削除できます。
oifcfg delif -global if_name/subnet
次に例を示します。
$ oifcfg delif -global eth1/10.10.0.0
|
注意: この手順は、代替インタフェースがグリッド・プラグ・アンド・プレイ構成に取り込まれた後でのみ実行する必要があります。有効な代替インタフェースを準備せずにクラスタのインタフェースを単純に削除すると、無効なクラスタ構成になる可能性があります。 |
次のコマンドを使用して現行の構成を検証します。
oifcfg getif
次に例を示します。
$ oifcfg getif eth2 10.220.52.0 global cluster_interconnect eth0 10.220.16.0 global public
rootとして、各ノードで次のコマンドを実行し、すべてのノードのOracle Clusterwareを停止します。
# crsctl stop crs
|
注意: クラスタのネットワーク構成が変更される場合、クラスタを完全に停止する必要があります。ローリング停止および再起動を使用しないでください。 |
Oracle Clusterwareが停止したら、ifconfigコマンドを使用して、削除したネットワーク・インタフェースをオペレーティング・システムで構成解除します。次に例を示します。
$ ifconfig down
この時点で、ネットワーク・インタフェースからの以前のサブネットのIPアドレスは、Oracle Clusterwareから構成解除されます。このコマンドは、オペレーティング・システムのIPアドレスの構成に影響しません。
ifconfigによる変更は、永続的ではないため、オペレーティング・システムの構成変更を更新する必要があります。
|
関連項目: ifconfigコマンドの効果を永続的にする方法の詳細は、オペレーティング・システムのマニュアルを参照してください。 |
クラスタの各ノードでrootユーザーとして次のコマンドを実行し、Oracle Clusterwareを再起動します。
# crsctl start crs
変更は、Oracle Clusterwareの再起動時に有効になります。
CLUSTER_INTERCONNECTS初期化パラメータを使用している場合は、変更を反映するためにそれを更新する必要があります。
