2 Oracle Clusterwareの構成と管理
Oracle Clusterwareとその様々なコンポーネントの構成と管理には、アプリケーションとデータベースの管理およびクラスタ内のネットワーク構成が含まれます。
クラスタを構成および管理するには2つの方法があり、いずれかを選択できます。従来型の管理者管理アプローチを使用して、クラスタ・リソースとワークロードを手動で管理するか、ポリシー管理アプローチを使用して、様々な程度の自動化管理を起動できます。
管理者管理クラスタの場合、クラスタ・リソースをどのようにデプロイするか、およびワークロードをどこで管理するかを手動で構成する必要があります。通常、これは、どのクラスタ・ノードでどのデータベース・インスタンスを優先して実行するか、および障害発生時にどこでそれらのインスタンスを再起動するかを構成する必要があるということです。データベース・インスタンスの配置場所を構成することにより、クラスタ全体のワークロードを構成します。
ポリシー管理クラスタでは、ワークロードをサーバー・プール内で実行するように構成します。これには、各サーバー・プール内でのこれらのワークロードの管理方法を指示するポリシー・セットを構成します。サーバー・プールとポリシー・セットの管理は自分で行い、データベース・インスタンスの場所およびワークロード配置の詳細は、設定したポリシーに委任します。このアプローチを使用する際は、Oracle Quality of Service Management (Oracle QoS Management)を使用することにより、クラスタの管理をさらに自動化する追加オプションを選択できます。
2.1 ロール別管理
ロール別管理は、リソースの競合と不足のリスクを軽減する目的でクラスタ・リソースおよびワークロードを協調的に管理するためのアプローチです。
ロール別管理では、オペレーティング・システムのセキュリティとロール定義、およびユーザーのロールに従ってリソースとワークロード管理を分離するためのOracle Clusterwareアクセス権限を使用します。統合環境においては、コンピューティング・リソースの競合が存在する可能性があり、リソース・コンシューマおよびそれらのリソースの管理にはある程度の分離が必要となるため、このような統合環境で作業するユーザーにとっては特にこれが重要になります。デフォルトでは、この機能はインストール時に実装されません。
ロール別管理を構成する場合、意図されたロールに従って(データベースなどの)クラスタ・リソースを管理するオペレーティング・システムのユーザーおよびグループを設定し、必要に応じてアクセス制御リスト(ACL)を介してクラスタ・リソースおよびサーバー・プールに対する権限を追加します。また、Oracle Automatic Storage Management (Oracle ASM)では、これらのロール別構造をストレージ管理機能にまで拡張できます。
ロール別管理の原則は、管理者管理システムとポリシー管理システムの両方に等しく適用されます。管理者管理の場合は、クラスタ・リソースおよびロールをノード・レベルで管理するように構成しますが、ポリシー管理システムの場合は、クラスタ・リソースおよびロールをサーバー・プール内で管理するように構成します。
Oracle Clusterwareのロール別管理は、現在はクラスタ管理者に依存していません(下位互換性は維持されています)。デフォルトでは、Oracle Grid Infrastructureホーム(Gridホーム)にOracle Clusterwareをインストールしたユーザーおよびroot
は、永続的なクラスタ管理者となります。プライマリ・グループ権限(デフォルトではoinstall
,)により、データベース管理者はDatabase Configuration Assistant (DBCA)を使用して新しく作成したサーバー・プールにデータベースを作成できますが、ロール区分は有効になりません。
注意:
クラスタに最初にサーバー・プールを作成する前にロール区分を有効にすることをお薦めします。構成ポリシーおよび各ポリシー・セットを使用してサーバー・プールを作成および管理します。ACL
属性に格納されている各サーバー・プールのアクセス権限の詳細は、表3-1を参照してください。
関連トピック
2.1.1 クラスタ管理者の管理
アクセス制御リスト(ACL)を使用して、クラスタの管理者を定義できます。
クラスタにサーバー・プールを作成する機能は、クラスタ管理者に制限されています。以前のリリースでは、デフォルトでは、登録されているすべてのオペレーティング・システム・ユーザーがクラスタ管理者とみなされましたが、このデフォルトは必要に応じてcrsctl add | delete crs administrator
コマンドを使用して変更できました。ただし、このリリースではこれらのコマンドの使用は非推奨であり、かわりに、ポリシー・セットのACLを使用してサーバー・プールの作成機能を制御する必要があります。
原則として、サーバー・プールまたはクラスタ・リソースの作成権限を設定するには、オペレーティング・システム・ユーザー、またはそのユーザーがメンバーになっているオペレーティング・システム・グループの読取り、書込みおよび実行権限がACL
属性内で設定されている必要があります。
2.1.2 ロール区分の構成
ロール区分は、必要なロール、ロールが管理するリソースおよびサーバー・プール、およびロールのアクセス権限の決定です。これらを決定した後、ACLおよびCRSCTLユーティリティを使用して、グループ権限(oinstall
やgrid
など)用のオペレーティング・システム・ユーザー・アカウントを作成または変更できます。
最も基本的には、2つのオペレーティング・システム・ユーザーをoinstall
グループの一部として作成した後、クラスタを作成し、2つのサーバー・プールを作成します。サーバー・プールごとに、そのサーバー・プールを管理するオペレーティング・システム・ユーザーの1つを割り当て、それ以外のユーザーには、そのサーバー・プールへの読取りアクセス権のみを付与します。
このことは、慎重に計画し、一貫性を維持しながら細部を重視して実行することが必要ですが、実装後、誤りの修正や時間の経過に伴う調整のために構成を変更できます。
注意:
ロール別手法をora.*リソース(Oracle RACデータベース・リソース)に適用することはできません。これらの手法は、サーバー・プールとユーザー定義のクラスタ・リソースおよびタイプにのみ適用できます。サーバー・プールまたはリソースは、root
またはgrid
アカウントの下に作成します。指定されたオペレーティング・システム・ユーザーがこれらのサーバー・プールまたはリソースを管理するためには、それらのユーザーに各自のロールを実行するための正しい権限を付与する必要があります。
crsctl setperm
コマンドを使用して、サーバー・プール、リソースまたはその両方に割り当てられるACLを使用した水平ロール区分を構成します。CRSCTLユーティリティは、パスGrid_home
/bin
にあります(Grid_home
は、クラスタ・ホームのOracle Grid Infrastructureです)。
コマンドには次の構文を使用し、アクセス制御(ACL)文字列はイタリックで示します。
crsctl setperm {resource | type | serverpool} name {-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
は権限を付与、-
は権限を禁止)
たとえば、グループpersonnel
に対して、psft
というサーバー・プール上の権限を設定し、管理ユーザーが読取り/書込み/実行権限を持ち、personnel
グループのメンバーが読取り/書込み権限を持ち、グループ以外のユーザーにはアクセス権が付与されないようにするには、次のコマンドをroot
ユーザーとして入力します。
# crsctl setperm serverpool psft -u user:personadmin:rwx,group:personnel:rw-,
other::---
クラスタ・リソースの場合、グループcrsadmin
に対して(Maynard
により管理される) MyProgram
という名前のアプリケーション(リソース)に対する権限を設定するとき、管理ユーザーに読取り、書込みおよび実行権限を付与し、crsadmin
グループのメンバーに読取り権限と実行権限を付与し、グループ外のユーザーに(ステータスおよび構成チェックのために)読取りアクセス権のみを付与するには、最初にリソースを作成したユーザー(root
またはgrid
所有者)として、次のコマンドを入力します。
# crsctl setperm resource MyProgram -u user:Maynard:r-x,group:crsadmin:rw-,other:---:r--
2.2 グリッド設定ウィザードを使用したOracle Grid Infrastructureの構成
構成ウィザードでは、1つ以上のノードに新しいOracle Grid Infrastructureを構成するか、またはアップグレードされたOracle Grid Infrastructureを構成することができます。また、グリッド設定ウィザードはサイレント・モードでも実行できます。
Oracle Grid Infrastructureのソフトウェアのみのインストールを実行した後、グリッド設定ウィザードを使用してソフトウェアを構成できます。このウィザードでは、ウィザードの実行前と実行後にグリッド・ホームおよび入力の様々な検証が実行されます。
注意:
-
グリッド設定ウィザードを実行する前に、Oracle Grid Infrastructureホームがカレントであり、必要なすべてのパッチが適用されていることを確認してください。
-
グリッド設定ウィザードを一連の手順で起動するには、次の手順を実行します。
LinuxおよびUNIXの場合は、次のコマンドを実行します。
Oracle_home/gridSetup.sh
Windowsの場合は、次のコマンドを実行します。
Oracle_home\gridSetup.bat
2.2.2 複数ノードの構成
構成ウィザードを使用して、クラスタ内に複数ノードを構成できます。
構成ウィザードを使用して構成するノードへのOracle Grid Infrastructureソフトウェアのインストールは、必須ではありません。
注意:
構成ウィザードを起動する前に、次の点を確認します。
すべてのノードにソフトウェアをインストールする必要はありませんが、インストールする場合は、ソフトウェアを同じGrid_home
パスにインストールし、すべてのノードで同一レベルに配置する必要があります。
構成ウィザードを使用して複数ノードを構成するには、次の手順を実行します。
2.2.3 Oracle Grid Infrastructureのアップグレード
グリッド設定ウィザードを使用して、クラスタのOracle Grid Infrastructureをアップグレードします。
クラスタ用のOracle Grid Infrastructureをアップグレードするには、次の手順を実行します。
関連項目:
Oracle Restartの手順の詳細は、ご使用のプラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。
2.2.4 サイレント・モードでの構成ウィザードの実行
—silentパラメータを指定して、構成ウィザードをサイレント・モードで実行できます。
構成ウィザードをサイレント・モードで使用してノードを構成またはアップグレードするには、次の手順を実行します。
-
次のようにして、コマンドラインから構成ウィザードを起動します。
$ $ORACLE_HOME/gridSetup.sh -silent -responseFile file_name
構成ウィザードはレスポンス・ファイルを検証してから、構成に進みます。レスポンス・ファイルで無効な入力を検出すると、構成ウィザードはエラーを表示して終了します。
-
指示に従って、
root
スクリプトおよびGrid_home/gridSetup -executeConfigTools
スクリプトを実行します。
2.3 サーバーの重みベースのノード削除
Oracle Clusterwareの障害リカバリ・メカニズムを、プライベート・ネットワーク(クラスタ・インターコネクト)障害のイベントで終了または削除するノードを選択するように構成できます。
クラスタでネットワーク分離が発生し、クラスタが非結合コホートにパーティション化されるスプリット・ブレイン状況においては、Oracle Clusterwareは特定のルールを適用して存続コホートを選択し、場合によってはクリティカルなシングルトン・リソースを実行しているノードを削除することがあります。
これらの決定の結果を反映させるには、値をデータベース・インスタンスまたはノードに追加します。これにより、Oracle Clusterwareは、削除か終了かを決定する必要があるとき、これらの要因を考慮し、すべてのクリティカル・コンポーネントを使用可能な状態に保持しようとします。重み関数を構成して、クラスタ内のクリティカル・コンポーネントに重みを追加できます。これにより、スプリット・ブレイン状況を解決するときにどのノードを削除するかを決定する際に、Oracle Clusterwareに付加的な入力が提供されます。
同じレベルのノードから選択するプロセスにおいては、特定のハードウェア特性を考慮して特性のノードを存続させたり、特定のデータベースまたはサービスを考慮して特定のリソースを存続させることもできます。次の基準に基づいて、特定のノード、リソースまたはサービスに重みを割り当てることができます。
-
重みは管理者管理ノードにのみ割り当てることができます。
-
重みは、登録済のOracle Clusterwareリソースであるサーバーまたはアプリケーションに割り当てることができます。
重みは、コンポーネントの重要度の一因となり、分離ブレイン状況の管理中にOracle Clusterwareが行う選択に影響します。様々なコホート間で他のクリティカルな因子が同等であれば、Oracle Clusterwareは最も重いコホートを存続させるように選択します。
様々なコンポーネントに重みを割り当てるには、次のようにします。
-
データベース・インスタンスまたはサービスに重みを割り当てるには、データベース・インスタンスまたはサービスを追加するときに、
srvctl add database
またはsrvctl add service
コマンドで-css_critical yes
パラメータを使用します。また、srvctl modify database
およびsrvctl modify service
コマンドでこのパラメータを使用することもできます。 -
ora.*でないリソースに重みを割り当てるには、リソースを追加または変更するときに、
crsctl add resource
およびcrsctl modify resource
コマンドで-attr "CSS_CRITICAL=yes"
パラメータを使用します。 -
サーバーに重みを割り当てるには、
crsctl set server
コマンドで-css_critical yes
パラメータを使用します。
注意:
-
値を有効にするには、ノードでOracle Clusterwareスタックを再起動する必要があります。リソースは再起動しなくても変更が有効になるため、これはリソースには適用されません。
-
管理者管理環境をポリシー管理環境または両者混合の環境に変更した場合、割り当てた重みはすべて保存されますが、考慮はされません。つまり、クラスタを元の管理者管理に再構成しないかぎりは、適用も考慮もされません。
2.4 Oracle Database Quality of Service Managementの概要
Oracle Database Quality of Service Management (Oracle Database QoS Management)は、システム全体のワークロード・リクエストを監視する自動化されたポリシーベース製品です。
Oracle Database QoS Managementは、アプリケーション間で共有されるリソースを管理し、システム構成を調整して、アプリケーションの実行をビジネスに必要なパフォーマンス・レベルに維持します。Oracle Database QoS Managementは、システム構成および要求で発生した変更に対応し、アプリケーションのパフォーマンス・レベルがそれ以上変動することを回避します。
Oracle Database QoS Managementは、Oracle RACデータベース・ワークロード・パフォーマンスの目標を監視および管理するもので、これらの目標に影響を与えているボトルネックのリソースを特定し、パフォーマンスを回復するためのアクションを推奨し、実行します。管理者管理のデプロイメントではデータベース・インスタンスがノードにバインドされますが、ポリシー管理のデプロイメントではバインドされないため、Oracle Database QoS Managementサーバー・プール・サイズ・リソース制御はポリシー管理のデプロイメントでのみ使用可能です。これ以外のすべてのリソース管理制御は、どちらのデプロイメントでも使用可能です。
Oracle Database QoS Managementでは、管理者管理のOracle RACおよびOracle RAC One Nodeデータベースを、測定のみモード、監視モードおよび管理モードでサポートしています。このため、管理者管理のOracle RACデータベース内でパフォーマンス・クラスのCPU共有を調整することにより、データベース内でのスキーマ統合サポートが可能になります。また、同じ物理サーバー上でホストされるデータベースのCPU数を調整することにより、データベース統合もサポートされます。
ポリシー管理データベース・デプロイメントではサーバー・プール・サイズの変更によるインスタンス数の拡張または縮小機能がサポートされていますが、管理者管理のデータベースはサーバー・プール内で実行されないため、管理者管理のデータベースではこの機能を使用できません。この新しいデプロイメント・サポートは、Oracle Enterprise Manager Cloud ControlのOracle QoS Managementページに統合されています。
2.5 グリッド・ネーミング・サービスの概要
Oracle Clusterwareでは、シングルクラスタおよびマルチクラスタの環境のアドレス解決にグリッド・ネーミング・サービス(GNS)が使用されます。単一のプライマリGNSインスタンスを使用してクラスタを構成し、さらに異なるロールを持つ1つ以上のセカンダリGNSインスタンスを構成して、高可用性アドレス参照などのサービスをクライアントに提供することもできます。
2.5.1 GNSおよびGNS仮想IPアドレスのネットワーク管理タスク
GNSを実装するには、ネットワーク管理者がDNSを構成してクラスタのドメインを設定し、そのドメイン解決をGNS VIPに委譲する必要があります。別のドメインを使用するか、クラスタに既存のドメインのサブドメインを作成できます。
GNSは、そのクラスタ・ノードのホスト名の一部であるクラスタ名と個別のノード識別子を使用してノードを区別するため、クラスタAのクラスタ・ノード123とクラスタBのクラスタ・ノード123を区別することができます。
ただし、手動でホスト名を構成する場合、GNSに委譲するサブドメインにサブドメインがあってはなりません。たとえば、サブドメインmydomain.example.com
をGNSに委譲して解決する場合、other.mydomain.example.com
ドメインがあってはなりません。GNSが排他的に使用するGNSにサブドメインを委譲することをお薦めします。
注意:
Oracle Flex ASMまたはOracle Flex Clusterなどで静的なアドレス変換を行う構成では、DNSに委譲せずにGNSを使用できます。ただし、DHCPを使用して住所を割り当てる場合、GNSには委譲先となるドメインが必要です。
例2-1は、myclustergns.example.com
というドメインをGNS VIPアドレス10.9.8.7
に委譲するために必要なDNSエントリを示しています。
GNSデーモンおよびGNS VIPは、サーバー・クラスタの1つのノードに対して実行されます。GNSデーモンは、ポート53を使用しているGNS VIPでDNSリクエストをリスニングします。Oracle Clusterwareによって、GNSデーモンおよびGNS VIPはいつでも使用できるように管理されます。GNSデーモンを実行しているサーバーに障害が発生した場合、Oracle ClusterwareはGNSサーバーおよびGNS VIPを、正常に動作するクラスタ・メンバー・ノードにフェイルオーバーします。クラスタがOracle Flex Cluster構成である場合、Oracle Clusterwareは、GNSデーモンおよびGNS VIPをハブ・ノードにフェイルオーバーします。
注意:
Oracle Clusterwareは、GNSアドレスを他のクラスタにフェイルオーバーしません。フェイルオーバーは、同じクラスタのメンバーのみに実行されます。
例2-1 DNSエントリ
# Delegate to gns on mycluster mycluster.example.com NS myclustergns.example.com #Let the world know to go to the GNS vip myclustergns.example.com. 10.9.8.7
2.5.2 グリッド・ネーミング・サービス構成オプションの理解
GNSは、自動または標準のクラスタ・アドレス構成モードのいずれかで実行できます。自動構成は、IPv4アドレスのDynamic Host Configuration Protocol (DHCP)またはIPv6アドレスのStateless Address Autoconfiguration Protocol (autoconfig) (RFC 2462およびRFC 4862)のいずれかを使用します。
この項には次のトピックが含まれます:
2.5.2.1 高可用性グリッド・ネーミング・サービス
高可用性GNSは、1つのプライマリGNSインスタンスおよび0以上のセカンダリGNSインスタンスで構成されています。
プライマリGNSインスタンスでクライアントからのすべての更新を処理し、プライマリGNSインスタンスとセカンダリGNSインスタンスの両方で参照問合せを処理します。また、セカンダリGNSインスタンスはプライマリGNSインスタンスのバックアップとしても機能します。既存のプライマリGNSインスタンスが失敗するか、クラスタ管理者によって削除されたときでも、セカンダリGNSインスタンスをプライマリ・ロールに昇格できます。
さらに、高可用性GNSでは、ゾーン転送を使用してセカンダリGNSインスタンスでデータ・バックアップを取ることによりフォルト・トレランスを実現します。セカンダリGNSインスタンスは、インストール中にプライマリGNSインスタンスからデータのコピーを取得します。これ以降、プライマリGNSインスタンス上の更新は、セカンダリGNSインスタンスにレプリケートされます。
プライマリGNSインスタンスはゾーン・データを管理し、委任されたドメインですべてのレコードを保持します。ゾーン・データおよびその変更履歴はOracle Cluster Registry (OCR)に格納されます。セカンダリGNSインスタンス上でゾーン・データが更新されると、次の2つのいずれかの方法でゾーン転送が行われます。
-
完全ゾーン転送: プライマリGNSインスタンスは、すべてのゾーン・データをセカンダリGNSインスタンスにレプリケートします。
-
増分ゾーン転送: プライマリGNSインスタンスは、変更されたデータのみをセカンダリGNSインスタンスにレプリケートします。GNSでは、次のシナリオにおいてこの転送メカニズムを使用します。
-
プライマリGNSインスタンスにゾーン・データの更新がある場合、このインスタンスはデータ転送を開始するようにセカンダリ・インスタンスに通知します。セカンダリGNSインスタンスは、プライマリGNSインスタンスのOCR内のデータのシリアル番号がセカンダリGNSインスタンスのデータのシリアル番号よりも大きいときにのみ、データ転送を要求します。
-
セカンダリGNSインスタンスのリフレッシュ時間が満了すると、インスタンスは、そのデータ・シリアル番号を含む問合せをプライマリGNSインスタンスに送信します。セカンダリGNSインスタンスのシリアル番号がプライマリGNSインスタンスのシリアル番号よりも小さい場合、GNSによってゾーン転送が開始されます。
注意:
セカンダリGNSインスタンスに返答してもプライマリ・インスタンスの動作に支障がないように、リフレッシュ時間は、プライマリGNSインスタンスのロードを減らすために十分な長さにする必要があります。デフォルトのリフレッシュ時間は1時間ですが、この値はクラスタ管理者がクラスタ・サイズに基づいて変更できます。
-
まずプライマリGNSインスタンスを構成してから、セカンダリGNSインスタンスを構成する必要があります。プライマリGNSインスタンスを正常に構成した後、クライアント用のクライアント・データおよびセカンダリGNSインスタンスをエクスポートします。セカンダリGNSインスタンスを構成するときに、エクスポートしたクライアント・データを提供します。すべてのセカンダリGNSインスタンスはプライマリGNSインスタンスに自身を登録し、ゾーン・データのコピーを取得します。セカンダリGNSインスタンスは、セカンダリGNSインスタンスのリフレッシュ時間が満了したときまたは通知に応答するとき、ゾーン転送メカニズムを使用して、プライマリGNSインスタンスにデータ更新について問い合せます。
2.5.2.2 アドレスの自動構成オプション
自動構成の場合、DNS管理者はGNSサブドメインを使用して解決するDNS上のドメインを委譲します。Oracle Universal Installerは、インストールまたは構成中にOracle Grid Infrastructureを使用できるよう、指定された各クラスタ・メンバー・ノード・インタフェースに名前を割り当てます。SCANおよびその他すべてのクラスタ名とアドレスは、DNS上ではなくクラスタ内で解決されます。
-
IPv4アドレスの場合、Oracle Clusterwareは、Oracle Grid Infrastructureに割り当てられた各クラスタ・メンバー・ノード・インタフェースに一意の識別子を割り当て、GNSに委譲されたサブドメイン内のこれらの識別子を使用して名前を生成します。DHCPサーバーはこれらのインタフェースにアドレスを割り当て、GNSは、IPv4 DHCP プールから借用したIPv4アドレスに関連する名前とアドレスを維持します。
-
IPv6アドレスの場合、Oracle Clusterwareは、autoconfigを使用して自動的にアドレスを生成します。
2.5.2.3 アドレスの静的な自動構成オプション
静的な構成では、委譲されるサブドメインはありません。DNS管理者はGNS VIPを構成して、DNS上で構成された名前とアドレスに解決し、また、DNS管理者はSCAN名を構成して、クラスタのこれらの静的なアドレスに解決します。
また、DNS管理者は、各クラスタ・メンバー・ノードに静的なパブリックIP名とアドレスおよび仮想IP名とアドレスを構成します。DNS管理者は、クラスタに追加された各ノードに新しいパブリックおよび仮想IP名とアドレスを構成する必要もあります。すべての名前とアドレスはDNSによって解決されます。
静的なVIPアドレスおよびSCANを使用したサブドメインの委譲がないGNSでは、クラスタ内に名前解決情報が必要なOracle Flex ClusterおよびCloudFS機能を使用できます。ただし、ノードを追加したり変更する場合は、手動で管理タスクを実行する必要があります。
2.5.2.4 アドレスの共有GNSオプション
動的な構成の場合、GNSを構成して、あるクラスタに名前解決をしたり、複数のクラスタに名前を通知できるため、単一のGNSインスタンスで、登録された複数のクラスタに対して名前解決を実行できます。このオプションは共有GNSと呼ばれます。
共有GNSは標準的なGNSと同じサービスを提供し、名前解決を受け取るクライアント側でも同様に表示されます。相違点は、1つのクラスタで動作するGNSデーモンは、GNSに名前解決を委譲したドメイン内のすべてのクラスタに対して名前解決を提供するように構成される点、およびGNSをSRVCTLコマンドを使用して一元的に管理できる点です。共有GNS構成を使用すると、Oracle Grid Infrastructureクラスタのエンタープライズ全体に対するネットワーク管理者タスクを最小限に抑えることができます。
マルチクラスタ環境でのアドレス解決に共有GNSを使用するクラスタでは、静的なアドレス構成は使用できません。共有GNSには自動アドレス構成が必要であり、DHCPまたはIPv6ステートレス・アドレス自動構成のいずれかによって割り当てられるアドレスを使用します。
注意:
GNSが提供するクラスタのセット内のすべてのノード名は一意である必要があります。
Oracle Universal Installerを使用すると、共有GNSクライアントまたはサーバーのGNSを使用して、あるいは検出に使用するGNSを使用して、静的アドレスを構成できます。
2.6 グリッド・ネーミング・サービスの管理
SRVCTLを使用して、シングルクラスタおよびマルチクラスタの両方の環境でグリッド・ネーミング・サービス(GNS)を管理します。
注意:
GNSサーバーおよびクライアントは、同じオペレーティング・システムおよびプロセッサ・アーキテクチャを使用しているコンピュータで実行する必要があります。コンピュータ上のオペレーティング・システムが異なる、プロセッサ・アーキテクチャが異なる、またはその両方が異なる場合、GNSは実行できません。
この項には次のトピックが含まれます:
2.6.1 高可用性GNSの構成
高可用性GNSの構成では、プライマリGNSインスタンスとセカンダリGNSインスタンスを構成します。GNSはOracle Clusterwareのインストール時にOracle Universal Installerを使用して構成できますが、セカンダリGNSインスタンスはOracle Clusterwareのインストール後にしか構成できないため、高可用性GNSはOracle Clusterwareのインストール後にしか構成できません。
2.6.2 プライマリGNSインスタンスおよびセカンダリGNSインスタンスの削除
プライマリGNSインスタンスおよびセカンダリGNSインスタンスをクラスタから削除できます。
クラスタ管理者として、次のようにして、セカンダリGNSインスタンスを選択し、それをプライマリGNSインスタンスに昇格します。
# srvctl modify gns -role primary
2.6.4 GNSサーバーまたはGNSクライアント・クラスタへのクラスタの変換
GNSを実行していないクラスタをGNSサーバーまたはクライアント・クラスタに変換したり、サーバーおよびクライアント・クラスタのGNSクラスタ・タイプの構成を変更できます。
2.6.4.1 非GNSクラスタのGNSサーバー・クラスタへの変換
srvctlコマンドを使用して、GNSを実行していないクラスタをGNSサーバー・クラスタに変換できます。
-
root
として次のコマンドを実行して、GNSをクラスタに追加し、有効なIPアドレスおよびドメインを指定します。# srvctl add gns -vip IP_address -domain domain
-
GNSインスタンスを起動します。
# srvctl start gns -node node_name
注意:
-
GNS VIPを追加するときに、ドメインを指定する必要はありません。
-
現在別のGNSインスタンスで使用されているIPアドレスを指定することはできません。
-
構成済クラスタがGNSサーバー・クラスタとなるためには、DNS委任が必要です。
2.6.4.2 非GNSクラスタのクライアント・クラスタへの変換
GNSを実行していないクラスタをクライアント・クラスタに変換するには、サーバー・クラスタから資格証明ファイルをインポートする必要があります。
次のようにして、GNSを実行していないクラスタをGNSクライアント・クラスタに変換します。
2.6.4.3 GNSを実行しているシングル・クラスタのサーバー・クラスタへの変換
2.6.5 別のクラスタへのGNSの移動
クラスタ障害または管理計画のいずれかが理由で、別のクラスタをGNSサーバー・クラスタにする必要が出た場合、srvctlコマンドを使用してGNSを別のクラスタに移動できます。
注意:
この手順には、サーバー・クラスタおよびクライアント・クラスタのダウンタイムが必要です。また、GNSクライアント・データを新しいサーバー・クラスタから任意のOracle Flex ASMと高速ホーム・プロビジョニング・サーバーおよびクライアントにインポートする必要があります。
GNSを別のクラスタに移動するには、次の手順を実行します。
2.6.6 IPv4からIPv6ネットワークへの移行時のGNSサブドメインの変更
IPv4ネットワークからIPv6ネットワークに移行するとき、GNSサブドメインを変更する必要があります。
2.7 ノード障害分離
障害分離は、障害が発生したノードをクラスタの残りのノードから分離させ、障害が発生したノードでデータが失われるのを防ぐプロセスです。
障害が発生したノードの分離には、Oracle Clusterwareやそのノードで実行されているオペレーティング・システムとの連携なく問題のノードを再起動できる外部メカニズムが関与します。この機能を提供するために、Oracle Clusterware 12cでは、業界標準の管理プロトコルであるIntelligent Platform Management Interface仕様(IPMI)(Baseboard Management Controller(BMC)とも呼ばれる)をサポートしています。
通常、IPMIを使用する障害分離は、Oracle Grid Infrastructureのインストール時の「障害の分離のサポート」画面でIPMI構成のオプションが提示されたときに構成します。インストール中にIPMIを構成しない場合は、インストール後にOracle Clusterware Controlユーティリティ(CRSCTL)を使用して構成できます(後続の項を参照)。
障害分離用にIPMIを使用するには、各クラスタ・メンバー・ノードに、IPMIバージョン1.5(Local Area Network (LAN)を介してIPMIがサポートされます)に対応するファームウェアが動作するIPMIデバイスを装備する必要があります。IPMIバージョン1.5ではLANを介した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デバイスを構成するにはドライバが必要ですが、一部のプラットフォームでは管理コンソールを使用してこれを行うこともできます。
2.7.1 IPMI用のサーバー・ハードウェア構成
最初に、IPMIドライバをインストールして有効にし、IPMIデバイスを構成する必要があります。(ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイド』を参照)。
2.7.2 CRSCTLを使用したIPMIベース障害分離のインストール後の構成
Oracle Clusterwareをインストールした後、crsctlコマンドを使用してIPMIベースの障害分離を構成します。このコマンドを使用して、IPMI構成を変更または削除することもできます。
これは、次のトピックで説明します。
2.7.2.1 Oracle ClusterwareでのIPMIインストール後の構成
IPMIドライバをインストールおよび有効化し、IPMIデバイスを構成し、サーバー構成を完了した後、CRSCTLコマンドを使用してIPMI構成を完了できます。
インストールを開始する前に、サーバー・オペレーティング・システムにIPMIドライバをインストールして有効にし、各ノードでIPMIハードウェア(IPアドレス・モード、管理資格証明など)を構成しました(『Oracle Grid Infrastructureインストレーション・ガイド』を参照)。Oracle Clusterwareをインストールすると、インストーラによって、IPMI管理者のユーザーIDおよびパスワードが収集され、ノードのローカル記憶域の(OLRにある)Oracle Walletに格納されます。
サーバーの構成が完了したら、各クラスタ・ノードで次の手順を実行し、ノードにIPMI管理者およびパスワードを登録します。
注意:
IPMIがDHCPを使用してIPアドレスを取得するように構成されている場合は、IPMIをリセットするか、またはノードを再起動して、アドレスを取得するようにする必要がある可能性があります。
2.7.2.2 CRSCTLを使用したIPMI構成の変更
既存のIPMIベースの障害分離構成を変更して、IPMIパスワードを変更するか、既存のインストールの障害分離に対するIPMIを構成する必要がある場合があります。ご使用のプラットフォームに適切なIPMI構成ツールでCRSCTLを使用して、これを完了させます。
たとえば、IPMIの管理者パスワードを変更するには、まず『Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイド』で説明しているようにIMPI構成を変更してから、CRSCTLを使用してOLR内のパスワードを変更します。
Oracle Clusterwareで必要なIPMIの構成データはOCRのOracle Walletに保存されています。構成情報はセキュアなストアに保持されるため、この情報はOracle Clusterwareインストールの所有者アカウント(グリッド・ユーザー)が書き込む必要があり、このインストールのユーザーとしてログインする必要があります。
既存のIPMI構成を変更するには、次の手順を実行します。
2.7.2.3 CRSCTLを使用したIPMI構成の削除
IPMIの使用を完全に停止する場合、またはIPMIの最初の構成がOracle Clusterwareをインストールしたユーザー以外のユーザーによって行われていた場合は、CRSCTLを使用してクラスタからIPMI構成を削除できます。
後者に該当する場合、Oracle ClusterwareはIPMI構成データにアクセスできず、Oracle ClusterwareソフトウェアはIPMIを使用できないため、Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成する必要があります。
IPMIを完全に削除するには、次の手順を実行します。Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成するには、手順3および4を実行し、前の項の手順2および3を繰り返します。
2.8 手動構成ネットワーク上のネットワーク・アドレスの理解
手動構成ネットワーク上のネットワーク・アドレスの概念および要件を理解することは役立ちます。
この項では、次の項目について説明します。
2.8.1 ネットワーク・アドレスの構成要件の理解
Oracle Clusterware構成には、少なくとも1つのパブリック・ネットワーク・インタフェースと1つのプライベート・ネットワーク・インタフェースが必要です。
-
パブリック・ネットワーク・インタフェースは、データベース・サーバー上のデータにアクセスするためにユーザーとアプリケーション・サーバーを接続します。
-
プライベート・ネットワーク・インタフェースはノード間の通信用で、Oracle Clusterwareによって排他的に使用されます。
パブリック・ネットワーク・インタフェースは、特定のネットワーク上のIPv4、IPv6または両方のタイプのアドレスに対して構成できます。冗長なネットワーク・インタフェース(ボンディングまたはチーミングされたインタフェース)を使用する場合、Oracleでは、1つのインタフェースがIPv4アドレスをサポートしていますが、別のインタフェースがIPv6アドレスをサポートするような構成はサポートしていないので注意してください。冗長なインタフェースのネットワーク・インタフェースは、同じIPプロトコルを使用して構成する必要があります。
1つ以上のプライベート・ネットワーク・インタフェースを、すべてのネットワーク・アダプタに対してIPv4アドレスかIPv6アドレスのどちらかを使用して構成できます。プライベート・ネットワーク・インタフェースに対してIPv4アドレスとIPv6アドレスを組み合せて使用することはできません。
注意:
クラスタ内のプライベート・ネットワークに対してIPv6を使用できるのは、Oracle Clusterware 12c リリース2 (12.2)以上を使用する場合のみです。クラスタ内のすべてのノードには、同じIPプロトコル構成を使用する必要があります。すべてのノードがIPv4を使用するか、すべてのノードがIPv6を使用するか、すべてのノードがIPv4およびIPv6の両方を使用するかのいずれかです。クラスタ内の一部のノードがIPv6アドレスのみをサポートするように構成し、その他のノードがIPv4アドレスのみをサポートするように構成することはできません。
VIPエージェントは、ステートレス・アドレス自動構成(RFC 2462)を使用したIPv6の生成をサポートしており、これらのアドレスをGNSで通知します。srvctl config network
コマンドを実行して、DHCPまたはステートレス・アドレス自動構成が使用されているかを識別します。
この項には次のトピックが含まれます:
2.8.1.1 IPv6アドレスのフォーマットについて
Oracle Grid Infrastructureクラスタの各ノードは、同一ネットワーク上でIPv4アドレスとIPv6アドレスの両方をサポートできます。推奨されるIPv6アドレス書式は次のとおりです(各xは、16進文字を表します)。
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
IPv6アドレス・フォーマットはRFC 2460によって定義されます。Oracle Grid Infrastructureでは次のIPv6アドレスがサポートされます。
-
RFC 4193によって定義されるグローバルIPv6アドレスとサイトローカルのIPv6アドレス。
注意:
RFC 1884で定義されているリンクローカルとサイトローカルのIPv6アドレスはサポートされません。
-
IPアドレスの各フィールドの先頭に圧縮されたゼロを使用。
-
圧縮されて、「::」セパレータでで表現された空のフィールド。たとえば、IPv6アドレス2001:0db8:0000:0000:0000:8a2e:0370:7334を2001:db8::8a2e:370:7334と表記できます。
-
8ビットの断片を含む下位4つのフィールド(標準的なIPv4アドレス・フォーマット)。たとえば、2001:db8:122:344::192.0.2.33です。
2.8.1.2 名前解決およびネットワーク・リソースのアドレス・タイプ
ネットワーク構成の確認にはsrvctl config network
コマンド(構成の確認用)を、ネットワーク・アドレス・タイプの制御にはsrvctl modify network -iptype
コマンドをそれぞれ使用します。
srvctl modify network -nettype
コマンドを使用してアドレスの取得方法を構成できます。-nettype
パラメータの値をdhcp
またはstatic
に設定して、IPv4ネットワーク・アドレスの取得方法を制御します。または、-nettype
パラメータの値をautoconfig
またはstatic
を設定して、IPv6アドレスの生成方法を制御します。
-nettype
と-iptype
パラメータは直接関連していませんが、-iptype ipv4
と-nettype dhcp
を同時に使用したり、-iptype ipv6
と-nettype autoconfig
を同時に使用できます。
注意:
ネットワークがIPv4サブネットとIPv6サブネットの両方で構成されている場合、-nettype
がmixed
に設定されていると両方のサブネットがサポートされません。
-nettype
をmixed
に設定した場合、IPv4からIPv6への移行はサポートされません。最初にstatic
からdhcp
への移行が完了してから、IPv6をサブネットに追加する必要があります。
同様に、-nettype
をmixed
に設定した場合、IPv6からIPv4への移行の開始はサポートされません。最初にautoconfig
からstatic
への移行が完了してから、IPv4をサブネットに追加する必要があります。
2.8.2 SCANアドレスおよびクライアント・サービス接続の理解
パブリック・ネットワーク・アドレスはクライアントにサービスを提供するために使用します。
クライアントで単一クライアント・アクセス名(SCAN)アドレスに接続している場合は、クラスタに対してノードを追加または削除する際にパブリックおよび仮想IPアドレスを変更する必要がある場合がありますが、クライアントを新しいクラスタ・アドレスで更新する必要はありません。
注意:
listener.ora
ファイルを編集して、SCANおよびノード・リスナーのOracle Netリスナー・パラメータを変更できます。たとえば、TRACE_LEVEL_listener_name
を設定できます。ただし、リスナー・エージェントは動的にリスナー・エンドポイントを管理するため、プロトコル・アドレス・パラメータを設定して、リスニング・エンドポイントを定義することはできません。
SCANはクラスタの別名のように機能します。ただし、SCANはクラスタ内の任意のノードで解決され、ノードのVIPアドレスとは異なり、SCANに接続するクライアントでは、クラスタに対してノードを追加または削除する際に、更新されたVIPアドレスは必要なくなります。SCANアドレスはクラスタ内のノード・アドレスではなくクラスタに解決されるため、SCANアドレス構成に影響を与えることなく、クラスタでノードを追加または削除できます。
SCANは完全修飾名(ホスト名およびドメイン)で、SCANに割り当てられたすべてのアドレスに解決するように構成されています。SCANは、DNSサーバー上のSCAN名に構成された3つすべてのアドレスに解決するか、GNS構成のクラスタ内に解決します。SCANリスナーはクラスタ内の任意のノードで実行できます。SCANは、クライアント構成が特定のデータベースを実行するノードに依存する必要がないように、データベースに位置の独立性を提供します。
Oracle Database 11gリリース2 (11.2)以上のインスタンスは、SCANリスナーにのみリモート・リスナーとして登録されます。アップグレードしたデータベースは、リモート・リスナーとしてSCANリスナーに登録されるとともに、引き続きすべてのノード・リスナーにも登録されています。
注意:
インストール時にSCAN名を指定するというOracle Clusterwareのインストール要件により、サーバーの/etc/hosts
ファイルを使用して1つ以上のIPアドレスを解決してこのインストール要件を回避し、SCANに必要なインフラストラクチャがない場合は、インストール後、SCANを無視し、VIPを使用してクラスタ内のデータベースに接続できます。
Oracleでは、SCANアドレスの削除はサポートされていません。
2.8.3 有効なノード・チェックにおけるSCANリスナーおよびサービス登録制限
有効なノード・チェックを使用して、SCANリスナーが登録を受け入れるノードおよびサブネットを指定できます。SRVCTLを使用してノードおよびサブネット情報を指定できます。SRVCTLは、ノードおよびサブネット情報をSCANリスナー・プロファイルに格納します。SCANリスナー・エージェントは、リソース・プロファイルからその情報を読み出し、listener.ora
ファイルに書き込みます。
非クラスタ化(シングル・インスタンス)データベースの場合、ローカル・リスナーは、ローカル・ノード上にあるデータベース・インスタンスのサービス登録のみ受け入れます。Oracle RAC 11g リリース2 (11.2)より前のOracle RACリリースでは、SCANリスナーを使用せず、ローカル・リスナーおよびREMOTE_LISTENERS
初期化パラメータで定義されたリスナーを使用してサービスの登録を試行します。これらのデータベース・インスタンスでのサービス登録をサポートするには、Oracle RAC 12cのローカル・リスナーのvalid_node_check_for_registration_
aliasのデフォルトの値をローカル・ノードではなく、SUBNET
に設定します。ノード・リスナーに対する有効なノード・チェックの設定を変更するには、listener.ora
ファイルを変更します。
SCANリスナーはHTTPプロトコルを認識するため、HTTPクライアントを適切なハンドラ(クラスタ内のSCANリスナーが存在するノードとは別のノードに存在する可能性がある)にリダイレクトできます。
SCANリスナーは、リモート・ノード上のインスタンスのサービス登録を受け入れる必要があります。SCANリスナーの場合、valid_node_check_for_registration_alias
の値を、listener.ora
ファイルのSUBNET
に設定すると、対応するリスナーが、同じサブネットを元にするサービス登録を受け入れることができます。
リスナーを構成して、別のサブネットのサービス登録を受け入れることができます。たとえば、SCANリスナーが別々のクラスタのインスタンス間で共有されており、これらのクラスタのノードが別々のサブネットにあるときに、この環境を構成します。この環境にノードを含めるには、srvctl modfiy scan_listener -invitednodes -invitedsubnets
コマンドを実行します。
このクラスタのOracle Notification Serviceネットワークと、候補インスタンスを持つクラスタを接続するには、srvctl modify nodeapps -remoteservers host:port,...
コマンドも実行する必要があります。
2.9 手動構成システム上のネットワーク・アドレスの変更
手動構成システム上でネットワーク・アドレス・メンテナンスを実行できます。
これは、次のトピックで説明します。
2.9.1 SRVCTLを使用した仮想IPアドレスの変更
SRVCTLを使用して、仮想IPアドレスを変更できます。
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 -subnet
コマンドは、DHCPネットワークを作成するだけです。
注意:
次の説明は、VIPアドレスのみを変更する方法を示すもので、VIPアドレスに関連付けられたホスト名は変更しないことを想定しています。GNSを使用していて、VIPがDHCPを使用して割り当てられている場合は、VIPアドレスを手動で更新する必要はありません。
VIPアドレスのみを変更する場合、DNSおよびクライアントのhostsファイルを更新します。また、サーバーのhostsファイルがVIPアドレスに対して使用されている場合は、それも更新します。
VIPアドレスを変更するには、次の手順を実行します。
2.9.2 Oracle Clusterwareのプライベート・ネットワーク構成の変更
Oracle Clusterwareプライベート・ネットワーク構成を変更できます。
この節では、以下のトピックについて説明します。
2.9.2.1 プライベート・ネットワークおよびネットワーク・インタフェースについて
Oracle Clusterwareでは、各ノードが、(パブリック・ネットワークに加えて)プライベート・ネットワークに接続されている必要があります。プライベート・ネットワーク接続は、クラスタ・インターコネクトとも呼ばれます。
表2-1に、ネットワーク・インタフェース・カードおよびプライベートIPアドレスがどのように格納されるかを示します。
すべてのノードが、同一のサブネットに接続された同一のネットワーク・インタフェース(oifcfg
コマンドによりグローバル・インタフェースとして定義済)を使用しているクラスタのみをサポートしています。ノードごとに異なるネットワーク・インタフェース(ノード固有のインタフェース)を使用することはできません。
表2-1 ネットワーク・インタフェース、プライベートIPアドレスおよびプライベート・ホスト名の記憶域
エンティティ | 格納先 | コメント |
---|---|---|
ネットワーク・インタフェース名 |
オペレーティング・システム たとえば、 |
ネットワーク・インタフェース名を指定する場合、ワイルドカードを使用できます。 たとえば、 |
プライベート・ネットワーク・インタフェース |
Oracle Clusterwareのグリッド・プラグ・アンド・プレイ(GPnP)・プロファイル内 |
インストール時にインタフェースを「プライベート」とすることによって、使用するインタフェースをプライベート・インタフェースとして構成するか、 |
2.9.2.2 冗長インターコネクトの使用
インストール時、またはインストール後に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アドレスとして、「プライベート」ロールを指定したインタフェースのHAIPアドレスを使用するので、提供されたクラスタ・インターコネクト・インタフェースのセット全体でロード・バランシングが可能になります。定義済のクラスタ・インターコネクト・インタフェースのいずれかに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースのいずれかに対応するHAIPアドレスを透過的に移動します。
たとえば、インストール後に新しいインタフェースを、サブネット番号が172.16.2.0のeth3
というサーバーに追加する場合は、次のコマンドを使用して、このインタフェースをプライベート・インタフェースとしてOracle Clusterwareで使用できるようにします。
$ oifcfg setif -global eth3/172.16.2.0:cluster_interconnect
Oracle Clusterwareではeth3
で169.254.*.*というHAIPアドレス(HAIP用の予約済サブネット)が使用され、データベースOracle ASMおよびOracle ACFSはそのアドレスを通信に使用しますが、Oracle Clusterwareは自身の通信に172.16.2.0アドレスも使用します。
注意:
HAIPサブネット(169.264.*.*)を分類するためにOIFCFGを使用しないでください。OIFCFGは、Oracle Clusterwareのインタフェース名、サブネットおよびタイプ(パブリック、クラスタ・インターコネクトまたはOracle ASM)を記録するために使用できます。ただし、OIFCFGを使用して各インタフェースの実際のIPアドレスを変更することはできません。
注意:
Oracle Clusterwareが使用するインタフェースは、定義されているインタフェースの数に関係なく、常に最大で4つです。あるインタフェースに障害が発生すると、HAIPアドレスは、定義されたセット内の別の構成済インタフェースに移動します。
HAIPアドレスが1つのみで、選択するインタフェースが複数ある場合、HAIPアドレスの移動先のインタフェースは、そのアドレスが構成された元のインタフェースではなくなります。Oracle Clusterwareは、HAIPアドレスの追加先として、数が最も小さいサブネットのインタフェースを選択します。
2.9.2.3 OIFCFGを使用したインタフェース名の変更結果
インタフェース名の変更結果は、どの名前を変更するか、またIPアドレスも変更するかどうかによって異なります。
インタフェース名のみを変更する場合、結果は、それほど重要ではありません。OCR内に格納されたパブリック・インタフェースの名前を変更する場合、クラスタのノード・アプリケーションも変更する必要があります。したがって、この変更を有効にするために、ノード・アプリケーションを停止する必要があります。
2.9.2.4 ネットワーク・インタフェースの変更
OIFCFGコマンドを使用して、ネットワーク・インタフェースおよびそれに関連するサブネット・アドレスを変更できます。
この手順では、Oracle ClusterwareおよびOracle Databaseが以前使用していたクラスタ内の各ノードで、ネットワーク・インタフェースおよびIPアドレスを変更します。
注意:
Oracle RAC(RDBMS)インターコネクトで使用されるインタフェースは、Oracle Clusterwareでホスト名に使用されるインタフェースと同じである必要があります。Oracle Clusterwareで監視されない別のインタフェースで、Oracle RACのプライベート・インターコネクトを構成しないでください。
2.9.3 SRVCTLを使用したネットワークの作成
SRVCTLを使用して、クラスタ・メンバー・ノードにネットワークを作成し、アプリケーション構成情報を追加します。
次のように、クラスタ・メンバー・ノード用のネットワークを作成します。
2.9.4 クラスタ内のネットワーク・アドレス構成
IPv4、IPv6または指定されたネットワーク上での両タイプのアドレスのいずれかにネットワーク・インタフェースを構成できます。
サード・パーティーの技術を使用して冗長なネットワーク・インタフェースを構成する場合、Oracleでは、1つのインタフェースがIPv4アドレスをサポートし、別のインタフェースがIPv6アドレスをサポートするような構成はサポートしていません。冗長なインタフェースのネットワーク・インタフェースは、同じIPアドレス・タイプを使用して構成する必要があります。Oracle Clusterwareの冗長インターコネクト機能を使用する場合は、インタフェースにIPv4アドレスを使用する必要があります。
クラスタ内のすべてのノードには、同じIPプロトコル構成を使用する必要があります。すべてのノードがIPv4を使用するか、すべてのノードがIPv6を使用するか、すべてのノードがIPv4およびIPv6の両方を使用するかのいずれかです。クラスタ内の一部のノードがIPv6アドレスのみをサポートするように構成し、その他のノードがIPv4アドレスのみをサポートするように構成することはできません。
ローカル・リスナーは、ネットワーク・リソースに構成されたサブネットのアドレス・タイプに基づくエンドポイントでリスニングします。IPV4、IPV6または両方のタイプを使用できます。
2.9.5 SRVCTLを使用した、静的IPv4アドレスの静的IPv6アドレスへの変更
IPv4静的アドレスからIPv6静的アドレスに変更する場合は、静的IPv6アドレスのみを使用するように切り替える前に、IPv6アドレスを追加し、IPv4アドレスとIPv6アドレスの両方を短期間受け入れるようにネットワークを変更します。
注意:
IPv4ネットワークが、静的および動的アドレスの両方が混合したモードである場合、この手順は実行できません。最初にすべてのアドレスを静的に移行する必要があります。
静的IPv4アドレスを静的IPv6アドレスに変更するには、次の手順を実行します。
2.9.6 SRVCTLを使用した、動的IPv4アドレスの動的IPv6アドレスへの変更
SRVCTLコマンドによって、動的IPv4アドレスを動的IPv6アドレスに変更します。
注意:
IPv4ネットワークが、静的および動的アドレスの両方が混合したモードである場合、この手順は実行できません。最初にすべてのアドレスを動的に移行する必要があります。
動的IPv4アドレスを動的IPv6アドレスに変更するには、次の手順を実行します。
関連トピック
2.9.7 IPv4ネットワークのIPv4およびIPv6ネットワークへの変更
IPv6ネットワークを既存のIPv4ネットワークに追加して、IPv4ネットワークをIPv4およびIPv6ネットワークに変更できます。
このプロセスは、SRVCTLを使用した、静的IPv4アドレスの静的IPv6アドレスへの変更の手順1から5に説明されています。
これらの手順を完了した後、グリッド・ユーザーとしてログインし、次のコマンドを実行します。
$ srvctl status scan
出力を確認して、SCAN VIPの変更を確認します。