1. Clusterware管理およびデプロイメント・ガイド
  2. Oracle Clusterwareの構成と管理

2 Oracle Clusterwareの構成と管理

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

ノート:

Oracle Grid Infrastructure 23ai以降、Oracleクラスタ・ドメイン・アーキテクチャに含まれるドメイン・サービス・クラスタ(DSC)は非推奨になりました。

Oracleクラスタ・ドメインは、ドメイン・サービス・クラスタ(DSC)とメンバー・クラスタで構成されます。メンバー・クラスタは、Oracle Grid Infrastructure 19cで非推奨となりました。DSCは、引き続き、本番クラスタにサービスを提供するために使用可能です。ただし、それらのサービスの大部分ではホスティングにDSCを必要としなくなったため、DSCのインストールはOracle Database 23aiでサポートされなくなります。該当する場合、以前にDSCでホストされていたサービスに、任意のクラスタまたはシステムを使用することをお薦めします。Oracleでは、代替システムで各サービスを使用できるようになるまで、共有サービスをホストするためのDSCのサポートを継続します。

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

ノート:

ポリシー管理型のデータベース・デプロイメント・オプションは、Oracle Database 23aiではサポートされなくなりました。

ロール別管理

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

ロール別管理では、オペレーティング・システムのセキュリティとロール定義、およびユーザーのロールに従ってリソースとワークロード管理を分離するためのOracle Clusterwareアクセス権限を使用します。統合環境においては、コンピューティング・リソースの競合が存在する可能性があり、リソース・コンシューマおよびそれらのリソースの管理にはある程度の分離が必要となるため、このような統合環境で作業するユーザーにとっては特にこれが重要になります。デフォルトでは、この機能はインストール時に実装されません。

ロール別管理を構成する場合、意図されたロールに従って(データベースなどの)クラスタ・リソースを管理するオペレーティング・システムのユーザーおよびグループを設定し、必要に応じてクラスタ・リソースに対する権限を追加します。また、Oracle Automatic Storage Management (Oracle ASM)では、これらのロール別構造をストレージ管理機能にまで拡張できます。

Oracle Clusterwareのロール別管理は、現在はクラスタ管理者に依存していません(下位互換性は維持されています)。デフォルトでは、Oracle Grid Infrastructureホーム(Gridホーム)にOracle Clusterwareをインストールしたユーザーおよびrootは、永続的なクラスタ管理者となります。プライマリ・グループ権限(デフォルトではoinstall,)により、データベース管理者はOracle Database Configuration Assistant (Oracle DBCA)を使用してデータベースを作成できますが、ロール区分は有効になりません。

ロール区分の構成

ロール区分は、必要なロール、ロールが管理するリソースおよびロールのアクセス権限の決定です。

ロールを決定した後、ACLおよびCRSCTLユーティリティを使用して、グループ権限(oinstallやgridなど)用のオペレーティング・システム・ユーザー・アカウントを作成または変更できます。最も基本的には、2つのオペレーティング・システム・ユーザーをoinstallグループの一部として作成し、クラスタを作成します。

このことは、慎重に計画し、一貫性を維持しながら細部を重視して実行することが必要ですが、実装後、誤りの修正や時間の経過に伴う調整のために構成を変更できます。

ノート:

ロール別手法を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は権限を付与、-は権限を禁止)

クラスタ・リソースの場合、グループ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 Clusterwareでは、クラスタ環境のアドレス解決にグリッド・ネーミング・サービス(GNS)が使用されます。

ノート:

Oracle Grid Infrastructureのグリッド・ネーミング・サービス(GNS)の高可用性グリッド・ネーミング・サービス機能は、Oracle Database 23aiでは非推奨になりました。

高可用性GNSでは、マルチクラスタ環境における複数の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)のいずれかを使用します。

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

自動構成の場合、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機能を使用できます。ただし、ノードを追加したり変更する場合は、手動で管理タスクを実行する必要があります。

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

SRVCTLを使用して、クラスタ環境でグリッド・ネーミング・サービス(GNS)を管理します。

ノート:

Oracle Grid Infrastructureのグリッド・ネーミング・サービス(GNS)の高可用性グリッド・ネーミング・サービス機能は、Oracle Database 23aiでは非推奨になりました。

高可用性GNSでは、マルチクラスタ環境における複数のGNSインスタンスを様々なロールで実行できます。この機能は非推奨になります。これに替わる機能はありません。

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

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

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

# srvctl start gns
# srvctl stop 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)としてログインし、次の構成検証ユーティリティを使用して、クラスタを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 -allnodes
  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

関連トピック

ノード障害分離

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

ノート:

IPMIドライバは、すべてのクラスタ・ノードで構成するか、まったく構成しないかのいずれかにする必要があります。

障害が発生したノードの分離には、Oracle Clusterwareやそのノードで実行されているオペレーティング・システムとの連携なく問題のノードを再起動できる外部メカニズムが関与します。この機能を提供するために、Oracle Clusterwareでは、業界標準の管理プロトコルであるIntelligent Platform Management Interface仕様(IPMI)(Baseboard Management Controller (BMC)とも呼ばれる)がサポートされています。

通常、IPMIを使用する障害分離は、Oracle Grid Infrastructureのインストール時の「障害の分離のサポート」画面でIPMI構成のオプションが提示されたときに構成します。インストール中にIPMIを構成しない場合は、インストール後にOracle Clusterware Controlユーティリティ(CRSCTL)を使用して構成できます(後続の項を参照)。

障害分離用にIPMIを使用するには、各クラスタ・メンバー・ノードに、IPMIバージョン2.0(Local Area Network (LAN)を介してIPMIがサポートされます)に対応するファームウェアが動作するIPMIデバイスを装備する必要があります。BMCに加えて、各ノードにipmitoolまたはipmiutilがインストールされている必要があります。ipmiutilユーティリティは、Oracle Grid Infrastructureインストールとともに配布されないため、ダウンロードする必要があります。ipmiutilは、ipmiutil.sourceforge.netまたは他のリポジトリからダウンロードできます。必要なipmiutilユーティリティの最小バージョンは、3.08です。バージョン番号はヘルプ・プロンプトでも表示されますが、ipmiutilの実行によっても表示できます。

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デバイスを構成するにはドライバが必要ですが、一部のプラットフォームでは管理コンソールを使用してこれを行うこともできます。

関連トピック

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

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

ノート:

IPMIドライバは、すべてのクラスタ・ノードで構成するか、まったく構成しないかのいずれかにする必要があります。

関連トピック

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

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

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

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

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

サーバーの構成、およびipmitoolまたはipmiutilバイナリの場所の構成が完了した後、各クラスタ・ノードで次の手順を実行し、ノードに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を使用して各ノード上のipmitoolまたはipmiutilバイナリの場所を設定します。

    たとえば:

    crsctl set ipmi binaryloc /usr/bin/ipmitool

    crsctl set ipmi binaryloc /usr/bin/ipmiutil

    ノート:

    バイナリ名は、ipmitoolまたはipmiutilで終わる必要があります。
  3. CRSCTLを使用して、crsctl set css ipmiadminコマンドを実行し、プロンプトにパスワードを指定することで、装備されているIPMI用に以前に作成したユーザーIDおよびパスワードをOLRに格納します。たとえば:
    crsctl set css ipmiadmin administrator_name
IPMI BMC password: password

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

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

    インストールを開始する前に、ipmitoolまたは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 Grid Infrastructureインストールの所有者アカウント(グリッド・ユーザー)によって書き込まれる必要があるため、このインストールのユーザーとしてログインする必要があります。

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

  1. ipmitoolまたはipmiutilバイナリ・ファイルの場所が変更されている場合は、そのバイナリ・ファイルの場所を設定します。たとえば:
    $ crsctl set ipmi binaryloc /usr/bin/ipmitool
$ crsctl set ipmi binaryloc /usr/bin/ipmiutil

    IPMI構成を変更するその他のCRSCTLコマンドを実行する前に、そのバイナリの場所が変更されているすべてのノードで、crsctl set ipmi binarylocコマンドを実行する必要があります。

    ノート:

    バイナリ名は、ipmitoolまたはipmiutilで終わる必要があります。
  2. crsctl set css ipmiadmin administrator_nameコマンドを入力します。たとえば、ユーザーIPMIadmの場合は、次のようになります。
    $ crsctl set css ipmiadmin IPMIadm

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

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

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

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

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

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

  5. 次のように、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によって排他的に使用されます。

パブリック・ネットワーク・インタフェースは、特定のネットワーク上の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またはステートレス・アドレス自動構成が使用されているかを識別します。

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

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

同様に、-nettypeをmixedに設定した場合、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インスタンスは、リモート・リスナーとしてSCANリスナーにのみ登録されます。アップグレードしたデータベースは、リモート・リスナーとしてSCANリスナーに登録されるとともに、引き続きすべてのノード・リスナーにも登録されています。

ノート:

インストール時にSCAN名を指定するというOracle Grid Infrastructureのインストール要件により、サーバーの/etc/hostsファイルを使用して1つ以上のIPアドレスを解決してこのインストール要件を回避し、SCANに必要なインフラストラクチャがない場合は、インストール後、SCANを無視し、VIPを使用してクラスタ内のデータベースに接続できます。

Oracleでは、SCANアドレスの削除はサポートされていません。

関連トピック

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

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

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_nameをlistener.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)を構成する必要があります。

ノート:

Oracle Grid Infrastructure 23ai以降、Oracleクラスタ・ドメイン・アーキテクチャに含まれるドメイン・サービス・クラスタ(DSC)は非推奨になりました。

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

Oracle Real Application Cluster (Oracle RAC)データベース・クラスタにはSCAN VIP (共有またはそれ以外)が必要であることに注意してください。

共有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 -allnodes -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ソフトウェア(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

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

  10. 前のステップが完了したら、次のように名前およびサブネット・アドレスを指定して、静的IPv4アドレスを削除できます:
    oifcfg delif -global if_name/subnet
    たとえば: 
    $ oifcfg delif -global eth1/10.10.0.0

関連トピック

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アドレスのみに解決されます。

  6. 前のステップが完了したら、次のように名前およびサブネット・アドレスを指定して、静的IPv4アドレスを削除できます:
    oifcfg delif -global if_name/subnet
    たとえば: 
    $ oifcfg delif -global eth1/10.10.0.0

関連トピック

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アドレスの削除プロセスが開始されます。