ヘッダーをスキップ
Oracle® Clusterware管理およびデプロイメント・ガイド
12c リリース1 (12.1)
B71322-02
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

2 Oracle Clusterwareの管理

この章では、Oracle Clusterwareの管理方法について説明します。内容は次のとおりです。

ロール別管理

この項の内容は次のとおりです。

ロール別管理について

ロール別管理は、必要に応じてリソースへのアクセスを提供したり制限するために、ユーザーが実装できる機能であり、サーバー・プールまたはリソースに対する権限を設定することで、複数のアプリケーションおよびデータベースが、同じクラスタ・リソースおよびハードウェア・リソースを協調的に共有できるようになります。デフォルトでは、この機能はインストール時に実装されません。

次の2つの方法のいずれかで、ロール別管理を実装できます。

  • 垂直実装(レイヤー間)は、技術スタック内の様々なレイヤーで使用される異なるオペレーティング・システム・ユーザーおよびグループに基づいたロール区分手法です。サーバー・プールおよびリソースに対する権限は、アクセス制御リストを使用して、スタック内の各レイヤーの異なるユーザー(およびグループ)に付与されます。Oracle Automatic Storage Management(ASM)でのロール区分の設定は、Oracle Grid Infrastructureのインストールの一部として、特定のロールのオペレーティング・システム・グループの細かい割当てに基づいて提供されます。

  • 水平実装(1つのレイヤー内)は、サーバー・プールおよびポリシー管理データベースまたはアプリケーションに割り当てられたアクセス制御リストを使用して付与されるリソースに対するアクセス権限を使用して、1つのレイヤー内のリソース・アクセスを制限するロール区分手法です。

たとえば、Oracle Grid Infrastructureのインストールおよび2つのデータベース・サーバー・プールの作成を実行するための、gridという名前のオペレーティング・システム・ユーザーと、プライマリ・オペレーティング・システム・グループoinstallを検討します。オペレーティング・システム・ユーザーouser1およびouser2は、サーバー・プール内で操作できる必要がありますが、サーバー・プールを変更できないようにして、他のサーバー・プールからハードウェア・リソースを誤って、または意図的に除去されないようにします。

各ポリシー・セットを構成して、データベース・ソフトウェアおよびデータベースを配備する前に、サーバー・プールを構成できます。


関連項目:

詳細は、「クラスタ構成ポリシーおよびポリシー・セットの概要」を参照してください。

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


注意:

クラスタに最初にサーバー・プールを作成する前にロール区分を有効にすることをお薦めします。構成ポリシーおよび各ポリシー・セットを使用してサーバー・プールを作成および管理します。各サーバー・プールのアクセス権限はACL属性に格納されますが、これについては表3-1「サーバー・プール属性」を参照してください。

クラスタ内のクラスタ管理者の管理

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

原則として、サーバー・プールを作成する権限を持つには、オペレーティング・システム・ユーザー、またはそのユーザーがメンバーとして属するオペレーティング・システム・グループの読取り、書込みおよび実行権限がACL属性に設定されている必要があります。crsctl modify policyset –attr "ACL=value"コマンドを使用して、オペレーティング・システム・ユーザーおよびグループの権限を追加したり削除します。

水平ロール区分の構成

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::---

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

アドレス解決にグリッド・ネーミング・サービス(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エントリを示しています。

例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におけるネットワーク・ドメインおよび委譲に関する詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

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アドレスを他のクラスタにフェイルオーバーしません。フェイルオーバーは、同じクラスタのメンバーのみに実行されます。


関連項目:

Oracle Flex ClusterおよびGNSの詳細は、第4章「Oracle Flex Cluster」を参照してください。

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

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

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

アドレスの共有GNSオプション

動的な構成の場合、GNSを構成して、あるクラスタに名前解決をしたり、複数のクラスタに名前をアドバタイズできるため、単一のGNSインスタンスで、登録された複数のクラスタに対して名前解決を実行できます。このオプションは共有GNSと呼ばれます。


注意:

GNSが提供するクラスタのセット内のすべてのノード名は一意である必要があります。

共有GNSは標準的なGNSと同じサービスを提供し、名前解決を受け取るクライアント側でも同様に表示されます。相違点は、1つのクラスタで動作するGNSデーモンは、GNSに名前解決を委譲したドメイン内のすべてのクラスタに対して名前解決を提供するように構成される点、およびGNSをSRVCTLコマンドを使用して一元的に管理できる点です。共有GNS構成を使用すると、Oracle Grid Infrastructureクラスタのエンタープライズ全体に対するネットワーク管理者タスクを最小限に抑えることができます。

マルチクラスタ環境でのアドレス解決に共有GNSを使用するクラスタでは、静的なアドレス構成は使用できません。共有GNSには自動アドレス構成が必要であり、DHCPまたはIPv6ステートレス・アドレス自動構成のいずれかによって割り当てられるアドレスを使用します。

Oracle Universal Installerを使用すると、共有GNSクライアントまたはサーバーのGNSを使用して、あるいは検出に使用するGNSを使用して、静的アドレスを構成できます。

構成ウィザードを使用したOracle Grid Infrastructureの構成

Oracle Grid Infrastructureのソフトウェアのみのインストールを実行した後、構成ウィザードを使用してソフトウェアを構成できます。このウィザードでは、crsconfig_params構成ファイルを簡単に編集できます。構成ウィザードでは、Oracle Grid Infrastructureのインストーラと同様に、ユーザーがウィザードで操作を行う前後にグリッド・ホームと入力の様々な検証が実行されます。

構成ウィザードでは、1つ以上のノードに新しいOracle Grid Infrastructureを構成するか、またはアップグレードされたOracle Grid Infrastructureを構成することができます。また、構成ウィザードはサイレント・モードでも実行できます。


注意:

  • 構成ウィザードを実行する前に、Oracle Grid Infrastructureホームがカレントであり、必要なすべてのパッチが適用されていることを確認します。

  • 以降の手順で構成ウィザードを起動する場合は、次のようにします。

    LinuxおよびUNIXの場合は、次のコマンドを実行します。

    Oracle_home/crs/config/config.sh
    

    Windowsの場合は、次のコマンドを実行します。

    Oracle_home\crs\config\config.bat
    

この項の内容は次のとおりです。

単一ノードの構成

構成ウィザードを使用して単一ノードを構成するには、次の手順を実行します。

  1. 次のように、構成ウィザードを起動します。

    $ Oracle_home/crs/config/config.sh
    
  2. 「インストール・オプションの選択」ページで、「クラスタ用のOracle Grid Infrastructureの構成」を選択します。

  3. 「クラスタ・ノードの情報」ページで、ローカル・ノードと、それに対応するVIP名のみを選択します。

  4. 残りのウィザード・ページで、引き続き情報を追加します。

  5. 「サマリー」ページで入力を確認して、「終了」をクリックします。

  6. 構成ウィザードの指示に従って、root.shスクリプトを実行します。

複数ノードの構成

構成ウィザードを使用して複数ノードを構成するには、次の手順を実行します。

  1. 次のように、構成ウィザードを起動します。

    $ Oracle_home/crs/config/config.sh
    
  2. 「インストール・オプションの選択」ページで、「クラスタ用のOracle Grid Infrastructureの構成」を選択します。

  3. 「クラスタ・ノードの情報」ページで、構成するノードと、それに対応するVIP名を選択します。構成ウィザードは、選択されたノードを検証し、その準備が整っていることを確認します。

  4. 残りのウィザード・ページで、引き続き情報を追加します。

  5. 「サマリー」ページで入力を確認して、「終了」をクリックします。

  6. 構成ウィザードの指示に従って、root.shスクリプトを実行します。

Oracle Grid Infrastructureのアップグレード

構成ウィザードを使用して、クラスタのOracle Grid Infrastructureをアップグレードする手順は次のとおりです。

  1. 構成ウィザードを起動します。

    $ Oracle_home/crs/config/config.sh
    
  2. 「インストール・オプションの選択」ページで、「Oracle Grid Infrastructureのアップグレード」を選択します。

  3. 「Oracle Grid Infrastructureノードの選択」ページで、アップグレードするノードを選択します。

  4. 残りのウィザード・ページで、引き続き情報を追加します。

  5. 「サマリー」ページで入力を確認して、「終了」をクリックします。

  6. 構成ウィザードの指示に従って、rootupgrade.shスクリプトを実行します。


注意:

Oracle Restartは、構成ウィザードを使用してアップグレードできません。


関連項目:

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

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

構成ウィザードをサイレント・モードで使用してノードを構成またはアップグレードするには、コマンドラインで-silent -responseFile file_nameを指定して構成ウィザードを起動します。ウィザードは、レスポンス・ファイルを検証して構成を行います。レスポンス・ファイルで無効な入力を検出すると、構成ウィザードはエラーを表示して終了します。指示に従って、rootおよびconfigToolAllCommandsスクリプトを実行します。

障害分離のためのIPMIの構成

この項の内容は次のとおりです。

障害分離のためのIPMIの使用について

障害分離は、障害が発生したノードをクラスタの残りのノードから分離させ、障害が発生したノードでデータが失われるのを防ぐプロセスです。理想的なフェンシングには、Oracle Clusterwareまたはそのノードで実行されているオペレーティング・システムとの連携がなくても問題のノードを再起動できる外部メカニズムが含まれます。この機能を提供するために、Oracle Clusterware 12cでは、業界標準の管理プロトコルであるIntelligent Platform Management Interface仕様(IPMI)(Baseboard Management Controller(BMC)とも呼ばれる)をサポートしています。

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

障害分離用にIPMIを使用するには、各クラスタ・メンバー・ノードに、IPMIバージョン1.5(Local Area Network (LAN)を介してIPMIがサポートされます)に対応するファームウェアが動作するIPMIデバイスを装備する必要があります。データベースの操作中、障害分離は、削除を行うクラスタ同期サービス・デーモンから障害が発生したノードのIPMIデバイスへのLANを介した通信によって行われます。IPMI-over-LANプロトコルは、インストール時に管理者から取得したユーザー名およびパスワードで保護される認証セッションに引き継がれます。

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

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

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

IPMIドライバをインストールして有効にし、IPMIデバイスを構成します(ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照)。

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

この項の内容は次のとおりです。

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

Oracle Clusterwareのインストール時にIPMIをインストールする場合は、障害分離を2つのフェーズで構成します。インストールを開始する前に、サーバー・オペレーティング・システムに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ベースの障害分離は完全に機能します。

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

既存のIPMIベースの障害分離構成を変更するには(IPMIパスワードを変更したり、既存のインストールで障害分離用にIPMIを構成する場合など)、ご使用のプラットフォームに適したIPMI構成ツールでCRSCTLを使用します。たとえば、IPMIの管理者パスワードを変更するには、まず『Oracle Grid Infrastructureインストレーション・ガイド』で説明しているようにIMPI構成を変更してから、CRSCTLを使用してOLR内のパスワードを変更します。

Oracle Clusterwareで必要なIPMIの構成データはOCRの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コマンドの詳細は、「Oracle RAC環境のCRSCTLコマンド」を参照してください。

CRSCTLを使用したIPMI構成の削除

IPMIの使用を完全に停止する場合、またはIPMIの最初の構成がOracle Clusterwareをインストールしたユーザー以外のユーザーによって行なわれていた場合は、CRSCTLを使用してクラスタからIPMI構成を削除できます。後者に該当する場合、Oracle ClusterwareはIPMI構成データにアクセスできず、Oracle ClusterwareソフトウェアはIPMIを使用できないため、Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成する必要があります。

IPMIを完全に削除するには、次の手順を実行します。Oracle ClusterwareをインストールしたユーザーとしてIPMIを再構成するには、手順3および4を実行し、「CRSCTLを使用したIPMI構成の変更」の手順2および3を繰り返します。

  1. 次のように、IPMIドライバを無効にして、起動時のインストールを回避します。

    /sbin/modprobe –r
    

    関連項目:

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

  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構成には次の2つ以上のインタフェースが必要です。

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

  • ノード間の通信用のプライベート・ネットワーク・インタフェース

IPv4IPv6または指定されたネットワーク上での両タイプのアドレスのいずれかにネットワーク・インタフェースを構成できます。冗長なネットワーク・インタフェース(ボンディングまたはチーミングされたインタフェース)を使用する場合、Oracleでは、1つのインタフェースがIPv4アドレスをサポートしていますが、別のインタフェースがIPv6アドレスをサポートするような構成はサポートしていないので注意してください。冗長なインタフェースのネットワーク・インタフェースは、同じIPプロトコルを使用して構成する必要があります。

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

VIPエージェントは、ステートレス・アドレス自動構成(RFC 2462)を使用したIPv6の生成をサポートしており、これらのアドレスをGNSでアドバタイズします。srvctl config networkコマンドを実行して、DHCPまたはステートレス・アドレス自動構成が使用されているかを識別します。

この項の内容は次のとおりです。

IPv6アドレスのフォーマットについて

Oracle RACクラスタの各ノードは、同じネットワーク上のIPv4およびIPv6アドレスの両方をサポートできます。推奨されるIPv6アドレス書式は次のとおりです(各xは、16進文字を表します)。

xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

IPv6アドレス・フォーマットはRFC 2460で定義されています。Oracle RACがサポートする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 status 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を同時に使用できます。


注意:

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

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



関連項目:


SCANアドレスおよびクライアント・サービス接続の理解

パブリック・ネットワーク・アドレスはクライアントにサービスを提供するために使用します。クライアントで単一クライアント・アクセス名(SCAN)アドレスに接続している場合は、クラスタに対してノードを追加または削除する際にパブリックおよび仮想IPアドレスを変更する必要がある場合がありますが、クライアントを新しいクラスタ・アドレスで更新する必要はありません。


注意:

listener.oraファイルを編集して、SCANおよびノード・リスナーのOracle Netリスナー・パラメータを変更できます。たとえば、TRACE_LEVEL_listener_nameを設定できます。ただし、リスナー・エージェントは動的にリスナー・エンドポイントを管理するため、プロトコル・アドレス・パラメータを設定して、リスニング・エンドポイントを定義することはできません。


関連項目:

listener.oraファイルの編集の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

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 11g リリース2 (11.2)より前のOracle RACリリースでは、SCANリスナーを使用せず、ローカル・リスナーおよびREMOTE_LISTENERS初期化パラメータで定義されたリスナーを使用してサービスの登録を試行します。これらのデータベース・インスタンスでのサービス登録をサポートするには、Oracle RAC 12cのローカル・リスナーのvalid_node_check_for_registration_aliasのデフォルトの値をローカル・ノードではなく、SUBNETに設定します。ノード・リスナーに対する有効なノード・チェックの設定を変更するには、listener.oraファイルを変更します。

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,...コマンドも実行する必要があります。


関連項目:

  • 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』srvctl add scan_listenersrvctl modify nodeappsおよびsvrctl modify scan_listenerコマンド

  • 『Oracle Database Net Services管理者ガイド』


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

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

この項の内容は次のとおりです。


注意:

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


関連項目:

この項で説明する手順で使用されるSRVCTLコマンドの使い方については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

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

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

# srvctl start gns
# srvctl stop gns

注意:

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

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

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

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

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

GNSを実行していないクラスタをGNSサーバー・クラスタに変換するには、rootとして次のコマンドを実行し、有効なIPアドレスおよびドメインを提供します。

# srvctl add gns -vip IP_address -domain domain

注意:

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

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

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


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

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

  1. rootとしてログインし、サーバー・クラスタで次のコマンドを実行して、GNSインスタンス・クライアント・データ構成をファイルにエクスポートします。

    # srvctl export gns -clientdata path_to_file
    

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


    注意:

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

  2. 次のコマンドをrootとして実行して、前述の手順で作成したファイルをクラスタ内のノードにインポートして、そのクラスタをクライアント・クラスタにします。

    # srvctl add gns -clientdata path_to_file
    

    注意:

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

GNSを実行しているシングル・クラスタのサーバー・クラスタへの変換

GNSを実行しているシングル・クラスタをGNSサーバー・クラスタに変換するためには、何もする必要がありません。クライアント・クラスタが追加されると、自動的にサーバー・クラスタであるとみなされます。

GNSを実行しているシングル・クラスタのGNSクライアント・クラスタへの変換

この変換が処理されている間、現在のGNSに接続した状態を維持する必要があるため、手順は、単一のクラスタをサーバー・クラスタに変換する場合の手順よりも複雑になります。

  1. GNSクライアント情報をファイルにエクスポートするには、サーバー・クラスタでrootとして次のコマンドを実行します。

    # srvctl export gns -clientdata path_to_client_data_file
    

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

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

    # srvctl stop gns
    

    注意:

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

  3. GNSインスタンスをエクスポートするには、サーバー・クラスタでrootとして次のコマンドを実行します。

    # srvctl export gns -instance path_to_file
    

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

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

    # srvctl import gns -instance path_to_file
    

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

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

    # srvctl start gns -node path_to_file
    

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

  6. 次のコマンドを使用してGNSクライアント・クラスタからGNSを削除します。

    # srvctl remove gns
    
  7. 次のように、前のクラスタをクライアント・クラスタにします。

    # srvctl add gns -clientdata path_to_client_data_file
    

    注意:

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

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


注意:

この手順には、サーバー・クラスタおよびクライアント・クラスタのダウンタイムが必要です。また、GNSクライアント・データを新しいサーバー・クラスタからOracle Flex ASMおよびGridホーム・サーバーまたはクライアントにインポートする必要があります。

クラスタ障害または管理計画のいずれかが理由で、別のクラスタを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
    

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

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

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


関連項目:

GNSを構成する事前インストール手順を実行するには、ご使用のプラットフォームの『Oracle Grid Infrastructureのインストレーション・ガイド』を参照してください。

  1. グリッド・ユーザー(grid)としてログインし、次のCluster Verification Utilityを使用して、クラスタをGNSに移動させるためのステータスを確認します(ここで、nodelistは、クラスタ・メンバー・ノードのカンマ区切りのリストです)。

    $ cluvfy stage –pre crsinst –n nodelist
    
  2. rootユーザーとしてログインし、次のSRVCTLコマンドを使用してGNSリソースを構成します(ここで、domainは、ネットワーク管理者が解決をGNSに委譲するよう構成したドメインで、vip_nameは、GNS仮想IPアドレス(GNS VIP)の名前です)。

    # srvctl add gns -domain domain_name -vip vip_name
    
  3. GNSを起動するには、次のコマンドを使用します。

    # srvctl start gns
    

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

  4. グリッド・ユーザーとして、次のコマンドを使用してGNS構成の整合性を確認します(ここで、domainは、解決をGNSに委譲されるドメインで、gns_vipはGNS VIPです)。

    $ cluvfy comp gns -precrsinst -domain domain -vip gns_vip
    
  5. 静的およびDHCPネットワーク・アドレスが混在するモードをサポートするために、rootとして、次のコマンドを使用してネットワークCRSリソースを変更します。

    # srvctl modify network -nettype MIXED
    

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

  6. グリッド・ユーザーとして、登録されたSCANを変更し、新しく取得したSCAN VIPの動的アドレスを使用します。

    $ srvctl update scan_listener
    
  7. グリッド・ユーザーとして、データベース・リスナーのリスナー・エンドポイントの再検出を開始します。

    $ srvctl update listener
    
  8. グリッド・ユーザーとして、各データベースに次のコマンドを一度実行して、データベース・エンドポイントを更新します(ここで、db_unique_nameは、クラスタのデータベースの名前です)。

    $ srvctl update database -db db_unique_name
    
  9. Oracle RACデータベースのOSDBAグループのメンバーとして、SQLにログインし、次のコマンドを使用してリモート・データベース・リスナー・エンドポイントを変更します。

    SQL> alter database set remote_listener=["scan_name:scan_port"];
    

    関連項目:

    詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

  10. グリッド・ユーザーとして、次のコマンドを入力して、Oracle Clusterwareが新しいGNS、動的アドレスおよびリスナー・エンドポイントを使用していることを確認します。

    cluvfy stage -post crsinst -n all
    
  11. 検証が正常に終了した後、GNSで解決されるSCANおよびVIPを使用するために、DNSで解決されるSCANまたはVIPを以前に使用したリモート・エンドポイントを変更します。

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

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

  12. rootとして次のコマンドを入力して、システムを新しいネットワークに更新し、静的なアドレスを削除して動的なアドレスのみが使用されるようにします。

    # srvctl modify network -nettype DHCP
    # srvctl update database -db db_unique_name
    # srvctl update scan_listener
    # srvctl update listener
    # srvctl modify scan -scanname scan_name
    

    srvctl update database -db db_unique_nameコマンドは、必要に応じて、クラスタで実行されている各データベースに対して繰り返されます(db_unique_nameは、クラスタ内のデータベース名です)。

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

この項の内容は次のとおりです。

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ネットワークを作成するだけです。


関連項目:

srvctl add networkコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。


注意:

次の説明は、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: Current user oracle is not a privileged user」が表示される場合があります。このエラーを回避するには、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では、各ノードが、(パブリック・ネットワークに加えて)プライベート・ネットワークに接続されている必要があります。プライベート・ネットワーク接続は、クラスタ・インターコネクトとも呼ばれます。表2-1に、ネットワーク・インタフェース・カードおよびプライベートIPアドレスがどのように格納されるかを示します。

すべてのノードが、同一のサブネットに接続された同一のネットワーク・インタフェース(oifcfgコマンドによりグローバル・インタフェースとして定義済)を使用しているクラスタのみをサポートしています。ノードごとに異なるネットワーク・インタフェース(ノード固有のインタフェース)を使用することはできません。グローバル・インタフェースおよびノード固有のインタフェースの詳細は、付録D「Oracle Interface Configurationツール(OIFCFG)のコマンド・リファレンス」を参照してください。

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

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

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

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

たとえば、eth1など。

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

たとえば、eth*など。

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

Oracle Clusterwareのグリッド・プラグ・アンド・プレイ(GPnP)・プロファイル内

インストール時にインタフェースを「プライベート」とすることによって、使用するインタフェースをプライベート・インタフェースとして構成するか、oifcfg setifコマンドを使用して、インタフェースをプライベート・インタフェースに指定します。

関連項目: oifcfg setifコマンドの詳細は、「OIFCFGコマンド」を参照してください。


冗長なインターコネクトの使用

インストール時、またはインストール後に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アドレスの追加先として、数が最も小さいサブネットのインタフェースを選択します。



関連項目:

インタフェースの定義については、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

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

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


関連項目:

新しいパブリック・インタフェース名を使用するためのノード・アプリケーションの変更の詳細は、My Oracle Support(以前のOracleMetaLink)のNote 276434.1を参照してください。次のURLから入手できます。
https://metalink.oracle.com

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

次の手順を実行して、ネットワーク・インタフェースおよびそれに関連するサブネット・アドレスを変更できます。クラスタのすべてのノードでこの変更を実行する必要があります。

この手順では、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
    

    注意:

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


    関連項目:

    OIFCFGコマンドの使用方法の詳細は、付録D「Oracle Interface Configurationツール(OIFCFG)のコマンド・リファレンス」を参照してください。

  4. 前の手順が完了したら、次のように、以前のインタフェースの名前およびサブネット・アドレスを指定して、以前のサブネットを削除できます。

    oifcfg delif -global if_name/subnet
    

    次に例を示します。

    $ oifcfg delif -global eth1/10.10.0.0
    

    注意:

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

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

    oifcfg getif
    

    次に例を示します。

    $ oifcfg getif
    eth2 10.220.52.0 global cluster_interconnect
    eth0 10.220.16.0 global public
    
  6. rootとして、各ノードで次のコマンドを実行し、すべてのノードのOracle Clusterwareを停止します。

    # crsctl stop crs
    

    注意:

    クラスタのネットワーク構成が変更される場合、クラスタを完全に停止する必要があります。ローリング停止および再起動を使用しないでください。

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

    $ ifconfig down
    

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

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

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

    # crsctl start crs
    

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

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

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

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

  1. rootとしてログインします。

  2. 次の構文を使用してノードにノード・アプリケーションを追加します。

    srvctl add nodeapps -node node_name -address {vip |
       addr}/netmask[/if1[|if2|...]]
    

    前述の構文の各要素は次のとおりです。

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

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

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

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


    注意:

    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
    

関連項目:

この手順で使用されているSRVCTLコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

SRVCTLを使用したネットワーク・アドレス・タイプの変更

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

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

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

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


注意:

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

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

静的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. IPv4アドレスと同じ数のIPv6アドレスを持つようDNSのSCANを更新します。ネットワーク全体に対して次のコマンドをrootとして一度使用して、IPv6アドレスをSCAN VIPに追加します。

    # srvctl modify scan -scanname scan_name
    

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

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

    srvctl modify network -netnum network_number -iptype both
    

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

  5. クラスタが提供するすべてのクライアントをIPv4のネットワークおよびアドレスからIPv6のネットワークおよびアドレスに変更します。

  6. 次のコマンドを使用して、ネットワークの使用プロトコルを、両方のプロトコルからIPv6のみに移行します。

    # srvctl modify network -iptype ipv6
    
  7. 次のコマンドをrootとして実行して、IPv6に解決するVIP名でVIPを変更します。

    # srvctl modify vip -node node_name -address vip_name -netnum network_number
    

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

  8. 次のコマンドを実行して、IPv6に解決するSCAN名でSCANを変更します。

    $ srvctl modify scan -scanname scan_name
    

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


関連項目:

この手順で使用されているSRVCTLコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

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動的アドレスを開始します。

    srvctl modify network -netnum network_number -iptype both
    

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

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

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

  4. 次のコマンドを使用して、クラスタの動的アドレスのIPv4の部分を無効にします。

    # srvctl modify network -iptype ipv6
    

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

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

IPv4ネットワークをIPv4およびIPv6ネットワークに変更するには、「SRVCTLを使用した、静的IPv4アドレスの静的IPv6アドレスへの変更」で説明されている手順1から4で行ったように、IPv6ネットワークを既存のIPv4ネットワークに追加する必要があります。

これらの3つの手順を完了した後、グリッド・ユーザーとしてログインし、次のコマンドを実行する必要があります。

$ srvctl status scan

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

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

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

# srvctl modify network -iptype ipv6

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