| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for IBM AIX on POWER Systems (64-Bit) E49837-10 |
|
 前 |
 次 |
| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for IBM AIX on POWER Systems (64-Bit) E49837-10 |
|
前 |
次 |
この付録では、通常、クラスタ検証ユーティリティ(CVU)およびOracle Universal Installer (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=1100(grid) gid=1000(oinstall) groups=1000(oinstall) 1100(grid,asmadmin,asmdba) $ id grid uid=1100(grid) gid=1000(oinstall) groups=1000(oinstall), 1100(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ソフトウェア所有者が作成されていることを確認します。
この項の内容は次のとおりです。
|
注意: この項には、パラメータおよびシェル制限の推奨値のみを示します。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。 |
シェル制限およびシステム構成パラメータは、この項の説明に従って設定することをお薦めします。
Oracle Grid Infrastructureのインストール所有者およびrootのシェル制限を設定します。smitユーティリティを使用するか、/etc/security/limitsファイルを編集して、両方のアカウントのシェル制限が次の表に示す値に設定されていることを確認します。crsデーモン(crsd)はrootで実行されるため、rootユーザーにはこれらの設定が必要です。AIXでは、ulimit設定により、プロセス・メモリー関連のリソース制限が決定されます。
| シェル制限(smitでの表示) | 推奨値 |
|---|---|
| Soft File Descriptors | 1024以上 |
| Hard File Descriptors | 65536以上 |
| プロセスの数(Soft) | 2047以上 |
| プロセスの数(Hard) | 16384以上 |
| Soft STACKサイズ | 10240KB以上 |
| Hard STACKサイズ | 10240 KB以上、32768 KB以下 |
| Soft FILE size | -1 (無制限) |
| Soft CPU時間 | -1 (無制限)
注意: これがデフォルト値です。 |
| Soft DATAセグメント | -1 (無制限) |
| RSSメモリー・サイズ | -1 (無制限) |
これらのシェル制限に指定されている現在の値を表示し、必要に応じて変更するには、次の手順を実行します。
次のコマンドを入力します。
# smit chuser
「User NAME」フィールドに、Oracleソフトウェア所有者のユーザー名(oracleなど)を入力します。
リストをスクロール・ダウンして、シェル制限用に表示される値が前述の表にリストされているとおりであることを確認します。smitユーティリティおよび/etc/security/limitsファイルについて、-1は値を無制限に設定します。
必要に応じて既存の値を編集します。値を編集するには、smitユーティリティを使用するか、/etc/security/limitsファイルを編集します。smitユーティリティを実行する権限がある場合は、必然的にlimitsファイルを編集する権限もあります。
変更が完了したら、[F10]を押して終了します。
修正スクリプトが使用できない場合は、次の表で、各カーネル・パラメータが表に示す最小値以上の値に設定されていることを確認します。いずれかのパラメータの現在の値がこの表にリストされている値より大きい場合、修正スクリプトはそのパラメータの値を変更しません。
| パラメータ | 最小値 |
|---|---|
maxuprocs |
16384 |
ncargs |
128 |
次の手順で、手動による値の確認および設定方法について説明します。
ユーザーごとに許可されたプロセスの最大数が16384以上に設定されていることを確認するには、次の手順を実行します。
|
注意: 本番システムの場合、この値は、システムで実行している各データベースのPROCESSESおよびPARALLEL_MAX_SERVERS初期化パラメータの合計に128を加算した値以上である必要があります。 |
次のコマンドを入力します。
# smit chgsys
ユーザーごとに許容される最大プロセス数に示された値が16384以上であることを確認します。
必要に応じて既存の値を編集します。
変更が完了したら、[F10]を押して終了します。
シェルから長いコマンドを実行できることを確認するには、次の手順を使用します。
|
注意: ncargsシステム属性の値を128以上に設定することをお薦めします。ncargs属性により、コマンドラインの引数として渡すことができる値の最大数が決まります。 |
次のコマンドを入力します。
# smit chgsys
「ARG/ENV list size in 4K byte blocks」に表示される値が128以上であることを確認します。
必要に応じて既存の値を編集します。
変更が完了したら、[F10]を押して終了します。
AIX 6およびAIX 7では、非同期入出力(AIO)デバイス・ドライバはデフォルトで有効です。AIX 6でもAIX 7でも、aioserverプロセスの数をデフォルト値より増やします。aio_maxreqsの推奨値は64k(65536)です。AIX 6とAIX 7の両方で、この値を確認してください。
次の手順で、aio_maxreqs値を確認します。
# ioo –o aio_maxreqs aio_maxreqs = 65536
ファイル・システムに非同期I/Oを行うと、各非同期I/O操作が非同期I/Oサーバーに関係付けられます。つまり、非同期I/Oサーバーの数によって、システムで同時に実行される非同期I/O操作の数が制限されます。
システムの再起動時に起動されるサーバーの初期数は、aio_minserversパラメータによって決まります。同時実行される非同期I/O操作が発生すると、aio_maxserversパラメータで設定された値を上限として非同期I/Oサーバーが追加で起動されます。
通常、非同期I/Oサーバーの数を設定するには、次の手順を実行します。
aio_maxserversの初期値を、10×ディスク数÷(同時に使用されるCPUの数)に調整します(ただし80を超えないこと)。
I/Oアクティビティが多いときのシステム・パフォーマンスに対する効果を監視します。すべてのAIOサーバー・プロセスが起動されている場合は、aio_maxserversの値を大きくします。また、I/Oアクティビティのピーク時のシステム・パフォーマンスの監視を続け、追加AIOサーバーによる効果があったかどうかを確認します。非同期I/Oサーバーが多すぎると、追加プロセスによるメモリーとプロセッサ・オーバーロードが増えますが、このデメリットはわずかです。AIOパラメータのチューニングの詳細は、使用するオペレーティング・システムのベンダーのドキュメントを参照してください。
起動済のAIOサーバー・プロセスの数を監視するには、次のように入力します。
# ps -ek|grep -v grep|grep –v posix_aioserver|grep -c aioserver
修正スクリプトまたはCVUを使用してエフェメラル・ポートを設定しない場合は、NDDを使用して、AIXカーネルTCP/IPエフェメラル・ポート範囲が、予想されるサーバーのワークロードに対して十分なエフェメラル・ポートを提供できることを確認します。下限を9000以上に設定し、Well KnownポートとOracleおよびその他のサーバー・ポートで一般的に使用される登録済ポート範囲のポートを避けます。使用するアプリケーションに予約済のポートを避けるようにポート範囲を高く設定します。範囲の下限が9000を超え、予想されるワークロードに対して範囲が十分大きい場合は、エフェメラル・ポート範囲に関するOUI警告は無視できます。
次に例を示します。
# /usr/sbin/no -a | fgrep ephemeral
tcp_ephemeral_low = 32768
tcp_ephemeral_high = 65500
udp_ephemeral_low = 32768
udp_ephemeral_high = 65500
上の例で、TCPおよびUDPエフェメラル・ポートはデフォルトの範囲(32768-65536)に設定されています。
高い値のエフェメラル・ポートが必要な負荷になることが予測できる場合は、UDPおよびTCPエフェメラル・ポートの範囲を広くします。次に例を示します。
# /usr/sbin/no -p -o tcp_ephemeral_low=9000 -o tcp_ephemeral_high=65500 # /usr/sbin/no -p -o udp_ephemeral_low=9000 -o udp_ephemeral_high=65500
