この付録では、通常Cluster Verification Utility(CVU)およびインストーラ(OUI)がインストール時に完了する構成作業を、手動で行う方法について説明します。この付録は、修正スクリプトを使用できないときに参考にしてください。
この付録の内容は次のとおりです。
パスワードなしのSSH構成は、必須のインストール要件です。SSHは、インストール時にクラスタ・メンバー・ノードの構成に使用され、またインストール後にはコンフィギュレーション・アシスタント、Oracle Enterprise Manager、Opatchおよび他の機能によって使用されます。
OUIを使用したパスワードなしのSSHの自動構成によって、クラスタのすべてのノード上にRSA暗号化キーが作成されます。システム上の制約により、DSA鍵を使用するなどして手動でSSHを設定することが求められる場合は、この手順を参考にして、パスワードなしのSSHを設定してください。
この後の例では、Oracleソフトウェア所有者をgrid
ユーザーとしています。
SSHが使用できない場合は、OUIはかわりにrsh
とrcp
の使用を試行します。ただし、多くの場合、セキュリティのためこれらのサービスを使用できません。
この項の内容は次のとおりです。
次のコマンドを入力して、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.3項「リモート表示および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ソフトウェア所有者が作成されていることを確認します。
すべてのクラスタ・ノードで、表E-1に示すカーネル・パラメータが、表に示されている計算式または推奨値以上に設定されていることを確認します。表の後に、値を確認して設定する手順を示します。
表E-1 HP-UXでのカーネル・パラメータの最小値
パラメータ | 必要最小値 |
---|---|
32768 |
|
0 |
|
1024 |
|
1073741824(1GB) |
|
2147483648(2GB) |
|
1024 |
|
63488 |
|
134217728(128MB) |
|
1073741824(1GB) |
|
3686 |
|
4096 |
|
4096 |
|
35840 |
|
4096 |
|
34816 |
|
7184 |
|
4096 |
|
4096 |
|
8192 |
|
4092 |
|
32767 |
|
1073741824 |
|
4096 |
|
512 |
|
tcp_largest_anon_port |
65500 |
udp_largest_anon_port |
65500 |
TCPおよびUDPカーネル・パラメータが、「UDPおよびTCPカーネル・パラメータの手動設定」の項の説明に従って設定されていることを確認します。
注意:
|
これらのカーネル・パラメータに指定されている現行の値または計算式を表示し、必要に応じて変更するには、kctune
、HP System Management Homepage(HP SMH)またはHP-UX Kernel Configuration(kcweb
)を使用します。
/usr/sbin/kctune
を使用してカーネル・パラメータを表示または変更します。たとえば、カーネル・パラメータを表示するには、kctuneに-d
フラグを付けて入力します。次に例を示します。
# /usr/sbin/kctune -d
カーネル・パラメータを変更するには、kctune variable=valueを入力します。次に例を示します。
# /usr/sbin/kctune aio_listio_max=512
他のすべてのクラスタ・ノードでこの手順を実行します。
次に、HP System Management Homepage(SMH)を使用してカーネル設定を変更する手順を示します。
オプションで、DISPLAY環境変数を設定し、ローカル・システムの表示を指定します。
Bourne、BashまたはKornシェル:
# DISPLAY=local_host:0.0 ; export DISPLAY
Cシェル:
# setenv DISPLAY local_host:0.0
# /usr/sbin/smh
「Kernel Configuration」領域→「Configurable Parameters」領域の順に選択します。
これらのパラメータに指定した値または式を確認し、必要に応じてその値または式を変更します。
必要に応じて、この手順の詳細についてSMHのオンライン・ヘルプを参照してください。
注意: 動的でないパラメータの値を変更した場合は、システムを再起動する必要があります。 |
必要に応じて、システムの再起動時に、ログインしてユーザーをroot
に切り替えます。
他のすべてのクラスタ・ノードでこの手順を実行します。
次に、手順を示します。
次のコマンドを入力して、kcweb
アプリケーションを起動します。
# /usr/sbin/kcweb -F
これらのパラメータに指定した値または式を確認し、必要に応じてその値または式を変更します。
必要に応じて、この手順の詳細についてkcweb
のオンライン・ヘルプを参照してください。
注意: 動的でないパラメータの値を変更した場合は、システムを再起動する必要があります。 |
必要に応じて、システムの再起動時に、ログインしてユーザーをroot
に切り替えます。
他のすべてのクラスタ・ノードでこの手順を実行します。
インストール時にFixupスクリプトを生成して実行し、データベースを正常にインストールするために必要なカーネル・パラメータ値を確認および設定できます。このスクリプトは、必要なカーネル・パッケージを必要に応じて最小値に更新します。
Fixupスクリプトを使用できない場合は、カーネル・パラメータが付録E「カーネル・パラメータの構成」に示す最小値以上に設定されていることを確認してください。値を手動で確認および設定する方法については、表に続く手順で説明します。
注意: 付録E「カーネル・パラメータの構成」に示されている、Fixupスクリプトで構成したカーネル・パラメータおよびシェル制限値は最小値です。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。 |
サーバーの予測負荷に対応できる十分なエフェメラル・ポートを提供するために、NDDを使用してHP-UXカーネルTCP/IPエフェメラル・ポート範囲が十分な広さを持つことを確認します。使用するアプリケーションに予約済のポートを避けるようにポート範囲を高く設定します。
次に例を示します。
# /usr/bin/ndd /dev/tcp tcp_largest_anon_port 65535
この例では、tcp_largest_anon_port
はデフォルト値に設定されています。
必要に応じて、ファイル/etc/rc.config.d/nddconf
を編集し、エントリを追加してUDPおよびTCPエフェメラル・ポート値を更新します。次に例を示します。
TRANSPORT_NAME[0]=tcp NDD_NAME[0]=tcp_largest_anon_port NDD_VALUE[0]=65500 TRANSPORT_NAME[1]=udp NDD_NAME[1]=udp_largest_anon_port NDD_VALUE[1]=65500
エントリに正しい順番で番号が付いていることを確認してください。たとえば、nddconf
にTCPポートおよびUDPポートのエントリが2つ存在する場合は、0と1(TRANSPORT_NAME[0]=tcp、TRANSPORT_NAME[1]=udp)にナンバリングされます。
注意: tcp_smallest_anon_port パラメータおよびudp_smallest_anon_port パラメータは廃止されているため、設定する必要はありません。 |