| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for Linux B71324-15 |
|
 前 |
 次 |
この章では、クラスタ用のOracle Grid InfrastructureとOracle Real Application Clustersをインストールする前に完成させるユーザー、グループ・ユーザー環境および管理環境の設定について説明します。
この章の内容は次のとおりです。
rootとしてログインし、次の手順を実行して、Oracle InventoryグループおよびOracle Grid Infrastructureのソフトウェア所有者を検索または作成します。
|
注意: Oracle Grid Infrastructureのインストールでは、Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)の両方がインストールされます。Oracle Clusterwareのインストール所有者とOracle ASMのインストール所有者は、分離することができなくなりました。 |
システムに初めて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 Grid Infrastructureインストールの場合、中央インベントリはノード上のローカル記憶域にある必要があります。
既存のOracle中央インベントリがある場合は、必ずすべてのOracleソフトウェア・インストールで同じOracle Inventoryを使用し、インストールに使用するすべてのOracleソフトウェア・ユーザーがこのディレクトリへの書込み権限を持つようにします。
システムにOracle中央インベントリ・ディレクトリ(oraInventory)があるかどうかを確認するには、次のようにします。
# more /etc/oraInst.loc
oraInst.locファイルが存在する場合、このコマンドの出力は次のようになります。
inventory_loc=/u01/app/oracle/oraInventory inst_group=oinstall
前述の出力例は、次の内容を示します。
inventory_locグループは、Oracle Inventoryの場所を示します。
inst_groupパラメータは、Oracleインベントリ・グループ名(この例ではoinstall)を示します。
grep groupname /etc/groupコマンドを使用して、Oracle Inventoryグループとして指定されたグループがまだシステムに存在していることを確認します。次に例を示します。
$ grep oinstall /etc/group oinstall:x:54321:grid,oracle
oraInst.locファイルが存在しない場合は、次のコマンドを入力して、Oracle Inventoryグループを作成します。
# /usr/sbin/groupadd -g 54321 oinstall
このコマンドによって、グループID番号が54321のoraInventoryグループoinstallが作成されます。oraInventoryグループのメンバーには、Oracle中央インベントリ(oraInventory)への書込み権限、およびOracleインストール所有者ユーザーの他のシステム権限が付与されます。
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ソフトウェアに作成されるユーザーに対して、次の制限事項を確認してください。
異なるOracle Databaseホームに対して複数のOracleソフトウェア所有者を使用する場合は、Oracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)ソフトウェアに対して別途ソフトウェア所有者を作成し、その所有者でOracle Grid Infrastructureをインストールすることをお薦めします。
インストール中に、クラスタ・メンバー・ノード間にSSHを設定する必要があります。SSHは、Oracle Universal Installer (インストーラ)によって自動で設定できます。SSHの自動設定を有効にするには、プロファイルにsttyコマンドがないOracleインストール所有者を作成し、ログイン中にトリガーされて端末へのメッセージを生成する他のセキュリティ対策を削除します。これらのメッセージやメール・チェックなどが表示されていると、Oracleソフトウェア・インストール所有者アカウントは、インストーラに組み込まれているSSH構成スクリプトを使用できません。これらの表示が無効になっていない場合は、SSHを手動で構成してからでなければ、インストールを実行できません。
Oracle DatabaseまたはOracle RACをインストールする予定がある場合は、Oracle Grid InfrastructureおよびOracle Databaseのインストール・ユーザーを別々に作成することをお薦めします。使用するインストール所有者が1つの場合は、管理タスクを実行するときに、$ORACLE_HOMEの値を管理対象のインスタンス(Oracle ASM、Oracle Grid Infrastructureホーム内、またはOracleホームのデータベース)に変更する必要があり、その際のコマンド構文の例は次のようになります(ここで、/u01/app/12.1.0/gridはOracle Grid Infrastructureホームです)。
$ ORACLE_HOME=/u01/app/12.1.0/grid; export ORACLE_HOME
環境変数$ORACLE_HOMEに異なるOracleホームまたはGridホーム・パスが設定されている一方で、sqlplus、lsnrctlまたはasmcmdコマンドを使用してOracleホームまたはGridホーム・インスタンスを管理しようとすると、エラーが発生します。たとえば、データベース・ホームからSRVCTLを開始する場合は$ORACLE_HOMEにそのデータベース・ホームを設定する必要があり、そうしないと、SRVCTLが失敗します。ただし、Oracle Grid InfrastructureホームでSRVCTLを使用する場合は例外です。その場合、$ORACLE_HOMEは無視され、Oracleホーム環境変数はSRVCTLコマンドに影響を与えません。その他のすべての場合は、$ORACLE_HOMEを管理対象のインスタンスに変更する必要があります。
別のOracleソフトウェア所有者を作成して、Oracleソフトウェア・インストールごとに、オペレーティング・システム権限グループを分離するには、各ユーザーのプライマリ・グループとして、Oracle中央インベントリ・グループ(oraInventoryグループ)が設定されている必要があります。このグループのメンバーにはOracle中央インベントリ(oraInventory)ディレクトリに書き込むための、OINSTALLシステム権限が付与され、様々なOracle Clusterwareリソース、OCRキー、DBAが書込みアクセスを必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限も付与されます。このグループのメンバーには、Clusterwareインフラストラクチャのリソースおよびデータベースを開始および停止する実行権限も付与されます。Oracleドキュメントのコード・サンプルでは、このグループはoinstallと表されています。
各Oracleソフトウェア所有者は、すべてのOracleソフトウェア・インストール所有者が同じOINSTALLシステム権限を共有するように、同じ中央インベントリoraInventoryグループのメンバーである必要があり、また、このグループをプライマリ・グループとして持つ必要があります。Oracleインストールに対して複数の中央インベントリを使用しないことをお薦めします。あるOracleソフトウェア所有者が別の中央インベントリ・グループを持っている場合、その中央インベントリは破損することがあります。
oracleやgridというOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracleの存在を確認します)。
# id oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=54321(oracle) gid=54321(oinstall) groups=54322(dba),54323(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。ユーザーIDおよびグループIDの番号は、クラスタ・メンバー・ノードにする各ノード上で同一である必要があります。
Oracle Grid InfrastructureおよびOracle DatabaseインストールのLinuxオペレーティング・システムのプロビジョニングにOracle Preinstallation RPMを使用している場合、これにはOracle Databaseインストール所有者(oracle)、Oracle Inventoryグループ(oinstall)およびOracle管理権限グループ(dba)が構成されています。
このインストールのインストール所有者として既存ユーザーを使用する場合は、ユーザーのプライマリ・グループがOracle Inventoryグループ(oinstall)であることを確認します。
Oracleソフトウェア所有者ユーザー(oracle、grid)が存在しない、または新しいOracleソフトウェア所有者ユーザーが必要な場合は作成します。既存のユーザー・アカウントを使用する場合は、各クラスタ・メンバー・ノードでユーザーID(UID)およびグループID(GID)が一致していることを確認します。
デフォルトで割り当てられているUIDおよびGIDはノードごとに異なる可能性があるため、各ノードでデフォルト値を使用しないことをお薦めします。かわりに、特別に指定および番号付したUIDおよびGIDを決定し、グループまたはユーザーを作成する前に、他のノードでそれらが使用されていないことを確認します。インストールを開始する前に、クラスタのメンバー・ノードにする予定の各ノードのユーザー構成が同一で、UIDおよびGIDは変更する必要がないことを確認することを強くお薦めします。Oracleソフトウェア・ユーザーおよびグループ用にUIDおよびGIDを変更する必要がある場合、ソフトウェアを再インストールする必要があります。
Oracle RACまたはOracle Grid Infrastructureをインストールおよび構成するために以前使用したユーザー・アカウントのUID、GID、グループ・メンバーシップの変更はサポートされていません。あるOracleユーザーから別のユーザーに既存のOracle Databaseホームの所有者を変更することはサポートしていません。
Oracle Grid Infrastructureを一度インストールした後に既存のGridインストールの所有者を変更する必要がある場合(たとえば、Oracle Grid Infrastructure所有者とOracle RAC Oracle Database所有者ユーザー・アカウントを区別するために、Oracle RACをインストールする前に既存のOracle Databaseユーザー・アカウントを変更したい場合)、各ノードで(ローリング方式で)Oracle Clusterwareを停止後に開始してOracle Grid Infrastructureを所有するユーザー・アカウントに対して行われた変更を取得する必要があります。
次の手順では、Oracleソフトウェア所有者の名前としてgridが、OSASMグループとしてasmadminが使用されています。異なる管理権限に対して個別のシステム権限グループを作成するには、ユーザーを作成する前に、グループ作成を完了します(第6.1.7項「役割区分によるオペレーティング・システム権限グループおよびユーザーについて」を参照)。
既存のシステム権限グループ(この例ではdba)がある場合にグリッド・インストール所有者アカウントを作成し、グループのメンバーにOracle ASMインスタンスを管理するためのSYSASM権限を付与する場合、次のようなコマンドを入力します。
# /usr/sbin/useradd -u 54322 -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グループと同じグループを使用する必要があります。インストール中に、他のいくつかのOracle Databaseシステム管理権限用のオペレーティング・システム・グループを割り当てることも求められます。
usermodコマンドを使用して、既存のユーザーID番号とグループを変更します。
次に例を示します。
# id oracle uid=1101(oracle) gid=1000(oinstall) groups=1200(dba) # /usr/sbin/usermod -u 54421 -g 54331 -G 54321,54322,54327 oracle # id oracle uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),54322(dba),54327 (asmdba)
Oracle Grid Infrastructureを所有するユーザーのパスワードを設定します。次に例を示します。
# passwd grid
他のすべてのクラスタ・ノードでこの手順を繰り返します。
|
注意: 既存ユーザーを使用または変更する前に、必要に応じて、システム管理者に連絡してください。 |
Oracle Grid InfrastructureインストールのOracleベース・ディレクトリは、Oracle ASMおよびOracle Clusterwareに関する診断ログ、管理ログおよびその他のログが格納される場所です。クラスタのOracle Grid Infrastructureを除くOracleインストールの場合、Oracleホームが配置される場所でもあります。
ただし、Oracle Grid Infrastructureインストールの場合は、別のパスを作成し、Oracleベースのパスをその他のOracleインストールが使用できるようにする必要があります。
OUIがOracleベース・パスを認識するには、u[00-99][00-99]/appという形式にし、oraInventory(oinstall)グループのすべてのメンバーによる書込みを可能にする必要があります。OracleベースのOFAパスはu[00-99][00-99]/app/userで、userはソフトウェア・インストール所有者の名前です。次に例を示します。
/u01/app/grid
Oracle Grid Infrastructureソフトウェア用Oracleホーム(Gridホーム)は、他のOracleソフトウェアのOracleホーム・ディレクトリのパスとは異なるパスにある必要があります。Optimal Flexible Architectureガイドラインでは、Gridホームには、/pm/v/uの形式のパスを作成することとされています(ここで、/pは文字定数、/mは一意な固定長キー(通常は2桁の数字)、/vはソフトウェアのバージョン、/uはOracle Grid Infrastructureソフトウェアのインストール所有者(Gridユーザー)です)。クラスタに対してOracle Grid Infrastructureをインストールする際に、Gridホームのパスはrootユーザーに変更されるため、その他のユーザーがパス内のコマンドを読取り、書込みまたは実行することはできません。
たとえば、標準のマウント・ポイント形式のu[00-99][00-99]/app/release/gridでGridホームを作成するには(ここで、releaseはOracle Grid Infrastructureソフトウェアのリリース番号です)、次のパスを作成します。
/u01/app/12.1.0/grid
インストール中に、Gridホームへのパス全体の所有者がrootに変更されます(/u01、/u01/app、/u01/app/12.1.0、/u01/app/12.1.0/grid)。Gridホームへの一意のパスを作成しない場合は、グリッドのインストール後に、同じパスにある既存のインストールを含むその他のインストールの権限エラーが発生します。
rootが所有するマウント・ポイントにアプリケーション・ディレクトリを配置することを避けるには、Gridホーム用に次などのパスを作成および選択できます。
/u01/12.1.0/grid
|
関連項目: Optimal Flexible Architecture (OFA)のガイドラインの詳細については、『Oracle Databaseインストレーション・ガイド』を参照してください。 |
Oracle Grid Infrastructureインストール所有者のログ・ファイルを別のOracleベースに分離できるようにし、Oracleベースのパスの下にGridホームが誤って配置されないようにするために、Oracle Grid InfrastructureのGridホームおよびOracleベース・ホームは手動で作成することをお薦めします(特に、クラスタ用Oracle Grid InfrastructureおよびOracle Databaseソフトウェア所有者が別の場合にお薦めします)。
次に例を示します。
# mkdir -p /u01/app/12.1.0/grid # mkdir -p /u01/app/grid # mkdir -p /u01/app/oracle # chown -R grid:oinstall /u01 # chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/
|
注意: クラスタ用Oracle Grid Infrastructureバイナリをクラスタ・ファイル・システムに配置することはサポートされていません。共有のOCFS2の場所にOracle RACホームをインストールする場合は、OCFS2を、書込み可能な共有 各クラスタ・メンバー・ノードで、Oracle Grid Infrastructureをローカルにインストールすることをお薦めします。共有Gridホームを使用すると、ローリング・アップグレードを実行できなくなり、クラスタの単一障害点となります。 |
Oracle DatabaseとOracle ASMの役割区分の構成は、オペレーティング・システム認証の個別のグループを提供するためのグループおよびユーザーを作成する構成です。
Oracle Databaseの役割区分では、各Oracle Databaseインストールが別個のオペレーティング・システム・グループを保持して、そのOracle Databaseでのシステム権限の認証を提供することにより、システム権限のオペレーティング・システム認証を共有することなく、クラスタに複数のデータベースをインストールできるようになります。また、各Oracleソフトウェア・インストールを別々のインストール所有者が所有することで、Oracle Databaseバイナリへの変更に対してオペレーティング・システム・ユーザー認証が提供されます。すべてのOracleソフトウェア所有者が、すべてのデータベースおよびOracle ASMや仮想IP (VIP)などの共有のOracle Grid Infrastructureリソースを開始および停止できることに注意してください。役割区分を構成できることにより、データベースが安全になり、様々なClusterwareリソースを開始および停止できるユーザー・ロールは制限されません。
Oracle Grid Infrastructureの役割区分では、Oracle ASMは別々のオペレーティング・システム・グループを持ち、記憶域層の管理に関するOracle ASMシステム権限のオペレーティング・システム認証を提供します。このオペレーティング・システム認証は、Oracle Databaseオペレーティング・システム認証から分離されています。また、Oracle Grid Infrastructureインストール所有者は、Oracle Grid Infrastructureバイナリへの変更に対してオペレーティング・システム・ユーザー認証を提供します。
Oracle Databaseのインストール中に、Oracle Universal Installer (OUI)から、OSDBA、OSOPER、OSBACKUPDBA、OSDGDBAおよびOSKMDBAグループの名前を指定するように求められます。これらのグループのメンバーには、各グループが認可するデータベース・システム権限セットに対するオペレーティング・システム認証が付与されます。システム権限のセットごとに、異なるオペレーティング・システム・グループを作成することをお薦めします。
|
注意: この構成はオプションで、Oracleソフトウェアに対するユーザー・アクセスを、様々な管理者ユーザーの役割に応じて制限するための構成です。 |
記憶域層およびデータベース層のすべてのシステム権限のオペレーティング・システム認証に対して、1つの管理ユーザーと1つのグループを作成することもできます。
たとえば、oracleユーザーをすべてのOracleソフトウェアのインストール所有者として指定し、oinstallグループのメンバーにOracle Clusterwareのすべてのシステム権限、Oracle ASMのすべてのシステム権限、サーバー上のすべてのOracle Databaseに対するすべてのシステム権限、およびインストール所有者のすべてのOINSTALLシステム権限を付与することを指定できます。このグループは、Oracleインベントリ・グループでもあります。
ロール割当てをしたグループを使用しない場合は、2つ以上のグループを使用することを強くお薦めします。
システム権限グループ: OSDBA、OSASM、その他のシステム権限グループなどがあり、そのメンバーには管理システム権限が付与されます。
インストール所有者グループ(oraInventoryグループ): メンバーには、Oracleインストール所有者システム権限(OINSTALLシステム権限)が付与されます。
クラスタ検証ユーティリティなどのOracleツールでデフォルトを使用しやすくするため、すべてのシステム権限とoraInventoryへの書込み権限を1つのオペレーティング・システム・グループに付与する場合は、そのグループ名をoinstallにする必要があります。
|
関連項目:
|
この項の内容は次のとおりです。
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、OSBACKUPDBA、OSDGDBAおよびOSKMDBAグループが必要です。Oracleドキュメントでは、Oracleソフトウェア所有者ユーザーをoracleユーザーとします。
ソフトウェア所有者ユーザーを個別に作成し、各Oracleソフトウェア・インストールの所有者にすることをお薦めします。特に、システムに複数のデータベースをインストールする場合にお薦めします。
Oracleドキュメントでは、Oracle Grid Infrastructureバイナリを所有するために作成されたユーザーをgridユーザーとします。このユーザーは、Oracle ClusterwareとOracle Automatic Storage Managementの両方のバイナリを所有します。
|
関連項目: オペレーティング・システム・グループおよびシステム権限認証の詳細は、『Oracle Automatic Storage Management管理者ガイド』および『Oracle Database管理者ガイド』を参照してください。 |
標準Oracle Databaseグループのリストを次に示します。これらのグループは、データベース管理システム権限のオペレーティング・システム認証を提供します。
Oracle Databaseソフトウェアをシステムに初めてインストールする場合は、このグループを作成する必要があります。このグループのオペレーティング・システム・ユーザー・アカウントには、データベースの管理権限(SYSDBA権限)があります。Oracle ASMインスタンスに個別のOSDBA、OSOPERおよびOSASMグループを作成しない場合は、SYSOPERおよびSYSASM権限を持つオペレーティング・システム・ユーザー・アカウントが、このグループのメンバーである必要があります。Oracleコードの例で使用されるこのグループ名はdbaです。OSASMグループとして個別のグループを指定しない場合は、定義するOSDBAグループもデフォルトでOSASMとなります。
デフォルト(dba)以外のグループ名を指定するには、拡張インストール・タイプを選択してソフトウェアをインストールするか、またはこのグループのメンバーではないユーザーとしてOracle Universal Installer (OUI)を起動する必要があります。dbaと呼ばれるグループのメンバーではないユーザーでOUIを開始すると、OSDBAグループの名前を指定するようにOUIから求められます。
以前は、OSDBAグループのメンバーにOracle ASMインスタンスのSYSASM権限(ディスク・グループのマウントおよびマウント解除を含む)が付与されていました。Oracle Grid Infrastructure 11g リリース2 (11.2)の場合、別々のオペレーティング・システム・グループがOSDBAとOSASMグループとして指定されているときには、この権限が付与されません。同じグループが、OSDBAとOSASMの両方に使用されている場合は、権限がそのまま保持されます。
Oracle DatabaseのOSOPERグループ(通常、oper)
データベースを起動および停止するためのデータベース管理権限の一部(SYSOPER権限)を持つ別個のオペレーティング・システム・ユーザー・グループが必要な場合は、このグループの作成を選択できます。
Oracle Database 12cリリース1 (12.1)からは、データベースを起動および停止するためのOSOPER権限に加えて、日常のデータベース操作に必要な特定の管理権限タスクをサポートする、よりタスク固有で、OSDBA/SYSDBAシステム権限より権限の少ない新しい管理権限を作成できます。ユーザーが付与したこれらのシステム権限は、オペレーティング・システム・グループ・メンバーシップを通じても認証されます。
これらの特定のグループ名を作成する必要はありませんが、インストール中にオペレーティング・システム・グループを指定するように求められます(そのメンバーに、これらのシステム権限へのアクセス権が付与されます)。同じグループを、これらの権限の認証を提供するために割り当てることができますが、各権限の指定には固有のグループを提供することをお薦めします。
OSDBAサブセット役割区分の権限およびグループは、次のもので構成されます。
Oracle Database用のOSBACKUPDBAグループ(通常、backupdba)
このグループは、オペレーティング・システム・ユーザーの別のグループにバックアップおよびリカバリ関連権限の一部(SYSBACKUP権限)を付与する場合に作成します。
Oracle Data Guard用のOSDGDBAグループ(通常、dgdba)
このグループは、オペレーティング・システム・ユーザーの別のグループにOracle Data Guardを管理および監視する権限の一部(SYSDG権限)を付与する場合に作成します。
このグループは、オペレーティング・システム・ユーザーの別のグループに、Oracle Wallet Managerの管理など暗号化鍵を管理権限の一部(SYSKM権限)を付与する場合に作成します。
SYSASM、ASM用のSYSOPERおよびASM用のSYSDBAシステム権限では、SYSDBAからOracle ASMストレージ管理権限の分離が可能になります。指定するオペレーティング・システムのメンバーには、これらのロールのシステム権限が付与されます。Oracle ASMに対する権限のオペレーティング・システム認証グループとして、別のオペレーティング・システム・グループを選択します。
OUIを開始する前に、Oracle ASMに対して次のOSグループおよびユーザーを作成します(そのメンバーには対応するSYS権限が付与されます)。
Oracle ASM管理用のOSASMグループ(通常、asmadmin)
Oracle ASM管理者用とOracle Database管理者用の管理権限グループを別にする場合、このグループを別のグループとして作成します。このグループのメンバーには、Oracle ASMを管理するためのSYSASMシステム権限が付与されます。Oracleドキュメントでは、メンバーに権限が付与されたオペレーティング・システム・グループをOSASMグループと呼びます。コード例には、この権限を付与するために特別に作成された、asmadminと呼ばれるグループがあります。
Oracle ASMは、複数のデータベースをサポートできます。システム上に複数のデータベースがあり、複数のOSDBAグループを使用してデータベースごとに別々のSYSDBA権限を提供できるようにする場合は、グループを作成してそのメンバーにOSASM/SYSASM管理権限が付与されるようにし、データベース・インストールを所有しないグリッド・インフラストラクチャ・ユーザー(grid)を作成する必要があります(これによって、Oracle Grid Infrastructure SYSASM管理権限がデータベース管理権限グループから分離されます)。
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グループ(ASM用のOSOPER、通常はasmoper)
これはオプションのグループです。Oracle ASMインスタンスの起動と停止を含む、制限付きのOracle ASMインスタンスの管理権限(ASM用のSYSOPER権限)を別のグループのオペレーティング・システム・ユーザーに付与する場合に、このグループを作成します。デフォルトでは、OSASMグループのメンバーには、ASMのSYSOPER権限により付与されるすべての権限もあります。
Oracle ASMオペレータ・グループを使用してデフォルトのasmadminグループより少ない権限でOracle ASM管理者グループを作成するには、拡張インストール・タイプを選択してソフトウェアをインストールする必要があります。この場合、OUIによって、グループ名の指定を求めるプロンプトが表示されます。コード例では、このグループはasmoperです。
次の項では、Oracle Grid InfrastructureおよびOracle Databaseに必要なオペレーティング・システム・ユーザーおよびグループを作成する方法を説明します。
Oracle DatabaseをインストールしてOracle Grid Infrastructure環境で使用するときに、次のような場合はOSDBAグループを作成する必要があります。
OSDBAグループが存在しない場合(たとえば、システムへOracle Databaseソフトウェアを初めてインストールする場合)。
OSDBAグループは存在するが、新規のOracle Databaseインストールでは、異なるオペレーティング・システム・ユーザー・グループにデータベース管理権限を付与する場合。
OSDBAグループが存在しない場合または新しいOSDBAグループが必要な場合は、次の手順で作成します。既存のグループですでに使用されていないかぎり、グループ名にはdbaを使用します。次に例を示します。
# /usr/sbin/groupadd -g 54322 dba
OSOPERグループを作成する必要があるのは、制限付きのデータベース管理権限(SYSOPERオペレータ権限)を持つオペレーティング・システム・ユーザーのグループを指定する場合のみです。ほとんどのインストールの場合、OSDBAグループを作成するのみで十分です。次の場合にOSOPERグループを使用するには、このグループを作成する必要があります。
OSOPERグループが存在しない場合。たとえば、これがシステムに対するOracle Databaseソフトウェアの初回インストールの場合。
OSOPERグループは存在するが、新規のOracleインストールでは、異なるオペレーティング・システム・ユーザー・グループにデータベース・オペレータ権限を付与する場合。
OSOPERグループが存在しない場合、または新しいOSOPERグループが必要な場合は、作成します。既存のグループですでに使用されていないかぎり、グループ名にはoperを使用します。次に例を示します。
# groupadd -g 54323 oper
OSASMグループが存在しない場合、または新しいOSASMグループが必要な場合は、作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmadminを使用します。次に例を示します。
# groupadd -g 54329 asmadmin
データベース管理者などのオペレーティング・システム・ユーザーのグループを指定し、Oracle ASM記憶域の起動と停止を含む、Oracle ASM記憶域層に対する制限付きの管理権限を付与する場合には、ASM用のOSOPERグループを作成します。ほとんどの環境では、OSASMグループを作成するのみで十分です。インストールのインタビュー時に、そのグループをASM用のOSOPERグループとして指定します。
ASM用のOSOPERグループが存在しない場合、または新しいASM用のOSOPERグループが必要な場合は、作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmoperを使用します。次に例を示します。
# groupadd -g 54328 asmoper
Oracle ASMインスタンスへのアクセスを可能にするには、ASM用のOSDBAグループを作成する必要があります。これは、OSASMとOSDBAが異なるグループである場合に必要です。
ASM用のOSDBAグループが存在しない場合、または新しいASM用のOSDBAグループが必要な場合は、作成します。既存のグループですでに使用されていないかぎり、グループ名にはasmdbaを使用します。次に例を示します。
# groupadd -g 54327 asmdba
この項では、通常Oracle Databaseまたはその他のOracleアプリケーション・ソフトウェアを所有するユーザーである、Oracleソフトウェア所有者ユーザーに関する情報を説明します。この項の内容は次のとおりです。
次の場合、Oracleソフトウェア所有者ユーザーを作成する必要があります。
Oracleソフトウェア所有者ユーザーは存在するが、新規のOracle Databaseインストールでは、別のグループ・メンバーシップを設定した別のオペレーティング・システム・ユーザーを使用して、これらのグループにデータベース管理権限を付与する場合。
Oracle Grid InfrastructureのOracleソフトウェア所有者(gridなど)を作成し、Oracle Databaseソフトウェア用に別のOracleソフトウェア所有者(oracleなど)を作成する場合。
oracleやgridというOracleソフトウェア所有者ユーザーが存在するかどうかを確認するには、次のようなコマンドを入力します(この場合、oracleの存在を確認します)。
# id oracle
ユーザーが存在する場合、このコマンドの出力結果は、次のようになります。
uid=54321(oracle) gid=54321(oinstall) groups=54322(dba),54323(oper)
既存ユーザーを使用するか、別のユーザーを作成するかを決定します。既存のユーザーを使用する場合は、そのユーザーのプライマリ・グループがOracleインベントリ・グループであり、そのユーザーが適切なOSDBAグループおよびOSOPERグループのメンバーであることを確認します。詳細は、次のいずれかの項を参照してください。
既存のユーザーを変更するには、第6.1.9.6.4項「既存のOracleソフトウェア所有者ユーザーの変更」を参照してください。
ユーザーを作成するには、第6.1.9.6.3項「Oracleソフトウェア所有者ユーザーの作成」を参照してください。
Oracleソフトウェア所有者ユーザーが存在しない場合、または新しいOracleソフトウェア所有者ユーザーが必要な場合は、作成します。既存のユーザーですでに使用されていないかぎり、ユーザー名にはoracleを使用します。
oracleユーザーを作成するには、次の手順を実行します。
# useradd -u 54322 -g oinstall -G dba,asmdba oracle
このコマンドの内容は次のとおりです。
-uオプションは、ユーザーIDを指定します。システムによって自動的にユーザーID番号を生成するようにできるため、このコマンド・フラグの使用は任意です。ただし、oracleユーザーID番号は、この後のインストール前の作業で必要になるため、記録しておく必要があります。
-gオプションは、プライマリ・グループを指定します。プライマリ・グループは、Oracle Inventoryグループである必要があります。たとえば、oinstallです。
-Gオプションは、セカンダリ・グループを指定します。セカンダリ・グループには、OSDBAグループとASM用のOSDBAグループ、必要に応じてASM用のOSOPERグループを含める必要があります。たとえば、dba、asmdba、またはdba、asmdba、asmoperなどです。
oracleユーザーのパスワードを設定します。
# passwd oracle
oracleユーザーは存在するが、プライマリ・グループがoinstallではない場合、または適切なOSDBAまたはASM用OSDBAグループでない場合は、新規のoracleユーザーを作成します。Oracleでは、既存のインストール所有者の変更はサポートされていません。制限の全リストについては、第6.1.3.3項「Oracle Grid InfrastructureのOracleソフトウェア所有者ユーザーの作成または変更」を参照してください。
Oracleソフトウェア所有者ユーザー、Oracle Inventory、OSDBAグループおよびOSOPERグループは、すべてのクラスタ・ノードに存在し、また同一である必要があります。同一のユーザーおよびグループを作成するには、ユーザーおよびグループを作成したノードで割り当てられたユーザーIDおよびグループIDを確認してから、他のクラスタ・ノードで同じ名前とIDを持つユーザーおよびグループを作成する必要があります。
|
注意: 次の手順は、ローカル・ユーザーおよびグループを使用している場合にのみ実行する必要があります。NISなどのディレクトリ・サービスで定義されたユーザーおよびグループを使用している場合、各クラスタ・ノードのユーザーおよびグループはすでに同一です。 |
gridまたはoracleユーザーのユーザーID(uid)と、既存のOracleグループのグループID(gid)を確認するには、次の手順を実行します。
次のコマンドを入力します(ここでは、oracleユーザーのユーザーIDを確認します)。
# id oracle
このコマンドの出力結果は、次のようになります。
uid=54321(oracle) gid=54321(oinstall) groups=54322(dba),54323(oper),54327(asmdba)
表示された情報から、ユーザーのユーザーID(uid)および所属するグループのグループID(gid)を特定します。これらのID番号がクラスタの各ノードで同じであることを確認します。ユーザーのプライマリ・グループはgidの後に表示されます。セカンダリ・グループはgroupsの後に表示されます。
他のクラスタ・ノードでユーザーおよびグループを作成するには、各ノードで次の手順を繰り返します。
rootとしてノードにログインします。
asmadmin、asmdba、backupdba、dgdba、kmdba、asmoperおよびoperグループ、また、Oracle Preinstallation RPMまたは前のインストールで構成されていない場合にoinstallおよびdbaグループを作成するには、次のようなコマンドを入力します。
-gオプションを使用して、各グループに正しいグループIDを指定します。
# groupadd -g 54321 oinstall # groupadd -g 54322 dba # groupadd -g 54323 oper # groupadd -g 54324 backupdba # groupadd -g 54325 dgdba # groupadd -g 54326 kmdba # groupadd -g 54327 asmdba # groupadd -g 54328 asmoper # groupadd -g 54329 asmadmin
|
注意: この例では、UIDおよびGIDを使用する必要はありません。グループがすでに存在している場合は、必要に応じてgroupmodコマンドを使用してそのグループを変更します。ノード上の特定のグループに、同じグループIDを使用できない場合、すべてのノードの/etc/groupファイルを表示し、どのノードでも使用できるグループIDを特定します。すべてのノードのグループIDが同じになるように、グループIDを変更する必要があります。 |
oracleユーザーまたはOracle Grid Infrastructure (grid)ユーザーを作成するには、次のようなコマンドを入力します
# useradd -u 54321 -g oinstall -G asmadmin,asmdba grid
このコマンドの内容は次のとおりです。
-uオプションは、ユーザーIDを指定します。ユーザーIDは、前の項で特定したユーザーIDである必要があります。
-gオプションはGridユーザーのプライマリ・グループを指定します(このグループはOracleインベントリ・グループ(OINSTALL)である必要があり、OINSTALLシステム権限を付与します)。この例では、OINSTALLグループはoinstallです。
-Gオプションは、セカンダリ・グループを指定します。Gridユーザーは、OSASMグループ(asmadmin)およびASM用のOSDBAグループ(asmdba)のメンバーである必要があります。
|
注意: ユーザーがすでに存在している場合は、必要に応じてusermodコマンドを使用して変更します。すべてのノードのユーザーに、同じユーザーIDを使用できない場合、すべてのノードの/etc/passwdファイルを表示して、どのノードでも使用できるユーザーIDを特定します。すべてのノードのユーザーにそのIDを指定する必要があります。 |
# passwd oracle
第6.2項「グリッド・インフラストラクチャ・ソフトウェア所有者ユーザー環境の構成」で説明するとおり、各ユーザーに対してユーザー環境の構成タスクを完了します。
この構成例では、次を示します。
Oracleインベントリ・グループ(oinstall)の作成
すべてのOracle Grid Infrastructure、Oracle ASMおよびOracle Databaseシステム権限に割り当てる唯一のシステム権限グループとして、単一グループ(dba)の作成
適切なグループ・メンバーシップを持つOracle Grid Infrastructureソフトウェア所有者(grid)および1つのOracle Database所有者(oracle)の作成
OFA構造に準拠し、正しい権限を持つOracleベースのパスの作成および構成
次のコマンドを入力して、オペレーティング・システム認証の最小構成を作成します。
# groupadd -g 54321 oinstall # groupadd -g 54322 dba # useradd -u 54321 -g oinstall -G dba oracle # useradd -u 54322 -g oinstall -G dba grid # mkdir -p /u01/app/12.1.0/grid # mkdir -p /u01/app/grid # mkdir -p /u01/app/oracle # chown -R grid:oinstall /u01 # chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/
これらのコマンドを実行すると、次のグループとユーザーができます。
Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall)。プライマリ・グループが中央インベントリ・グループであるメンバーは、oraInventoryディレクトリに書込みできるOINSTALL権限を付与されます。
Oracle Grid Infrastructure、Oracle ASMおよびOracle Databaseシステム権限の1つのシステム権限グループ(dba)。dbaグループをプライマリまたはセカンダリ・グループとして持つメンバーには、Oracle Clusterware、Oracle ASMおよびOracle Databaseを管理するためのOSASM/SYSASM、OSDBA/SYSDBA、OSOPER/SYSOPER、OSBACKUPDBA/SYSBACKUP、OSDGDBA/SYSDG、OSKMDBA/SYSKM、ASM用のOSDBA/ASM用のSYSDBA、およびASM用のOSOPER/ASM用のSYSOPERのオペレーティング・システム認証が付与され、Oracle ASMストレージへのSYSASMおよびASM用のOSOPERアクセスが付与されます。
クラスタ用のOracle Grid Infrastructureの所有者、つまりGridユーザー(grid)。プライマリ・グループはoraInventoryグループ(oinstall)、セカンダリ・グループはOSASMグループ(dba)。Oracleベース・ディレクトリは/u01/app/grid。
Oracle Database所有者(oracle)。プライマリ・グループはoraInventoryグループ(oinstall)、セカンダリ・グループはOSDBAグループ(dba)。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/12.1.0/grid。これらの権限はインストールに必要であり、インストール・プロセスで変更されます。
インストール前は775権限で、インストール後は755権限でgrid:oinstallが所有する/u01/app/grid。
775権限でoracle:oinstallが所有する/u01/app/oracle。
|
注意: Oracle Grid Infrastructureとその他のOracleインストールの両方に対して、1つのインストール所有者を使用できます。ただし、Oracleソフトウェア・インストールごとに別のインストール所有者アカウントを使用することをお薦めします。 |
この項では、Optimal Flexible Architecture(OFA)デプロイメントに準拠する、ロール割当てされたグループおよびユーザーの作成方法の例を示します。
この例のシナリオは次のとおりです。
Oracle Grid Infrastructureインストール
クラスタに対して計画された2つの別々のOracle Databaseインストール(DB1およびDB2)
Oracle Grid Infrastructureおよび各Oracle Databaseの別々のインストール所有者
Oracle ASMおよび各Oracle Databaseのシステム権限の完全なロール割当て
Oracle Database所有者oracle1(Oracle ASMインスタンスの起動および停止権限を持つ)
次のコマンドを使用して、このシナリオのロール割当てをした構成のグループおよびユーザーを作成します。
# groupadd -g 54321 oinstall # groupadd -g 54322 dba1 # groupadd -g 54332 dba2 # groupadd -g 54323 oper1 # groupadd -g 54333 oper2 # groupadd -g 54324 backupdba1 # groupadd -g 54334 backupdba2 # groupadd -g 54327 asmdba # groupadd -g 54325 dgdba1 # groupadd -g 54335 dgdba2 # groupadd -g 54326 kmdba1 # groupadd -g 54336 kmdba2 # groupadd -g 54329 asmadmin # groupadd -g 54328 asmoper # useradd -u 54422 -g oinstall -G asmadmin,asmdba grid # useradd -u 54421 -g oinstall -G dba1,backupdba1,dgdba1,kmdba1,asmdba,asmoper oracle1 # useradd -u 54431 -g oinstall -G dba2,backupdba2,dgdba2,kmdba2,asmdba oracle2 # mkdir -p /u01/app/12.1.0/grid # mkdir -p /u01/app/grid # mkdir -p /u01/app/oracle1 # mkdir -p u01/app/oracle2 # chown -R grid:oinstall /u01 # chmod -R 775 /u01/ # chown oracle1:oinstall /u01/app/oracle1 # chown oracle2:oinstall /u01/app/oracle2
これらのコマンドを実行すると、Oracle Grid Infrastructureおよび2つの別々のOracle Database (DB1とDB2)の管理権限グループおよびユーザーのセットが作成されます。
Oracle中央インベントリ・グループ、つまりoraInventoryグループ(oinstall)。メンバーは、このグループをプライマリ・グループとして持ちます。このグループのメンバーにはOINSTALLシステム権限が付与され、これによってoraInventoryディレクトリへの書込み権限と、その他の関連するバイナリのインストール権限が付与されます。
OSASMグループ(asmadmin)。このグループはインストール中にOracle Grid Infrastructureと関連付けられ、そのメンバーにはOracle ASMを管理するためのSYSASM権限が付与されます。
ASM用のOSDBAグループ(asmdba)。インストール中にOracle Grid Infrastructure記憶域に関連付けられます。メンバーにはgridとすべてのデータベース・インストール所有者(oracle1、oracle2など)が含まれ、これらのメンバーはOracle ASMへのアクセス権が付与されます。記憶域にOracle ASMを使用するその他のインストール所有者も、このグループのメンバーである必要があります。
Oracle ASMのためのASM用のOSOPERグループ(asmoper)。インストール中にOracle Grid Infrastructureに関連付けられます。asmoperグループのメンバーには、Oracle ASMインスタンスの起動および停止の権限など、制限付きのOracle ASM管理者権限が付与されます。
Oracle Grid Infrastructureインストール所有者(grid)。プライマリ・グループはoraInventoryグループ(oinstall)、セカンダリ・グループはOSASM(asmadmin)グループおよびASM用のOSDBA(asmdba)グループ。
/u01/app/oraInventory。クラスタ上のOracleインストールの中央インベントリ。このパスの所有者はgrid:oinstallのままで、他のOracleソフトウェア所有者による中央インベントリへの書込みを可能にします。
インストール前にgrid:oinstallによって所有されるOFA準拠のマウント・ポイント/u01。Oracle Universal Installerがそのパスに書き込めるようになります。
775権限でgrid:oinstallが所有する、グリッド・インストール所有者のOracleベース/u01/app/grid。インストール・プロセスで755権限に変更されます。
775(drwxdrwxr-x)権限でgrid:oinstallが所有する、Gridホーム/u01/app/12.1.0/grid。これらの権限はインストールに必要であり、インストール・プロセスでroot:oinstallの755権限(drwxr-xr-x)に変更されます。
Oracle Databaseソフトウェア所有者(oracle1)。DB1のOracle Databaseバイナリを所有します。oracle1ユーザーは、プライマリ・グループとしてoraInventoryグループ、そのデータベースのOSDBAグループ(dba1)、およびセカンダリ・グループとしてのOracle Grid InfrastructureのASM用のOSDBAグループ(asmdba)を持ちます。また、oracle1ユーザーはasmoperのメンバーであり、Oracle ASMを起動および停止するユーザー権限が付与されます。
OSDBAグループ(dba1)。インストール中に、ユーザーoracle1によってインストールされたデータベースのOSDBAグループとして、グループdba1を指定します。dba1のメンバーには、Oracle Database DB1に対するSYSDBA権限が付与されます。SYSDBAとして接続するユーザーは、DB1でユーザーSYSとして識別されます。
OSBACKUPDBAグループ(backupdba1)。インストール中に、ユーザーoracle1によってインストールされたデータベースのOSDBAグループとして、グループbackupdba1を指定します。backupdba1のメンバーには、ユーザーoracle1によってインストールされたデータベースに対する、データベースをバックアップするためのSYSBACKUP権限が付与されます。
OSDGDBAグループ(dgdba1)。インストール中に、ユーザーoracle1によってインストールされたデータベースのOSDGDBAグループとして、グループdgdba1を指定します。dgdba1のメンバーには、ユーザーoracle1によってインストールされたデータベースに対する、Oracle Data Guardを管理するためのSYSDG権限が付与されます。
OSKMDBAグループ(kmdba1)。インストール中に、ユーザーoracle1によってインストールされたデータベースのOSKMDBAグループとして、グループkmdba1を指定します。kmdba1のメンバーには、ユーザーoracle1によってインストールされたデータベースに対する、暗号化鍵を管理するためのSYSKM権限が付与されます。
OSOPERグループ(oper1)。インストール中に、ユーザーoracle1によってインストールされたデータベースのOSOPERグループとして、グループoper1を指定します。oper1のメンバーには、DB1データベースの起動および停止の権利など、SYSOPER権限(SYSDBA権限の一部)が付与されます。OSOPER権限として接続するユーザーは、DB1でユーザーPUBLICとして識別されます。
775権限でoracle1:oinstallが所有する、Oracleベース/u01/app/oracle1。ユーザーoracle1は、このディレクトリにソフトウェアをインストールする権限を持ちます(/u01/appパスのその他のディレクトリは対象外です)。
Oracle Databaseソフトウェア所有者(oracle2)。DB2のOracle Databaseバイナリを所有します。oracle2ユーザーは、そのプライマリ・グループとしてのoraInventoryグループ、そのデータベースのOSDBAグループ(dba2)、およびセカンダリ・グループとしてのOracle Grid InfrastructureのASM用のOSDBAグループ(asmdba)を持ちます。ただし、oracle2ユーザーはasmoperグループのメンバーでないため、oracle2はOracle ASMを停止または起動できません。
OSDBAグループ(dba2)。インストール中に、ユーザーoracle2によってインストールされたデータベースのOSDBAグループとして、グループdba2を指定します。dba2のメンバーには、Oracle Database DB2に対するSYSDBA権限が付与されます。SYSDBAとして接続するユーザーは、DB2でユーザーSYSとして識別されます。
OSBACKUPDBAグループ(backupdba2)。インストール中に、ユーザーoracle2によってインストールされたデータベースのOSDBAグループとして、グループbackupdba2を指定します。backupdba2のメンバーには、ユーザーoracle2によってインストールされたデータベースに対する、データベースをバックアップするためのSYSBACKUP権限が付与されます。
OSDGDBAグループ(dgdba2)。インストール中に、ユーザーoracle2によってインストールされたデータベースのOSDGDBAグループとして、グループdgdba2を指定します。dgdba2のメンバーには、ユーザーoracle2によってインストールされたデータベースに対する、Oracle Data Guardを管理するためのSYSDG権限が付与されます。
OSKMDBAグループ(kmdba2)。インストール中に、ユーザーoracle2によってインストールされたデータベースのOSKMDBAグループとして、グループkmdba2を指定します。kmdba2のメンバーには、ユーザーoracle2によってインストールされたデータベースに対する、暗号化鍵を管理するためのSYSKM権限が付与されます。
OSOPERグループ(oper2)。インストール中に、ユーザーoracle2によってインストールされたデータベースのOSOPERグループとして、グループoper2を指定します。oper2のメンバーには、DB2データベースの起動および停止の権利など、SYSOPER権限(SYSDBA権限の一部)が付与されます。OSOPER権限として接続するユーザーは、DB2でユーザーPUBLICとして識別されます。
775権限でoracle1:oinstallが所有する、Oracleベース/u01/app/oracle2。ユーザーoracle2は、このディレクトリにソフトウェアをインストールする権限を持ちます(/u01/appパスのその他のディレクトリは対象外です)。
インストーラ・ソフトウェアは、Oracle Grid Infrastructureインストール所有者ユーザー・アカウント(oracleまたはgrid)で実行します。ただし、インストーラを起動する前に、インストール所有者ユーザー・アカウントの環境を構成する必要があります。必要に応じて、他の必要なOracleソフトウェア所有者を作成する必要もあります。
この項の内容は次のとおりです。
Oracleソフトウェア所有者の環境を構成するには、次の変更を行う必要があります。
シェル起動ファイルで、インストール・ソフトウェア所有者ユーザー(grid、oracle)のデフォルトのファイル・モード作成マスク(umask)を022に設定します。 マスクを022に設定すると、ソフトウェア・インストールを実行するユーザーが作成するファイルの権限は常に644になります。
インストール・ソフトウェア所有者(grid、oracle)のファイル記述子およびプロセスに対して、ulimitを設定します。
Oracle Universal Installer (OUI)でインストールを実行する準備として、ソフトウェア所有者のDISPLAY環境変数を設定します。
|
注意: Oracle Grid Infrastructureソフトウェア所有者のユーザーIDでインストールしたOracleインストールがすでにある場合、そのユーザーのすべてのOracle環境変数の設定を解除します。詳細は、第B.5.2項「Oracle環境変数の設定解除」を参照してください。 |
Oracleソフトウェア所有者の環境を設定するには、ソフトウェア所有者(grid、oracle)ごとに次の手順を実行します。
インストールを実行するサーバーからXターミナル・セッション(xterm)を開始します。
次のコマンドを入力し、X Windowアプリケーションをシステムに表示できるかを確認します(ここで、hostnameは、サーバーにアクセスするローカル・ホストの完全修飾名です)。
$ xhost + 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
次のコマンドを使用してPATH環境変数をチェックします。
$ echo $PATH
すべてのOracle環境変数を削除します。
ローカル・システムにソフトウェアをインストールしていない場合は、次のコマンドを入力してXアプリケーションをローカル・システムに表示します。
Bourne、BashまたはKornシェル:
$ export DISPLAY=local_host:0.0
Cシェル:
% setenv DISPLAY local_host:0.0
この例で、local_hostは、インストーラを表示するためのシステム(ご使用のワークステーションまたは他のクライアント)のホスト名またはIPアドレスです。
/tmpディレクトリの空き領域が1GB未満である場合は、1GB以上の空き領域があるファイル・システムを特定し、そのファイル・システムの一時ディレクトリとしてTMPおよびTMPDIR環境変数を設定します。
|
注意: Oracle RACのインストール用の一時ファイル・ディレクトリ(通常、/tmp)の場所として、共有ファイル・システムは使用できません。共有ファイル・システムに/tmpを配置すると、インストールは失敗します。 |
必要に応じて、次のようなコマンドを入力し、識別したファイル・システム上に一時ディレクトリを作成し、そのディレクトリに適切な権限を設定します。
$ sudo - s # mkdir /mount_point/tmp # chmod 775 /mount_point/tmp # exit
次のようなコマンドを入力し、TMPおよびTMPDIR環境変数を設定します。
Bourne、BashまたはKornシェル:
$ TMP=/mount_point/tmp $ TMPDIR=/mount_point/tmp $ export TMP TMPDIR
Cシェル:
% setenv TMP /mount_point/tmp % setenv TMPDIR /mount_point/tmp
環境が正しく設定されていることを確認するには、次のコマンドを入力します。
$ umask $ env | more
umaskコマンドによって値22、022または0022が表示されること、およびこの項で設定した環境変数に正しい値が指定されていることを確認します。
インストール・ソフトウェア所有者ごとに、次の推奨範囲を使用してインストールのリソース制限を確認します。
表6-1 インストール所有者のリソース制限の推奨範囲
| リソースのシェル制限 | リソース | ソフト制限 | ハード制限 |
|---|---|---|---|
|
オープン・ファイル記述子 |
nofile |
1024以上 |
65536以上 |
|
単一ユーザーが使用可能なプロセス数 |
nproc |
2047以上 |
16384以上 |
|
プロセスのスタック・セグメントのサイズ |
スタック |
10240KB以上 |
10240KB以上かつ32768KB以下 |
|
ロックされたメモリーの最大上限 |
memlock |
HugePagesメモリーを有効にする場合は現在のRAMの90%以上、HugePagesメモリーを無効にする場合は、3145728 KB (3 GB)以上。 |
HugePagesメモリーを有効にする場合は現在のRAMの90%以上、HugePagesメモリーを無効にする場合は、3145728 KB (3 GB)以上。 |
リソース制限を確認するには、次の手順を実行します。
インストール所有者としてログインします。
ファイル記述子設定の弱い制限および強い制限を確認します。結果が推奨範囲内であることを確認します。次に例を示します。
$ ulimit -Sn 1024 $ ulimit -Hn 65536
ユーザーが使用可能なプロセス数の弱い制限および強い制限を確認します。結果が推奨範囲内であることを確認します。次に例を示します。
$ ulimit -Su 2047 $ ulimit -Hu 16384
スタック設定の弱い制限を確認します。結果が推奨範囲内であることを確認します。次に例を示します。
$ ulimit -Ss 10240 $ ulimit -Hs 32768
Oracleソフトウェア・インストール所有者ごとに、この手順を繰り返します。
リモート端末で作業を行っていて、そのローカル・ノードのみが表示されている場合(通常は、この状態になります)、次の構文を使用して、ユーザー・アカウントのDISPLAY環境変数を設定します。
Bourne、KornおよびBashシェル:
$ export DISPLAY=hostname:0
Cシェル:
$ setenv DISPLAY hostname:0
たとえば、Bashシェルを使用していて、ホスト名がnode1の場合は、次のコマンドを入力します。
$ export DISPLAY=node1:0
X11転送が原因でインストールが失敗しないようにするには、次のように、Oracleソフトウェア所有者ユーザーに対してユーザーレベルのSSHクライアント構成ファイルを作成します。
テキスト・エディタを使用して、ソフトウェア・インストール所有者の~/.ssh/configファイルを編集または作成します。
~/.ssh/configファイルでForwardX11属性がnoに設定されていることを確認します。次に例を示します。
Host *
ForwardX11 no
~/.sshに対する権限がGridユーザーに固定されることを確認します。次に例を示します。
$ ls -al .ssh total 28 drwx------ 2 grid oinstall 4096 Jun 21 2014 drwx------ 19 grid oinstall 4096 Jun 21 2014 -rw-r--r-- 1 grid oinstall 1202 Jun 21 2014 authorized_keys -rwx------ 1 grid oinstall 668 Jun 21 2014 id_dsa -rwx------ 1 grid oinstall 601 Jun 21 2014 id_dsa.pub -rwx------ 1 grid oinstall 1610 Jun 21 2014 known_hosts
Oracle Grid Infrastructureのインストール中、OUIは、SSHを使用してコマンドを実行したり、他のノードにファイルをコピーします。システム上の隠しファイル(.bashrcや.cshrcなど)に端末出力コマンドが含まれていると、インストール中に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を使用します。
リモート・シェルによってロードされる隠しファイルに |
Intelligent Platform Management Interface(IPMI)は、コンピュータのハードウェアおよびファームウェアへの共通インタフェースを提供し、システム管理者はそのインタフェースを使用して、システム状態の監視およびシステムの管理を実行できます。Oracle ClusterwareにIPMIを統合して、障害分離をサポートしたりクラスタの整合性を確保することができます。
インストール中に「障害の分離のサポート」画面からIPMIを選択して、ノード・ターミネーションにIPMIを構成できます。また、IPMIは、crsctlコマンドを使用してインストール後に構成することもできます。
|
関連項目: インストール後にIPMIの構成を行う方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
クラスタ・ノードをIPMIで管理できるようするには、次のようにハードウェアおよびソフトウェアを構成する必要があります。
各クラスタ・メンバー・ノードにBaseboard Management Controller(BMC)が必要です。このBMCは、IPMI over LANをサポートするIPMIバージョン1.5以上と互換性があるファームウェアを実行し、LANを使用したリモート制御に対応するように構成されている必要があります。
各クラスタ・メンバー・ノードに、IPMIドライバがインストールされている必要があります。
クラスタに、IPMI用の管理ネットワークが必要です。これは共有ネットワークでも可能ですが、専用ネットワークの構成をお薦めします。
BMCで使用する各クラスタ・メンバー・ノードのイーサネット・ポートが、IPMI管理ネットワークに接続されている必要があります。
各クラスタ・メンバーが管理ネットワークに接続されている必要があります。
一部のサーバー・プラットフォームでは、電源を切るとネットワーク・インタフェースが省電力モードになります。この場合には、低いリンク速度(1GBではなく100MBなど)で動作することになります。こうしたプラットフォームの場合、BMCが接続されるネットワーク・スイッチ・ポートで、低い速度に合わせた自動ネゴシエートが可能である必要があります。そうでない場合は、IPMIが正常に動作できません。
|
注意: IPMIは、ベースボード管理コントローラ(BMC)のネットワーク・インタフェースを通して物理ハードウェア・プラットフォームに作用します。実際のシステム構成によっては、IPMIによるサーバー再起動が、そのサーバーでホスティングされているすべての仮想環境に影響を及ぼす可能性があります。詳細は、ハードウェアおよびオペレーティング・システムのベンダーに問い合せてください。 |
BMCはDHCPまたは静的IPアドレスで構成できます。お薦めするのは、DHCPを使用して動的に割り当てたIPアドレスでBMCを構成する方法です。この方法を選択する場合は、BMCのIPアドレスを割り当てるようにDHCPサーバーを構成する必要があります。
|
注意: IPMIを構成し、グリッド・ネーミング・サービス(GNS)を使用する場合でも、IPMIインタフェースには別のアドレスを構成する必要があります。IPMIアダプタはホストから直接には認識できないため、GNSはホスト上のアドレスとしてIPMIアダプタを認識できません。 |
Oracle ClusterwareがBMCと通信するには、システムの再起動時にIPMIドライバが使用できるように、IPMIドライバが各ノードに永続的にインストールされている必要があります。IPMIドライバは、このリリースでサポートしているAsianux Linux、Oracle Linux、Red Hat Enterprise LinuxおよびSUSE Enterprise Linux Serverのディストリビューションで使用可能です。
Linuxシステムの場合、IPMIを組み込んだOracle Clusterwareデプロイメントでサポートしているドライバは、OpenIPMIドライバです。
このドライバは、必要なモジュールを手動でロードすることで、動的にインストールして構成できます。ご使用のディストリビューション用にIPMIを構成する方法については、ご使用のLinuxディストリビューションのベンダーにお問い合せください。
次の例では、Oracle Linuxに手動でOpen IPMIドライバを構成する方法を示します。
rootとしてログインします。
# /sbin/modprobe ipmi_msghandler # /sbin/modprobe ipmi_si # /sbin/modprobe ipmi_devintf
(オプション)コマンド/sbin/lsmod |grep ipmiを実行して、IPMIモジュールがロードされていることを確認します。次に例を示します。
# /sbin/lsmod | grep ipmi ipmi_devintf 12617 0 ipmi_si 33377 0 ipmi_msghandler 33701 2 ipmi_devintf,ipmi_si
|
注意: BMCがあるかどうかにかかわらず、モジュールはインストールできます。 |
テキスト・エディタを使用して/etc/rc.localファイルを開き、ファイルの末尾に移動して、次のような行を入力し、手順2のmodprobeコマンドがシステムの再起動時に自動的に実行されるようにします。
# START IPMI ON SYSTEM RESTART /sbin/modprobe ipmi_msghandler /sbin/modprobe ipmi_si /sbin/modprobe ipmi_devintf
|
注意: SUSE Linux Enterprise Serverシステムの場合は、/etc/init.d/boot.localの上にmodprobeコマンドを追加します。 |
次のコマンドを使用して、LinuxシステムがIPMIデバイスを認識していることを確認します。
ls -l /dev/ipmi0
IPMIデバイスが動的にロードされた場合、出力は次のようになります。
# ls -l /dev/ipmi0 crw------- 1 root root 253, 0 Sep 23 06:29 /dev/ipmi0
デバイス・ファイルの出力が表示された場合は、IPMIドライバが構成済であり、これ以降の手順を行う必要はありません。
デバイス・ファイルの出力が表示されない場合は、デバイス・ファイルが自動的に作成されるようにudevdデーモンが設定されていません。次の手順に進みます。
コマンドgrep ipmi /proc/devicesを使用して、IPMIデバイスのデバイス・メジャー番号を確認します。次に例を示します。
# grep ipmi /proc/devices 253 ipmidev
この例の場合、デバイス・メジャー番号は253です。
デバイス・メジャー番号を指定してmknodコマンドを実行し、IPMIデバイスのディレクトリ・エントリとi-nodeを作成します。次に例を示します。
# mknod /dev/ipmi0 c 253 0x0
この例の/dev/ipmi0の権限により、rootのみがデバイスにアクセスできます。システムの脆弱性を防ぐため、デバイスはrootのみがアクセスするようにしてください。
IPMIベースのノード・フェンシングを適切に機能させるには、各ノードのBMCがLANによるリモート制御を行えるように構成します。BMCの構成は、BIOSプロンプトからディストリビューション固有の管理ユーティリティを使用して実行できます。また、次のような公開ユーティリティを使用して実行することもできます。
IPMItool(Linuxで使用可能):
http://ipmitool.sourceforge.net
IPMIutil(LinuxおよびWindowsで使用可能):
http://ipmiutil.sourceforge.net
ツールを使用してBMCを構成する方法の詳細は、選択した構成ツールのドキュメントを参照してください。
各ノードでBMCを構成するときには、次の手順を実行する必要があります。
IPMI over LANを有効にして、管理ネットワーク経由でBMCを制御できるようにします。
DHCPまたはGNSを使用して動的なIPアドレスを有効にするか、BMCに対して静的IPアドレスを構成します。
BMCの管理者ユーザー・アカウントおよびパスワードを設定します。
BMCをタグVLANで使用する場合は、VLANのタグに対応するようにBMCを構成します。
使用する構成ツールは問いませんが、BMCが正しく機能するには、これらの条件を満たしている必要があります。
次に示すのは、ipmitool(バージョン1.8.6)を使用してBMCを構成する例です。
rootとしてログインします。
ipmitoolが、IPMIドライバを使用してBMCと通信できることを確認します。これを行うには、コマンドbmc infoを使用して、その出力からデバイスIDを探します。次に例を示します。
# ipmitool bmc info Device ID : 32 . . .
ipmitoolがBMCと通信していない場合は、「Open IPMIドライバの構成」の項を参照して、IPMIドライバが動作しているかどうかを確認します。
次の手順で、IPMI over LANを有効にします。
IPMI over LANに使用するチャネルの、チャネル番号を決めます。チャネル1から始めて、LAN属性(IPアドレスなど)が表示されるチャネルが見つかるまで、次のコマンドを実行します。
# ipmitool lan print 1 . . . IP Address Source : 0x01 IP Address : 192.0.2.10 . . .
検出されたチャネルに対してLANアクセスを有効にします。たとえば、チャネルが1の場合は次のようにします。
# ipmitool lan set 1 access on
次のいずれかの手順で、IPMIのIPアドレス設定を構成します。
動的IPアドレス(DHCP)を使用する場合
動的IPアドレスは、Oracle Universal Installerでのデフォルトです。クラスタのノードを簡単に追加または削除できるように(アドレスの設定を自動的に割り当てることができるように)、このオプションを選択することをお薦めします。
|
注意: DHCPを使用するには、サブネット上にDHCPサーバーがあることが必要です。 |
チャネルを設定します。たとえば、チャネルが1の場合は、次のコマンドを入力してDHCPを有効にします。
# ipmitool lan set 1 ipsrc dhcp
静的IPアドレスを使用する場合
ネットワーク接続をBMCとオペレーティング・システムで共有する場合は、IPアドレスが同じサブネット上にあることが必要です。IPアドレスを設定するだけでなく、ネットマスクの値およびデフォルト・ゲートウェイも適切に設定する必要があります。たとえば、チャネルが1の場合は次のようにします。
# ipmitool lan set 1 ipaddr 192.168.0.55 # ipmitool lan set 1 netmask 255.255.255.0 # ipmitool lan set 1 defgw ipaddr 192.168.0.1
指定したアドレス(192.168.0.55)は、BMCのみに関連付けられ、通常のpingに応答することはできません。
次の手順を実行して、ユーザー名とパスワードを管理アカウントに設定します(チャネルは1を想定しています)。
LAN経由のADMINアクセスに対してパスワード認証を要求するようにBMCを設定します。次に例を示します。
# ipmitool lan set 1 auth ADMIN MD5,PASSWORD
BMCでアカウント・スロットをリストして、使用されていないスロットを識別します。使用可能な未使用スロットは、最大IDより小さいスロットであり、リストには表示されません。たとえば、より最近のバージョンのIPMIツールの場合、コマンドipmitool user summaryを使用できます
# ipmitool user summary 1 Maximum IDs : 20 Enabled User Count : 3 Fixed Name Count : 2 # ipmitool user list 1 ID Name Enabled Callin Link Auth IPMI Msg Channel Priv Li 1 true false false true USER 2 root true false false true ADMINISTRATOR 3 sysoper true true false true OPERATOR 12 default true true false true NO ACCESS 13 true false true false CALLBACK
可能なスロットが20あり、使用されていない最初のスロットの番号は4です。
任意の管理者ユーザー名およびパスワードを割り当て、特定したスロットに対してメッセージ機能を有効にします。(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.0.2.10
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.0.2.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とパスワードmypasswordを使用して、node1からnode2上のBMCを確認するには、node1上で次のコマンドを入力します。
$ ipmitool -H node2-ipmi -U username -P mypassword bmc info
BMCが正しく構成されている場合は、リモート・ノードのBMCに関する情報が表示されます。Error: Unable to establish LAN sessionなどのエラー・メッセージが表示された場合は、リモート・ノードのBMC構成を確認する必要があります。
Oracle Grid Infrastructureのインストール中に、多数のシステム構成タスクを完了するために、スーパーユーザー(root)権限でスクリプトを実行するようにインストーラから求められます。
次のオプションのいずれかを使用して、rootとして手動でスクリプトを実行するか、rootとして構成手順を実行する権限をインストーラに委任することができます。
rootパスワードを使用: その他の構成情報を入力する際に、インストーラにパスワードを提供します。パスワードはインストール中に使用され、格納されません。rootユーザー・パスワードは、各クラスタ・メンバー・ノードで同一である必要があります。
rootコマンドの委任を有効にするには、要求された際に、インストーラにrootパスワードを提供します。
sudoを使用: sudoはUNIXおよびLinuxのユーティリティで、sudoersリスト権限のメンバーは、個々のコマンドをrootとして実行できます。
Sudoを有効にするには、適切な権限を持つシステム管理者がsudoersリストのメンバーであるユーザーを構成し、インストール時の求めに応じてユーザー名とパスワードを指定します。
