プライマリ・コンテンツに移動
Oracle® Grid Infrastructureインストレーション・ガイド
12cリリース1 (12.1) for HP-UX Itanium
E52983-07
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

E インストール作業を手動で行う方法

この付録では、通常Cluster Verification Utility(CVU)およびインストーラ(OUI)がインストール時に完了する構成作業を、手動で行う方法について説明します。この付録は、修正スクリプトを使用できないときに参考にしてください。

この付録の内容は次のとおりです。

E.1 すべてのクラスタ・ノードでの手動によるSSHの構成

パスワードなしのSSH構成は、必須のインストール要件です。SSHは、インストール時にクラスタ・メンバー・ノードの構成に使用され、またインストール後にはコンフィギュレーション・アシスタント、Oracle Enterprise Manager、Opatchおよび他の機能によって使用されます。

OUIを使用したパスワードなしのSSHの自動構成によって、クラスタのすべてのノード上にRSA暗号化キーが作成されます。システム上の制約により、DSA鍵を使用するなどして手動でSSHを設定することが求められる場合は、この手順を参考にして、パスワードなしのSSHを設定してください。

この後の例では、Oracleソフトウェア所有者をgridユーザーとしています。

SSHが使用できない場合は、OUIはかわりにrshとrcpの使用を試行します。ただし、多くの場合、セキュリティのためこれらのサービスを使用できません。

この項の内容は次のとおりです。

E.1.1 システム上の既存のSSH構成の確認

次のコマンドを入力して、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を構成します。

E.1.2 クラスタ・ノードでのSSHの構成

SSHを構成するには、最初に各クラスタ・ノードにRSA鍵およびDSA鍵を作成してから、すべてのクラスタ・ノード・メンバーで生成されたすべての鍵を各ノードで同じ認証鍵ファイルにコピーする必要があります。SSHファイルを読み取ることができのは、rootおよびソフトウェア・インストール・ユーザー(oracle、grid)のみである必要があります。これは、SSHが他のユーザーによってアクセス可能であると、SSHは秘密鍵を無視するためです。この後の例では、DSA鍵が使用されています。

インストールに使用するOracleソフトウェアのインストール所有者ごとにSSHを構成する必要があります。

SSHを構成するには、次の手順を実行します。

E.1.2.1 各ノードでのSSHディレクトリおよびSSH鍵の作成

各ノードに対し、次の手順を実行します。

  1. ソフトウェア所有者(この例ではgridユーザー)としてログインします。

  2. コマンド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)

  3. 必要に応じて、gridユーザーのホーム・ディレクトリに.sshディレクトリを作成して適切な権限を設定し、読取り/書込み権限を持っているのはoracleユーザーのみであることを確認します。

    $ mkdir ~/.ssh
$ chmod 700 ~/.ssh

    注意:

    権限が700に設定されていないと、SSH構成は失敗します。

  4. 次のコマンドを入力します。

    $ /usr/bin/ssh-keygen -t dsa

    プロンプトで、鍵ファイルには、デフォルトの位置を使用します([Enter]を押します)。


    注意:

    パス・フレーズを持つSSHは、Oracle Clusterware 11gリリース2以上のリリースではサポートされません。

    このコマンドによって、DSA公開鍵が~/.ssh/id_dsa.pubファイルに、秘密鍵が~/.ssh/id_dsaファイルに書き込まれます。

    秘密鍵は、Oracleソフトウェア・インストールの実行を許可されていない他のユーザーには配布しないでください。

  5. DSA鍵を使用して、クラスタ・メンバーを作成する各ノードで手順1から手順4を実行します。

E.1.2.2 共通のauthorized_keysファイルへのすべての鍵の追加

次の手順を実行します。

  1. ローカル・ノードで、Oracle Grid Infrastructure所有者のホーム・ディレクトリ(通常、gridまたはoracle)にある.sshディレクトリに移動します。

    次に、次のコマンドを使用してDSA鍵をauthorized_keysファイルに追加します。

    $ cat id_dsa.pub >> authorized_keys
$ ls

    .sshディレクトリに、作成したid_dsa.pub鍵とauthorized_keysファイルが表示されるはずです。

  2. ローカル・ノードで、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

  3. 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ファイルのすべての内容が含まれている必要があります。

E.1.3 クラスタ・ノードでのSSHユーザー等価関係の有効化

すべての鍵が含まれているauthorized_keysファイルをクラスタ内の各ノードにコピーしたら、示されている順に次の手順を実行します。この例では、Oracle Grid Infrastructureソフトウェア所有者の名前はgridです。

  1. OUIを実行するシステムにgridユーザーとしてログインします。

  2. 次のコマンド構文を使用して、ローカル・ノードから各ノードに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転送の構成の設定」に進みます。

  3. 各クラスタ・ノード・メンバーに対して手順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.2 カーネル・パラメータの構成


注意:

次の項には、カーネル・パラメータの推奨値のみを示します。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

HP-UX 11.31(バージョン3)では、次のパラメータは有効ではありません。

  • msgmap

  • msgseg

E.2.1 カーネル・パラメータの最小値

すべてのクラスタ・ノードで、表E-1に示すカーネル・パラメータが、表に示されている計算式または推奨値以上に設定されていることを確認します。表の後に、値を確認して設定する手順を示します。

表E-1 HP-UXでのカーネル・パラメータの最小値

パラメータ 必要最小値

ksi_alloc_max

32768

executable_stack

0

max_thread_proc

1024

maxdsiz

1073741824(1GB)

maxdsiz_64bit

2147483648(2GB)

maxfiles

1024

maxfiles_lim

63488

maxssiz

134217728(128MB)

maxssiz_64bit

1073741824(1GB)

maxuprc

3686

msgmni

4096

msgtql

4096

ncsize

35840

nflocks

4096

ninode

34816

nkthread

7184

nproc

4096

semmni

4096

semmns

8192

semmnu

4092

semvmx

32767

shmmax

1073741824

shmmni

4096

shmseg

512

tcp_largest_anon_port

65500

udp_largest_anon_port

65500

TCPおよびUDPカーネル・パラメータが、「UDPおよびTCPカーネル・パラメータの手動設定」の項の説明に従って設定されていることを確認します。


注意:

  • パラメータに対する現行の値がこの表の値より大きい場合は、そのパラメータの値を変更しないでください。

  • HFSを使用しない場合は、デフォルトのninode値を保持してください。

E.2.2 カーネル・パラメータの手動設定

これらのカーネル・パラメータに指定されている現行の値または計算式を表示し、必要に応じて変更するには、kctune、HP System Management Homepage(HP SMH)またはHP-UX Kernel Configuration(kcweb)を使用します。

E.2.2.1 KCTUNEを使用したカーネル設定の変更

/usr/sbin/kctuneを使用してカーネル・パラメータを表示または変更します。たとえば、カーネル・パラメータを表示するには、kctuneに-dフラグを付けて入力します。次に例を示します。

# /usr/sbin/kctune -d

カーネル・パラメータを変更するには、kctune variable=valueを入力します。次に例を示します。

# /usr/sbin/kctune aio_listio_max=512

他のすべてのクラスタ・ノードでこの手順を実行します。

E.2.2.2 SMHを使用したカーネル設定の変更

次に、HP System Management Homepage(SMH)を使用してカーネル設定を変更する手順を示します。

  1. オプションで、DISPLAY環境変数を設定し、ローカル・システムの表示を指定します。

    • Bourne、BashまたはKornシェル:

      # DISPLAY=local_host:0.0 ; export DISPLAY

    • Cシェル:

      # setenv DISPLAY local_host:0.0

  2. SMHを起動します。

    # /usr/sbin/smh

  3. 「Kernel Configuration」領域→「Configurable Parameters」領域の順に選択します。

  4. これらのパラメータに指定した値または式を確認し、必要に応じてその値または式を変更します。

    必要に応じて、この手順の詳細についてSMHのオンライン・ヘルプを参照してください。


    注意:

    動的でないパラメータの値を変更した場合は、システムを再起動する必要があります。

  5. 必要に応じて、システムの再起動時に、ログインしてユーザーをrootに切り替えます。

  6. 他のすべてのクラスタ・ノードでこの手順を実行します。

E.2.2.3 KCWEBを使用したカーネル設定の変更

次に、手順を示します。

  1. 次のコマンドを入力して、kcwebアプリケーションを起動します。

    # /usr/sbin/kcweb -F

  2. これらのパラメータに指定した値または式を確認し、必要に応じてその値または式を変更します。

    必要に応じて、この手順の詳細についてkcwebのオンライン・ヘルプを参照してください。


    注意:

    動的でないパラメータの値を変更した場合は、システムを再起動する必要があります。

  3. 必要に応じて、システムの再起動時に、ログインしてユーザーをrootに切り替えます。

  4. 他のすべてのクラスタ・ノードでこの手順を実行します。

E.2.3 HP-UXシステムのカーネル・パラメータの構成

インストール時にFixupスクリプトを生成して実行し、データベースを正常にインストールするために必要なカーネル・パラメータ値を確認および設定できます。このスクリプトは、必要なカーネル・パッケージを必要に応じて最小値に更新します。

Fixupスクリプトを使用できない場合は、カーネル・パラメータが付録E「カーネル・パラメータの構成」に示す最小値以上に設定されていることを確認してください。値を手動で確認および設定する方法については、表に続く手順で説明します。


注意:

付録E「カーネル・パラメータの構成」に示されている、Fixupスクリプトで構成したカーネル・パラメータおよびシェル制限値は最小値です。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

E.3 UDPおよびTCPカーネル・パラメータの手動設定

サーバーの予測負荷に対応できる十分なエフェメラル・ポートを提供するために、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パラメータは廃止されているため、設定する必要はありません。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引