| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for Oracle Solaris B57234-07 |
|
 前 |
 次 |
この章では、Oracle Universal Installer(OUI)を起動してクラスタ用Oracle Grid Infrastructureをインストールする前に完了する必要があり、クラスタにOracle Real Application Clusters(Oracle RAC)をインストールする場合に完了する必要があるシステム構成作業について説明します。
この章の内容は次のとおりです。
|
注意: 構成の変更を開始する前に、既存のデータベースのバックアップを必ず作成してください。 |
既存のOracleインストールがある場合は、バージョン番号、パッチおよびその他の構成情報を記録して、既存のインストール用のアップグレード手順を確認します。インストールを進める前に、アップグレードに関するOracleドキュメントを確認し、その後の処理を確認します。
Oracle Automatic Storage Management(Oracle ASM)11gリリース1(11.1)は、クラスタ内の個別のノードに対して、または複数のノードに対してまとめてローリング・アップグレードを行うことで、Oracle RACデータベースを停止することなくアップグレードできます。ただし、Oracle ASMを使用しているクラスタにスタンドアロン・データベースがある場合、アップグレードする前にそのスタンドアロン・データベースを停止する必要があります。Oracle ASM 10gからアップグレードする場合は、Oracle ASMクラスタ全体を停止してアップグレードを行う必要があります。
Oracle ASMがすでにインストールされている場合は、Oracleのアップグレードに関するドキュメントを確認します。今回のリリースでは、Oracle ASMホームの場所が変更されています。したがって、ストレージ管理を簡略化またはカスタマイズするためには、他の構成の変更も検討することが必要な場合があります。以前のリリースのOracle ASMホームがすでにある場合は、Oracle Clusterwareのアップグレードに使用する予定のユーザーが所有している必要があります。
オペレーティング・システムのローリング・アップグレード時に、そのオペレーティング・システムの両方のバージョンが、使用しているOracle Databaseリリースで保証されている場合は、異なるオペレーティング・システム・バイナリを使用できます。
|
注意: 異なるバージョンのオペレーティング・システムを使用できるのは、アップグレードの間の数時間だけです。Oracle Clusterwareでは、同じクラスタで異なる命令セット・アーキテクチャ(ISA)を使用するプロセッサを搭載するノードはサポートされていません。各ノードは、バイナリ・レベルでクラスタ内の他のノードとの互換性が必要です。たとえば、同じクラスタの1つのノードでIntel 64プロセッサを使用し、別のノードでIA-64(Itanium)プロセッサを使用することはできません。同じクラスタの1つのノードでIntel 64プロセッサを使用し、別のノードでAMD64プロセッサを使用することはできますが、これは、プロセッサが同じx86-64 ISAを使用し、同じバイナリ・バージョンのOracleソフトウェアを実行するためです。クラスタに異なる処理速度やサイズのCPUを搭載するノードをインストールできますが、ハードウェア構成が同じノードを使用することをお薦めします。 |
最新のソフトウェア更新情報や、アップグレードの前後、互換性、相互運用性に関するベスト・プラクティスについては、「Oracle Upgrade Companion」を参照してください。「Oracle Upgrade Companion」は、My Oracle SupportのNote 785351.1で参照できます。
Oracle Clusterware 11gリリース2では、インストールの最小要件を満たしていない場合はOracle Universal Installer(OUI)によって検知され、要件を満たしていないシステム構成手順を実行するために、修正スクリプトと呼ばれるシェル・スクリプト・プログラムが作成されます。OUIによって不完全な作業が検知されると、修正スクリプト(runfixup.sh)が生成されます。「修正および再チェック」ボタンをクリックした後で、修正スクリプトを実行できます。
CVUで、インストールの前に修正スクリプトを生成することもできます。
|
関連項目: cluvfyコマンドの使用の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
修正スクリプトによって、次の作業が実行されます。
必要に応じて、インストールを正しく実行するために必要な値を次のカーネル・パラメータに設定します。
共有メモリーのパラメータ
オープン・ファイル記述子とUDP送受信のパラメータ
Oracle Inventory(中央インベントリ)ディレクトリに権限を設定します。
インストール所有者、必要な場合はOracleインベントリ・ディレクトリ、オペレーティング・システム権限グループの、プライマリおよびセカンダリ・グループ・メンバーシップが再構成されます。
必要に応じて、シェル制限が必要な値に設定されます。
インストールに使用するユーザー・アカウントのために、クラスタ・メンバー・ノード間でSSHを構成している場合は、インストール前にクラスタ構成を確認し、インストールを開始する前にオペレーティング・システムの変更を行うための修正スクリプトを生成できます。
これを行うには、インストールを実行するユーザー・アカウントでログインし、runcluvfyコマンドがあるステージング領域に移動し、次のコマンド構文を使用します。nodeは、クラスタ・メンバーにするノードをカンマで区切ったリストです。
$ ./runcluvfy.sh stage -pre crsinst -n node -fixup -verbose
たとえば、node1とnode2の2ノードがあるクラスタを構成する場合は、次のコマンドを入力します。
$ ./runcluvfy.sh stage -pre crsinst -n node1,node2 -fixup -verbose
インストール中は、rootまたは他のユーザーとして、リモート端末上で作業を行う必要があります。リモート表示できるようにする必要があるユーザー・アカウントに対して、次の手順を実行します。
|
注意: 別のユーザー(oracleなど)としてログインする場合は、そのユーザーでもこの手順を繰り返します。 |
リモート表示を可能にするには、次のいずれかの手順を実行します。
ソフトウェアをX Window SystemワークステーションまたはX端末からインストールする場合は、次の手順を実行します。
X端末(xterm)などのローカル端末セッションを開始します。
ソフトウェアを別のシステムにインストールし、そのシステムをX11ディスプレイとして使用する場合は、次の構文を使用してコマンドを入力し、リモート・ホストがローカルのXサーバーでXアプリケーションを表示できるようにします。
# xhost + RemoteHost
RemoteHostは完全修飾されたリモートのホスト名です。次に例を示します。
# xhost + somehost.example.com somehost.example.com being added to the access control list
ソフトウェアをローカル・システムにインストールしない場合は、ssh,コマンドを使用してソフトウェアをインストールするシステムに接続します。
# ssh -Y RemoteHost
RemoteHostは完全修飾されたリモートのホスト名です。-Yフラグ(Yes)により、元のX11ディスプレイに対する完全なアクセス権がリモートのX11クライアントに付与されます。次に例を示します。
# ssh -Y somehost.example.com
rootユーザーでログインしていない場合は、次のコマンドを入力してユーザーをrootに切り替えます。
$ su - root password: #
Xサーバー・ソフトウェアがインストールされているPCまたはその他のシステムからソフトウェアをインストールする場合は、次の手順を実行します。
|
注意: この手順の詳細は、ご使用のXサーバーのマニュアルを参照してください。ご使用のXサーバー・ソフトウェアによっては、異なった順序で作業を実行する必要があります。 |
Xサーバー・ソフトウェアを起動します。
リモート・ホストがローカル・システムでXアプリケーションを表示できるようにXサーバー・ソフトウェアのセキュリティを設定します。
ソフトウェアをインストールするリモート・システムに、クラスタ用Oracle Grid Infrastructureソフトウェアの所有者(grid、oracle)として接続し、システムでX端末(xterm)などの端末セッションを開始します。
リモート・システム上で別の端末セッションを開き、rootユーザーとしてリモート・システムにログインします。プロンプトが表示されたら、rootとしてスクリプトを実行できます。
rootとしてログインし、次の手順を実行して、Oracle InventoryグループおよびOracle Grid Infrastructureのソフトウェア所有者を検索または作成します。
|
注意: Oracle Grid Infrastructureのインストールでは、Oracle Clusterwareおよび Oracle Automatic Storage Managementの両方がインストールされます。Oracle Clusterwareのインストール所有者とOracle Automatic Storage Managementのインストール所有者は、分離することができなくなりました。 |
システムに初めてOracleソフトウェアをインストールする場合は、OUIによってoraInst.locファイルが作成されます。このファイルに、Oracle Inventoryグループのグループ名(デフォルトはoinstall)およびOracle中央インベントリ・ディレクトリのパスが示されます。oraInst.locファイルには、次のような内容が含まれます。
inventory_loc=central_inventory_location inst_group=group
この場合、central_inventory_locationはOracle中央インベントリの場所、groupは中央インベントリへの書込み権限を持つグループの名前です(OINSTALLグループ権限)。
既存のOracle中央インベントリがある場合は、必ずすべてのOracleソフトウェア・インストールで同じOracle Inventoryを使用し、インストールに使用するすべてのOracleソフトウェア・ユーザーがこのディレクトリへの書込み権限を持つようにします。
システムにOracle中央インベントリ・ディレクトリ(oraInventory)があるかどうかを確認するには、次のようにします。
# more /var/opt/oracle/oraInst.loc
oraInst.locファイルが存在する場合、このコマンドの出力結果は、次のようになります。
inventory_loc=/u01/app/oracle/oraInventory inst_group=oinstall
前述の出力例の意味は次のとおりです。
inventory_locグループは、Oracle Inventoryの場所を示します。
inst_groupパラメータは、Oracle Inventoryグループの名前(この例では、oinstall)を示します。
grep groupname /etc/groupコマンドを使用して、Oracle Inventoryグループとして指定されたグループがまだシステムに存在していることを確認します。次に例を示します。
$ grep oinstall /etc/group oinstall:x:1000:grid,oracle
oraInst.locファイルが存在しない場合は、次のコマンドを入力して、Oracle Inventoryグループを作成します。
# /usr/sbin/groupadd -g 1000 oinstall
このコマンドによって、グループID番号が1000のoraInventoryグループoinstallが作成されます。oraInventoryグループのメンバーには、Oracle中央インベントリ(oraInventory)への書込み権限が付与されます。
oraInventoryグループが存在しない場合、デフォルトでは、クラスタ用Oracle Grid Infrastructureソフトウェアのインストール所有者のプライマリ・グループが、oraInventoryグループとして表示されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。
次の場合は、Oracle Grid Infrastructureのソフトウェア所有者を作成する必要があります。
Oracleソフトウェア所有者ユーザーが存在しない場合(たとえば、システムへOracleソフトウェアを初めてインストールする場合)。
Oracleソフトウェア所有者ユーザーは存在するが、他のグループに所属する別のオペレーティング・システム・ユーザーを使用して、Oracle Grid InfrastructureとOracle Databaseの管理権限を分離する場合。
Oracleドキュメントでは、Oracle Grid Infrastructureソフトウェアのインストールのみを所有するために作成されたユーザーをgridユーザーと呼びます。すべてのOracleインストールを所有するために作成されたユーザー、またはOracle Databaseのインストールのみを所有するために作成されたユーザーをoracleユーザーと呼びます。
異なるOracle Databaseホームに対して複数のOracleソフトウェア所有者を使用する場合は、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)ソフトウェアに対して別途ソフトウェア所有者を作成し、その所有者でOracle Grid Infrastructureをインストールすることをお薦めします。
Oracle DatabaseまたはOracle RACをインストールする予定がある場合は、Oracle Grid InfrastructureおよびOracle Databaseのインストール・ユーザーを別々に作成することをお薦めします。使用するインストール所有者が1つの場合は、管理タスクを実行するときに、$ORACLE_HOMEの値を管理対象のインスタンス(Oracle ASM、Oracle Grid Infrastructureホーム内、またはOracleホームのデータベース)に変更する必要があります。そのコマンド構文の例は次のようになります。ここで/u01/app/11.2.0/gridはOracle Grid Infrastructureホームです。
$ ORACLE_HOME=/u01/app/11.2.0/grid; export ORACLE_HOME
sqlplus、lsnrctl、asmcmdのいずれかのコマンドを使用してインスタンスを管理しようとしたときに、$ORACLE_HOMEが別のバイナリ・パスに設定されていると、エラーが発生します。データベース・ホームからsrvctlを起動する場合、$ORACLE_HOMEが設定されていないと、srvctlは失敗します。ただし、Oracle Grid Infrastructureホームでsrvctlを使用している場合は、$ORACLE_HOMEが無視されるため、Oracleホームのパスはsrvctlコマンドに影響しません。$ORACLE_HOMEは必ず、管理対象のインスタンスに変更する必要があります。
異なるOracleソフトウェアのインストール環境に対して、ユーザーを別々に作成し、オペレーティング・システム権限グループを別々に作成するためにOracleソフトウェア所有者を別々に作成する場合は、そのユーザーのプライマリ・グループとしてOracle中央インベントリ・グループ(oraInventoryグループ)が必要なことに注意してください。このグループのメンバーはOracle中央インベントリ(oraInventory)ディレクトリに対する書込み権限を所有します。また、様々なOracle Clusterwareリソース、OCRキー、DBAが書込み権限を必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限が付与されます。Oracleドキュメントのコード例では、このグループをoinstallで表しています。
それぞれのOracleソフトウェア所有者は、同じ中央インベントリ・グループのメンバーであることが必要です。Oracleインストールに対して複数の中央インベントリを持たないことをお薦めします。あるOracleソフトウェア所有者が別の中央インベントリ・グループを持っている場合、その中央インベントリは破損することがあります。
oracleやgridというOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracleの存在を確認します)。
# id -a oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。ユーザーIDおよびグループIDの番号は、クラスタ・メンバー・ノードにする各ノード上で同一である必要があります。
既存ユーザーを使用する場合は、ユーザーのプライマリ・グループがOracle Inventoryグループ(oinstall)であることを確認します。Oracle Databaseインストールにこのユーザー・アカウントを使用する場合は、OracleアカウントがOracle ASM用のOSDBAグループ(メンバーがOracle ASM記憶域への書込みを許可されているグループ)として指定する予定のグループのメンバーであることを確認します。
Oracleソフトウェア所有者ユーザー(oracle、grid)が存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は作成します。既存のユーザー・アカウントを使用する場合は、各クラスタ・メンバー・ノードでユーザーIDおよびグループIDが一致していることを確認します。次の手順では、Oracleソフトウェア所有者の名前としてgridが、OSASMグループとしてdbaが使用されています。異なる管理権限に対して個別のシステム権限グループを作成するには、ユーザーを作成する前に、グループ作成を行います(第2.4.5項「役割区分によるオペレーティング・システム権限グループおよびユーザーの作成」)。
既存のシステム権限グループ(この例ではdba)がある場合にグリッド・インストール所有者アカウントを作成し、グループのメンバーにOracle ASMインスタンスを管理するためのSYSASM権限を付与する場合、次のようなコマンドを入力します。
# /usr/sbin/useradd -u 1100 -g oinstall -G dba grid
前述のコマンドの意味は、次のとおりです。
-uオプションは、ユーザーIDを指定します。システムによって自動的にユーザーID番号を生成するようにできるため、このコマンド・フラグの使用は任意です。ただし、Oracle Grid Infrastructure用に作成するユーザーのユーザーID番号は、この後のインストール前の作業で必要になるため、記録しておく必要があります。また、クラスタのすべてのノードで、このユーザーのユーザーIDを一致させる必要があります。
-gオプションは、プライマリ・グループを指定します。プライマリ・グループは、Oracle Inventoryグループである必要があります。たとえば、oinstallです。
-Gオプションには、セカンダリ・グループ(この例ではdba)を指定します。
セカンダリ・グループにはOSASMグループを含める必要があります。このグループのメンバーは、Oracle ASMインスタンスを管理するためのSYSASM権限を付与されます。SYSASMシステム権限を付与するグループは1つのグループのみ指定でき、データベース管理者グループとは別のグループか、またはOSASMグループとOSDBAグループとして1つのグループを指定できます。この場合、グループのメンバーにはSYSASMおよびSYSDBA権限が付与され、Oracle ASMインスタンスとOracle Databaseインスタンスの両方を管理するためのシステム権限が与えられます。コード例では、このグループはasmadminです。
このユーザーを、Oracle Grid InfrastructureとOracle Databaseインストールの両方の所有者として作成する場合は、ASM用のOSDBAグループをユーザーのセカンダリ・グループにする必要があります。コード例では、このグループ名はasmdbaです。ASM用のOSDBAグループのメンバーには、Oracle ASM記憶域へのアクセス権限が付与されます。Oracle ASM記憶域にアクセスするデータベースが複数になる場合は、ASM用のOSDBAグループを作成するか、または、ASM用のOSDBAグループとして、すべてのデータベースに対するOSDBAグループと同じグループを使用する必要があります。
usermodコマンドを使用して、既存のユーザーID番号とグループを変更します。
次に例を示します。
# id -a oracle uid=501(oracle) gid=501(oracle) groups=501(oracle) # /usr/sbin/usermod -u 1001 -g 1000 -G 1000,1001 oracle # id -a oracle uid=1001(oracle) gid=1000(oinstall) groups=1000(oinstall),1001(oracle)
Oracle Grid Infrastructureを所有するユーザーのパスワードを設定します。次に例を示します。
# passwd grid
他のすべてのクラスタ・ノードでこの手順を繰り返します。
グリッド・インストール所有者のOracleベース・ディレクトリは、Oracle ASMおよびOracle Clusterwareに関する診断ログ、管理ログ、およびその他のログが格納される場所です。
Oracleソフトウェアのパスとして、Oracle Optimal Flexible Architecture(OFA)ガイドラインに準拠したOracle Clusterwareホームのパスを作成した場合は、Oracleベース・ディレクトリを作成する必要はありません。OUIでOFA準拠のパスが検出されると、そのパスにOracleベース・ディレクトリが作成されます。
OUIがパスをOracleソフトウェアのパスとして認識するには、u[00-99]/appという形式にし、oraInventory(oinstall)グループのすべてのメンバーによる書込みを可能にする必要があります。OracleベースのOFAパスは、/u01/app/userです。userは、ソフトウェアのインストール所有者の名前です。
クラスタ用Oracle Grid InfrastructureおよびOracle Databaseソフトウェア所有者が別の場合は特に、Oracle Grid InfrastructureのGridホームおよびOracleベース・ホームを手動で作成することをお薦めします。そうすることで、ログ・ファイルを分けることができます。
次に例を示します。
# mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/grid # mkdir -p /u01/app/oracle # chown grid:oinstall /u01/app/11.2.0/grid # chown grid:oinstall /u01/app/grid # chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/ # chown -R grid:oinstall /u01
|
注意: クラスタ用Oracle Grid Infrastructureバイナリをクラスタ・ファイル・システムに配置することはサポートされていません。 |
役割区分によるOracle ASMの権限構成は、Oracle ASMインストール環境に対する管理アクセス権限と、他のOracleインストール環境に関連付けられた管理権限グループおよびユーザーとを分離するためのグループおよびユーザーを持つ構成です。管理アクセス権は、個々のオペレーティング・システム・グループのメンバーシップによって付与され、インストール権限は、Oracleをインストールするたびにインストール所有者を変えることで付与されます。
|
注意: この構成はオプションで、Oracleソフトウェアに対するユーザー・アクセスを、様々な管理者ユーザーの役割に応じて制限するための構成です。 |
必要な場合、記憶域およびデータベース層におけるすべてのシステム権限について、1つの管理ユーザーと1つのグループをオペレーティング・システム認証で使用できるように、オペレーティング・システム・ユーザー権限を割り当てることができます。
たとえば、すべてのOracleソフトウェアのインストール所有者をoracleユーザーとし、Oracle Clusterware、Oracle ASM、サーバー上のすべてのOracle Databaseに対するすべてのシステム権限、およびインストール所有者としてのすべての権限をメンバーに付与されるグループをoinstallとすることができます。このグループは、Oracle Inventoryグループであることも必要です。
少なくとも2つのグループを使用することをお薦めします。メンバーに管理システム権限が付与されるシステム権限グループと、個別のインストール権限であるOINSTALL権限が付与されるインストール所有者グループ(oraInventoryグループ)です。クラスタ検証ユーティリティなどのOracleツールでデフォルトを使用しやすくするため、すべてのシステム権限とoraInventoryへの書込み権限を1つのオペレーティング・システム・グループに付与する場合は、そのグループ名をoinstallにする必要があります。
この項では、ユーザーおよびグループを作成し、役割区分を使用する方法の概要を説明します。これらのグループおよびユーザーを作成するには、rootでログインします。
個別のソフトウェア・インストール所有者を作成するすべてのインストールで、次のオペレーティング・システム・グループとユーザーを作成することをお薦めします。
各Oracleソフトウェア製品を所有する1つのソフトウェア所有者(通常、データベース・ソフトウェアの所有者ユーザーはoracle、Oracle Grid Infrastructureの所有者ユーザーはgrid)。
システムに初めてOracleソフトウェアをインストールするときは、少なくとも1つのソフトウェア所有者を作成する必要があります。このユーザーがOracle Grid InfrastructureソフトウェアのOracleバイナリを所有します。このユーザーをOracle DatabaseまたはOracle RACのバイナリ所有者にすることもできます。
Oracleソフトウェア所有者には、プライマリ・グループとしてOracle Inventoryグループが必要です。これによって、それぞれのOracleソフトウェア・インストールの所有者が中央インベントリ(oraInventory)に書込みできるようになり、OCRとOracle Clusterwareリソース権限が適切に設定されます。データベース・ソフトウェア所有者には、セカンダリ・グループ(作成する場合)としてOSDBAグループとOSOPERグループが必要です。Oracleドキュメントでは、Oracleソフトウェア所有者ユーザーをoracleユーザーとします。
ソフトウェア所有者ユーザーを個別に作成し、各Oracleソフトウェア・インストールの所有者にすることをお薦めします。特に、システムに複数のデータベースをインストールする場合にお薦めします。
Oracleドキュメントでは、Oracle Grid Infrastructureバイナリを所有するために作成されたユーザーをgridユーザーとします。このユーザーは、Oracle ClusterwareとOracle Automatic Storage Managementの両方のバイナリを所有します。
|
関連項目: OSDBAグループ、OSASMグループおよびOSOPERグループと、SYSDBA権限、SYSASM権限およびSYSOPER権限の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』および『Oracle Database管理者ガイド』を参照してください。 |
Oracle Databaseをインストールするには、次のオペレーティング・システム・グループおよびユーザーが必要です。
システムに初めてOracle Databaseソフトウェアをインストールする場合は、このグループを作成する必要があります。このグループのオペレーティング・システム・ユーザー・アカウントには、データベースの管理権限(SYSDBA権限)があります。Oracle ASMインスタンスに個別のOSDBA、OSOPERおよびOSASMグループを作成しない場合は、SYSOPERおよびSYSASM権限を持つオペレーティング・システム・ユーザー・アカウントが、このグループのメンバーである必要があります。Oracleのコード例では、このグループにdbaという名前を使用します。OSASMグループとして個別のグループを指定しない場合は、定義するOSDBAグループもデフォルトでOSASMとなります。
デフォルト(dba)以外のグループ名を指定するには、拡張インストール・タイプを選択してソフトウェアをインストールするか、またはこのグループのメンバーではないユーザーとしてOracle Universal Installer(OUI)を起動する必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。
以前は、OSDBAグループのメンバーにOracle ASMインスタンスのSYSASM権限(ディスク・グループのマウントおよびマウント解除を含む)が付与されていました。Oracle Grid Infrastructure 11g リリース2の場合、別々のオペレーティング・システム・グループがOSDBAとOSASMグループに指定されているときには、この権限が付与されません。同じグループが、OSDBAとOSASMの両方に使用されている場合は、権限がそのまま保持されます。
Oracle DatabaseのOSOPERグループ(通常、oper)
これは、オプションのグループです。制限付きのデータベース管理権限(SYSOPER権限)を別のグループのオペレーティング・システム・ユーザーに付与する場合に、このグループを作成します。OSDBAグループのメンバーには、デフォルトで、SYSOPER権限によって付与されるすべての権限もあります。
OSOPERグループを使用してデフォルトのdbaグループより少ない権限でデータベース管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールするか、またはdbaグループのメンバーでないユーザーとしてOUIを起動する必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。このグループの標準的な名前はoperです。
SYSASMは、Oracle ASMストレージ管理権限をSYSDBAから切り離すことができる新しいシステム権限です。Oracle Automatic Storage Management11gリリース2(11.2)では、OSASMグループに指定されたオペレーティング・システム・グループと、OSDBAグループに指定されたグループが同じ場合を除き、データベースOSDBAグループのメンバーにSYSASM権限は付与されません。
Oracle ASMに対する権限のオペレーティング・システム認証グループとして、別のオペレーティング・システム・グループを選択します。OUIを起動する前に、Oracle ASM用に次のグループとユーザーを作成します。
Oracle Automatic Storage Managementグループ(通常、asmadmin)
これは、必須のグループです。Oracle ASM管理者用とOracle Database管理者用の管理権限グループを別にする場合、このグループは個別のグループとして作成します。Oracleドキュメントでは、メンバーに権限が付与されたオペレーティング・システム・グループをOSASMグループと呼びます。コード例には、この権限を付与するために特別に作成された、asmadminと呼ばれるグループがあります。
システムに複数のデータベースがあり、複数のOSDBAグループがあるために、各データベースに別々のSYSDBA権限を付与できる場合は、OSASMグループを別途作成し、データベース・ユーザーとは別のユーザーにOracle Grid Infrastructureインストール(Oracle ClusterwareおよびOracle ASM)を所有させる必要があります。Oracle ASMでは、複数のデータベースがサポートされます。
OSASMグループのメンバーは、SQLを使用して、SYSASMとしてOracle ASMインスタンスに接続できます。このとき、オペレーティング・システム認証が使用されます。SYSASM権限では、ディスク・グループのマウント、マウント解除およびその他の記憶域管理作業が許可されます。SYSASM権限には、RDBMSインスタンスに対するアクセス権限はありません。
ASMデータベース管理者グループ(ASM用のOSDBA、通常はasmdba)
ASMデータベース管理者グループ(ASM用のOSDBA)のメンバーには、Oracle ASMによって管理されるファイルへの読取りおよび書込みアクセス権限が付与されます。Oracle Grid Infrastructureインストール所有者とすべてのOracle Databaseソフトウェア所有者は、このグループのメンバーである必要があります。また、Oracle ASMによって管理されるファイルへアクセスするデータベースに対するOSDBAメンバーシップを持つすべてのユーザーが、ASM用のOSDBAグループのメンバーである必要があります。
ASMオペレータ・グループ(ASM用のOSOPER、通常はasmoper)
これは、オプションのグループです。Oracle ASMインスタンスの起動と停止を含む、制限付きのOracle ASMインスタンスの管理権限(ASM用のSYSOPER権限)を別のグループのオペレーティング・システム・ユーザーに付与する場合に、このグループを作成します。OSASMグループのメンバーには、デフォルトで、ASM用のSYSOPER権限によって付与されるすべての権限もあります。
Oracle ASMオペレータ・グループを使用してデフォルトのasmadminグループより少ない権限でOracle ASM管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールする必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。コード例では、このグループはasmoperです。
次の項では、必要なオペレーティング・システム・ユーザーおよびグループを作成する方法について説明します。
Oracle DatabaseをインストールしてOracle Grid Infrastructure環境で使用するときに、次のような場合はOSDBAグループを作成する必要があります。
OSDBAグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)。
OSDBAグループが存在するが、新しいOracle Database環境では、データベースの管理権限を別のグループのオペレーティング・システム・ユーザーに付与する場合。
OSDBAグループが存在しない場合または新しいOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはdbaを使用します。
# /usr/sbin/groupadd -g 1031 dba
OSOPERグループを作成する必要があるのは、制限付きのデータベース管理権限(SYSOPERオペレータ権限)を持つオペレーティング・システム・ユーザーのグループを指定する場合のみです。ほとんどの環境では、OSDBAグループを作成するのみで十分です。次の場合にOSOPERグループを使用するには、このグループを作成する必要があります。
OSOPERグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)
OSOPERグループが存在するが、新しいOracle環境で、データベースのオペレータ権限を別のグループのオペレーティング・システム・ユーザーに付与する場合
新しいOSOPERグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはoperを使用します。
# /usr/sbin/groupadd -g 1032 oper1
OSASMグループが存在しない場合または新しいOSASMグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmadminを使用します。
# /usr/sbin/groupadd -g 1020 asmadmin
データベース管理者などのオペレーティング・システム・ユーザーのグループを指定し、Oracle ASM記憶域の起動と停止を含む、Oracle ASM記憶域層に対する制限付きの管理権限を付与する場合には、ASM用のOSOPERグループを作成します。ほとんどの環境では、OSASMグループを作成するのみで十分です。インストールのインタビュー時に、そのグループをASM用のOSOPERグループとして指定します。
新しいASM用のOSOPERグループが必要な場合は、次の手順で作成します。次の手順では、既存のグループですでに使用されていないかぎり、グループ名にはasmoperを使用します。
# /usr/sbin/groupadd -g 1022 asmoper
Oracle ASMインスタンスへのアクセスを可能にするには、ASM用のOSDBAグループを作成する必要があります。これは、OSASMとOSDBAが異なるグループである場合に必要です。
ASM用のOSDBAグループが存在しない場合、または新しいASM用のOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmdbaを使用します。
# /usr/sbin/groupadd -g 1021 asmdba
次の場合は、Oracleソフトウェア所有者ユーザーを作成する必要があります。
Oracleソフトウェア所有者ユーザーが存在するが、新しいOracle Database環境では、別のオペレーティング・システム・ユーザー(異なるグループ・メンバーシップを持つ)を使用して、このグループにデータベースの管理権限を付与する場合。
Oracle Grid Infrastructureに対してgridなどのOracleソフトウェア所有者が作成されており、Oracle Databaseソフトウェアに対してoracleなどの別のOracleソフトウェア所有者を作成する場合。
oracleやgridというOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracleの存在を確認します)。
# id -a oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。既存のユーザーを使用する場合は、そのユーザーのプライマリ・グループがOracleインベントリ・グループであり、そのユーザーが適切なOSDBAグループおよびOSOPERグループのメンバーであることを確認します。詳細は、次のいずれかの項を参照してください。
既存のユーザーを変更するには、「既存のOracleソフトウェア所有者ユーザーの変更」を参照してください。
ユーザーを作成するには、次の項を参照してください。
Oracleソフトウェア所有者ユーザーが存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は、次の手順で作成します。既存のユーザーですでに使用されていないかぎり、ユーザー名にはoracleを使用します。
# /usr/sbin/useradd -u 1101 -g oinstall -G dba,asmdba oracle
前述のコマンドの意味は、次のとおりです。
-uオプションは、ユーザーIDを指定します。システムによって自動的にユーザーID番号を生成するようにできるため、このコマンド・フラグの使用は任意です。ただし、oracleユーザーID番号は、この後のインストール前の作業で必要になるため、記録しておく必要がります。
-gオプションは、プライマリ・グループを指定します。プライマリ・グループは、oinstallなどのOracle Inventoryグループである必要があります。
-Gオプションは、セカンダリ・グループを指定します。セカンダリ・グループには、OSDBAグループとASM用のOSDBAグループ、必要に応じてASM用のOSOPERグループを含める必要があります。たとえば、dba、asmdba、またはdba、asmdba、asmoperなどです。
oracleユーザーのパスワードを設定します。
# passwd oracle
Oracleソフトウェア所有者ユーザー、Oracle Inventory、OSDBAグループおよびOSOPERグループは、すべてのクラスタ・ノードに存在し、また同一である必要があります。同一のユーザーおよびグループを作成するには、ユーザーおよびグループを作成したノードで割り当てられたユーザーIDおよびグループIDを確認してから、他のクラスタ・ノードで同じ名前とIDを持つユーザーおよびグループを作成する必要があります。
|
注意: 次の手順は、ローカル・ユーザーおよびグループを使用している場合にのみ実行する必要があります。NISなどのディレクトリ・サービスで定義されたユーザーおよびグループを使用している場合、各クラスタ・ノードのユーザーおよびグループはすでに同一です。 |
gridまたはoracleユーザーのユーザーID(uid)と、既存のOracleグループのグループID(gid)を確認するには、次の手順を実行します。
次のコマンドを入力します(ここでは、oracleユーザーのユーザーIDを確認します)。
# id -a oracle
このコマンドの出力結果は、次のようになります。
uid=502(oracle) gid=501(oinstall) groups=502(dba),503(oper),506(asmdba)
表示された情報から、ユーザーのユーザーID(uid)および所属するグループのグループID(gid)を特定します。これらのID番号がクラスタの各ノードで同じであることを確認します。ユーザーのプライマリ・グループはgidの後に表示されます。セカンダリ・グループはgroupsの後に表示されます。
他のクラスタ・ノードでユーザーおよびグループを作成するには、各ノードで次の手順を繰り返します。
次のクラスタ・ノードへrootでログインします。
次のコマンドを入力して、oinstall、asmadminおよびasmdbaグループを作成します。また、必要に応じて、asmoper、dbaおよびoperグループを作成します。-gオプションを使用して、各グループに正しいgidを指定します。
# /usr/sbin/groupadd -g 1000 oinstall # /usr/sbin/groupadd -g 1020 asmadmin # /usr/sbin/groupadd -g 1021 asmdba # /usr/sbin/groupadd -g 1022 asmoper # /usr/sbin/groupadd -g 1031 dba # /usr/sbin/groupadd -g 1032 oper
|
注意: グループがすでに存在している場合は、必要に応じてgroupmodコマンドを使用してそのグループを変更します。このノードのグループに、同じグループIDを使用できない場合、すべてのノードの/etc/groupファイルを表示し、どのノードでも使用できるグループIDを特定します。すべてのノードのグループIDが同じになるように、グループIDを変更する必要があります。 |
oracleユーザーまたはOracle Grid Infrastructure(grid)ユーザーを作成するには、次のようなコマンドを入力します(この例では、oracleユーザーを作成します)。
# /usr/sbin/useradd -u 1101 -g oinstall -G asmdba,dba oracle
前述のコマンドの意味は、次のとおりです。
-uオプションは、ユーザーIDを指定します。ユーザーIDは、前の項で特定したユーザーIDである必要があります。
-gオプションは、プライマリ・グループを指定します。プライマリ・グループは、oinstallなどのOracle Inventoryグループである必要があります。
-Gオプションは、セカンダリ・グループを指定します。セカンダリ・グループには、OSASM、OSDBA、ASM用のOSDBA、OSOPERまたはASM用のOSOPERグループを含めることができます。次に例を示します。
グリッド・インストール所有者: OSASM(asmadmin)。メンバーはSYSASM権限を付与されます。
SYSASMアクセス権限のないOracle Databaseインストール所有者: OSDBA(dba)、ASM用のOSDBA(asmdba)、ASM用のOSOPER(asmoper)。
|
注意: ユーザーがすでに存在している場合は、必要に応じてusermodコマンドを使用して変更します。すべてのノードのユーザーに、同じユーザーIDを使用できない場合、すべてのノードの/etc/passwdファイルを表示して、どのノードでも使用できるユーザーIDを特定します。すべてのノードのユーザーにそのIDを指定する必要があります。 |
# passwd oracle
「グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成」で説明するとおり、各ユーザーに対してユーザー環境の構成を行います。
Oracle Inventoryグループ(oinstall)を作成し、OSDBA、OSASM、Oracle ASM用のOSDBAグループとして1つのグループ(dba)を作成する方法の例を次に示します。また、適切なグループ・メンバーシップを持つ、Oracle Grid Infrastructureソフトウェア所有者(grid)と1つのOracle Database所有者(oracle)を作成する方法も示します。また、この例は、適切な権限を持つ、OFA構造に準拠したOracleベース・パスの構成方法も示しています。
# groupadd -g 1000 oinstall # groupadd -g 1031 dba # useradd -u 1100 -g oinstall -G dba grid # useradd -u 1101 -g oinstall -G dba oracle # mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/grid # chown -R grid:oinstall /u01 # mkdir /u01/app/oracle # chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/
これらのコマンドを実行すると、次のグループとユーザーができます。
Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall)。プライマリ・グループが中央インベントリ・グループであるメンバーは、oraInventoryディレクトリに書込みできるOINSTALL権限を付与されます。
OSASM、OSDBA、ASM用のOSDBAおよびASM用のOSOPERグループとして使用される1つのシステム権限グループ(dba)。メンバーは、Oracle Clusterware、Oracle ASM、Oracle Databaseを管理するためのSYSASMおよびSYSDBA権限を付与され、さらにOracle ASM記憶域にアクセスするためのSYSASMおよびASM用のOSOPER権限を付与されます。
クラスタ用Oracle Gridのインストール所有者(grid)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSASMグループ。Oracleベース・ディレクトリは/u01/app/grid。
Oracle Database所有者(oracle)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSDBAグループ。Oracleベース・ディレクトリは/u01/app/oracle。
インストール前は775権限でgrid:oinstallが所有し、インストール中にroot.shスクリプトが実行された後はrootが所有する/u01/app。この所有権と権限によって、OUIはパス/u01/app/oraInventoryにOracle Inventoryディレクトリを作成できるようになります。
インストール前はgrid:oinstallが所有し、インストール中にroot.shスクリプトが実行された後はrootが所有する/u01。
775権限でgrid:oinstallが所有する/u01/app/11.2.0/grid。これらの権限はインストールに必要であり、インストール・プロセスで変更されます。
インストール前は775権限で、インストール後は755権限でgrid:oinstallが所有する/u01/app/grid。
775権限でoracle:oinstallが所有する/u01/app/oracle。
Optimal Flexible Architecture(OFA)デプロイメントに準拠した、ロール割当てをしたグループおよびユーザーを作成する方法の例を、次に示します。
# groupadd -g 1000 oinstall # groupadd -g 1020 asmadmin # groupadd -g 1021 asmdba # groupadd -g 1031 dba1 # groupadd -g 1041 dba2 # groupadd -g 1022 asmoper # useradd -u 1100 -g oinstall -G asmadmin,asmdba grid # useradd -u 1101 -g oinstall -G dba1,asmdba oracle1 # useradd -u 1102 -g oinstall -G dba2,asmdba oracle2 # mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/grid # chown -R grid:oinstall /u01 # mkdir -p /u01/app/oracle1 # chown oracle1:oinstall /u01/app/oracle1 # mkdir -p /u01/app/oracle2 # chown oracle2:oinstall /u01/app/oracle2 # chmod -R 775 /u01
これらのコマンドを実行すると、次のグループとユーザーができます。
Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall)。プライマリ・グループがこのグループであるメンバーは、oraInventoryディレクトリへの書込み権限を付与されます。
個別のOSASMグループ(asmadmin)。メンバーは、Oracle ClusterwareおよびOracle ASMを管理するためのSYSASM権限を付与されます。
個別のASM用OSDBAグループ(asmdba)。メンバーは、grid、oracle1、oracle2の他、Oracle ASMへのアクセス権を付与されたユーザーです。
個別のASM用のOSOPERグループ(asmoper)。メンバーはOracle ASMインスタンスの起動と停止を含む、制限付きのOracle ASMの管理者権限が付与されたユーザーです。
クラスタ用Oracle Gridのインストールの所有者(grid)。プライマリ・グループはoraInventoryグループ、セカンダリ・グループはOSASM(asmadmin)、ASM用のOSDBAグループ(asmdba)。
2つの異なるデータベースに対する、2つの別々のOSDBAグループ(dba1とdba2)。それぞれのデータベースに対して、別々のSYSDBA権限を設定します。
Oracle Databaseバイナリの所有権を分けるための、2つのOracle Databaseソフトウェア所有者(oracle1とoracle2)と、プライマリ・グループとしてのoraInventoryグループ、セカンダリ・グループとしてのそれぞれのデータベースに対するOSDBAグループ(dba1またはdba2)と、ASM用のOSDBAグループ(asmdba)。
grid:oinstallが所有する、OFA準拠のマウント・ポイント/u01(インストール前)。
775権限でgrid:oinstallが所有する、グリッド・インストール所有者のOracleベース/u01/app/grid。インストール・プロセスで755権限に変更されます。
775権限でoracle1:oinstallが所有する、Oracleベース/u01/app/oracle1。
775権限でoracle2:oinstallが所有する、Oracleベース/u01/app/oracle2。
775(drwxdrwxr-x)権限でgrid:oinstallが所有する、Gridホーム/u01/app/11.2.0/grid。これらの権限はインストールに必要であり、インストール・プロセスでroot:oinstallの755権限(drwxr-xr-x)に変更されます。
/u01/app/oraInventory。このパスの所有者はgrid:oinstallのままで、他のOracleソフトウェア所有者による中央イベントリへの書込みを可能にします。
各サーバーで、同じオペレーティング・システム・バイナリが実行されていることを確認します。Oracle Grid InfrastructureインストールとOracle Real Application Clusters(Oracle RAC)では、同一クラスタ内でハードウェアが異なるサーバーを使用できます。
各システムは、次の最小ハードウェア要件を満たしている必要があります。
Cluster用Oracle Grid Infrastructureインストール用に2.5GB以上のRAM(Oracle RACをインストールする計画があるインストールを含む)。
1024 x 768以上のディスプレイ解像度。OUIを正しく表示するため。
次の表に示す使用可能なRAMの倍数と同等のスワップ領域
|
注意: Oracle Solarisでは、スワップできないメモリー(ISMなど)を使用する場合、スワップ領域を計算する前に、この領域に割り当てられるメモリー分を使用可能なRAMから差し引く必要があります。DISMを使用してシステムにOracle DatabaseまたはOracle RACをインストールする場合は、使用可能なスワップ領域が、サーバーで実行しているすべてのインスタンスのSGAサイズの合計以上である必要があります。 |
/tmpディレクトリに1GBの領域。
クラスタ用Oracle Grid Infrastructureホーム(Gridホーム)に6.6GBの領域で、ここには、Oracle Clusterware、Oracle Automatic Storage Management(Oracle ASM)およびOracle ACFSのファイルとログ・ファイル、およびクラスタ状態モニター・リポジトリが格納されます。
トレース・ファイル・アナライザおよびコレクタによって生成された診断収集用に、グリッド・インフラストラクチャ所有者のOracleベース・ディレクトリに最大10GBの追加領域。
|
注意: Oracle DatabaseまたはOracle RACデータベースをクラスタ上にインストールする場合は、各サーバーの/dev/shmマウント領域が、サーバーのデータベースのシステム・グローバル領域(SGA)およびプログラム・グローバル領域(PGA)より大きいサイズである必要があることに注意してください。SGAおよびPGAの予想サイズをデータベース管理者に確認し、データベースをクラスタにインストールした後に/dev/shmを増やす必要がないようにしてください。 |
Oracle Databaseのインストールでは、自動バックアップを構成する場合は、高速リカバリ領域用に追加の領域(ファイル・システムまたはOracle Automatic Storage Managementディスク・グループ)が必要です。
|
関連項目: 『Oracle Databaseストレージ管理者ガイド』 |
各システムがこれらの要件を満たしていることを確認するには、次の手順を実行します。
次のコマンドを入力してシステム・アクティビティ・レポートを取得し、使用可能なRAMおよびスワップ領域を確認します。
# sar -r n i
システムに搭載されている物理RAMのサイズが要件のサイズより少ない場合、次の手順に進む前にメモリーを増設する必要があります。
次のコマンドを入力して、構成されたスワップ領域のサイズを確認します。
# /usr/sbin/swap -s
|
注意: 値をファイナライズする前に、使用可能なRAM領域およびスワップ領域用に複数の値を選択することをお薦めします。これは、使用可能なRAMとスワップ領域が、ユーザーとコンピュータの対話に応じて変化するためです。 |
次のコマンドを入力して、/tmpディレクトリで使用できる領域の大きさを確認します。
# df -k /tmp
このコマンドでは1KBブロック単位でディスク領域が表示されます。ほとんどのシステムでは、-hフラグ付きのdfコマンド(df -h)を使用して、「24G」や「10M」など、判読可能な書式で出力を表示できます。/tmpディレクトリで使用できるディスク領域が1GB未満の場合(1048576 1k-blocks未満)、次のいずれかの手順を完了します。
必要な領域を確保するために、/tmpディレクトリから不要なファイルを削除します。
oracleユーザーの環境を設定するときに、TEMPおよびTMPDIR環境変数を設定します(後述の説明を参照)。
/tmpディレクトリを含むファイル・システムを拡張します。ファイル・システムの拡張については、必要に応じてシステム管理者に連絡してください。
次のコマンドを入力して、システムの空きディスク領域の大きさを確認します。
# df -k /tmp
次のコマンドを入力して、システム・アーキテクチャでOracleソフトウェアを実行できるかどうかを確認します。
# /bin/isainfo -kv
|
注意: このコマンドでの想定される出力は次のとおりです。64-bit SPARCインストール:
64-bit x86インストール:
ご使用のOracleソフトウェアがプロセッサ・タイプに適したOracleソフトウェアであることを確認します。 ご使用のOracleソフトウェアが書き込まれるシステムとご使用のシステム・アーキテクチャが一致しないことがコマンドの出力に示される場合、ソフトウェアをインストールすることはできません。次の手順に進む前に、ご使用のシステム・アーキテクチャに適したソフトウェアを入手してください。 |
次の項で、クラスタ用Oracle Grid Infrastructure環境に必要なネットワーク・ハードウェアおよびインターネット・プロトコル(IP)・アドレスがあるかを確認します。
|
注意: Oracle RAC環境でサポートされるネットワーク・プロトコルおよびハードウェアの最新情報は、次のMy Oracle Support Webサイトの「動作保証」ページを参照してください。WebサイトのURLは次のとおりです。
|
次にネットワーク構成要件を示します。
各ノードには2つ以上のネットワーク・アダプタまたはネットワーク・インタフェース・カード(NIC)が必要です。パブリック・ネットワーク・インタフェース用とプライベート・ネットワーク・インタフェース(インターコネクト)用のネットワーク・アダプタです。Solaris 11以上の場合、ネットワーク・アダプタは論理デバイスであり、物理デバイスではありません。
冗長インターコネクトを使用すると、ボンディングなどのテクノロジを使用しなくても、複数のインタフェースを指定してクラスタ・プライベート・ネットワークに使用します。この機能は、Oracle Database 11g リリース2(11.2.0.2)以上で使用可能です。
複数のインタフェースを定義すると、Oracle Clusterwareは1つから4つの高可用性IP(HAIP)アドレスを作成します。Oracle RACおよびOracle ASMインスタンスはこれらのインタフェース・アドレスを使用して、ノード間でのロード・バランシングされた高可用性インタフェース通信を保証します。インストーラは、冗長インターコネクトを使用して、高可用性プライベート・ネットワークを提供します。
|
関連項目: OIFCFGを使用したインタフェースの変更については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
デフォルトでは、Oracle Grid InfrastructureソフトウェアはすべてのHAIPアドレスをプライベート・ネットワーク通信に使用して、プライベート・ネットワークとして指定した一連のインタフェースにロード・バランシングを提供します。プライベート・インターコネクト・インタフェースに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースのいずれかに対応するHAIPアドレスを透過的に移動します。
|
注意: プライベート・ネットワーク・インタフェースとして5つ以上のインタフェースを定義した場合は、Oracle Clusterwareが一度にアクティブにするインタフェースは4つのみであることに注意してください。ただし、4つのアクティブなインタフェースのうちの1つに障害が発生した場合は、その障害が発生したインタフェースに構成されたHAIPアドレスを、一連の定義済プライベート・インタフェースのうちの予備インタフェースの1つに移します。 |
|
注意: Oracle Solaris ClusterにOracle Clusterwareをインストールしている場合は、クラスタウェアのプライベート・ネットワーク・アドレスとして、Oracle Solaris Cluster仮想ネットワーク・インタフェースclprivnet0を選択する必要があります。
Oracle SolarisでIPネットワーク・マルチパス(IPMP)を使用してパブリック・ネットワークまたはプライベート・ネットワーク用に複数のインタフェースを集約する場合は、Oracle Grid Infrastructureのインストール時に、IPMPグループに集約したすべてのインタフェース名を、パブリック・ネットワークまたはプライベート・ネットワークに使用する必要があるインタフェースとして指定する必要があります。 |
ノードをOracle Grid Infrastructure 11gリリース2(11.2.0.2)以上にアップグレードする場合、アップグレードされたシステムは既存のネットワーク分類を使用します。アップグレードの完了後、OIFCFGを使用してプライベート・ネットワークに複数のインタフェースを選択することによって、冗長インターコネクトの使用を有効にできます。
プライベート・ネットワークに複数のインタフェースを使用するには、冗長インターコネクト機能を使用することをお薦めします。ただし、サード・パーティのテクノロジを使用しても、プライベート・ネットワークを冗長にすることは可能です。
OUIを使用してOracle Clusterwareをインストールする場合は、各ネットワークのネットワーク・アダプタに関連付けるパブリック・インタフェース名は、すべてのノードで同じである必要があり、ネットワーク・アダプタに関連付けるプライベート・インタフェース名もすべてのノードで同じである必要があります。この制限は、新しいクラスタを作成するため、または既存のクラスタにノードを追加するためにクローニングを使用する場合は適用されません。
たとえば、2ノードのクラスタのネットワーク・アダプタの場合、パブリック・インタフェースとしてnode1ではeth0、node2ではeth1というようには構成できません。パブリック・インタフェース名は同じである必要があるため、両方のノードでパブリックとしてeth0を構成する必要があります。同じネットワークのアダプタでは、プライベート・インタフェースも同様に構成する必要があります。eth1がnode1のプライベート・インタフェースであれば、node2のプライベート・インタフェースもeth1である必要があります。
|
関連項目: クローニングを使用してノードを追加する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
パブリック・ネットワークの場合、各ネットワーク・アダプタではTCP/IPがサポートされている必要があります。
プライベート・ネットワークでは、インタフェースにTCP/IPをサポートする高速ネットワーク・アダプタおよびスイッチ(最低要件: 1ギガビット・イーサネット)を使用して、ユーザー・データグラム・プロトコル(UDP)がサポートされている必要があります。
|
注意: UDPはOracle RAC用のデフォルトのインタフェース・プロトコルで、TCPはOracle Clusterware用のインターコネクト・プロトコルです。インターコネクト用のスイッチを使用する必要があります。専用のスイッチを使用することをお薦めします。インターコネクト用のトークン・リングまたはクロスオーバー・ケーブルはサポートされていません。 |
各ノードのインターコネクト用のプライベート・インタフェースは同じサブネット上にある必要があり、これらのサブネットはクラスタのすべてのノードに接続する必要があります。たとえば、プライベート・インタフェースのサブネット・マスクが255.255.255.0の場合、プライベート・ネットワークの範囲は192.168.0.0から192.168.0.255になり、プライベート・アドレスの範囲は192.168.0.[0-255]である必要があります。プライベート・インタフェースのサブネット・マスクが255.255.0.0の場合、プライベート・アドレスの範囲は192.168.[0-255].[0-255]になります。
冗長インターコネクトを使用するクラスタの場合、各プライベート・インタフェースは、異なるサブネット上にある必要があります。ただし、各クラスタ・メンバー・ノードは各プライベート・インターコネクト・サブネット上にインタフェースを持つ必要があり、これらのサブネットがクラスタのすべてのノードに接続されている必要があります。たとえば、プライベート・ネットワークがサブネット192.168.0および10.0.0上にある場合、各クラスタ・メンバー・ノードにはサブネット192.168.0および10.0.0に接続されているインタフェースが必要です。
プライベート・ネットワークでは、指定されているすべてのインターコネクト・インタフェースのエンドポイントがネットワークで確実にアクセス可能である必要があります。ノードはすべてのプライベート・ネットワーク・インタフェースに接続されている必要があります。pingを使用して、インターコネクト・インタフェースが接続可能であるかどうかをテストできます。
インストールを開始する前に、各ノードにインタフェースが2つ以上構成されている必要があります。1つはプライベートIPアドレス用、もう1つはパブリックIPアドレス用です。
IPアドレスは、次のいずれかのオプションで構成できます。
Oracleグリッド・ネーミング・サービス(GNS)を使用した動的IPアドレスの割当て。このオプションを選択すると、ネットワーク管理者は静的IPアドレスを物理ホスト名に割り当て、動的に割り当てられたIPをOracle Clusterware管理VIPアドレスに割り当てます。この場合、VIPのIPアドレスはDHCPによって割り当てられ、クラスタ内でOracle Clusterwareの一部として構成されたマルチキャスト・ドメイン・ネーム・サーバーを使用して解決されます。GNSを使用する場合は、次のものが必要です。
クラスタのために、パブリック・ネットワーク上で実行されているDHCPサービス。
DHCP上の十分なアドレス。これにより、各ノードの仮想IPとしてIPアドレスを1つずつ、そしてクラスタの単一クライアント・アクセス名(SCAN)によって使用される、クラスタのIPアドレスを3つ提供します。
静的IPアドレスの割当て。このオプションを選択すると、ネットワーク管理者は固定IPアドレスをクラスタの各物理ホスト名とOracle Clusterware管理VIPのIPに割り当てます。また、各ノードには、ドメイン・ネーム・サーバー(DNS)に基づいた静的名前解決が使用されます。このオプションを選択する場合は、クラスタの変更時にネットワーク管理の更新を依頼する必要があります。
|
注意: すべてのサーバー・ノードのパブリック・ホスト名には、静的なホスト名を使用することをお薦めします。パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。 DHCP割当てのネットワークは、デフォルトのネットワークでのみサポートされ、その後のネットワークではサポートされません。 |
グリッド・ネーミング・サービス(GNS)を有効にする場合、クラスタへの名前解決要求はGNSに委任され、GNSによってGNS仮想IPアドレスでリスニングされます。このアドレスは、インストール前にDNSドメインに定義します。DNSは、クラスタ名(クラスタに委任されたサブドメイン内のすべての名前)の解決要求がGNSに委任されるように構成する必要があります。要求がドメインに届くと、GNSによってその要求が処理され、要求された名前に対する適切なアドレスとともに応答が返されます。
GNSを使用するには、インストールの前に、サブドメインのDNS解決をクラスタに指示するDNS参照をDNS管理者が設定しておく必要があります。GNSを有効にする場合は、クラスタで必要な仮想IPアドレスをクラスタによって動的に割り当てるために、パブリック・ネットワーク上にDHCPサービスが必要です。
|
注意: 次の制限事項が、ご使用のシステムのベンダー構成に適用されます。
|
GNSを有効にしない場合、各ノードのパブリックIPアドレスおよび仮想IPアドレスは、静的アドレスであることが必要です。このアドレスは、インストール前に各ノードで構成しておく必要がありますが、現在未使用である必要があります。パブリックIPアドレスと仮想IPアドレスは、同じサブネット内にある必要があります。
インストールのインタビュー時にプライベートとして指定したインタフェース上のプライベート・サブネットに含まれるプライベートIPアドレスが、Oracle Clusterwareによって管理されます。
クラスタには、次のアドレスが構成されている必要があります。
次の特性がある、各ノードのパブリックIPアドレス:
静的IPアドレス
各ノードでインストール前に構成済で、インストール前にそのノードに対して解決可能
他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある
次の特性がある、各ノードの仮想IPアドレス:
静的IPアドレス
各ノードでインストール前に構成済だが、現在は使用されていない
他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある
次の特性がある、クラスタの単一クライアント・アクセス名(SCAN):
SCANとして指定された名前に3つの静的IPアドレスが関連付けられ、そのすべてのアドレスがランダムな順序でDNSによってリクエスタに返されるように、インストール前にドメイン・ネーム・サーバー(DNS)上で静的IPアドレスが3つ構成されている
現在使用されていないアドレスに解決されるためにDNSでインストール前に構成済
数値以外で始まる名前が指定されている
他のすべてのパブリックIPアドレス、VIPアドレスおよびSCANアドレスと同じサブネット上にある
RFC 952標準に準拠し、英数字とハイフン("-")は使用できるが、アンダースコア("_")は使用できない
次の特性がある、各ノードのプライベートIPアドレス:
静的IPアドレス
インストール前に構成済だが、独自のサブネットを持つ別のプライベート・ネットワーク上では、他のクラスタ・メンバー・ノード以外が解決することはできない
SCANは、クラスタへのサービス・アクセスをクライアントに提供するために使用される名前です。SCANは、特定のノードではなくクラスタ全体に関連付けされているため、クライアントの再構成を必要とせずに、クラスタでノードを追加または削除することを可能にします。また、データベースに場所の独立性がもたらされるため、クライアント構成は特定のデータベースがどのノードで実行されているかに依存しません。クライアントは引き続き、以前のリリースと同じ方法でクラスタにアクセスできますが、クラスタにアクセスするクライアントではSCANの使用をお薦めします。
|
注意: 標準インストールでは、指定するSCANはクラスタ名でもあります。拡張インストールでは、SCANとクラスタ名はインストール時に別のフィールドに入力します。SCANおよびクラスタ名は両方とも長さ1文字以上15文字以下の英数字である必要があり、ハイフン(-)を含ることはできますが、先頭を数字にすることはできません。 |
nslookupコマンドを使用して、DNSによってSCANが正常にアドレスに関連付けられていることを確認できます。次に例を示します。
root@node1]$ nslookup mycluster-scan Server: dns.example.com Address: 192.0.2.001 Name: mycluster-scan.example.com Address: 192.0.2.201 Name: mycluster-scan.example.com Address: 192.0.2.202 Name: mycluster-scan.example.com Address: 192.0.2.203
インストール後、クライアントがクラスタにリクエストを送信すると、Oracle Clusterware SCANリスナーは、クライアント・リクエストをクラスタのサーバーにリダイレクトします。
|
注意: SCAN VIPアドレスの構成は、hostsファイルで行わないことを強くお薦めします。SCAN VIPにはDNS解決を使用します。SCANの解決にhostsファイルを使用すると、1つのIPアドレスへの解決しかできず、SCANアドレスは1つのみになってしまいます。サポートされているのは、DNSまたはホスト・ファイルでのSCANの構成のみです。Network Information Service(NIS)でのSCANの構成はサポートされていません。 |
ブロードキャスト通信(ARPおよびUDP)は、Oracle Grid Infrastructureリリース2パッチセット1(11.2.0.2)以上で使用するために構成されたすべてのパブリックおよびプライベート・インタフェース全体で適切に動作する必要があります。
ブロードキャストは、パブリックまたはプライベート・インタフェースによって使用されるものとして構成されたVLAN全体で動作する必要があります。
Oracle Grid Infrastructureリリース2(11.2)では、各クラスタ・メンバー・ノードで、Oracle mDNSデーモンがすべてのインタフェースでマルチキャスティングを使用して、クラスタの他のノードと通信します。
Oracle Grid Infrastructureリリース2パッチセット1(11.2.0.2)以上では、マルチキャスティングはプライベート・インターコネクトで必須です。このため、少なくとも次のクラスタでマルチキャスティングを有効にする必要があります。
プライベート・インターコネクトとして定義されたブロードキャスト・ドメイン全体
IPアドレス・サブネット範囲224.0.0.0/24および230.0.1.0/24
ルーター全体でマルチキャスト通信を有効にする必要はありません。
GNSを使用する場合、Oracle Grid Infrastructureのインストール前に、GNSが提供するサブドメイン(クラスタ・メンバー・ノード)に対する名前解決要求がGNSへ送信されるよう、ドメイン・ネーム・サーバー(DNS)を構成しておく必要があります。次にドメイン委任に必要な手順の概要を示します。実際の手順はこの例と異なる場合があります。
委任を使用してGNS名前解決要求を送信するようにDNSを構成します。
DNSでGNS仮想IPアドレスのエントリを作成します。アドレスの書式はgns-server.CLUSTERNAME.DOMAINNAMEです。たとえば、クラスタ名がmyclusterで、ドメイン名がexample.comで、IPアドレスが192.0.2.1の場合、次のようなエントリを作成します。
mycluster-gns.example.com A 192.0.2.1
指定したアドレスは、ルーティング可能である必要があります。
GNSでGNSサブドメインへのアドレスを解決できるように、GNS仮想IPアドレスへのGNSサブドメインの転送を設定します。これには、委任されたドメインに対して次のようなBIND構成エントリを作成します。cluster01.example.comは、委任するサブドメインです。
cluster01.example.com NS mycluster-gns.example.com
GNSを使用する場合、クラスタ内のノードのresolve.conf(または解決情報を提供するシステムのファイル)を構成し、社内のDNSサーバーに解決可能なネーム・サーバーのエントリを追加する必要があります。オプションの試行回数(リトライ回数)とオプションのタイムアウト(指数バックオフ)を組み合わせた合計タイムアウト時間の構成は、30秒以下にすることをお薦めします。たとえば、xxx.xxx.xxx.42とxxx.xxx.xxx.15がネットワーク内で有効なネーム・サーバーのアドレスである場合、/etc/resolv.confに次のようなエントリを入力します。
options attempts: 2 options timeout: 1 search cluster01.example.com example.com nameserver xxx.xxx.xxx.42 nameserver xxx.xxx.xxx.15
/etc/nsswitch.confによって、ネーム・サービスの参照順序が制御されます。一部のシステム構成では、ネットワーク情報システム(NIS)によってOracle SCANアドレス解決に問題が発生することがあります。nisエントリは、検索リストの最後に配置することをお薦めします。次に例を示します。
/etc/nsswitch.conf
hosts: files dns nis
|
注意: ホスト名およびユーザー名の解決が失敗する可能性があるため、NISを使用することがケーブルのプル・テストを実行するときの問題の原因になることがあることに注意してください。 |
GNSを使用する場合は、GNSのVIPアドレスに静的なIPアドレスを指定し、その静的なGNSのIPアドレスにサブドメインを委任する必要があります。
クラスタにノードが追加されると、社内のDHCPサーバーによって、これらのノードに動的にアドレスが提供されます。これらのアドレスは自動的にGNSに登録され、GNSによってサブドメイン内で、GNSに登録されたクラスタ・ノード・アドレスの解決が行われます。
アドレスの割当てと構成はGNSによって自動的に行われるため、これ以上の構成は必要ありません。Oracle Clusterwareによって、クラスタに対してノードが追加または削除されるときに、動的なネットワーク構成が行われます。参考までに例を示します。
2ノードのクラスタで、GNSのVIPが定義されている場合、インストール後に次のような構成を2ノードのクラスタに対して行います。クラスタ名はmycluster、GNSの親ドメインはexample.com、サブドメインはgrid.example.comです。IPアドレスの192.0.2はクラスタのパブリックIPアドレス・ネットワークを表し、192.168.0はプライベートIPアドレス・サブネットを表します。
表2-2 グリッド・ネーミング・サービスのネットワーク例
| 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を使用しない場合は、インストールの前に、パブリックIPアドレス、仮想IPアドレスおよびプライベートIPアドレスを構成する必要があります。また、pingコマンドを実行し、デフォルトのゲートウェイにアクセスできることも確認してください。デフォルトのゲートウェイを検出するには、routeコマンドを使用します(オペレーティング・システムのヘルプを参照)。
たとえば、各ノードに1つのパブリック・インタフェースと1つのプライベート・インタフェースがある2ノードのクラスタの場合に、3つのIPアドレスのいずれかに解決されるSCANドメイン・アドレスがDNSに定義してあるとすると、ネットワーク・インタフェースには、次の表に示す構成が考えられます。
表2-3 手動によるネットワークの構成例
| ID | ホーム・ノード | ホスト・ノード | 指定された名前 | 種類 | アドレス | アドレスの割当て元 | 解決方法 |
|---|---|---|---|---|---|---|---|
|
ノード1パブリック |
ノード1 |
|
|
パブリック |
192.0.2.101 |
固定 |
DNS |
|
ノード1 VIP |
ノード1 |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.104 |
固定 |
DNSおよびhostsファイル |
|
ノード1プライベート |
ノード1 |
|
|
プライベート |
192.168.0.1 |
固定 |
DNSおよびhostsファイル、またはなし |
|
ノード2パブリック |
ノード2 |
|
|
パブリック |
192.0.2.102 |
固定 |
DNS |
|
ノード2 VIP |
ノード2 |
Oracle Clusterwareにより選択 |
|
仮想 |
192.0.2.105 |
固定 |
DNSおよびhostsファイル |
|
ノード2プライベート |
ノード2 |
|
|
プライベート |
192.168.0.2 |
固定 |
DNSおよびhostsファイル、またはなし |
|
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 ノード・ホスト名が、複数のアドレスに解決される場合があります。
インターコネクト用にプライベート名を指定する必要はありません。インターコネクト用に名前解決が必要な場合は、hostsファイルかDNSでプライベートIP名を構成できます。ただしOracle Clusterwareでは、インストール中にプライベート・インタフェースとして定義されたインタフェース(eth1など)と、プライベート・サブネットに使用されるサブネットに、インターコネクト・アドレスが割り当てられます。
SCANが解決されるアドレスはOracle Clusterwareによって割り当てられるため、特定のノードには固定されません。VIPのフェイルオーバーが有効になるように、前述の表で示した構成では、SCANアドレスと、両方のノードのパブリック・アドレスおよびVIPアドレスが同一のサブネット(192.0.2)上に定義されています。
|
注意: すべてのホスト名はRFC 952標準(英数字を許可)に準拠している必要があります。アンダースコア(_)を使用するホスト名は使用できません。 |
選択する正確なネットワーク構成は、構成するクラスタのサイズおよび使用方法と、必要な可用性のレベルによって異なります。
動作保証されているネットワーク接続ストレージ(NAS)をOracle RAC用に使用し、このストレージにイーサネットベースのネットワークを介して接続する場合は、NAS I/O用に3つ目のネットワーク・インタフェースが必要です。この場合、3つの別々のインタフェースを使用しないと、負荷によってパフォーマンスと安定性の問題が発生します。
Oracle ClusterwareがNASデバイスまたはNFSマウントの使用によるネットワーク障害をより許容できるようにするには、ネーム・サービス・キャッシュ・デーモン(nscd)を有効にします。nscdは、ほとんどの共通ネーム・サービス要求に対するキャッシング・メカニズムを提供します。システムがマルチユーザーの状態で起動すると、自動的に起動します。Oracleソフトウェアでは、Oracle Solarisのデフォルトであるマルチユーザー実行レベル(3)でサーバーが起動される必要があります。
サーバーが3に設定されているかどうかを確認するには、コマンドwho -rを入力します。次に例を示します。
# who -r . run-level 3 Jan 4 14:04 3 0 S
実行レベルの変更が必要な場合は、ご使用のオペレーティング・システムのドキュメントを参照してください。
ネーム・サービス・キャッシュ・デーモンが実行されていることを確認するには、次のコマンドを入力します。
# svcs svc:/sysstem/name-service-cache STATE STIME FMRI online Aug_28 svc:/system/name-service-cache:default
また、コマンドps -aef |grep nscdを入力することもできます。
サービス管理機能(SMF)がシステムで有効になっているかどうか、およびmulti-userとmulti-user-serverの各サービスがオンラインになっているかどうかを確認するには、次のようにsvcs svcコマンドを使用します。
# svcs svc:/milestone/multi-user STATE STIME FMRI online Aug_28 svc:/milestone/multi-user:default # svcs svc:/milestone/multi-user-server STATE STIME FMRI online Aug_28 svc:/milestone/multi-user-server:default
インストールする製品に応じて、次のオペレーティング・システム・ソフトウェアがシステムにインストールされていることを確認します。パッチ要件は、最小限必要なパッチのバージョンであり、下位のパッチ番号は、上位のパッチ更新に含まれていることに注意してください。
ここに記載されている要件は、初回リリース日時点で最新のものです。カーネル要件の最新情報については、Oracle Technology Network(OTN)を参照してください。URLは次のとおりです。
http://www.oracle.com/technetwork/indexes/documentation/index.html
ソフトウェア要件を確認するには、2.9項「ソフトウェア要件の確認」を参照してください。
OUIによって、ご使用のシステムが示されたオペレーティング・システムの要件を満たしていることを確認する検証が実行されます。これらの検証が正常に完了するように、OUIを起動する前に要件を確認してください。
サポートされているOracle Solarisプラットフォームおよびリリース時における要件は、次のとおりです。
表2-4 Oracle Solaris(SPARC 64-bit)のシステム要件
| 項目 | 要件 |
|---|---|
|
Oracle Solaris 11用のオペレーティング・システム、パッケージおよびパッチ |
Oracle Grid Infrastructure release 11.2.0.3以上の場合は、Oracle Solaris 11 (11/2011 SPARC)以上。 pkg://solaris/developer/build/make pkg://solaris/developer/assembler 特別なカーネル・パラメータまたはパッチは、現時点では必要ありません。 |
|
Oracle Solaris 10用のオペレーティング・システム、パッケージおよびパッチ |
Oracle Solaris 10 U6 (5.10-2008.10)。 SUNWarc SUNWbtool SUNWcsl SUNWhea SUNWi1cs (ISO8859-1) SUNWi15cs (ISO8859-15) SUNWi1of SUNWlibC SUNWlibm SUNWlibms SUNWsprot SUNWtoo SUNWxwfnt 119963-14: Sun OS 5.10: Shared Library Patch for C++ 120753-06: SunOS 5.10: Microtasking libraries (libmtsk) patch 139574-03: SunOS 5.10 141414-02 141414-09 (11.2.0.2 or later) 146808-01 (for Solaris 10 U9 or earlier) 注意: ロケールに応じて、追加のJava用フォント・パッケージが必要になる場合があります。詳細は、次のWebサイトを参照してください。
|
|
Database Smart Flash Cache(Enterprise Edition専用の機能) |
フラッシュ・キャッシュ機能を使用している場合、Oracle Solaris(SPARC 64-bit)では次のパッチが必要です。 125555-03 139555-08 140796-01 140899-01 141016-01 141414-10 141736-05 |
|
IPMI |
次のパッチは、SPARCシステムでIPMIを使用して障害分離を構成する場合にのみ必要です。 137585-05 or later (IPMItool patch) 137594-02 or later (BMC driver patch) また、ご使用のファームウェアに追加のパッチが必要な場合もあります。追加情報については、第2.15項「Intelligent Platform Management Interface(IPMI)の有効化」 を参照してください。 |
|
Oracle RAC |
Oracle Clusterwareは必要であり、Oracle Solaris ClusterはSPARC上のOracle RACで使用する場合にサポートされています。Oracle Solaris Cluster 3.2を使用する場合は、次の追加のカーネル・パッケージおよびパッチをインストールする必要があります。 SUNWscucm 3.2.0: 126106-40 VERSION=3.2.0、REV=2006.12.05.22.58以上。 125508-08 125514-05 125992-04 126047-11 126095-05 126106-33 注意: Oracle Clusterwareのみを使用し、Oracle Solaris Clusterがない場合、追加のパッケージは必要ありません。 ボリューム・マネージャを使用する場合は、追加のカーネル・パッケージのインストールが必要になる場合があります。 |
|
Oracle Solaris Cluster用のパッケージおよびパッチ |
注意: Oracle Clusterwareをインストールする場合は、Oracle Solaris Clusterは必要ありません。 Oracle Solaris 11の場合、Oracle Solaris Clusterのサポートされる最低バージョンはOracle Solaris Cluster 4.0です。 Oracle Solaris 10の場合、Oracle Solaris Cluster 3.3以上。 UDLM(オプション):
注意: 詳細は、第2.8項「SPARCでのOracle Solaris Cluster構成のガイドライン」を参照してください。 SPARC上のOracle Solaris Clusterの場合は、Oracle RACのインストールおよび構成を行う前に、OracleによりGrid_home |
|
Oracle Messaging Gateway |
Oracle Messaging Gatewayは、Oracle Streams Advanced Queuing(AQ)と次のソフトウェアの統合をサポートします。 IBM MQSeries V6(6.6.0)クライアントおよびサーバー Tibco Rendezvous 7.2 |
|
Pro*C/C++、 |
Oracle Solaris Studio 12(以前のSun Studio)(CおよびC++ 5.9) 119963-14: SunOS 5.10: C++用共有ライブラリ・パッチ 124863-12: C++ SunOS 5.10: Sun C C++用コンパイラ共通パッチ(オプション) |
|
gcc 3.4.2 Open Database Connectivity(ODBC)パッケージは、ODBCを使用する計画の場合にのみ必要です。ODBCを使用しない場合は、Oracle Clusterware、Oracle ASMまたはOracle RACにODBC RPMをインストールする必要はありません。 |
|
Oracle Solaris Studio 12(Fortran 95) 次のURLからダウンロードします。
|
|
|
Oracle JDBC/OCIドライバ |
Oracle JDBC/OCIドライバでは、次の任意のJDKバージョンを使用できますが、インストールには必要ありません。
注意: Oracle Solaris 11でサポートされる最低レベルのJDKはJDK 6です。 |
|
SSH |
Oracle ClusterwareにはSSHが必要です。必須のSSHソフトウェアは、オペレーティング・システムに付属するデフォルトのSSHです。 |
表2-5 Oracle Solaris(x86 64-bit)のシステム要件
| 項目 | 要件 |
|---|---|
|
Oracle Solaris 11のオペレーティング・システムおよびパッケージ |
Oracle Grid Infrastructure release 11.2.0.3以上の場合は、Oracle Solaris 11 (11/2011 X86)以上。 pkg://solaris/developer/build/make pkg://solaris/developer/assembler 特別なカーネル・パラメータまたはパッチは、現時点では必要ありません。 |
|
Oracle Solaris 10のパッケージおよびパッチ |
Oracle Solaris 10 U6 (5.10-2008.10)以上。 SUNWarc SUNWbtool SUNWcsl SUNWhea SUNWlibC SUNWlibm SUNWlibms SUNWsprot SUNWtoo SUNWi1of SUNWi1cs (ISO8859-1) SUNWi15cs (ISO8859-15) SUNWxwfnt 119961-05: SunOS 5.10_x86: Assembler 119964-14: SunOS 5.10_x86 Shared library patch for C++_x86 120754-06: SunOS 5.10_x86 libmtsk 137104-02 139575-03 139556-08 141415-04 注意: ロケールに応じて、追加のJava用フォント・パッケージが必要になる場合があります。詳細は、次のWebサイトを参照してください。
|
|
Database Smart Flash Cache(Enterprise Edition専用の機能) |
フラッシュ・キャッシュ機能を使用している場合、Oracle Solaris(x86 64-bit)では次のパッチが必要です。 139556-08 140797-01 140900-01 141017-01 141415-10 141737-05 |
|
IPMI |
また、ご使用のファームウェアに追加のパッチが必要な場合もあります。追加情報については、第2.15項「Intelligent Platform Management Interface(IPMI)の有効化」 を参照してください。 |
|
Oracle Solaris Cluster |
注意: Oracle Clusterwareをインストールする場合は、Oracle Solaris Clusterは必要ありません。 Oracle Solaris 11の場合、Solaris Clusterのサポートされる最低バージョンはOracle Solaris Cluster 4.0です。 Oracle Solaris 10については、Oracle Solaris Clusterを使用する場合、次の追加のカーネル・パッケージおよびパッチ(以降の更新)をインストールする必要があります。 Oracle Solaris Cluster 3.2 Update 2 SUNWscucm 3.2.0: 126107-40 VERSION=3.2.0、REV=2006.12.05.21.06 125509-10 125515-05 125993-04 126048-11 126096-04 126096-05 126107-33 137104-02 ボリューム・マネージャを使用する場合は、追加のカーネル・パッケージのインストールが必要になる場合があります。 Oracle Solaris Cluster 3.3または3.3.5/11を使用する場合は、Oracle Solaris Clusterドキュメント・ライブラリを参照してください。特に、Data Service for Oracle Real Application Clustersガイドを参照してください。 |
|
Oracle Messaging Gateway |
Oracle Messaging Gatewayは、Oracle Streams Advanced Queuing(AQ)と次のソフトウェアの統合をサポートします。 IBM MQSeries V6クライアントおよびサーバー |
|
Pro*C/C++、 |
Oracle Solaris Studio 12(以前のSun Studio)September 2007 Release(次のパッチを適用済): デプロイするアプリケーションに応じて、追加のパッチが必要な場合があります。 Oracle Solaris Studioを次のURLからダウンロードします。
|
|
gcc 3.4.2 Open Database Connectivity(ODBC)パッケージは、ODBCを使用する計画の場合にのみ必要です。ODBCを使用しない場合は、Oracle Clusterware、Oracle ASMまたはOracle RACにODBC RPMをインストールする必要はありません。 |
|
|
|
|
Oracle JDBC/OCIドライバ |
Oracle JDBC/OCIドライバでは、次の任意のJDKバージョンを使用できますが、インストールには必要ありません。
注意: Oracle Solaris 11でサポートされる最低レベルのJDKはJDK 6です。 |
|
SSH |
Oracle ClusterwareにはSSHが必要です。必須のSSHソフトウェアは、オペレーティング・システムに付属するデフォルトのSSHです。 |
SPARCプロセッサのサーバーにOracle Grid Infrastructureをインストールする場合は、次の情報を確認します。
Oracle Solaris Cluster 3.3または3.3.5/11を使用する場合は、Oracle Grid InfrastructureのインストールおよびOracle RACのインストールを開始する前に、Oracle Solaris Clusterドキュメント・ライブラリを参照してください。特に、Oracle Solaris Cluster Data Service for Oracle Real Application Clustersガイドを参照してください(次のURLで参照可能)。
http://download.oracle.com/docs/cd/E18728_01/html/821-2852/index.html
UDLMおよびネイティブのクラスタ・メンバーシップ・インタフェースに関する次の追加情報を確認します。
Oracle Solaris Cluster 3.3以上では、UDLMを使用しないことをお薦めします。かわりに、UDLMがデプロイされていない場合にOracle Solaris Cluster 3.3とともに自動的にインストールされる、ネイティブのクラスタ・メンバーシップ・インタフェース機能(ネイティブSKGXN)を使用することをお薦めします。このインタフェースを使用するのに追加のパッケージは必要ありません。
UDLMを使用する場合は、このリリースでサポートされるOracle Solaris ClusterバージョンのORCLudlmパッケージをインストールする必要があります。
ネイティブのOracle Solaris ClusterインタフェースとUDLMインタフェースは同じOracle RACクラスタに共存できないため、Oracle RACクラスタのすべてのノードにORCLudlmがインストールされているか、Oracle RACクラスタのどのノードにもORCLudlmがインストールされていないかのいずれかである必要があります。
Oracle Solarisコンテナ(ゾーンと呼ばれます)を使用すると、1つの物理サーバーで複数のOracle RACクラスタをホストでき、それぞれが独立したコンテナ・クラスタ内にあります。これらの各コンテナ・クラスタは、使用されるメンバーシップ・モデルに関して自己一貫性がある必要があります。ただし、各コンテナ・クラスタは独立した環境であるため、ゾーン・クラスタを使用すると、1つの物理システムでORCLudlmのOracle RACクラスタとネイティブのクラスタ・メンバーシップ・インタフェースのOracle RACクラスタを組み合せることができます。
システムがこれらの要件を満たしていることを確認するには、次の手順を実行します。
インストールされているOracle Solarisのバージョンを確認するには、次のコマンドを入力します。
# uname -r 5.11
この例で示されているバージョンは、Oracle Solaris 11(5.11)です。必要な場合、オペレーティング・システムのアップグレードについては、ご使用のオペレーティング・システムのマニュアルを参照してください。
次のコマンドを入力して、必要なパッケージがインストールされているかどうかを確認します。
# pkginfo -i SUNWarc SUNWbtool SUNWhea SUNWlibC SUNWlibm SUNWlibms SUNWsprot \ SUNWtoo SUNWi1of SUNWi1cs SUNWi15cs SUNWxwfnt SUNWcsl
システム・アーキテクチャに必要なパッケージがインストールされていない場合は、インストールします。パッケージのインストールについては、ご使用のオペレーティング・システムまたはソフトウェアのマニュアルを参照してください。
|
注意: 表示されたパッケージのより新しいバージョンが、システムにインストールされている場合があります。表示されたパッチがインストールされていない場合は、そのバージョンをインストールする前に、より新しいバージョンがインストールされていないことを確認してください。 |
NDDを使用して、Oracle SolarisカーネルのTCP/IPエフェメラル・ポート範囲が、サーバーの予測負荷に対応できる十分なエフェメラル・ポートを提供できるほど広いことを確認します。下限を9000以上に設定し、Well KnownポートとOracleおよびその他のサーバー・ポートで一般的に使用される登録済ポート範囲のポートを避けます。ポート範囲は、使用する予定のアプリケーションに予約されているポートを避けるために十分に高く設定します。範囲の下限が9000を超え、予想されるワークロードに対して範囲が十分大きい場合は、エフェメラル・ポート範囲に関するOUI警告は無視できます。
次のコマンドを使用して、エフェメラル・ポートの現在の範囲を確認します。
# /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port 32768 65535
上の例で、tpc_smallest_anon_portはデフォルトの範囲(32768から65535)に設定されています。
予測負荷やサーバー数に対応できるように、必要に応じて、UDPおよびTCPエフェメラル・ポートの範囲をより広い範囲に更新します。次に例を示します。
# /usr/sbin/ndd -set /dev/tcp tcp_smallest_anon_port 9000 # /usr/sbin/ndd -set /dev/tcp tcp_largest_anon_port 65500 # /usr/sbin/ndd -set /dev/udp udp_smallest_anon_port 9000 # /usr/sbin/ndd -set /dev/udp udp_largest_anon_port 65500
これらの設定は永続的にすることをお薦めします。システムの再起動時にこのエフェメラル・ポートの範囲変更を自動で行う方法の詳細は、Oracle Solarisシステムの管理ドキュメントを参照してください。
Solarisプラットフォームでは、/etc/pam.confファイルが、システム上のユーザーを制御および制限します。ユーザーによるサービス拒否攻撃を行えないようにするには、システムのユーザーに対して、ログイン時にリソース制御および制限が設定される必要があります。
Solarisオペレーティング・システムに対して、PAMリソース制限はデフォルトでは設定されません。このようなリソース制限が行われるようにするには、/etc/pam/confのlogin serviceセクションに次の行を追加します。
login auth required pam_dial_auth.so.1
次に例を示します。
# login service (explicit because of pam_dial_auth) # login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 #
|
注意: 表示されたパッチのより新しいバージョンが、システムにインストールされている場合があります。表示されたパッチがインストールされていない場合は、そのバージョンをインストールする前に、より新しいバージョンがインストールされていないことを確認してください。 |
ご使用のシステム・アーキテクチャの表を選択して、必要なパッチを持っているかを確認します。
システムがこれらの要件を満たしていることを確認するには、次の手順を実行します。
オペレーティング・システム・パッチがインストールされているかどうかと、それが適切なバージョンなのかを確認するには、次のようなコマンドを入力します。
# /usr/sbin/patchadd -p | grep patch_number
たとえば、いずれかのバージョンの119963パッチがインストールされているかを確認するには、次のコマンドを使用します。
# /usr/sbin/patchadd -p | grep 119963
オペレーティング・システム・パッチがインストールされていない場合は、次のWebサイトからダウンロードして、インストールします。
http://support.oracle.com
Oracle Solarisを実行するx86-64プラットフォームでは、Oracle Clusterwareに加えてOracle Solaris Clusterをインストールする場合、次のタスクを実行します。
ユーザーをrootに切り替えます。
$ su - root
インストールの場所に応じて、次のいずれかの手順を実行します。
インストール・ファイルがDVDにある場合、次のようなコマンドを入力します。mountpointは、ディスク・マウント・ポイント・ディレクトリ、またはDVD上のデータベース・ディレクトリのパスです。
# mountpoint/clusterware/rootpre.sh
インストール・ファイルがハード・ディスクにある場合は、/Disk1に移動してから、次のコマンドを入力します。
# ./rootpre.sh
rootアカウントを終了します。
# exit
クラスタ内のすべてのノードで手順1から3を繰り返します。
Oracle Clusterwareでは、すべてのクラスタ・ノードで同じのタイムゾーン設定が必要です。インストール中に、インストール・プロセスは、OUIを実行しているノードでグリッド・インストール所有者のタイムゾーン設定を選択し、Oracle Clusterwareによって管理されるすべてのプロセスのデフォルトのTZ設定として、すべてのノードでその設定を使用します。このデフォルトは、データベース、Oracle ASMおよびその他の管理プロセスで使用されます。
時刻を同期させるための手段は2つあります。オペレーティング・システムに構成されているネットワーク・タイム・プロトコル(NTP)と、Oracleクラスタ時刻同期化サービスです。Oracleクラスタ時刻同期化サービスは、クラスタ・サーバーからNTPサービスにアクセスできない組織のために設計されています。NTPを使用する場合は、Oracleクラスタ時刻同期化デーモン(ctssd)がオブザーバ・モードで起動します。NTPデーモンがない場合は、ctssdがアクティブ・モードで起動し、外部の時刻サーバーに接続しなくても、クラスタ・メンバー間の時刻が同期されます。
Oracle Solaris Clusterシステムでは、Oracle Solaris Clusterソフトウェアによって、すべてのクラスタ・ホスト間でピア関係を確立するntp.cluster(インストール済クラスタ・ホストの/etc/inet/ntp.clusterを参照)というテンプレート・ファイルが提供されます。1つのホストを優先ホストとして指定します。ホストは、プライベート・ホスト名によって識別されます。クラスタ・インターコネクト全体で時刻の同期が行われます。/etc/inet/ntp.confファイルまたは/etc/inet/ntp.conf.clusterファイルで、Oracle Solaris Cluster NTPまたは外部のNTPサーバーがシステムのデフォルトのNTPサーバーに設定されていることがOracle Clusterwareで検出された場合、CTSSはオブザーバ・モードに設定されます。
|
注意: Oracle Grid Infrastructureのインストールを開始する前に、すべてのノードの時計が同じ時刻になっていることを確認することをお薦めします。 |
サーバー上にNTPデーモンがあっても時間サーバーの時刻と同期されるように構成できない場合に、クラスタ時刻同期化サービスを使用してクラスタ内で同期化サービスを提供する場合は、NTPを非アクティブにし、削除します。
NTPサービスを無効化するには、次のコマンドをrootユーザーとして実行します。
# /usr/sbin/svcadm disable ntp
NTPプロトコルがアクティブでないとインストーラによって判断されると、クラスタ時刻同期化サービスがアクティブ・モードでインストールされ、ノード間で時刻が同期されます。NTPが構成されていると判断された場合は、クラスタ時刻同期化サービスはオブザーバ・モードで起動され、クラスタ内でOracle Clusterwareによるアクティブな時刻同期化は行われません。
インストール後にctssdがアクティブになっていることを確認するには、グリッド・インストール所有者として次のコマンドを入力します。
$ crsctl check ctss
NTPを使用しており、クラスタ時刻同期化サービスではなくNTPを使用し続ける場合は、NTP初期化ファイルを変更してスルーイングを有効にし、逆向きの時間調整が行われないようにします。この作業が終わった後で、ネットワーク・タイム・プロトコル・デーモンを再起動します。
Oracle Sun Clusterを使用せずにOracle Solarisでこのことを行うには、/etc/inet/ntp.confファイルを編集して、slewalways yesおよびdisable pllをファイルに追加します。これらの変更を行った後、コマンド/usr/sbin/svcadm restart ntpを使用して、ntpd (Oracle Solaris 11の場合)またはxntpd (Oracle Solaris 10の場合)を再起動します。
Oracle Solaris Sun Cluster 4.0を使用してOracle Solaris 11でこのことを行うには、/etc/inet/ntp.conf.scファイルを編集して、slewaways yesおよびdisablepllをファイルに追加します。これらの変更を行った後、コマンド/usr/sbin/svcadmn restart ntpを使用して、ntpdまたはxntpdを再起動します。Oracle Sun Cluster 3.2を使用してOracle Solaris 10でこのことを行うには、/etc/inet/ntp.conf.clusterファイルを編集します。
無効化されたNTPを有効化するには、次のコマンドを入力します。
# /usr/sbin/svcadm enable ntp
Intelligent Platform Management Interface(IPMI)は、コンピュータのハードウェアおよびファームウェアへの共通インタフェースを提供し、システム管理者はそのインタフェースを使用して、システム状態の監視およびシステムの管理を実行できます。Oracle 11g リリース2では、Oracle ClusterwareにIPMIを統合して、障害分離をサポートしたりクラスタの整合性を確保することができます。
現在、Oracle ClusterwareではOracle SolarisでネイティブIPMIドライバをサポートしていないため、OUIでは管理者資格証明が収集されず、CSSではIPアドレスを取得できません。インストール前に静的IPアドレスを使用してBMCを構成し、インストール後にcrsctlを使用してIPアドレスおよびIPMI資格証明を格納することによって、障害分離を手動で構成する必要があります。
この項の内容は次のとおりです。
|
関連項目: インストール後にIPMIの構成を行う方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
クラスタ・ノードをIPMIで管理できるようするには、次のようにハードウェアおよびソフトウェアを構成する必要があります。
各クラスタ・メンバー・ノードにBaseboard Management Controller(BMC)が必要です。このBMCは、IPMI over LANをサポートするIPMIバージョン1.5以上と互換性があるファームウェアを実行し、LANを使用したリモート制御に対応するように構成されている必要があります。
クラスタに、IPMI用の管理ネットワークが必要です。これは共有ネットワークでも可能ですが、専用ネットワークの構成をお薦めします。
BMCで使用する各クラスタ・メンバー・ノードのポートが、IPMI管理ネットワークに接続されている必要があります。
各クラスタ・メンバーが管理ネットワークに接続されている必要があります。
一部のサーバー・プラットフォームでは、電源を切るとネットワーク・インタフェースが省電力モードになります。この場合には、低いリンク速度(1GBではなく100MBなど)で動作することになります。こうしたプラットフォームの場合、BMCが接続されるネットワーク・スイッチ・ポートで、低い速度に合わせた自動ネゴシエートが可能である必要があります。そうでない場合は、IPMIが正常に動作しません。
第2.15.1.1項「IPMIファームウェア・パッチ」で説明するとおり、IPMIファームウェア・パッチをインストールおよび構成します。
Oracleは、Sunシステム上のIPMIファームウェアのパッチレベル情報を提供しています。次のURLで、ご使用のファームウェアに必要なパッチ・バージョンを入手します。
http://www.oracle.com/technetwork/systems/patches/firmware/index.html
各クラスタ・メンバー・ノードに次をインストールします。
Sun Blade T6340 Server Module Sun System Firmware(LDOMSサポート)
139448-03
SPARC Enterprise T5440 Sun System Firmware(LDOMSサポート)
139446-03
Netra T5440 Sun System Firmware(LDOMSサポート)
139445-04
SPARC Enterprise T5140 & T5240 Sun System Firmware LDOMS
139444-03
Netra T5220 Sun System Firmware(LDOMSサポート)
139442-06
Sun Blade T6320 + T6320-G2 Server Module Sun System Firmware(LDOMSサポート)
139440-04
SPARC Enterprise T5120 & T5220 Sun System Firmware(LDOMSサポート)
139439-04
Oracle Solarisプラットフォームでは、BMCは構成情報をIntegrated Lights Out Manager(ILOM)サービス・プロセッサと共有します。Oracle Clusterwareの場合は、ILOM/BMCを静的IPアドレス用に構成する必要があります。Oracle Solarisでは、BMCを動的アドレス(DHCP)を使用して構成することはサポートされていません。
|
注意: IPMIを構成し、グリッド・ネーミング・サービス(GNS)を使用する場合でも、IPMIインタフェースには別のアドレスを構成する必要があります。IPMIアダプタはホストから直接には認識できないため、GNSはホスト上のアドレスとしてIPMIアダプタを認識できません。 |
各ノードで、次の手順を実行してIPMIベースのノード・フェンシングをサポートするようにBMCを構成します。
IPMI over LANを有効にして、管理ネットワーク経由でBMCを制御できるようにします。
BMC用に静的IPアドレスを構成します。
BMCの管理者ユーザー・アカウントおよびパスワードを設定します。
BMCをタグVLANで使用する場合は、VLANのタグに対応するようにBMCを構成します。
使用する構成ツールは問いませんが、BMCが正しく機能するには、これらの条件を満たしている必要があります。
BMCの構成の詳細は、選択した構成オプションのドキュメントを参照してください。
|
注意: Oracle Solarisソフトウェアおよびファームウェアの初回リビジョンの問題によって、IPMIサポートは正常に動作しませんでした。ご使用のプラットフォーム用の最新のファームウェアおよび次のバージョン以上のOracle Solarisパッチを入手していることを確認してください(次のURLから入手可能)。
|
ILOM Webインタフェースにログインするときに、次の手順でパラメータを構成して、IPMIを有効化します。
「Configuration」→「System Management Access」→「IPMI」の順にクリックします。「Enabled」をクリックして、IPMI over LANを有効化します。
「Configuration」→「Network」順にクリックします。IPアドレス、ネットマスクおよびデフォルトのゲートウェイの情報を入力します。
「User Management」→「User Account Settings」の順にクリックします。IPMI管理者アカウントのユーザー名およびパスワードを追加して、ロールを「Administrator」に設定します。
ユーティリティipmitoolがOracle Solarisディストリビューションの一部として提供されています。ipmitoolを使用してIPMIパラメータを構成することはできますが、ipmitoolを使用してパラメータを設定すると、サービス・プロセッサに対応するパラメータも設定されることに注意してください。
次に示すのは、ipmitool(バージョン1.8.6)を使用してBMCを構成する例です。
rootユーザーでログインします。
ipmitoolが、IPMIドライバを使用してBMCと通信できることを確認します。これを行うには、コマンドbmc infoを使用して、その出力からデバイスIDを探します。次に例を示します。
# ipmitool bmc info Device ID : 32 . . .
ipmitoolがBMCと通信していない場合は、「BMCの構成」の項を参照して、IPMIドライバが動作しているかどうかを確認します。
次の手順で、IPMI over LANを有効にします。
IPMI over LANに使用するチャネルの、チャネル番号を決めます。チャネル1から始めて、LAN属性(IPアドレスなど)が表示されるチャネルが見つかるまで、次のコマンドを実行します。
# ipmitool lan print 1 . . . IP Address Source : 0x01 IP Address : 140.87.155.89 . . .
検出されたチャネルに対してLANアクセスを有効にします。たとえば、チャネルが1の場合は次のようにします。
# ipmitool -I bmc lan set 1 access on
静的IPアドレスの設定手順を使用して、IPMIのIPアドレス設定を構成します。
静的IPアドレスを使用する場合
ネットワーク接続をBMCとILOMで共有する場合は、IPアドレスが同じサブネット上にあることが必要です。IPアドレスを設定するだけでなく、ネットマスクの値およびデフォルト・ゲートウェイも適切に設定する必要があります。たとえば、チャネルが1の場合は次のようにします。
# ipmitool -I bmc lan set 1 ipaddr 192.168.0.55 # ipmitool -I bmc lan set 1 netmask 255.255.255.0 # ipmitool -I bmc lan set 1 defgw ipaddr 192.168.0.1
指定したアドレス(192.168.0.55)は、BMCのみに関連付けられます。通常のpingに応答することはありません。
次の手順を実行して、ユーザー名とパスワードを管理アカウントに設定します(チャネルは1を想定しています)。
LAN経由のADMINアクセスに対してパスワード認証を要求するようにBMCを設定します。次に例を示します。
# ipmitool -I bmc lan set 1 auth ADMIN MD5,PASSWORD
BMC上のアカウント・スロットをリストして、使用されていないスロット(ユーザー名フィールドが空のユーザーID)を特定します。次に例を示します。
# ipmitool channel getaccess 1 . . . User ID : 4 User Name : Fixed Name : No Access Available : call-in / callback Link Authentication : disabled IPMI Messaging : disabled Privilege Level : NO ACCESS . . .
任意の管理者ユーザー名およびパスワードを割り当て、特定したスロットに対してメッセージ機能を有効にします。(IPMI v1.5の場合、ユーザー名およびパスワードは最長で16文字です。)さらに、そのスロットがLAN(チャネル1)経由でアクセスされる場合の権限レベルをADMIN(レベル4)に設定します。たとえば、username が管理ユーザー名で、password がパスワードの場合は、次のようになります。
# ipmitool user set name 4 username # ipmitool user set password 4 password # ipmitool user enable 4 # ipmitool channel setaccess 1 4 privilege=4 # ipmitool channel setaccess 1 4 link=on # ipmitool channel setaccess 1 4 ipmi=on
lan print 1コマンドを使用して、設定を確認します。出力結果は、次のようになります。太字のテキストで示した項目は、前述の構成手順で設定した内容です。コメントや代替オプションは、カッコ[ ]内に示しています。
# ipmitool lan print 1
Set in Progress : Set Complete
Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback : MD2 MD5
: User : MD2 MD5
: Operator : MD2 MD5
: Admin : MD5 PASSWORD
: OEM : MD2 MD5
IP Address Source : DHCP Address [or Static Address]
IP Address : 192.168.0.55
Subnet Mask : 255.255.255.0
MAC Address : 00:14:22:23:fa:f9
SNMP Community String : public
IP Header : TTL=0x40 Flags=0x40 Precedence=…
Default Gateway IP : 192.168.0.1
Default Gateway MAC : 00:00:00:00:00:00
.
.
.
# ipmitool channel getaccess 1 4
Maximum User IDs : 10
Enabled User IDs : 2
User ID : 4
User Name : username [This is the administration user]
Fixed Name : No
Access Available : call-in / callback
Link Authentication : enabled
IPMI Messaging : enabled
Privilege Level : ADMINISTRATOR
クラスタ内のリモート・ノードからBMCにアクセスして管理できることを、bmc infoコマンドで確認します。たとえば、node2のBMCのIPアドレスを割り当てられたネットワーク・ホスト名がnode2-ipmiの場合、管理者アカウントusernameを使用してnode1からnode2上のBMCを確認し、node1で次のコマンドを入力します。
$ ipmitool -H node2-ipmi -U username lan print 1
パスワードを求めるプロンプトが表示されます。IPMIパスワードを入力します。
BMCが正しく構成されている場合は、リモート・ノードのBMCに関する情報が表示されます。Error: Unable to establish LAN sessionなどのエラー・メッセージが表示された場合は、リモート・ノードのBMC構成を確認する必要があります。
この処理を各クラスタ・メンバー・ノードに対して繰り返します。
インストールした後、第5.2.2項「Crsctlを使用したIPMIベースの障害分離の構成」で説明するとおり、IPMIを構成します。
Oracleソフトウェアをインストールするには、すべてのクラスタ・メンバー・ノード間にセキュア・シェル(SSH)の接続が設定されている必要があります。OUIは、インストール中にsshおよびscpコマンドを使用して、他のクラスタ・ノードに対してリモート・コマンドを実行し、そのクラスタ・ノードにファイルをコピーします。これらのコマンドを使用する際にパスワードを求めるプロンプトが表示されないように、SSHを構成する必要があります。
|
注意: SSHは、Oracleコンフィギュレーション・アシスタントによる、ローカル・ノードからリモート・ノードに対する構成操作に使用されます。Oracle Enterprise Managerでも使用されます。 |
OUIインタフェースから、インストール中に、インストールを実行しているユーザー・アカウントにSSHを構成することができます。自動構成によって、パスワードなしのSSH接続をすべてのクラスタ・メンバー・ノード間に作成することができます。可能なかぎり、この自動手順を利用することをお薦めします。
スクリプトを実行できるようにするには、すべてのOracleソフトウェア・インストール所有者のプロファイルからsttyコマンドを削除するとともに、ログイン時にトリガーされる他のセキュリティ手段で、端末に対してメッセージを生成するものを削除する必要があります。これらのメッセージやメール・チェックなどが表示されていると、Oracleソフトウェア・インストール所有者は、Oracle Universal Installerに組み込まれているSSH構成スクリプトを使用できません。これらの表示が無効になっていない場合は、SSHを手動で構成してからでなければ、インストールを実行できません。
デフォルトでは、OUIはディレクトリ/usr/local/etc/でSSH公開鍵、/usr/local/binでssh-keygenバイナリを検索します。ただし、Oracle Solarisの場合、SSH公開鍵は通常はパス/etc/sshにあり、ssh-keygenバイナリはパス/usr/binにあります。OUIでSSHを設定できるようにするには、次のコマンドを使用してソフト・リンクを作成します。
# ln -s /etc/ssh /usr/local/etc # ln -s /usr/bin /usr/local/bin
まれに、リモート・ノードがSSH接続を閉じると、「AttachHome」操作時にOracle Clusterwareインストールが失敗する場合があります。この問題を回避するために、すべてのクラスタ・ノードでSSHデーモン構成ファイル/etc/ssh/sshd_configに次のパラメータを設定し、タイムアウト待機時間を無制限に設定します。
LoginGraceTime 0
インストーラ・ソフトウェアは、Oracle Grid Infrastructureインストール所有者ユーザー・アカウント(oracleまたはgrid)で実行します。ただし、インストーラを起動する前に、インストール所有者ユーザー・アカウントの環境を構成する必要があります。また、必要に応じて、他の必要なOracleソフトウェア所有者を作成します。
この項の内容は次のとおりです。
Oracle Grid Infrastructureソフトウェア所有者の環境を構成するには、次の変更を行う必要があります。
Oracleソフトウェア所有者の環境を設定するには、ソフトウェア所有者(grid、oracle)ごとに次の手順を実行します。
X端末(xterm)などの端末セッションを新規に開始します。
次のコマンドを入力して、このシステムでX Windowアプリケーションが表示可能であることを確認します。
$ xhost + hostname
hostnameは、ローカル・ホストの名前です。
ソフトウェアをインストールするシステムにまだログインしていない場合は、ソフトウェア所有者ユーザーとしてそのシステムにログインします。
そのユーザーでログインしていない場合は、構成するソフトウェア所有者に切り替えます。たとえば、gridユーザーの場合は次のようになります。
$ su - grid
次のコマンドを入力して、ユーザーのデフォルトのシェルを確認します。
$ echo $SHELL
|
注意: ご使用のオペレーティング・システム・ベンダーでサポートされているシェル・プログラムを使用してください。ご使用のオペレーティング・システムでサポートされていないシェル・プログラムを使用すると、インストール中にエラーが発生する場合があります。 |
テキスト・エディタでユーザーのシェル起動ファイルを開きます。
Bashシェル(bash):
$ vi .bash_profile
Bourneシェル(sh)またはKornシェル(ksh):
$ vi .profile
Cシェル(cshまたはtcsh):
% vi .login
次のように行を入力または編集して、デフォルトのファイル・モード作成マスクの値に022を指定します。
umask 022
環境変数ORACLE_SID、ORACLE_HOMEまたはORACLE_BASEがファイルに設定されている場合は、そのファイルからこれらの行を削除します。
ファイルを保存して、テキスト・エディタを終了します。
シェル起動スクリプトを実行するには、次のいずれかのコマンドを入力します。
Bashシェル:
$ . ./.bash_profile
Bourne、BashまたはKornシェル:
$ . ./.profile
Cシェル:
% source ./.login
ローカル・システムにソフトウェアをインストールしていない場合は、次のコマンドを入力してXアプリケーションをローカル・システムに表示します。
Bourne、BashまたはKornシェル:
$ DISPLAY=local_host:0.0 ; export DISPLAY
Cシェル:
% setenv DISPLAY local_host:0.0
この例で、local_hostは、インストーラを表示するためのシステム(ご使用のワークステーションまたは他のクライアント)のホスト名またはIPアドレスです。
/tmpディレクトリの空き領域が1GB未満である場合は、空き領域が1GB以上のファイル・システムを選択し、環境変数TEMPおよびTMPDIRを設定してこのファイル・システムの一時ディレクトリを指定します。
|
注意: Oracle RACのインストール用の一時ファイル・ディレクトリ(通常、/tmp)の場所として、共有ファイル・システムは使用できません。共有ファイル・システムに/tmpを配置すると、インストールは失敗します。 |
必要に応じて、次のコマンドを入力し、選択したファイル・システムに一時ディレクトリを作成して、そのディレクトリに適切な権限を設定します。
$ su - root # mkdir /mount_point/tmp # chmod 775 /mount_point/tmp # exit
次のコマンドを入力して、環境変数TEMPおよびTMPDIRを設定します。
Bourne、BashまたはKornシェル:
$ TEMP=/mount_point/tmp $ TMPDIR=/mount_point/tmp $ export TEMP TMPDIR
Cシェル:
% setenv TEMP /mount_point/tmp % setenv TMPDIR /mount_point/tmp
環境が正しく設定されていることを確認するには、次のコマンドを入力します。
$ umask $ env | more
umaskコマンドによって値22、022または0022が表示されること、およびこの項で設定した環境変数に正しい値が指定されていることを確認します。
この項で説明するとおり、シェル制限およびシステム構成パラメータを設定することをお薦めします。
|
注意: この項に示すシェル制限値は、単なる最小値です。本番データベース・システムでは、これらの値をチューニングしてシステムのパフォーマンスを最適化することをお薦めします。シェル制限の構成の詳細は、オペレーティング・システムのマニュアルを参照してください。 |
ulimitの設定は、リソース制限に関連するプロセス・メモリーを決定します。次の表に示すようにシェル制限が設定されていることを確認します。
| シェル制限 | 説明 | ソフト制限(KB) | ハード制限(KB) |
|---|---|---|---|
STACK |
プロセスのスタック・セグメントのサイズ | 10240以下 | 32768以下 |
NOFILES |
オープン・ファイル記述子数 | 1024以上 | 65536以上 |
MAXUPRCまたはMAXPROC |
最大ユーザー・プロセス | 2047以上 | 16384以上 |
これらのシェル制限に指定された現行の値を表示するには、次のコマンドを入力します。
ulimit -s ulimit -n
次のコマンドも使用できます。
ulimit -a
このコマンドでは、-aによってすべての現在のリソース制限がリストされます。
リモート端末で作業を行っていて、そのローカル・ノードのみが表示されている場合(通常は、この状態になります)、次の構文を使用して、環境変数DISPLAYを設定します。
Bourne、KornおよびBashシェル:
$ export DISPLAY=hostname:0
Cシェル:
$ setenv DISPLAY hostname:0
たとえば、Bashシェルを使用していて、ホスト名がnode1の場合は、次のコマンドを入力します。
$ export DISPLAY=node1:0
X11転送によってインストールが失敗しないように、次の手順に従って、Oracleソフトウェア所有者ユーザー用にユーザー・レベルのSSHクライアント構成ファイルを作成します。
テキスト・エディタを使用して、ソフトウェア・インストール所有者の~/.ssh/configファイルを編集または作成します。
ForwardX11属性がnoに設定されていることを確認します。次に例を示します。
Host *
ForwardX11 no
Oracle Grid Infrastructureのインストール中、OUIは、SSHを使用してコマンドを実行したり、他のノードにファイルをコピーします。システム上の隠しファイル(.bashrcや.cshrcなど)にsttyコマンドが含まれていると、インストール中にMakeファイルやその他のインストールに関するエラーが発生します。
この問題を回避するには、次の例に示すとおり、STDOUTまたはSTDERRでのすべての出力が抑制されるように、Oracleインストール所有者ユーザーのホーム・ディレクトリにあるこれらのファイルを変更する必要があります(sttyやxtitleなどのコマンド)。
Bourne、BashまたはKornシェル:
if [ -t 0 ]; then stty intr ^C fi
Cシェル:
test -t 0 if ($status == 0) then stty intr ^C endif
|
注意: SSHを使用できない場合、インストーラは、sshおよびscpコマンドのかわりにrshおよびrcpを使用します。
リモート・シェルによってロードされる隠しファイルに |
インストール中に、Oracle Grid Infrastructureソフトウェアを格納するホーム・ディレクトリへのパスを指定するように求められます。指定するディレクトリ・パスが次の要件を満たすことを確認します。
Oracle Clusterwareホームを含む、既存のOracleホーム以外のパスに作成する必要があります。
ユーザー・ホーム・ディレクトリには作成できません。
すべてのファイルをrootによって所有可能なパス内のサブディレクトリとして作成するか、一意のパス内に作成します。
インストール前にパスを作成する場合は、Oracle Grid Infrastructureのインストール所有者(通常、すべてのOracleソフトウェアに対して1つのインストール所有者の場合はoracle、ロール・ベースのOracleインストール所有者の場合はgrid)が所有し、権限が775に設定されている必要があります。
Oracle Grid Infrastructureは、共有記憶域の共有ホームではなく、ローカル・ホームにインストールすることをお薦めします。
Oracle Grid Infrastructureのみをインストールする場合は、Oracle Optimal Flexible Architecture(OFA)に準拠したパスを作成することをお薦めします。これによって、Oracle Universal Installer(OUI)がインストール中にそのディレクトリを選択できるようになります。OUIがパスをOracleソフトウェア・パスとして認識するには、u0[1-9]/appという形式にする必要があります。
OUIでOFA準拠のパスが検出されると、Oracle Grid InfrastructureおよびOracle Inventory(oraInventory)ディレクトリが作成されます。
手動でOracle Grid Infrastructureのパスを作成する場合は、既存のOracleベース・パスではなく、別のパスの下に作成します。次に例を示します。
# mkdir -p /u01/app/11.2.0/grid # chown grid:oinstall /u01/app/11.2.0/grid # chmod -R 775 /u01/app/11.2.0/grid
このパスでは、インストール所有者の名前がgridの場合、OUIによってデフォルトで、グリッド・ホームとして次のパスが作成されます。
/u01/app/11.2.0/grid
データベースのインストールのために、Oracle Databaseインストール所有者アカウントを所有者とするOracleベース・パスを作成します。OracleベースのOFAパスは、/u01/app/userです。userは、Oracleソフトウェア・インストールの所有者アカウントです。たとえば、次のコマンドを使用して、データベース・インストールの所有者アカウントoracleのOracleベースを作成します。
# mkdir -p /u01/app/oracle # chown -R oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/app/oracle
クラスタ名は長さ1文字以上15文字以下の英数字である必要があり、ハイフン(-)を含めることはできますが、先頭を数字にすることはできません。
標準インストールでは、指定するSCANはクラスタの名前でもあるため、SCAN名はクラスタ名の要件を満たしている必要があります。拡張インストールでは、SCANとクラスタ名はインストール時に別のフィールドに入力するため、クラスタ名要件はSCAN名に適用されません。
