| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for Oracle Solaris B71326-09 |
|
 前 |
 次 |
この付録では、通常Cluster Verification Utility(CVU)およびインストーラ(OUI)がインストール時に完了する構成作業を、手動で行う方法について説明します。この付録は、修正スクリプトを使用できないときに参考にしてください。
この付録の内容は次のとおりです。
パスワードなしのSSH構成は、必須のインストール要件です。SSHは、インストール時にクラスタ・メンバー・ノードの構成に使用され、またインストール後にはコンフィギュレーション・アシスタント、Oracle Enterprise Manager、OPatchおよび他の機能によって使用されます。
OUIを使用したパスワードなしのSSHの自動構成によって、クラスタのすべてのノード上にRSA暗号化キーが作成されます。システム上の制約により、DSA鍵を使用するなどして手動でSSHを設定することが求められる場合は、この手順を参考にして、パスワードなしのSSHを設定してください。
この後の例では、Oracleソフトウェア所有者をgridユーザーとしています。
この項の内容は次のとおりです。
次のコマンドを入力して、SSHが実行されているかどうかを確認します。
$ pgrep sshd
SSHが実行されている場合、このコマンドの結果は1つ以上のプロセスID番号になります。インストール・ソフトウェア所有者(grid、oracle)のホーム・ディレクトリで、コマンドls -alを使用して、.sshディレクトリを所有し、そのディレクトリへの書込みが可能であるのはそのユーザーのみであることを確認します。
SSHプロトコルには、RSA鍵またはDSA鍵のいずれかが必要です。RSAはSSH 1.5プロトコルで使用され、DSAはSSH 2.0プロトコルのデフォルトです。OpenSSHの場合は、RSAまたはDSAのいずれかを使用できます。この後の説明ではSSH1を想定しています。SSH2をインストールしており、SSH1を使用できない場合は、SSHディストリビューションのドキュメントを参照して、SSH1互換を構成するか、またはDSAを使用してSSH2を構成します。
SSHを構成するには、最初に各クラスタ・ノードにRSA鍵およびDSA鍵を作成してから、すべてのクラスタ・ノード・メンバーで生成されたすべての鍵を各ノードで同じ認証鍵ファイルにコピーする必要があります。SSHファイルを読み取ることができのは、rootおよびソフトウェア・インストール・ユーザー(oracle、grid)のみである必要があります。これは、SSHが他のユーザーによってアクセス可能であると、SSHは秘密鍵を無視するためです。この後の例では、DSA鍵が使用されています。
インストールに使用するOracleソフトウェアのインストール所有者ごとにSSHを構成する必要があります。
SSHを構成するには、次の手順を実行します。
各ノードに対し、次の手順を実行します。
ソフトウェア所有者(この例ではgridユーザー)としてログインします。
コマンドidおよびid gridを入力して、gridとしてログインしていること、およびユーザーIDがgridユーザーに割り当てたユーザーIDと一致していることを確認します。Oracleユーザー・グループおよびユーザーと、使用しているユーザー端末ウィンドウ・プロセスのグループIDおよびユーザーIDが同じであることを確認します。次に例を示します。
$ id uid=502(grid) gid=501(oinstall) groups=501(oinstall),502(grid,asmadmin,asmdba) $ id grid uid=502(grid) gid=501(oinstall) groups=501(oinstall),502(grid,asmadmin,asmdba)
必要に応じて、gridユーザーのホーム・ディレクトリに.sshディレクトリを作成して適切な権限を設定し、読取り/書込み権限を持っているのはoracleユーザーのみであることを確認します。
$ mkdir ~/.ssh $ chmod 700 ~/.ssh
次のコマンドを入力します。
$ /usr/bin/ssh-keygen -t dsa
プロンプトで、鍵ファイルには、デフォルトの位置を使用します([Enter]を押します)。
|
注意: パス・フレーズを持つSSHは、Oracle Clusterware 11gリリース2以上のリリースではサポートされません。 |
このコマンドによって、DSA公開鍵が~/.ssh/id_dsa.pubファイルに、秘密鍵が~/.ssh/id_dsaファイルに書き込まれます。
秘密鍵は、Oracleソフトウェア・インストールの実行を許可されていない他のユーザーには配布しないでください。
DSA鍵を使用して、クラスタ・メンバーを作成する各ノードで手順1から手順4を実行します。
次の手順を実行します。
ローカル・ノードで、Oracle Grid Infrastructure所有者のホーム・ディレクトリ(通常、gridまたはoracle)にある.sshディレクトリに移動します。
次に、次のコマンドを使用してDSA鍵をauthorized_keysファイルに追加します。
$ cat id_dsa.pub authorized_keys $ ls
.sshディレクトリに、作成したid_dsa.pub鍵とauthorized_keysファイルが表示されるはずです。
ローカル・ノードで、SCP(セキュア・コピー)またはSFTP(セキュアFTP)を使用して、authorized_keysファイルをリモート・ノードのoracleユーザーの.sshディレクトリにコピーします。次の例では、node2というノードでSCPを使用しています。Oracle Grid Infrastructureの所有者はgridです。gridユーザーのパスは/home/gridです。
[grid@node1 .ssh]$ scp authorized_keys node2:/home/grid/.ssh/
DSA鍵を受け入れるように求められます。Yesと入力して、コピー先のノードがknown_hostsファイルに追加されていることを確認します。
プロンプトに従って、gridユーザーのパスワードを入力します。パスワードは、クラスタ内のすべてのノードで同じにする必要があります。authorized_keysファイルがリモート・ノードにコピーされます。
出力結果は、次のようになります。xxxは有効なIPアドレスの一部を示しています。
[grid@node1 .ssh]$ scp authorized_keys node2:/home/grid/.ssh/ The authenticity of host 'node2 (xxx.xxx.173.152) can't be established. DSA key fingerprint is 7e:60:60:ae:40:40:d1:a6:f7:4e:zz:me:a7:48:ae:f6:7e. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'node1,xxx.xxx.173.152' (dsa) to the list of known hosts grid@node2's password: authorized_keys 100% 828 7.5MB/s 00:00
SSHを使用して、authorized_keysファイルをコピーしたノードにログインします。.sshディレクトリに移動し、catコマンドを使用して2つ目のノードのDSA鍵をauthorized_keysファイルに追加します。このとき、パスワードを求められたら[Enter]をクリックすることで、パスワードなしのSSHが設定されます。
[grid@node1 .ssh]$ ssh node2 [grid@node2 grid]$ cd .ssh [grid@node2 ssh]$ cat id_dsa.pub authorized_keys
各ノードからクラスタ内の他の各メンバー・ノードに対して手順2および3を繰り返します。
クラスタ・ノード・メンバーにする最後のノードのauthorized_keysファイルに各クラスタ・ノード・メンバーから鍵を追加した後、scpを使用して、すべてのノードの鍵を含むauthorized_keysファイルを各クラスタ・ノード・メンバーに再度コピーし、他のノードの既存のバージョンを上書きします。
authorized_keysファイルにすべてのノードが含まれていることを確認するには、more authorized_keysコマンドを入力して、各メンバー・ノードのDSA鍵が存在するかどうかを確認します。ファイルには、鍵のタイプ(ssh-dsa)、鍵、ユーザーおよびサーバーの順で示されます。次に例を示します。
ssh-dsa AAAABBBB . . . = grid@node1
|
注意: 各ノードのgridユーザーの/.ssh/authorized_keysファイルには、すべてのクラスタ・ノードで生成した/.ssh/id_dsa.pubファイルのすべての内容が含まれている必要があります。 |
すべての鍵が含まれているauthorized_keysファイルをクラスタ内の各ノードにコピーしたら、示されている順に次の手順を実行します。この例では、Oracle Grid Infrastructureソフトウェア所有者の名前はgridです。
OUIを実行するシステムにgridユーザーとしてログインします。
次のコマンド構文を使用して、ローカル・ノードから各ノードにSSHを実行します(ローカル・ノードからローカル・ノード自体へのSSHの実行、各ノードから他の各ノードへのSSHの実行を含みます)。hostname1やhostname2などは、クラスタ内のノードのパブリック・ホスト名(別名および完全修飾されたドメイン名)です。
[grid@nodename]$ ssh hostname1 date [grid@nodename]$ ssh hostname2 date . . .
次に例を示します。
[grid@node1 grid]$ ssh node1 date The authenticity of host 'node1 (xxx.xxx.100.101)' can't be established. DSA key fingerprint is 7z:60:60:zz:48:48:z1:a0:f7:4e. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'node1,xxx.xxx.100.101' (DSA) to the list of known hosts. Mon Dec 4 11:08:13 PST 2006 [grid@node1 grid]$ ssh node1.example.com date The authenticity of host 'node1.example.com (xxx.xxx.100.101)' can't be established. DSA key fingerprint is 7z:60:60:zz:48:48:z1:a0:f7:4e. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'node1.example.com,xxx.xxx.100.101' (DSA) to the list of known hosts. Mon Dec 4 11:08:13 PST 2006 [grid@node1 grid]$ ssh node2 date Mon Dec 4 11:08:35 PST 2006 . . .
この処理の終了時に、各メンバー・ノードのパブリック・ホスト名を、他のすべてのクラスタ・ノードのknown_hostsファイルに登録する必要があります。
リモート・クライアントを使用してローカル・ノードに接続しているときに、xauthデータがなく、X11転送に偽の認証データを使用することを示す警告メッセージが表示された場合は、認証鍵ファイルは適切に構成されているが、SSH構成でX11転送が有効になっていることを示しています。この問題を解決するには、第5.2.4項「リモート表示およびX11転送の構成の設定」に進みます。
各クラスタ・ノード・メンバーに対して手順2を繰り返します。
SSHが適切に構成されていれば、パスワードを求めるプロンプトは表示されることなくsshやscpコマンドを使用できます。次に例を示します。
[grid@node1 ~]$ ssh node2 date Mon Feb 26 23:34:42 UTC 2009 [grid@node1 ~]$ ssh node1 date Mon Feb 26 23:34:48 UTC 2009
パスワードを求めるノードがある場合、そのノードの~/.ssh/authorized_keysファイルに適切な公開鍵が含まれていること、および同じグループ・メンバーシップおよびIDを持つOracleソフトウェア所有者が作成されていることを確認します。
この項の内容は次のとおりです。
|
注意: 次の項に示すカーネル・パラメータ値およびシェル制限値は、単なる最小インストールの値です。本番データベース・システムでは、カーネル・リソースを調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・リソース管理の詳細は、次のURLの「Managing System Information, Processes, and Performance in Oracle Solaris 11.1」を参照してください。 |
インストール時にFixupスクリプトを生成して実行し、データベースを正常にインストールするために必要なカーネル・パラメータ値を確認および設定できます。このスクリプトは、必要なカーネル・パラメータを必要に応じて最小値に更新します。
修正スクリプトを使用できない場合は、次の表を参照して手動で値を設定します。Oracle Solaris 10では、次の表の各カーネル・パラメータが、表に示す最小値以上の値に設定されていることを確認します。
|
注意: Oracle Solaris 10の場合、System V IPCを実装するために/etc/systemファイルを変更する必要はありません。Oracle Solaris 10では、その実装にリソース制御機能が使用されます。 |
| リソース制御 | 最小値 |
|---|---|
project.max-sem-ids |
100 |
process.max-sem-nsems |
256 |
project.max-shm-memory |
この値はRAMのサイズによって異なります。最小値については第E.2.2項を参照してください。 |
project.max-shm-ids |
100 |
tcp_smallest_anon_port |
9000 |
tcp_largest_anon_port |
65500 |
udp_smallest_anon_port |
9000 |
udp_largest_anon_port |
65500 |
|
注意:
|
リソース制御のproject.max-shm-memoryを使用すると、プロジェクトの最大共有メモリーを設定できます。
表E-1に、project.max-shm-memoryの最小インストール設定を示します。
prctlコマンドを使用して、システム上のアクティブなプロセス、タスクまたはプロジェクトに関連付けられているリソース制御に対して、実行時の問合せや変更を行います。
プロジェクトおよびシステム全体のproject.max-shm-memoryセットの現在の値を表示するには、次のコマンドを入力します。
# prctl -n project.max-shm-memory -i project default
ここでdefaultは、id -pコマンドを実行して取得できるプロジェクトIDです。
たとえば、システムを再起動せずにプロジェクト・デフォルトに対してproject.max-shm-memoryの設定を6GBに変更するには、次を入力します。
prctl -n project.max-shm-memory -v 6gb -r -i project default
|
関連項目: 次のWebサイトのOracle Solaris 11の管理に関するドキュメントを参照してください。 |
Oracle Solaris 10以上のリリースでは、次の手順を使用して、リソース制御に指定された現在の値を表示し、必要に応じて変更します。
リソース制御の現在の値を表示するには、次のコマンドを入力します。
$ id -p // to verify the project id uid=100(oracle) gid=100(dba) projid=1 (group.dba) $ prctl -n project.max-shm-memory -i project group.dba $ prctl -n project.max-sem-ids -i project group.dba
現在のいずれかの値を変更する必要がある場合は、次のようにします。
max-shm-memoryの値を6GBに変更する場合:
# prctl -n project.max-shm-memory -v 6gb -r -i project group.dba
max-sem-idsの値を256に変更する場合:
# prctl -n project.max-sem-ids -v 256 -r -i project group.dba
|
注意: コマンドprctl(リソース制御)を使用してシステム・パラメータを変更する場合、これらのパラメータの変更を有効にするために、システムを再起動する必要はありません。ただし、変更されたパラメータは、システムの再起動後はなくなります。 |
次の手順を使用して、リソース制御のプロジェクト設定を変更すると、システムの再起動後も変更が有効になります。
デフォルトでは、Oracleインスタンスはdbaグループのoracleユーザーとして実行されます。group.dbaという名前のプロジェクトが、oracleユーザーのデフォルトのプロジェクトとして機能するように作成されます。コマンドidを実行して、oracleユーザーのデフォルトのプロジェクトを検証します。
# su - oracle $ id -p uid=100(oracle) gid=100(dba) projid=100(group.dba) $ exit
最大共有メモリー・サイズを4GBに設定するには、projmodコマンドを実行します。
# projmod -sK "project.max-shm-memory=(privileged,4G,deny)" group.dba
また、リソース制御値project.max-shm-memory=(privileged,4294967295,deny)を、Oracleプロジェクトのプロジェクト・エントリの最後のフィールドに追加する方法もあります。
これらの手順が完了した後で、次のコマンドを使用して、/etc/projectファイルの値を確認します。
# cat /etc/project
出力結果は、次のようになります。
system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: group.dba:100:Oracle default project:::project.max-shmmemory=(privileged,4294967295,deny)
次の例のように、プロセスの所有権を確認し、コマンドidおよびprctlを実行して、リソース制御がアクティブであることを確認します。
# su - oracle
$ id -p
uid=100(oracle) gid=100(dba) projid=100(group.dba)
$ prctl -n project.max-shm-memory -i process $$
process: 5754: -bash
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 4.00GB - deny
|
注意: 最大共有メモリーの値は、SGA要件によって異なります。SGAサイズより大きい値を設定する必要があります。詳細は、『Oracle Solarisチューニング可能パラメータ・リファレンス・マニュアル』を参照してください。 |
シェル制限およびシステム構成パラメータは、この項の説明に従って設定することをお薦めします。
|
注意: この項に示すシェル制限値は、単なる最小値です。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。シェル制限の構成の詳細は、オペレーティング・システムのマニュアルを参照してください。 |
ulimit設定により、プロセス・メモリー関連のリソース制限が決定されます。次の表に示されているシェル制限が、示されている値に設定されていることを確認します。
| シェル制限 | 説明 | ソフト制限(KB) | ハード制限(KB) |
|---|---|---|---|
STACK |
プロセスのスタック・セグメントのサイズ | 10240以下 | 32768以下 |
NOFILES |
オープン・ファイル記述子 | 1024以上 | 65536以上 |
MAXUPRCまたはMAXPROC |
最大ユーザー・プロセス | 2047以上 | 16384以上 |
これらのシェル制限に指定されている現在の値を表示するには、次のコマンドを入力します。
ulimit -s ulimit -n
次のコマンドも使用できます。
ulimit -a
このコマンドでは、-aによってすべての現在のリソース制限がリストされます。
NDDを使用して、Oracle SolarisカーネルのTCP/IPエフェメラル・ポート範囲が、サーバーの予測負荷に対応できる十分なエフェメラル・ポートを提供できるほど広いことを確認します。下限を9000以上に設定し、Well KnownポートとOracleおよびその他のサーバー・ポートで一般的に使用される登録済ポート範囲のポートを避けます。ポート範囲は、使用する予定のアプリケーションに予約されているポートを避けるために十分に高く設定します。範囲の下限が9000を超え、予想されるワークロードに対して範囲が十分大きい場合は、エフェメラル・ポート範囲に関するOUI警告は無視できます。
次のコマンドを使用して、エフェメラル・ポートの現在の範囲を確認します。
Oracle Solaris 10では、次のnddコマンドを使用します。
# /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port 32768 65535
Oracle Solaris 11では、次のipadmコマンドを使用します。
# ipadm show-prop -p smallest_anon_port,largest_anon_port tcp PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE tcp smallest_anon_port rw 32768 -- 32768 1024-65535 tcp largest_anon_port rw 65500 -- 65535 32768-65535
上の例で、エフェメラル・ポートの範囲はデフォルトの範囲(32768-65500)に設定されています。
予測負荷やサーバー数に対応できるように、必要に応じて、UDPおよびTCPエフェメラル・ポートの範囲をより広い範囲に更新します。たとえば、Oracle Solaris 11では次のようにします。
# ipadm set-prop -p smallest_anon_port=9000 tcp # ipadm set-prop -p largest_anon_port=65500 tcp # ipadm set-prop -p smallest_anon_port=9000 udp # ipadm set-prop -p largest_anon_port=65500 udp
これらの設定は永続的にすることをお薦めします。システムの再起動時にこのエフェメラル・ポートの範囲変更を自動で行う方法の詳細は、Oracle Solarisシステムの管理ドキュメントを参照してください。
|
関連項目: Oracle Solarisチューニング可能パラメータ・リファレンス・マニュアルは、次のリンクで入手できます。
|
