クラスタでの名前解決を有効にするための情報を指定します。
オラクルのグリッド・プラグ・アンド・プレイ・フレームワークは、クラスタ・メンバーごとに永続的な構成データを設定する必要のない操作環境を、Oracle Grid Infrastructureに提供します。グリッド・プラグ・アンド・プレイでは、クラスタにノードを追加するとノードの大部分のクラスタ構成が動的に構成され、クラスタからノードを削除するとクラスタが再構成されます。
Grid Naming Serviceを使用すると、クラスタでノードが追加および削除された際に、クラスタから動的にホスト名とIPアドレスを通知できます。これには、DNSに最小のネットワーク・アドレス構成を追加する必要があります。
GNSを使用するには、Grid Infrastructureをインストールする前に、GNSが対応するサブドメインに対する名前解決リクエストを、GNSの仮想IPアドレスに送信するようドメイン・ネーム・サーバー(DNS)を構成する必要があります。DNS構成の要件の詳細は、グリッド・インフラストラクチャのインストレーション・ガイドを参照してください。
GNSを使用する場合は、GNS VIPアドレスに静的IPアドレスを指定し、サブドメインがその静的GNS IPアドレスに転送されるように委任する必要があります。
クラスタにノードが追加されると、組織のDHCPサーバーにより、これらのアドレスに動的にアドレスが指定されます。その後、これらのアドレスは自動的にGNSに登録され、GNSによりサブドメイン内で、GNSに登録されているクラスタ・ノード・アドレスに解決されます。
「クラスタ名」フィールドにクラスタの名前を指定します。クラスタ名は、作成するクラスタのメンバー・ノードの識別に使用されます。クラスタ名のデフォルト値は、ローカル・ノード名によって決まります。クラスタ名をデフォルトから変更する場合、使用するクラスタ名はエンタープライズ内でグローバルに一意である必要があります。
クラスタ名は、1文字以上15文字以下です。たとえば、次のようになります。
sales
Single Client Access Name(SCAN)は、クライアントにクラスタに対するサービス・アクセスを提供するために使用されるホスト名です。SCANは、個々のノードではなく、クラスタ全体と関連付けられているため、クライアントを再構成せずにクラスタへのノードの追加や削除を実行できます。また、データベース用に独立した場所が追加されるため、クライアント構成は特定のデータベースを実行しているいずれかのノードに依存する必要がありません。クライアントは、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANを使用することをお薦めします。
SCANは、クラスタ内でGrid Naming Service(GNS)を使用するか、ドメイン名サービス(DNS)を使用して解決できるように構成する必要があります。少なくとも、SCAN名は最低1つのアドレスに解決される必要があります。高可用性とスケーラビリティのため、SCAN名が3つのIPアドレスに解決されるように構成することをお薦めします。
たとえば、クラスタ名がsalesの場合にGNSを使用するとSCAN名はsales.localとなり、DHCPサーバーから割り当てられるIPアドレスに解決されます。
SCANの仮想IPアドレスのデフォルトのSCANポートは1521ですが、このポートを使用できない場合は別のポートを指定できます。Oracle Universal Installerは、指定されたSCANポートが有効なポート番号であり、他の用途に使用されていないことを確認します。インストール後に、TNSリスナーはこのポートをリスニングして、SCAN名へのクライアント接続に応答します。
次の表に、Grid Naming Service(GNS)の構成を選択した場合、インストール後にシステムがどのように構成されるかを示します。
Grid Naming Serviceのサンプル・ネットワーク
| ID | ホーム・ノード | ホスト・ノード | 指定された名前 | タイプ | アドレス | アドレスの割当て方法 | 解決方法 |
|---|---|---|---|---|---|---|---|
|
GNS VIP |
なし |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.1 |
ネット管理者が修正 |
DNS |
|
ノード1(パブリック) |
ノード1 |
|
|
パブリック |
192.0.2.101 |
固定 |
GNS |
|
ノード1(VIP) |
ノード1 |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.104 |
DHCP |
GNS |
|
ノード1(プライベート) |
ノード1 |
|
|
プライベート |
192.168.0.1 |
固定またはDHCP |
GNS |
|
ノード2(パブリック) |
ノード2 |
|
|
パブリック |
192.0.2.102 |
固定 |
GNS |
|
ノード2(VIP) |
ノード2 |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.105 |
DHCP |
GNS |
|
ノード2(プライベート) |
ノード2 |
|
|
プライベート |
192.168.0.2 |
固定またはDHCP |
GNS |
|
SCAN VIP 1 |
なし |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.201 |
DHCP |
GNS |
|
SCAN VIP 2 |
なし |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.202 |
DHCP |
GNS |
|
SCAN VIP 3 |
なし |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.203 |
DHCP |
GNS |
脚注1 ノードのホスト名は、現在そのホストで実行されているVIPアドレスなど、複数のアドレスに解決される場合があります。
GNSを使用しないことを選択した2ノード・クラスタの各ノードがパブリック・インタフェースとプライベート・インタフェースを1つずつ持ち、DNSで3つのIPアドレスのいずれかに解決されるSCANドメイン・アドレスを定義している場合、このクラスタで構成できるアドレスは次の表のようになります。
手動ネットワーク構成の例
| ID | ホーム・ノード | ホスト・ノード | 指定された名前 | タイプ | アドレス | アドレスの割当て方法 | 解決方法 |
|---|---|---|---|---|---|---|---|
|
ノード1(パブリック) |
ノード1 |
|
|
パブリック |
192.0.2.101 |
固定 |
DNS |
|
ノード1(VIP) |
ノード1 |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.104 |
固定 |
DNSおよびホスト・ファイル |
|
ノード1(プライベート) |
ノード1 |
|
|
プライベート |
192.168.0.1 |
固定 |
DNSおよびホスト・ファイル、またはなし |
|
ノード2(パブリック) |
ノード2 |
|
|
パブリック |
192.0.2.102 |
固定 |
DNS |
|
ノード2(VIP) |
ノード2 |
Oracle Clusterwareによる選択 |
|
仮想 |
192.0.2.105 |
固定 |
DNSおよびホスト・ファイル |
|
ノード2(プライベート) |
ノード2 |
|
|
プライベート |
192.168.0.2 |
固定 |
DNSおよびホスト・ファイル、またはなし |
|
SCAN VIP 1 |
なし |
Oracle Clusterwareによる選択 |
mycluster-scan |
仮想 |
192.0.2.201 |
固定 |
DNS |
|
SCAN VIP 2 |
なし |
Oracle Clusterwareによる選択 |
mycluster-scan |
仮想 |
192.0.2.202 |
固定 |
DNS |
|
SCAN VIP 3 |
なし |
Oracle Clusterwareによる選択 |
mycluster-scan |
仮想 |
192.0.2.203 |
固定 |
DNS |
脚注1 ノード・ホスト名は複数のアドレスに解決される場合があります。
SCANが解決するアドレスはOracle Clusterwareによって割り当てられるため、特定のノードには固定されません。VIPフェイルオーバーを有効にするには、前出の表で示した構成で、同じサブネット192.0.2にある両方のノードのSCANアドレスとパブリックおよびVIPアドレスを定義します。
|
注意: すべてのホスト名は、英数字のみを許可しているRFC952標準に準拠する必要があります。アンダースコア("_")を含むホスト名は使用できません。 |