ヘッダーをスキップ
Oracle® Grid Infrastructureインストレーション・ガイド
11gリリース2 (11.2) for Oracle Solaris
B57234-06
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

D インストールの前提条件の作業を手動で行う方法

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

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

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

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

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

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

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

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

次のコマンドを入力して、SSHが実行されているかどうかを確認します。

$ pgrep sshd

SSHが実行されている場合、このコマンドの結果は1つ以上のプロセスID番号になります。インストール・ソフトウェア所有者(gridoracle)のホーム・ディレクトリで、コマンドls -alを使用して、.sshディレクトリを所有し、そのディレクトリへの書込みが可能であるのはそのユーザーのみであることを確認します。

SSHプロトコルには、RSA鍵またはDSA鍵のいずれかが必要です。RSAはSSH 1.5プロトコルで使用され、DSAはSSH 2.0プロトコルのデフォルトです。OpenSSHの場合は、RSAまたはDSAのいずれかを使用できます。この後の説明ではSSH1を想定しています。SSH2をインストールしており、SSH1を使用できない場合は、SSHディストリビューションのドキュメントを参照して、SSH1互換を構成するか、またはDSAを使用してSSH2を構成します。

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

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

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

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

D.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を実行します。

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

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

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

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

  2. 次のコマンド構文を使用して、ローカル・ノードから各ノードにSSHを実行します(ローカル・ノードからローカル・ノード自体へのSSHの実行、各ノードから他の各ノードへのSSHの実行を含みます)。hostname1hostname2などは、クラスタ内のノードのパブリック・ホスト名(別名および完全修飾されたドメイン名)です。

    [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転送が有効になっていることを示しています。この問題を解決するには、「表示およびX11転送の構成の設定」に進みます。

  3. 各クラスタ・ノード・メンバーに対して手順2を繰り返します。

SSHが適切に構成されていれば、パスワードを求めるプロンプトは表示されることなくsshscpコマンドを使用できます。次に例を示します。

[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ソフトウェア所有者が作成されていることを確認します。

D.2 カーネル・リソースの構成

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


注意:

次の項には、カーネル・パラメータおよびシェル制限の推奨値のみを示します。本番データベース・システムでは、カーネル・リソースを調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・リソース管理の詳細は、オペレーティング・システムのドキュメントを参照してください。

D.2.1 Oracle Solaris 10を実行するSPARCシステムでのカーネル・パラメータの構成

Oracle Solaris 10以上のオペレーティング・システムで、次の表に示すproject.maxパラメータが、示されている推奨値以上に設定されていることを確認します。

表の後の手順で、値の確認および設定方法を説明します。


注意:

Oracle Solaris 10では、System V IPCを実装するために/etc/systemファイルを変更する必要はありません。/etc/systemパラメータは、ここでは参照専用に提供されています。

パラメータ リソース制御による置換え 推奨値
noexec_user_stack 適用不可(NA) NA
semsys:seminfo_semmni project.max-sem-ids 100
semsys:seminfo_semmns NA NA
semsys:seminfo_semmsl process.max-sem-nsems 256
semsys:seminfo_semvmx NA NA
shmsys:shminfo_shmmax project.max-shm-memory 4294967295
shmsys:shminfo_shmmni project.max-shm-ids 100


注意:

  • project.max-shm-memoryリソース制御は、対応するプロジェクトで開始された各Oracle Databaseインスタンスに割り当てられているすべての共有メモリーの累積合計と同じになります。
  • project.max-shm-memoryリソース制御値は、Oracleインスタンス以外の他のアプリケーションがこのプロジェクトの共有メモリー・セグメントを使用していないことを前提としています。

  • memory_target (またはmax_sga_size)がprocess.max-address-spaceおよびproject.max-shm-memoryを超えないようにします。詳細は、次のURLでMy Oracle SupportのNote 1370537.1を参照してください。

    https://support.oracle.com


Oracle Solaris 10以上のリリースでは、次の手順を使用して、リソース制御に指定された現在の値を表示し、必要に応じて変更します。

  1. リソース制御の現在の値を表示するには、次のコマンドを入力します。

    $ 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
    
  2. 現在のいずれかの値を変更する必要がある場合は、次のようにします。

    1. max-shm-memoryの値を6GBに変更する場合:

      # prctl -n project.max-shm-memory -v 6gb -r -i project group.dba 
      
    2. max-sem-idsの値を256に変更する場合:

      # prctl -n project.max-sem-ids -v 256 -r -i project group.dba
      

    注意:

    コマンドprctl(リソース制御)を使用してシステム・パラメータを変更する場合、これらのパラメータの変更を有効にするために、システムを再起動する必要はありません。ただし、変更されたパラメータは、システムの再起動後はなくなります。

次の手順を使用して、リソース制御のプロジェクト設定を変更すると、システムの再起動後も変更が有効になります。

  1. デフォルトでは、Oracleインスタンスはdbaグループのoracleユーザーとして実行されます。group.dbaという名前のプロジェクトが、oracleユーザーのデフォルトのプロジェクトとして機能するように作成されます。コマンドidを実行して、oracleユーザーのデフォルトのプロジェクトを検証します。

    # su - oracle
    $ id -p
    uid=100(oracle) gid=100(dba) projid=100(group.dba)
    $ exit
    
  2. 最大共有メモリー・サイズを4GBに設定するには、projmodコマンドを実行します。

    # projmod -sK "project.max-shm-memory=(privileged,4G,deny)" group.dba
    

    また、リソース制御値project.max-shm-memory=(privileged,4294967295,deny)を、Oracleプロジェクトのプロジェクト・エントリの最後のフィールドに追加する方法もあります。

  3. これらの手順が完了した後で、次のコマンドを使用して、/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)
    
  4. 次の例のように、プロセスの所有権を確認し、コマンド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チューニング可能パラメータ・リファレンス・マニュアル』を参照してください。

    リソース制御の設定およびOracle Solarisコマンドの使用方法の詳細は、Oracle Solaris製品ドキュメントのページを参照してください。