2 Oracle Clusterwareの構成と管理

Oracle Clusterwareとその様々なコンポーネントの構成と管理には、アプリケーションとデータベースの管理およびクラスタ内のネットワーク構成が含まれます。

クラスタを構成および管理するには2つの方法があり、いずれかを選択できます。従来型の管理者管理アプローチを使用して、クラスタ・リソースとワークロードを手動で管理するか、ポリシー管理アプローチを使用して、様々な程度の自動化管理を起動できます。

管理者管理クラスタの場合、クラスタ・リソースをどのようにデプロイするか、およびワークロードをどこで管理するかを手動で構成する必要があります。通常、これは、どのクラスタ・ノードでどのデータベース・インスタンスを優先して実行するか、および障害発生時にどこでそれらのインスタンスを再起動するかを構成する必要があるということです。データベース・インスタンスの配置場所を構成することにより、クラスタ全体のワークロードを構成します。

ポリシー管理クラスタでは、ワークロードをサーバー・プール内で実行するように構成します。これには、各サーバー・プール内でのこれらのワークロードの管理方法を指示するポリシー・セットを構成します。サーバー・プールとポリシー・セットの管理は自分で行い、データベース・インスタンスの場所およびワークロード配置の詳細は、設定したポリシーに委任します。このアプローチを使用する際は、Oracle Quality of Service Management (Oracle QoS Management)を使用することにより、クラスタの管理をさらに自動化する追加オプションを選択できます。

ロール別管理

ロール別管理は、リソースの競合と不足のリスクを軽減する目的でクラスタ・リソースおよびワークロードを協調的に管理するためのアプローチです。

ロール別管理では、オペレーティング・システムのセキュリティとロール定義、およびユーザーのロールに従ってリソースとワークロード管理を分離するための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を参照してください。

クラスタ管理者の管理

アクセス制御リスト(ACL)を使用して、クラスタの管理者を定義できます。

クラスタにサーバー・プールを作成する機能は、クラスタ管理者に制限されています。以前のリリースでは、デフォルトでは、登録されているすべてのオペレーティング・システム・ユーザーがクラスタ管理者とみなされましたが、このデフォルトは必要に応じてcrsctl add | delete crs administratorコマンドを使用して変更できました。ただし、このリリースではこれらのコマンドの使用は非推奨であり、かわりに、ポリシー・セットのACLを使用してサーバー・プールの作成機能を制御する必要があります。

原則として、サーバー・プールまたはクラスタ・リソースの作成権限を設定するには、オペレーティング・システム・ユーザー、またはそのユーザーがメンバーになっているオペレーティング・システム・グループの読取り、書込みおよび実行権限がACL属性内で設定されている必要があります。

ロール区分の構成

ロール区分は、必要なロール、ロールが管理するリソースおよびサーバー・プール、およびロールのアクセス権限の決定です。これらを決定した後、ACLおよびCRSCTLユーティリティを使用して、グループ権限(oinstallgridなど)用のオペレーティング・システム・ユーザー・アカウントを作成または変更できます。

最も基本的には、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--

グリッド設定ウィザードを使用した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

単一ノードの構成

構成ウィザードを使用して、単一ノードを構成できます。

単一ノードを構成するには:

  1. 次のように、構成ウィザードを起動します。
    $ Oracle_home/gridSetup.sh
    
  2. 「インストール・オプションの選択」ページで、「クラスタ用のOracle Grid Infrastructureの構成」を選択します。
  3. 「クラスタ・ノードの情報」ページで、ローカル・ノードと、それに対応するVIP名のみを選択します。
  4. 残りのウィザード・ページで、引き続き情報を追加します。
  5. 「サマリー」ページで入力を確認して、「終了」をクリックします。
  6. 構成ウィザードの指示に従って、root.shスクリプトを実行します。

複数ノードの構成

構成ウィザードを使用して、クラスタ内に複数ノードを構成できます。

構成ウィザードを使用して構成するノードへのOracle Grid Infrastructureソフトウェアのインストールは、必須ではありません。

ノート:

構成ウィザードを起動する前に、次の点を確認します。

すべてのノードにソフトウェアをインストールする必要はありませんが、インストールする場合は、ソフトウェアを同じGrid_homeパスにインストールし、すべてのノードで同一レベルに配置する必要があります。

構成ウィザードを使用して複数ノードを構成するには:

  1. 次のように、構成ウィザードを起動します。
    $ Oracle_home/gridSetup.sh
    
  2. 「インストール・オプションの選択」ページで、「クラスタ用のOracle Grid Infrastructureの構成」を選択します。
  3. 「クラスタ・ノードの情報」ページで、構成するノードと、それに対応するVIP名を選択します。構成ウィザードは、選択されたノードを検証し、その準備が整っていることを確認します。
  4. 残りのウィザード・ページで、引き続き情報を追加します。
  5. 「サマリー」ページで入力を確認して、「終了」をクリックします。
  6. 構成ウィザードの指示に従って、root.shスクリプトを実行します。

Oracle Grid Infrastructureのアップグレード

グリッド設定ウィザードを使用して、クラスタのOracle Grid Infrastructureをアップグレードします。

クラスタ用のOracle Grid Infrastructureをアップグレードするには:

  1. グリッド設定ウィザードを起動します。
    $ Oracle_home/gridSetup.sh
    
  2. 「インストール・オプションの選択」ページで、「Oracle Grid Infrastructureのアップグレード」を選択します。
  3. Oracle Grid Infrastructureノード選択ページで、アップグレードするノードを確認します。また、停止しているノードをアップグレードしないように選択できます。
  4. 残りのウィザード・ページで、引き続き情報を追加します。
  5. 「サマリー」ページで入力を確認して、「終了」をクリックします。
  6. 構成ウィザードの指示に従って、rootupgrade.shスクリプトを実行します。

関連項目:

Oracle Restartの手順の詳細は、ご使用のプラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。

サイレント・モードでの構成ウィザードの実行

—silentパラメータを指定して、構成ウィザードをサイレント・モードで実行できます。

構成ウィザードをサイレント・モードで使用してノードを構成またはアップグレードするには:

  1. 次のようにして、コマンドラインから構成ウィザードを起動します。

    $ $ORACLE_HOME/gridSetup.sh -silent -responseFile file_name

    構成ウィザードはレスポンス・ファイルを検証してから、構成に進みます。レスポンス・ファイルで無効な入力を検出すると、構成ウィザードはエラーを表示して終了します。

  2. 指示に従って、rootスクリプトおよびGrid_home/gridSetup -executeConfigToolsスクリプトを実行します。

Oracle Grid Infrastructureホームの移動およびパッチ適用

グリッド設定ウィザードを使用して、Oracle Grid Infrastructureホームを移動しそれにパッチを適用します。

Oracleインストーラ・スクリプトgridSetup.shでは、この目的のために、新しいスイッチ-switchGridHomeがサポートされています。この機能では、同じかより新しいパッチ・レベルになるように、Oracle Grid Infrastructureホームを移動してそれにパッチを適用できます。

関連項目:

サーバーの重みベースのノード削除

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スタックを再起動する必要があります。リソースは再起動しなくても変更が有効になるため、これはリソースには適用されません。

  • 管理者管理環境をポリシー管理環境または両者混合の環境に変更した場合、割り当てた重みはすべて保存されますが、考慮はされません。つまり、クラスタを元の管理者管理に再構成しないかぎりは、適用も考慮もされません。

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ページに統合されています。

グリッド・ネーミング・サービスの概要

Oracle Clusterwareでは、シングルクラスタおよびマルチクラスタの環境のアドレス解決にグリッド・ネーミング・サービス(GNS)が使用されます。単一のプライマリGNSインスタンスを使用してクラスタを構成し、さらに異なるロールを持つ1つ以上のセカンダリGNSインスタンスを構成して、高可用性アドレス参照などのサービスをクライアントに提供することもできます。

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

グリッド・ネーミング・サービス構成オプションの理解

GNSは、自動または標準のクラスタ・アドレス構成モードのいずれかで実行できます。自動構成は、IPv4アドレスのDynamic Host Configuration Protocol (DHCP)またはIPv6アドレスのStateless Address Autoconfiguration Protocol (autoconfig) (RFC 2462およびRFC 4862)のいずれかを使用します。

この項には次のトピックが含まれます:

高可用性グリッド・ネーミング・サービス

高可用性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インスタンスにデータ更新について問い合せます。

アドレスの自動構成オプション

自動構成の場合、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を使用して自動的にアドレスを生成します。

アドレスの静的な自動構成オプション

静的な構成では、委譲されるサブドメインはありません。DNS管理者はGNS VIPを構成して、DNS上で構成された名前とアドレスに解決し、また、DNS管理者はSCAN名を構成して、クラスタのこれらの静的なアドレスに解決します。

また、DNS管理者は、各クラスタ・メンバー・ノードに静的なパブリックIP名とアドレスおよび仮想IP名とアドレスを構成します。DNS管理者は、クラスタに追加された各ノードに新しいパブリックおよび仮想IP名とアドレスを構成する必要もあります。すべての名前とアドレスはDNSによって解決されます。

静的なVIPアドレスおよびSCANを使用したサブドメインの委譲がないGNSでは、クラスタ内に名前解決情報が必要なOracle Flex ClusterおよびCloudFS機能を使用できます。ただし、ノードを追加したり変更する場合は、手動で管理タスクを実行する必要があります。

アドレスの共有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を使用して、静的アドレスを構成できます。

グリッド・ネーミング・サービスの管理

SRVCTLを使用して、シングルクラスタおよびマルチクラスタの両方の環境でグリッド・ネーミング・サービス(GNS)を管理します。

ノート:

GNSサーバーおよびクライアントは、同じオペレーティング・システムおよびプロセッサ・アーキテクチャを使用しているコンピュータで実行する必要があります。コンピュータ上のオペレーティング・システムが異なる、プロセッサ・アーキテクチャが異なる、またはその両方が異なる場合、GNSは実行できません。

この項には次のトピックが含まれます:

高可用性GNSの構成

高可用性GNSの構成では、プライマリGNSインスタンスとセカンダリGNSインスタンスを構成します。GNSはOracle Clusterwareのインストール時にOracle Universal Installerを使用して構成できますが、セカンダリGNSインスタンスはOracle Clusterwareのインストール後にしか構成できないため、高可用性GNSはOracle Clusterwareのインストール後にしか構成できません。

高可用性GNSでは、マルチクラスタ環境における複数のGNSインスタンスを様々なロールで実行できます。1つのプライマリGNSインスタンスと、0以上のセカンダリ・インスタンスが存在します。プライマリ・インスタンスは更新および解決の操作を管理します。ただし、セカンダリ・インスタンスは解決操作のみを管理します。セカンダリGNSインスタンスを使用するように選択する場合は、まずプライマリGNSインスタンスを構成するか、共有GNS環境内の既存のGNSをプライマリGNSインスタンスに変更する必要があります。
  1. クラスタ管理者として、次のようにして、既存のクラスタ内の任意のノードにプライマリGNSインスタンスを構成します。
    # srvctl add gns -vip gns_vip -domain gns_subdomain
  2. 次のようにして、プライマリGNSインスタンスを起動します。
    # srvctl start gns

    マルチクラスタ環境内に存在できるプライマリGNSインスタンスは1つのみです。GNSによって複数のプライマリGNSインスタンスが検出されると、startコマンドを終了します。この場合、ステップ5の説明に従って、このインスタンスをセカンダリGNSインスタンスとして構成できます。

  3. 次のようにして、セカンダリGNSインスタンスのクライアント・データを作成します。
    # srvctl export gns -clientdata file_name -role secondary

    GNSにより、このゾーン・データ情報がOCRに格納され、構成後にセカンダリGNSインスタンスが更新されます。

  4. 前述のステップで作成したクライアント・データ・ファイルをセカンダリGNSインスタンスにコピーします。
  5. 次のようにして、セカンダリGNSインスタンスを構成します。
    # srvctl add gns -vip gns_vip -clientdata file_name
  6. 次のようにして、セカンダリGNSインスタンスを起動します。
    # srvctl start gns

    セカンダリGNSインスタンスを正常に構成および起動すると、プライマリGNSインスタンスにゾーン・データについての問合せが行われます。

プライマリGNSインスタンスおよびセカンダリGNSインスタンスの削除

プライマリGNSインスタンスおよびセカンダリGNSインスタンスをクラスタから削除できます。

プライマリGNSインスタンスは、別のプライマリGNSインスタンスを構成するまでは削除できません。置き換わるインスタンスがないのにプライマリGNSインスタンスを削除した場合、GNSは機能しなくなります。

クラスタ管理者として、次のようにして、セカンダリGNSインスタンスを選択し、それをプライマリGNSインスタンスに昇格します。

# srvctl modify gns -role primary
  1. プライマリGNSインスタンスかセカンダリGNSインスタンスのどちらを削除するかに応じて、次のようにしてインスタンスを停止します。
    # srvctl stop gns
  2. 次のようにして、インスタンスを削除します。
    # srvctl remove gns

    ノート:

    DNS管理者は、クライアントが使用不能になったインスタンスの問合せを試行することがないように、インスタンスのネーム・サーバーおよびA/AAAAレコード・エントリをDNSゾーン・データから削除できます。

SRVCTLを使用したGNSの起動と停止

srvctlコマンドを使用してGNSを起動および停止します。

サーバー・クラスタでのGNSの起動と停止は、次のそれぞれのコマンドをrootとして実行します。

# srvctl start gns
# srvctl stop gns

ノート:

クライアント・クラスタではGNSを起動したり停止できません。

GNSサーバーまたはGNSクライアント・クラスタへのクラスタの変換

GNSを実行していないクラスタをGNSサーバーまたはクライアント・クラスタに変換したり、サーバーおよびクライアント・クラスタのGNSクラスタ・タイプの構成を変更できます。

この項でのクラスタ・コンバージョンの使用例は、次のとおりです。

非GNSクラスタのGNSサーバー・クラスタへの変換

srvctlコマンドを使用して、GNSを実行していないクラスタをGNSサーバー・クラスタに変換できます。

  1. rootとして次のコマンドを実行して、GNSをクラスタに追加し、有効なIPアドレスおよびドメインを指定します。

    # srvctl add gns -vip IP_address -domain domain
  2. GNSインスタンスを起動します。

    # srvctl start gns -node node_name

ノート:

  • GNS VIPを追加するときに、ドメインを指定する必要はありません

  • 現在別のGNSインスタンスで使用されているIPアドレスを指定することはできません。

  • 構成済クラスタがGNSサーバー・クラスタとなるためには、DNS委任が必要です。

非GNSクラスタのクライアント・クラスタへの変換

GNSを実行していないクラスタをクライアント・クラスタに変換するには、サーバー・クラスタから資格証明ファイルをインポートする必要があります。

次のようにして、GNSを実行していないクラスタをGNSクライアント・クラスタに変換します。

  1. サーバー・クラスタで次のコマンドを実行して、GNSインスタンス・クライアント・データ構成をファイルにエクスポートします。
    $ srvctl export gns -clientdata path_to_file -role client
    

    ファイルの完全修飾パスを指定する必要があります。

    ノート:

    Oracle Universal Installerで生成するGNS構成クライアント・データ・ファイルを、共有GNSクライアントを作成する入力ファイルとして使用できます。

  2. 次のコマンドをrootとして実行して、前述のステップで作成したファイルをクラスタ内のノードにインポートして、そのクラスタをクライアント・クラスタにします。
    # srvctl add gns -clientdata path_to_file

    ノート:

    GNSデータを含むファイルを、サーバー・クラスタからこのコマンドを実行するクラスタのノードにコピーします。

  3. 次のようにSCAN名を変更します。
    $ srvctl modify scan -scanname scan_name.client_cluster_name.server_GNS_subdomain
GNSを実行しているシングル・クラスタのサーバー・クラスタへの変換
GNSを実行しているシングル・クラスタをGNSサーバー・クラスタに変換するためには、何もする必要がありません。クライアント・クラスタが追加されると、自動的にサーバー・クラスタであるとみなされます。
GNSを実行しているシングル・クラスタのGNSクライアント・クラスタへの変換

srvctlコマンドを使用して、GNSを実行している単一クラスタをGNSクライアント・クラスタに変換できます。この変換が処理されている間、現在のGNSに接続した状態を維持する必要があるため、手順は、単一のクラスタをサーバー・クラスタに変換する場合の手順よりも複雑になります。

GNSを実行しているシングル・クラスタをGNSクライアント・クラスタに変換するには:

  1. サーバー・クラスタで次のコマンドを実行して、GNSクライアント情報をファイルにエクスポートします。
    $ srvctl export gns -clientdata path_to_client_data_file
    

    ファイルの完全修飾パスを指定する必要があります。

  2. クライアント・クラスタに変換するクラスタのGNSを停止します。
    # srvctl stop gns

    ノート:

    変換の進行中は、GNSを使用した名前解決は使用できません。

  3. サーバー・クラスタで次のコマンドを実行して、GNSインスタンスをエクスポートします。
    $ srvctl export gns -instance path_to_file
    

    ファイルの完全修飾パスを指定する必要があります。

  4. GNSインスタンス・ファイルをインポートするには、サーバー・クラスタでrootとして次のコマンドを実行します。
    # srvctl import gns -instance path_to_file
    

    ファイルの完全修飾パスを指定する必要があります。

  5. GNSインスタンスを開始するには、GNSインスタンス・ファイルをインポートしたノードで、rootとして次のコマンドを実行します。
    # srvctl start gns
    

    GNSインスタンスを起動するノードの名前を指定しないと、インスタンスはランダム・モードで開始します。

  6. 次のコマンドを使用してGNSクライアント・クラスタからGNSを削除します。
    # srvctl remove gns
    
  7. 次のように、前のクラスタをクライアント・クラスタにします。
    # srvctl add gns -clientdata path_to_client_data_file

    ノート:

    GNSデータを含むファイルを、サーバー・クラスタからこのコマンドを実行するクラスタのノードにコピーします。

  8. GNSクライアント・クラスタのSCANを変更して、次のようにクライアント・クラスタ名で修飾されたGNSサブドメインを使用するようにします。
    $ srvctl modify scan -scanname scan_name.gns_domain
    

    前述のコマンドでは、gns_domainの形式はclient_cluster_name.server GNS subdomainです。

別のクラスタへのGNSの移動

クラスタ障害または管理計画のいずれかが理由で、別のクラスタをGNSサーバー・クラスタにする必要が出た場合、srvctlコマンドを使用してGNSを別のクラスタに移動できます。

ノート:

この手順には、サーバー・クラスタおよびクライアント・クラスタのダウンタイムが必要です。また、GNSクライアント・データを新しいサーバー・クラスタから任意のOracle Flex ASMとフリート・パッチ適用およびプロビジョニング・サーバーおよびクライアントにインポートする必要があります。

GNSを別のクラスタに移動するには:

  1. 現在のサーバー・クラスタのGNSインスタンスを停止します。
    # srvctl stop gns
    
  2. GNSインスタンス構成をファイルにエクスポートします。
    # srvctl export gns -instance path_to_file
    

    ファイルへの完全修飾パスを指定します。

  3. 以前のサーバー・クラスタからGNS構成を削除します。
    # srvctl remove gns
    
  4. GNSを新しいクラスタに追加します。
    # srvctl add gns -domain domain_name -vip vip_name
    

    別の方法として、VIPのIPアドレスを指定できます。

  5. ステップ2で作成したファイルに格納されているインスタンス情報を使用して、次のように新しいサーバー・クラスタのGNSインスタンスを構成します。
    # srvctl import gns -instance path_to_file

    ノート:

    以前のサーバー・クラスタのGNSデータを含むファイルが、srvctl import gnsコマンドを実行するクラスタのノードに存在する必要があります。

  6. 新しいサーバー・クラスタのGNSインスタンスを起動します。
    # srvctl start gns

IPv4からIPv6ネットワークへの移行時のGNSサブドメインの変更

IPv4ネットワークからIPv6ネットワークに移行するとき、GNSサブドメインを変更する必要があります。

GNSサブドメインを変更するには、次のようにして、IPv6ネットワークを追加し、GNSドメインを更新して、SCANを更新します。
  1. 次のようにして、srvctl modify networkコマンドを使用してIPv6サブネットを追加します。
    $ srvctl modify network -subnet ipv6_subnet/ipv6_prefix_length[/interface] -nettype autoconfig
  2. 次のようにして、GNSドメインを更新します。
    $ srvctl stop gns -force
    $ srvctl stop scan -force
    $ srvctl remove gns -force
    $ srvctl add gns -vip gns_vip -domain gns_subdomain
    $ srvctl start gns
  3. 次のようにして、新しいドメインでSCAN名を更新します。
    $ srvctl remove scan -force
    $ srvctl add scan -scanname new_domain
    $ srvctl start scan
  4. 次のようにして、ネットワークIPタイプをIPv4からIPv4 DHCPとIPv6両方のautoconfigに変換します。
    $ srvctl modify network -iptype both
  5. 次のようにして、ネットワークの使用プロトコルを、両方のプロトコルからIPv6 autoconfigのみに移行します。
    $ srvctl modify network -iptype ipv6

DNSによるクラスタの名前解決をGNSにローリング変換

名前解決にDNSを使用しているOracle Grid Infrastructureクラスタ・ネットワークを、GNSで名前解決を取得するグリッド・ネーミング・サービス(GNS)を使用したクラスタ・ネットワークに変換できます。

次の手順を使用して、標準的なDNS名前解決ネットワークからGNS名前解決ネットワークにダウンタイムなしで変換します。

  1. グリッド・ユーザー(grid)としてログインし、次のCluster Verification Utilityを使用して、クラスタをGNSに移動させるためのステータスを確認します(ここで、nodelistは、クラスタ・メンバー・ノードのカンマ区切りのリストです)。
    $ cluvfy stage -pre crsinst -n nodelist
  2. グリッド・ユーザーとして、次のコマンドを使用してGNS構成の整合性を確認します(ここで、domainは、解決をGNSに委譲されるドメインで、gns_vipはGNS VIPです)。
    $ cluvfy comp gns -precrsinst -domain domain -vip gns_vip
  3. rootユーザーとしてログインし、次のSRVCTLコマンドを使用してGNSリソースを構成します(ここで、domain_nameは、ネットワーク管理者が解決をGNSに委譲するよう構成したドメインで、ip_addressは、GNSがDNSリクエストをリスニングするIPアドレスです)。
    # srvctl add gns -domain domain_name -vip ip_address
  4. GNSを起動するには、次のコマンドを使用します。
    # srvctl start gns

    GNSが起動され、VIPおよびSCAN名を登録します。

  5. 静的およびDHCPネットワーク・アドレスが混在するモードをサポートするために、rootとして、次のコマンドを使用してネットワークCRSリソースを変更します。
    # srvctl modify network -nettype MIXED

    必要なVIPアドレスがDHCPサーバーから取得され、決定されます。

  6. グリッド・ユーザーとして、次のコマンドを入力して、Oracle Clusterwareが新しいGNS、動的アドレスおよびリスナー・エンドポイントを使用していることを確認します。
    cluvfy stage -post crsinst -n all
  7. 検証が正常に終了した後、GNSで解決されるSCANおよびVIPを使用するために、DNSで解決されるSCANまたはVIPを以前に使用したリモート・エンドポイントを変更します。

    SCANを使用する各クライアントで、クライアントが使用するSCANを変更して、クライアントがGNSに委譲されたドメイン内のSCANを使用するようにします。

    VIP名を使用している各クライアントでは、クライアントが同じサーバーVIP名およびGNSに移譲されたドメインのドメイン名を使用するように、各クライアントのVIP名を変更します。

  8. rootとして次のコマンドを入力して、GNSサブドメインのSCAN名でシステムを更新します。
    # srvctl modify scan -scanname scan_name.gns_domain

    このコマンド構文のgns_domainは、この手順のステップ3で入力したドメイン名です。

  9. すべてのクライアントで動的アドレスが使用されたら、次のように静的アドレスを無効化します。
    $ srvctl modify network -nettype DHCP

ノード障害分離

障害分離は、障害が発生したノードをクラスタの残りのノードから分離させ、障害が発生したノードでデータが失われるのを防ぐプロセスです。

障害が発生したノードの分離には、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デバイスを装備する必要があります。BMCに加えて、各ノードにipmiutilがインストールされている必要があります。ipmiutilユーティリティは、Oracle Grid Infrastructureインストールとともに配布されないため、ダウンロードする必要があります。ipmiutilは、ipmiutil.sourceforge.netまたは他のリポジトリからダウンロードできます。バージョン番号はヘルプ・プロンプトでも表示されますが、ipmiutilの実行によっても表示できます。

DHCPを使用してIPMIの動的IPアドレス割当てをサポートするには、クラスタ同期サービス・デーモンは、クラスタ同期サービスの起動時にローカルのIPMIデバイスと直接通信を行いIPMIデバイスのIPアドレスを取得する必要があります。(ただし、これはHP-UXおよびSolarisプラットフォームにはあてはまりません。これらのプラットフォームでは、IPMIデバイスに静的IPアドレスを割り当てる必要があります。)これは、各クラスタ・システムにインストールする必要があるIPMIドライバを介してIPMIデバイスと通信するIPMIプローブ・コマンド(OSD)を使用して行われます。

IPMIデバイスに静的IPアドレスを割り当てた場合、IPMIドライバは、クラスタ同期サービス・デーモンにとって必須ではありません。ただし、ipmitoolまたはipmiutilを使用してIPMIデバイスを構成するにはドライバが必要ですが、一部のプラットフォームでは管理コンソールを使用してこれを行うこともできます。

IPMI用のサーバー・ハードウェア構成

最初に、ipmiutilバイナリをインストールし、IPMIドライバをインストールして有効にし、IPMIデバイスを構成する必要があります(ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイド』を参照)。

CRSCTLを使用したIPMIベース障害分離のインストール後の構成

Oracle Clusterwareをインストールした後、crsctlコマンドを使用してIPMIベースの障害分離を構成します。このコマンドを使用して、IPMI構成を変更または削除することもできます。

これは、次のトピックで説明します。

Oracle ClusterwareでのIPMIインストール後の構成

ipmiutilバイナリをインストールし、IPMIドライバをインストールして有効化し、IPMIデバイスを構成し、サーバー構成を完了した後、CRSCTLコマンドを使用してIPMI構成を完了できます。

インストールを開始する前に、ipmiutilバイナリをインストールし、サーバー・オペレーティング・システムにIPMIドライバをインストールして有効にし、各ノードでIPMIハードウェア(IPアドレス・モード、管理資格証明など)を構成しました(『Oracle Grid Infrastructureインストレーション・ガイド』を参照)。Oracle Clusterwareをインストールすると、インストーラによって、IPMI管理者のユーザーIDおよびパスワードが収集され、ノードのローカル記憶域の(OLRにある)Oracle Walletに格納されます。

サーバーの構成が完了したら、各クラスタ・ノードで次の手順を実行し、ノードにIPMI管理者およびパスワードを登録します。

ノート:

IPMIがDHCPを使用してIPアドレスを取得するように構成されている場合は、IPMIをリセットするか、またはノードを再起動して、アドレスを取得するようにする必要がある可能性があります。

  1. Oracle Clusterwareを起動します(起動すると、IPMIから現在のIPアドレスを取得できます)。これにより、起動時に必要となるクラスタウェアとIPMIの通信が可能であることが確認されます。

    IPMIが構成される前にOracle Clusterwareが実行されていた場合は、Oracle Clusterwareを停止して再起動できます。または、IPMI管理ユーティリティを使用してIPMIのIPアドレスを取得してから、CRSCTLを使用して次のようなコマンドを実行することで、OLRにIPアドレスを格納します。

    crsctl set css ipmiaddr 192.168.10.45
    
  2. CRSCTLを使用して、crsctl set css ipmiadminコマンドを実行し、プロンプトにパスワードを指定することで、装備されているIPMI用に以前に作成したユーザーIDおよびパスワードをOLRに格納します。たとえば:
    crsctl set css ipmiadmin administrator_name
    IPMI BMC password: password
    

    このコマンドでは、指定した資格証明が検証され、これを使用して別のクラスタ・ノードがローカルIPMIにアクセスできない場合は失敗します。

    ハードウェアおよびオペレーティング・システムの構成を完了し、Oracle ClusterwareにIPMI管理者を登録した後、IPMIベースの障害分離は完全に機能します。

    インストールを開始する前に、ipmiutilをダウンロードしてクラスタ内の各ノードにインストールし、サーバー・オペレーティング・システムにIPMIドライバをインストールして有効にし、各ノードでIPMIハードウェア(IPアドレス・モード、管理資格証明など)を構成します(『Oracle Grid Infrastructureインストレーション・ガイド』を参照)。Oracle Clusterwareをインストールすると、インストーラによって、IPMI管理者のユーザーIDおよびパスワードが収集され、ノードのローカル記憶域の(OLRにある)Oracle Walletに格納されます。

CRSCTLを使用したIPMI構成の変更

既存のIPMIベースの障害分離構成を変更して、IPMIパスワードを変更するか、既存のインストールの障害分離に対するIPMIを構成する必要がある場合があります。ipmiutilバイナリ・ファイルへのパスの変更が必要になる場合もあります。

ご使用のプラットフォームに適したIPMI構成ツールでCRSCTLを使用して、これらの変更を行います。

たとえば、IPMIの管理者パスワードを変更するには、まず『Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイド』で説明しているようにIPMI構成を変更してから、CRSCTLを使用してOLR内のパスワードを変更します。

Oracle Clusterwareで必要なIPMIの構成データはOLRのOracle Walletに保存されています。構成情報はセキュアなストアに保持されるため、この情報はOracle Clusterwareインストールの所有者アカウント(グリッド・ユーザー)が書き込む必要があり、このインストールのユーザーとしてログインする必要があります。

既存のIPMI構成を変更するには、次の手順を実行します。

  1. crsctl set css ipmiadmin administrator_nameコマンドを入力します。たとえば、ユーザーIPMIadmの場合は、次のようになります。
    $ crsctl set css ipmiadmin IPMIadm

    管理者パスワードを指定します。Oracle Clusterwareでは、ローカルIPMIの管理者の名前およびパスワードがOLRに格納されます。

    新しい資格証明が格納されると、Oracle Clusterwareは新しい資格証明を取得し、必要に応じて配布することができます。

  2. crsctl set css ipmiaddr bmc_ip_addressコマンドを入力します。たとえば:
    $ crsctl set css ipmiaddr 192.0.2.244

    このコマンドでは、ローカルIPMIの新しいIPMI IPアドレスがOLRに格納され、IPアドレスの格納後、Oracle Clusterwareは、新しい構成を取得し、必要に応じて配布することができます。

  3. crsctl get css ipmiaddrコマンドを入力します。たとえば:
    $ crsctl get css ipmiaddr
    

    このコマンドでは、ローカルIPMIのIPアドレスがOLRから取得され、コンソールに表示されます。

  4. 次のように、OLRからローカルIPMIのIPMI構成情報を削除して、レジストリ・エントリを削除します。
    $ crsctl unset css ipmiconfig
CRSCTLを使用したIPMI構成の削除

IPMIの使用を完全に停止する場合、またはIPMIの最初の構成がOracle Clusterwareをインストールしたユーザー以外のユーザーによって行われていた場合は、CRSCTLを使用してクラスタからIPMI構成を削除できます。

後者に該当する場合、Oracle ClusterwareはIPMI構成データにアクセスできず、Oracle ClusterwareソフトウェアはIPMIを使用できないため、Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成する必要があります。

IPMIを完全に削除するには、次のステップを実行します。Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成するには、ステップ3および4を実行し、前の項のステップ3および4を繰り返します。

  1. 次のように、IPMIドライバを無効にして、起動時のインストールを回避します。
    /sbin/modprobe -r
  2. LAN経由でのアクセスを防ぐためにipmitoolまたはipmiutilを使用してローカルIPMIのIPMI-over-LANを無効にするか、またはIPMI管理者のユーザーIDとパスワードを変更します。
  3. Oracle Clusterwareが実行中であることを確認し、次のコマンドでCRSCTLを使用し、OLRからIPMI構成データを削除します。
    $ crsctl unset css ipmiconfig
  4. rootとして次のコマンドを実行し、Oracle Clusterwareを再起動して、IPMI構成なしで実行するようにします。
    # crsctl stop crs
    # crsctl start crs

手動構成ネットワーク上のネットワーク・アドレスの理解

手動構成ネットワーク上のネットワーク・アドレスの概念および要件を理解することは役立ちます。

この項では、次の項目について説明します。

ネットワーク・アドレスの構成要件の理解

Oracle Clusterware構成には、少なくとも1つのパブリック・ネットワーク・インタフェースと1つのプライベート・ネットワーク・インタフェースが必要です。

  • パブリック・ネットワーク・インタフェースは、データベース・サーバー上のデータにアクセスするためにユーザーとアプリケーション・サーバーを接続します。

  • プライベート・ネットワーク・インタフェースはノード間の通信用で、Oracle Clusterwareによって排他的に使用されます。

パブリック・ネットワーク・インタフェースは、特定のネットワーク上のIPv4IPv6または両方のタイプのアドレスに対して構成できます。冗長なネットワーク・インタフェース(ボンディングまたはチーミングされたインタフェース)を使用する場合、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またはステートレス・アドレス自動構成が使用されているかを識別します。

この項には次のトピックが含まれます:

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です。

名前解決およびネットワーク・リソースのアドレス・タイプ

ネットワーク構成の確認には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サブネットの両方で構成されている場合、-nettypemixedに設定されていると両方のサブネットがサポートされません。

-nettypemixedに設定した場合、IPv4からIPv6への移行はサポートされません。最初にstaticからdhcpへの移行が完了してから、IPv6をサブネットに追加する必要があります。

同様に、-nettypemixedに設定した場合、IPv6からIPv4への移行の開始はサポートされません。最初にautoconfigからstaticへの移行が完了してから、IPv4をサブネットに追加する必要があります。

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アドレスの削除はサポートされていません

有効なノード・チェックにおけるSCANリスナーおよびサービス登録制限

有効なノード・チェックを使用して、SCANリスナーが登録を受け入れるノードおよびサブネットを指定できます。SRVCTLを使用してノードおよびサブネット情報を指定できます。

SRVCTLは、ノードおよびサブネット情報をSCANリスナー・プロファイルに格納します。SCANリスナー・エージェントは、リソース・プロファイルからその情報を読み出し、listener.oraファイルに書き込みます。

リスナーへのデータベース・インスタンスの登録は、リクエスト元が有効なノードである場合にのみ成功します。ネットワーク管理者は、有効なノードおよび除外ノードのリストを指定したり、有効なノードの確認を完全に無効にすることができます。有効なノードのリストでは、データベースに登録できるノードやサブネットを明示的にリストします。除外ノードのリストでは、データベースに登録できないノードを明示的にリストします。動的登録を制御することによって、Oracle RACデプロイメントの管理性およびセキュリティが向上します。

デフォルトでは、SCANリスナー・エージェントはREMOTE_ADDRESS_REGISTRATION_listener_nameをプライベートIPエンドポイントに設定します。SCANリスナーは、プライベート・ネットワークからの登録要求のみを受け入れます。SCANリスナーのプライベート・ネットワークにアクセスできないリモート・ノードは、listener.oraファイルのregistration_invited_nodes_aliasパラメータを使用して、またはコマンドライン・インタフェースのSRVCTLを使用してSCANリスナーを変更して、有効なノードのリストに含める必要があります。

ノート:

Oracle Grid Infrastructure 12c以降、SCANリスナーについて、VALID_NODE_CHECKING_REGISTRATION_listener_nameおよびREGISTRATION_INVITED_NODES_listener_nameパラメータがlistener.oraファイルに設定されている場合、リスナー・エージェントはこれらのパラメータを上書きします。

SRVCTLユーティリティを使用してinvitednodes値とinvitedsubnets値を設定すると、リスナー・エージェントは自動的にVALID_NODE_CHECKING_REGISTRATION_listener_nameをSUBNETに設定し、REGISTRATION_INVITED_NODES_listener_namelistener.oraファイルで指定されたリストに設定します。

CRSによって管理されるその他のリスナーの場合、リスナー・エージェントは、listener.oraファイルでまだ設定されていない場合にのみ、listener.oraファイルでVALID_NODE_CHECKING_REGISTRATION_listener_nameをSUBNETに設定します。SRVCTLユーティリティでは、SCAN以外のリスナーについてinvitednodes値とinvitedsubnets値の設定はサポートされていません。リスナー・エージェントは、SCAN以外のリスナーについてlistener.oraファイルのREGISTRATION_INVITED_NODES_listener_nameを更新しません。

共有単一クライアント・アクセス名の構成

共有単一クライアント・アクセス名(SCAN)により、専用クラスタと他のクラスタで、一連のSCAN仮想IP(VIP)とリスナーを共有できます。

共有単一クライアント・アクセス名の構成について

データベース・サーバーとデータベース・クライアントの両方で共有単一クライアント・アクセス名(SCAN)を構成する必要があります。

共有SCANを使用すると、クラスタごとにSCAN VIPセットをデプロイするのではなく、複数のクラスタでSCAN仮想IP(VIP)アドレスの単一共通セットを使用してユーザー接続を管理できます。たとえば、10のクラスタで、クラスタごとに3つのSCAN VIPをデプロイする場合、合計30のIPアドレスを使用しますが、共有SCANデプロイメントでは、それらの同じ10のクラスタに対して3つのSCAN VIPのみデプロイするため、必要なIPアドレスは3つのみです。

SCAN VIP(共有またはそれ以外)は、Oracle Real Application Cluster (Oracle RAC)データベース・クラスタに必要ですが、アプリケーション・メンバー・クラスタやドメイン・サービス・クラスタには必要ないので注意してください。

共有SCANを構成する一般的な手順として、最初にサーバー(つまり、共有SCANをホストするクラスタ)でsrvctlユーティリティを使用して構成を行い、次に、クライアント(この共有SCANを使用するOracle RACクラスタ)でこのユーティリティを使用して構成を行います。サーバーでは、srvctlを使用した構成に加えて、環境変数の設定、資格証明ファイルの作成すが必要であり、またSCANクラスタ固有のOracle Notification Service (ONS)プロセスが、ONS構成を作成および管理する専用の構成ディレクトリにアクセス可能であることを保証する必要もあります。

共有SCANの使用の構成

他の必要な構成タスクの実行に加えて、SRVCTLを使用して、専用クラスタをホストするサーバーで共有SCANを構成します。

  1. 共有SCANを構成するサーバー・クラスタにログインします。
  2. 次のように、この共有SCANクラスタ専用のSCANリスナーを作成します。
    $ srvctl add scan_listener -clientcluster cluster_name
  3. サーバー・クラスタに固有の新しいOracle Notification Service (ONS)リソースを作成します。
    $ srvctl add ons -clientcluster cluster_name
    srvctl add onsコマンドにより、SCANにIDを割り当てます。
  4. 次のようにSCANリスナーをクライアント・クラスタにエクスポートします。
    $ srvctl export scan_listener -clientcluster cluster_name -clientdata file_name
  5. 次のようにONSリソースをクライアント・クラスタにエクスポートします。
    $ srvctl export ons -clientcluster cluster_name -clientdata file_name

    ノート:

    SCANリスナーとONSの両方に同じ資格証明ファイル名を使用できます。これらのオブジェクトをクライアント・クラスタに追加すると、SRVCTLにより、使用する資格証明ファイルが作成されます。
  6. このサービスを使用する各クラスタで共有SCANを構成します。
    1. 共有SCANを構成するクライアント・クラスタにログインします。
    2. 次のようにクライアント・クラスタにSCANを追加します。
      $ srvctl add scan -clientdata file_name
    3. 次のように、このクライアント・クラスタ専用のSCANリスナーを作成します。
      $ srvctl add scan_listener -clientdata file_name
    4. 次のように、このクラスタのONSリソースを作成します。
      $ srvctl add ons -clientdata file_name

      ノート:

      前述の各コマンドでは、前のステップで作成した資格証明ファイルの名前を指定します。

手動構成システム上のネットワーク・アドレスの変更

手動構成システム上でネットワーク・アドレス・メンテナンスを実行できます。

これは、次のトピックで説明します。

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アドレスを変更するには、次のステップを実行します。

  1. 次のコマンド構文を使用して、変更するVIPアドレスのノードで実行されているすべてのサービスを停止します。database_nameはデータベースの名前、service_name_listは停止するサービスのリスト、およびmy_nodeは変更するVIPアドレスのノードの名前です。
    srvctl stop service -db database_name -service "service_name_list" -node node_name

    次の例では、-dbオプションでデータベース名(grid)を指定し、適切なノード(mynode)上のサービス(sales,oltp)を指定しています。

    $ srvctl stop service -db grid -service "sales,oltp" -node mynode
    
  2. srvctl config vipコマンドを実行して、VIPアドレスの現在のIPアドレスを確認します。このコマンドにより、ネットワーク・インタフェースの1つにバインドされた現在のVIPアドレスが表示されます。node03-vipという名前のVIPに構成されたVIPアドレスの例を次に示します。
    $ srvctl config vip -vipname node03-vip
    VIP exists: /node03-vip/192.168.2.20/255.255.255.0/eth0
    
  3. srvctl stop vipコマンドを使用してVIPリソースを停止します。
    $ srvctl stop vip -node node_name
  4. LinuxまたはUNIXシステムでifconfig -aコマンドを実行(Windowsシステムの場合はipconfig /allコマンドを発行)して、VIPリソースが実行されていないことを確認し、インタフェース(この例ではeth0:1)が出力に表示されていないことを確認します。
  5. LinuxおよびUNIXシステムではすべてのノードの/etc/hostsファイルに、Windowsシステムでは%windir%\system32\drivers\etc\hostsファイルに、必要なすべての変更を加え、DNSを適切に変更して、新しいIPアドレスを古いホスト名に関連付けます。
  6. VIPリソースを変更する前に、デフォルト・ネットワークに異なるサブネットまたはネットワーク・インタフェース・カードを使用するには、srvctl modify network -subnet subnet/netmask/interfaceコマンドをrootとして使用して、ネットワーク・リソースを変更する必要があります(subnetは新しいサブネット・アドレス、netmaskは新しいネットマスク、interfaceは新しいインタフェースです)。サブネットの変更後、次のステップで説明するとおり、各ノードのVIPを新しいサブネットのIPアドレスに変更する必要があります。
  7. 次のsrvctl modify nodeapps構文を使用して、ノード・アプリケーションを変更し、新しいVIPアドレスを指定します。
    $ srvctl modify nodeapps -node node_name -address new_vip_address

    コマンドには次のフラグおよび値が含まれます。

    • -n node_nameはノード名です。

    • -A new_vip_addressはノード・レベルのVIPアドレスで、次のようになります。name|ip/netmask/[if1[|if2|...]]

      たとえば、rootユーザーとして次のコマンドを実行します。

      # srvctl modify nodeapps -node mynode -address 192.168.2.125/255.255.255.0/eth0

      インストール所有者アカウントとしてこのコマンドを実行しようとすると、エラーが発生する場合があります。たとえば、インストール所有者がoracleの場合は、「PRCN-2018: 現在のユーザーoracleは、権限のあるユーザーではありません」というエラーが表示される可能性があります。このエラーを回避するには、rootまたはシステム管理者アカウントとしてコマンドを実行します。

  8. 次のようにして、srvctl start vipコマンドを実行し、ノードVIPを起動します。
    $ srvctl start vip -node node_name

    次のコマンドの例では、mynodeという名前のノードでVIPを起動します。

    $ srvctl start vip -node mynode
  9. クラスタ内の各ノードでこのステップを繰り返します。

    SRVCTLユーティリティはクラスタ全体の管理ツールであるため、各クラスタ・ノードにログインせずに、クラスタ内の任意のノードから特定のノードに対し、これらのタスクを完了することができます。

  10. 次のコマンドを実行して、クラスタが構成されているすべてのノード間の接続性を確認します。このコマンドは、クラスタ・ノード上で使用可能なすべてのネットワーク・インタフェースを検出し、検出されたインタフェースからすべてのノードへの接続性を確認します。また、ノードで使用可能な、VIPアドレスとしての使用に適したすべてのインタフェースを表示します。
    $ cluvfy comp nodecon -n all -verbose

Oracle Clusterwareのプライベート・ネットワーク構成の変更

Oracle Clusterwareプライベート・ネットワーク構成を変更できます。

この節では、以下のトピックについて説明します。

プライベート・ネットワークおよびネットワーク・インタフェースについて

Oracle Clusterwareでは、各ノードが、(パブリック・ネットワークに加えて)プライベート・ネットワークに接続されている必要があります。プライベート・ネットワーク接続は、クラスタ・インターコネクトとも呼ばれます。

表2-1に、ネットワーク・インタフェース・カードおよびプライベートIPアドレスがどのように格納されるかを示します。

すべてのノードが、同一のサブネットに接続された同一のネットワーク・インタフェース(oifcfgコマンドによりグローバル・インタフェースとして定義済)を使用しているクラスタのみをサポートしています。ノードごとに異なるネットワーク・インタフェース(ノード固有のインタフェース)を使用することはできません。

表2-1 ネットワーク・インタフェース、プライベートIPアドレスおよびプライベート・ホスト名の記憶域

エンティティ 格納先 コメント

ネットワーク・インタフェース名

オペレーティング・システム

たとえば、eth1など

ネットワーク・インタフェース名を指定する場合、ワイルドカードを使用できます。

たとえば、eth*など

プライベート・ネットワーク・インタフェース

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アドレスとして、「プライベート」ロールを指定したインタフェースの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アドレスの追加先として、数が最も小さいサブネットのインタフェースを選択します。

OIFCFGを使用したインタフェース名の変更結果

インタフェース名の変更結果は、どの名前を変更するか、またIPアドレスも変更するかどうかによって異なります。

インタフェース名のみを変更する場合、結果は、それほど重要ではありません。OCR内に格納されたパブリック・インタフェースの名前を変更する場合、クラスタのノード・アプリケーションも変更する必要があります。したがって、この変更を有効にするために、ノード・アプリケーションを停止する必要があります。

ネットワーク・インタフェースの変更

OIFCFGコマンドを使用して、ネットワーク・インタフェースおよびそれに関連するサブネット・アドレスを変更できます。

この手順では、Oracle ClusterwareおよびOracle Databaseが以前使用していたクラスタ内の各ノードで、ネットワーク・インタフェースおよびIPアドレスを変更します。

注意:

Oracle RAC(RDBMS)インターコネクトで使用されるインタフェースは、Oracle Clusterwareでホスト名に使用されるインタフェースと同じである必要があります。Oracle Clusterwareで監視されない別のインタフェースで、Oracle RACのプライベート・インターコネクトを構成しないでください。

  1. 次のコマンドを実行し、Oracle Clusterwareがすべてのクラスタ・ノードで実行されていることを確認します。
    $ olsnodes -s

    このコマンドでは、次のような出力が戻され、Oracle Clusterwareがクラスタ内のすべてのノードで実行されていることが表示されます。

    ./olsnodes -s
    myclustera Active
    myclusterc Active
    myclusterb Active
  2. 代替インタフェースが構成され、すべてのノードのオペレーティング・システムで操作可能であることを確認します。ご使用のプラットフォームのifconfigコマンド(Windowsではipconfig)を使用します。たとえば、Linuxでは次のように使用します。
    $ /sbin/ifconfig
  3. 次のコマンドを使用して、新しいインタフェースの名前およびサブネット・アドレスを指定して、新しいインタフェースをクラスタに追加します。
    $ 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

    ノート:

    従来型ネットワーク構成ではワイルドカードがサポートされないため、ワイルドカードは更新の時点で現行のノード構成を使用して解決されます。

  4. Oracle ASMネットワークを変更した場合は、次のようにしてOracle ASMリスナーを更新します。
    $ srvctl update listener -listener listener_name -asm -remove -force
    $ srvctl add listener -listener listener_name -asmlistener -subnet subnet
  5. 前のステップが完了したら、次のように、以前のインタフェースの名前およびサブネット・アドレスを指定して、以前のサブネットを削除できます。
    oifcfg delif -global if_name/subnet

    たとえば:

    $ oifcfg delif -global eth1/10.10.0.0

    注意:

    このステップは、代替インタフェースがグリッド・プラグ・アンド・プレイ構成に取り込まれた後でのみ実行する必要があります。有効な代替インタフェースを準備せずにクラスタのインタフェースを削除すると、無効なクラスタ構成になる可能性があります。

  6. 次のコマンドを使用して現行の構成を検証します。
    oifcfg getif

    たとえば:

    $ oifcfg getif
    eth2 10.220.52.0 global cluster_interconnect
    eth0 10.220.16.0 global public
  7. プライベート・ネットワークを変更した場合は、各ノードでrootとして次のコマンドを実行して、すべてのノードでOracle Clusterwareを停止します。
    # crsctl stop crs

    ノート:

    eth0およびeth1でHAIPを構成したときに、eth1をeth3に置換する場合、Oracle Clusterwareを停止する必要はありません。ただし、eth0とeth1をすでに構成しているHAIP構成に、インタフェースの別セット(eth2とeth3など)を追加する場合は、Oracle Clusterwareを停止する必要があります。

  8. Oracle Clusterwareが停止したら、ifconfigコマンドを使用して、削除したネットワーク・インタフェースをオペレーティング・システムで構成解除できます。たとえば:
    $ ifconfig down

    この時点で、ネットワーク・インタフェースからの古いサブネットのIPアドレスは、Oracle Clusterwareから構成解除されます。このコマンドは、オペレーティング・システムのIPアドレスの構成に影響しません。

    ifconfigによる変更は、永続的ではないため、オペレーティング・システムの構成変更を更新する必要があります。

  9. クラスタの各ノードでrootユーザーとして次のコマンドを実行し、Oracle Clusterwareを再起動します。
    # crsctl start crs

    変更は、Oracle Clusterwareの再起動時に有効になります。

    CLUSTER_INTERCONNECTS初期化パラメータを使用している場合は、変更を反映するためにそれを更新する必要があります。

SRVCTLを使用したネットワークの作成

SRVCTLを使用して、クラスタ・メンバー・ノードにネットワークを作成し、アプリケーション構成情報を追加します。

次のように、クラスタ・メンバー・ノード用のネットワークを作成します。

  1. rootとしてログインします。
  2. 次の構文を使用してノードにノード・アプリケーションを追加します。
    srvctl add nodeapps -node node_name -address {vip |
       addr}/netmask[/if1[|if2|...]] [-pingtarget "ping_target_list"]

    前の構文では:

    • node_nameはノードの名前です。

    • vipはVIP名で、addrはIPアドレスです。

    • netmaskはネットマスクです。

    • if1[|if2|...]は、アプリケーションで使用するために結合されたインタフェースの、パイプ文字(|)区切りのリストです

    • ping_target_listは、pingの対象のIPアドレスまたはホスト名のカンマ区切りリストです

    ノート:

    • リンク・ステータスの監視が仮想マシン環境と同様に機能しない場合は-pingtargetパラメータを使用します。

    • srvctl add nodeapps -helpコマンドを入力して、他の構文オプションを確認します。

    次の例では、srvctl add nodeappsを使用してIPv4ノード・アプリケーションを構成しており、ノード名はnode1で、ネットマスクは255.255.252.0で、インタフェースはeth0です。

    # srvctl add nodeapps -node node1 -address node1-vip.mycluster.example.com/255.255.252.0/eth0

クラスタ内のネットワーク・アドレス構成

IPv4、IPv6または指定されたネットワーク上での両タイプのアドレスのいずれかにネットワーク・インタフェースを構成できます。

サード・パーティーの技術を使用して冗長なネットワーク・インタフェースを構成する場合、Oracleでは、1つのインタフェースがIPv4アドレスをサポートし、別のインタフェースがIPv6アドレスをサポートするような構成はサポートしていません。冗長なインタフェースのネットワーク・インタフェースは、同じIPアドレス・タイプを使用して構成する必要があります。Oracle Clusterwareの冗長インターコネクト機能を使用する場合は、インタフェースにIPv4アドレスを使用する必要があります。

クラスタ内のすべてのノードには、同じIPプロトコル構成を使用する必要があります。すべてのノードがIPv4を使用するか、すべてのノードがIPv6を使用するか、すべてのノードがIPv4およびIPv6の両方を使用するかのいずれかです。クラスタ内の一部のノードがIPv6アドレスのみをサポートするように構成し、その他のノードがIPv4アドレスのみをサポートするように構成することはできません。

ローカル・リスナーは、ネットワーク・リソースに構成されたサブネットのアドレス・タイプに基づくエンドポイントでリスニングします。IPV4、IPV6または両方のタイプを使用できます。

SRVCTLを使用した、静的IPv4アドレスの静的IPv6アドレスへの変更

IPv4静的アドレスからIPv6静的アドレスに変更する場合は、静的IPv6アドレスのみを使用するように切り替える前に、IPv6アドレスを追加し、IPv4アドレスとIPv6アドレスの両方を短期間受け入れるようにネットワークを変更します。

ノート:

IPv4ネットワークが、静的および動的アドレスの両方が混合したモードである場合、この手順は実行できません。最初にすべてのアドレスを静的に移行する必要があります。

静的IPv4アドレスを静的IPv6アドレスに変更するには:

  1. ネットワーク全体に対して次のコマンドをrootとして一度使用してIPv6サブネットを追加します。
    # srvctl modify network -subnet ipv6_subnet/prefix_length

    前述の構文のipv6_subnet/prefix_lengthは、変更後のIPv6アドレスのサブネットと、接頭辞の長さです(3001::/64など)。

  2. 各ノードで、次のコマンドをrootとして使用してIPv6 VIPを一度追加します。
    # srvctl modify vip -node node_name -netnum network_number -address vip_name/netmask

    前の構文では:

    • node_nameはノードの名前です。

    • network_numberは、ネットワークの番号です。

    • vip_name/netmaskは、IPv4アドレスとIPv6アドレスの両方に解決されるローカルVIPの名前です

      VIP名の後に続くIPv4ネットマスクまたはIPv6の接頭辞の長さは、次の2つの要件を満たす必要があります。

      • ネットマスクをIPv4フォーマット(255.255.255.0など)で指定すると、VIP名はIPv4アドレスに解決されます(IPv6アドレスに解決することもできます)。同様に、IPv6の接頭辞の長さを指定すると(64など)、VIP名はIPv6アドレスに解決されます(IPv4アドレスに解決することもできます)。

      • IPv4ネットマスクを指定する場合は、ネットワークの-iptypeがIPv6であるかどうかに関係なく、登録されているIPv4ネットワーク・サブネット番号のネットマスクに一致する必要があります。同様に、IPv6の接頭辞の長さを指定する場合は、ネットワークの-iptypeがIPv4であるかどうかに関係なく、登録されているIPv6ネットワーク・サブネット番号の接頭辞の長さに一致する必要があります。

  3. 次のコマンドを使用してIPv6ネットワーク・リソースをOCRに追加します。
    $ oifcfg setif -global if_name/subnet:public
  4. IPv4アドレスと同じ数のIPv6アドレスを持つようDNSのSCANを更新します。ネットワーク全体に対して次のコマンドをrootとして一度使用して、IPv6アドレスをSCAN VIPに追加します。
    # srvctl modify scan -scanname scan_name

    scan_nameは、IPv4アドレスとIPv6アドレスの両方に解決するSCANの名前です。

  5. ネットワーク全体に対して次のコマンドをrootとして一度使用して、ネットワークIPタイプをIPv4から、IPv4とIPv6の両方に変換します。
    srvctl modify network -netnum network_number -iptype both

    このコマンドにより、IPv6静的アドレスが決定します。

  6. クラスタが提供するすべてのクライアントをIPv4のネットワークおよびアドレスからIPv6のネットワークおよびアドレスに変更します。
  7. 次のコマンドを使用して、ネットワークの使用プロトコルを、両方のプロトコルからIPv6のみに移行します。
    # srvctl modify network -iptype ipv6
  8. 次のコマンドをrootとして実行して、IPv6に解決するVIP名でVIPを変更します。
    # srvctl modify vip -node node_name -address vip_name -netnum network_number
    

    これを各ノードに一度実行します。

  9. 次のコマンドを実行して、IPv6に解決するSCAN名でSCANを変更します。
    # srvctl modify scan -scanname scan_name
    

    これをクラスタ全体に一度実行します。

SRVCTLを使用した、動的IPv4アドレスの動的IPv6アドレスへの変更

SRVCTLコマンドによって、動的IPv4アドレスを動的IPv6アドレスに変更します。

ノート:

IPv4ネットワークが、静的および動的アドレスの両方が混合したモードである場合、この手順は実行できません。最初にすべてのアドレスを動的に移行する必要があります。

動的IPv4アドレスを動的IPv6アドレスに変更するには:

  1. srvctl modify networkコマンドを使用してIPv6サブネットを追加します。

    IPv6サブネットを追加するには、rootとしてログインし、次のコマンド構文を使用します。

    # srvctl modify network -netnum network_number -subnet ipv6_subnet/
      ipv6_prefix_length[/interface] -nettype autoconfig

    前の構文では:

    • network_numberは、ネットワークの番号です。

    • ipv6_subnetは、変更先のIPv6アドレスのサブネットです(たとえば、2001:db8:122:344:c0:2:2100::)

    • ipv6_prefix_lengthは、IPv6ネットワーク・アドレスを指定する接頭辞です(たとえば、64)

    たとえば、次のコマンドは、IPv6サブネット(2001:db8:122:344:c0:2:2100::)および接頭辞長(64)を追加することで、ネットワーク3を変更します。

    # srvctl modify network -netnum 3 -subnet 2001:db8:122:344:c0:2:2100::/64
      -nettype autoconfig
  2. 次のコマンドを使用してIPv6ネットワーク・リソースをOCRに追加します。
    $ oifcfg setif -global if_name/subnet:public
  3. 次のように、IPv6動的アドレスを開始します。
    # srvctl modify network -netnum network_number -iptype both

    たとえば、ネットワーク番号が3の場合は次のようになります。

    # srvctl modify network -netnum 3 -iptype both
  4. クラスタが提供するすべてのクライアントをIPv4のネットワークおよびアドレスからIPv6のネットワークおよびアドレスに変更します。

    この時点で、GNSに委譲されたドメインscan_name.gns_domainのSCANは、3つのIPv4と3つのIPv6アドレスに解決されます。

  5. 次のコマンドを使用して、クラスタの動的アドレスのIPv4の部分を無効にします。
    # srvctl modify network -iptype ipv6

    前述のコマンドを実行した後は、SCAN (scan_name.gns_domain)は、3つのIPv6アドレスのみに解決されます。

関連トピック

IPv4ネットワークのIPv4およびIPv6ネットワークへの変更

IPv6ネットワークを既存のIPv4ネットワークに追加して、IPv4ネットワークをIPv4およびIPv6ネットワークに変更できます。

このプロセスは、SRVCTLを使用した、静的IPv4アドレスの静的IPv6アドレスへの変更のステップ1から5に説明されています。

これらのステップを完了した後、グリッド・ユーザーとしてログインし、次のコマンドを実行します。

$ srvctl status scan

出力を確認して、SCAN VIPの変更を確認します。

SRVCTLを使用した、VIPアドレスのIPv4からIPv6ネットワークへの移行

SRVCTLコマンドを使用して、結合されたIPv4およびIPv6ネットワークからIPv4アドレス・タイプを削除します。

次のコマンドを入力します。

# srvctl modify network -iptype ipv6

このコマンドにより、クラスタに構成されたIPv4アドレスの削除プロセスが開始されます。

クラスタ間依存性プロキシ

クラスタ間依存性プロキシは、ドメイン・サービス・クラスタでリソースを稼働させるための、メンバ・クラスタ上の軽量な耐障害性の高いプロキシ・リソースです。

メンバー・クラスタにより、インフラストラクチャ・リソース使用のオーバーヘッドが削減されるため、ドメイン・サービス・クラスタでは、Oracle Automatic Storage Management(Oracle ASM)などの共有インフラストラクチャ・リソースの状態を効率的に監視できるようにすることが重要です。これにより、メンバー・クラスタ上のリソースは、その状態を適切に調整できます。

クラスタ間依存性プロキシは、ドメイン・サービス・クラスタ・リソースにこの機能を提供します。具体的およびより一般的に言うと、一方のクラスタで稼働しているリソースの状態が、他方のクラスタに反映されます。ドメイン・サービス・クラスタでは、クラスタ間依存性プロキシがデフォルトで構成されます。