Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2.0) B71694-10 |
|
前 |
次 |
このガイドで取り上げている参照エンタープライズ・トポロジはスケーラビリティが高くなっています。スケール・アップもスケール・アウトも可能です。この章では、その方法を説明します。
トポロジをスケール・アップするには、すでに1つ以上のコンポーネント・インスタンスを実行しているノードに、新しいコンポーネント・インスタンスを追加します。トポロジをスケール・アウトするには、新しいノードに新しいコンポーネント・インスタンスを追加します。
この章の内容は次のとおりです。
このガイドで説明しているOracle Identity and Access Managementトポロジには、ディレクトリ層、アプリケーション層およびWeb層の3つの層があります。このガイドで説明しているOracle Identity and Access Managementトポロジの3つすべての層内のコンポーネントは、スケール・アップまたはスケール・アウトが可能です。
このリリースでは、Identity and Access Managementデプロイメント・ツールを使用してコンポーネントをスケール・アウトまたはスケール・アップすることはできません。この章で説明するように、スケール・アップまたはスケール・アウトは手動の処理になります。
トポロジのスケールアップは、すでに1つ以上のサーバー・インスタンスが実行しているノードに、新しいサーバー・インスタンスを追加して実行します。トポロジのスケール・アウトは、新しいノードに新しいコンポーネントを追加して実行します。
LDAPディレクトリは次のようにスケーリングします。
OracleバイナリはLDAPホスト間で共有されます。スケール・アウト時、新しいホストに共有バイナリ・ディレクトリをマウントする必要があります。これを行うには、第5.7項「共有記憶域のホストへのマウント」の手順を実行してください。
Oracle Unified DirectoryのバイナリはIDM_TOP
にあり、これはLDAPHOST間で共有されています。Oracle Unified Directoryを新しいホストにスケール・アウトする際、このディレクトリが新しいホストにマウントされていることを確認します。第5.7項「共有記憶域のホストへのマウント」を参照してください。
ディレクトリ層には2つのOracle Unified Directoryノード(LDAPHOST1とLDAPHOST2)があり、それぞれでOracle Unified Directoryインスタンスを実行しています。いずれかのノードのOracle Unified Directoryバイナリを使用して、Oracle Unified Directoryの新しいインスタンスを作成できます。
次のようにします。
第14.2.2.1項「Oracle Unified Directoryをスケーリングするための情報収集」に示されるように情報を収集します。
スケール・アウトの場合、共有記憶域を新しいLDAPHOSTにマウントします。
第14.2.2.4項「新しいOracle Unified Directoryインスタンスのロード・バランサへの追加」の手順に従います。
第14.4.5項「ロード・バランサの再構成」に記載されているように、新しいOracle Unified Directoryインスタンスのホストおよびポートの情報を使用して、ロード・バランサを再構成します。
Oracle Unified Directoryをスケーリングする前に次の情報を収集します。
説明 | 変数 | ドキュメント内での値 | 実際の値 |
---|---|---|---|
新しいOracle Unified Directoryのホスト名 |
|
LDAPHOST3.mycompany.com |
|
Oracle Unified Directoryのリスニング・ポート |
|
1389 |
|
Oracle Unified DirectoryのSSLポート |
|
1636 |
|
Oracle Unified Directory管理ポート |
|
4444 |
|
Oracle Unified Directoryのレプリケーション・ポート |
|
8989 |
|
Oracleインスタンスの場所 |
|
|
|
Oracle Unified Directoryの既存のインスタンス/コンポーネント名 |
|
|
|
新しく作成されたインスタンス/コンポーネント名 |
|
|
|
Oracle Unified Directoryの管理者パスワード |
|
||
共通のパスワード |
|
別のマシンにスケール・アウトする場合、ポート1389 (LDAP_PORT)、1636 (LDAP_SSL_PORT)、4444 (LDAP_ADMIN_PORT)および8989を使用できます。スケール・アップする場合には、これらのポートはすでに使用されており、一意のポートを選択する必要があります。使用しているオペレーティング・システムに対して次のコマンドを発行して、使用を計画しているポートがコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても出力は何も返されません。
netstat -an | grep "1389"
ポートが使用されている(コマンドからどちらかのポートを識別する出力が返された)場合は、ポートを解放する必要があります。
解放したポートのエントリを/etc/services
ファイルから削除し、サービスを再起動するか、コンピュータを再起動します。
環境変数JAVA_HOME
を設定します
環境変数INSTANCE_NAME
を../../../../u02/private/oracle/config/instances/oud3
などの新しいインスタンス値に設定します。
ツールはインスタンス・ホームをOUD_ORACLE_HOME
を基準にして作成するため、前のディレクトリを含めてOUD_ORACLE_INSTANCE
で作成したインスタンスを取得する必要があります。
ディレクトリをOUD_ORACLE_HOME
に変更します
次のコマンドを実行してOracle Unified Directory構成アシスタントを起動します。
./oud-setup
「ようこそ」画面で、「次へ」をクリックします。
「サーバー設定」画面で、次を入力します。
ホスト名: Oracle Unified Directoryが実行されているホストの名前(たとえばLDAPHOST3)
LDAPリスナー・ポート: スケール・アウトの場合1389 (LDAP_PORT)、スケール・アップの場合一意のポート。
管理コネクタ・ポート: 4444 (LDAP_ADMIN_PORT)
LDAPセキュア・アクセス
「構成」をクリックします
「SSLアクセス」を選択します
ポートでSSLを有効化: 1636 (LDAP_SSL_PORT)
証明書: 自己署名証明書を生成するまたは独自の証明書の詳細を提供します。
「OK」をクリックします。
ルート・ユーザーDN: 管理ユーザーを入力します(たとえば、cn=oudadmin
)
パスワード: ouadminユーザーに割り当てるパスワードを入力します。COMMON_IDM_PASSWORD
を使用することをお薦めします。
パスワード(確認): パスワードを再入力します。
「次へ」をクリックします。
トポロジ・オプション画面で、次を入力します。
このサーバーは、レプリケーション・トポロジの一部になります
レプリケーション・ポート: (LDAP_REPLIC_PORT
) 8989
レプリケーション・トラフィックを暗号化する場合には、「セキュアとして構成する」を選択します。
トポロジにはすでにサーバーがあります: 選択済。
次の内容を入力します。
ホスト名: このインスタンス用のOracle Unified Directoryサーバー・ホストの名前(たとえばLDAPHOST1.mycompany.com)
管理者コネクタ・ポート: 4444 (LDAP_ADMIN_PORT)
管理ユーザー: LDAPHOST1のOracle Unified Directory管理ユーザーの名前(たとえば、cn=oudadmin
)
管理者パスワード: 管理者パスワード。COMMON_IDM_PASSWORD
を使用することをお薦めします。
「次へ」をクリックします。
信頼されていない証明書ダイアログが表示される場合、これは自己署名証明書を使用しているためです。「永久受入れ」をクリックします。
「次へ」をクリックします。
グローバル管理者の作成画面で、次を入力します。
グローバル管理者ID: Oracle Unified Directoryレプリケーションを管理するために使用するアカウントの名前(たとえば、oudmanager
)
グローバル管理者パスワード / 確認: このアカウントのパスワードを入力します。COMMON_IDM_PASSWORD
を使用することをお薦めします。
「次へ」をクリックします。
データ・レプリケーション画面で、dc=mycompany,dc=com
を選択し、「次へ」をクリックします。
Oracleコンポーネントの統合画面で、「次へ」をクリックします。
ランタイム・オプション画面で、「次へ」をクリックします。
「確認」画面で、表示された情報が正しいことを確認し、「終了」をクリックします。
「終了」画面で、「閉じる」をクリックします。
構成後、単純検索を実行することによってOracle Unified Directoryが動作することを検証できます。これを実行するには、次のコマンドを発行します。
OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAPHOST3.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl
Oracle Unified Directoryが正常に動作している場合、リストsupportedControl
エントリが返されます。
新しいOracle Unified Directoryインスタンスを、インスタンス間でリクエストを分散するためにロード・バランサで定義された既存のサーバー・プールに追加します。
アプリケーション層にはOracle Access Management Access Manager用の管理対象サーバーを実行する2つのノード(OAMHOST1およびOAMHOST2)と、Oracle Identity Managerの管理対象サーバーを実行する2つのノード(OIMHOST1およびOIMHOST2)があります。オプションで、アプリケーション層にはOracle Adaptive Access Managerの管理対象サーバーを実行する2つのノード(OAMHOST1およびOAMHOST2)がある場合もあります。
この項には次のトピックが含まれます:
次の表を使用して、必要な値を収集します。
Access Managerをスケーリングする前に次の情報を収集します。
説明 | 変数 | ドキュメント内での値 | 実際の値 |
---|---|---|---|
ホスト名 |
|
||
既存のAccess Managerサーバー |
|
||
新しいAccess Managerのサーバー名 |
|
|
|
サーバー・リスニング・ポート |
|
14100 |
|
WebLogic管理ホスト |
|
IADADMINVHN.mycompany.com |
|
WebLogic管理ポート |
|
7001 |
|
WebLogic管理ユーザー |
weblogic_idm |
||
WebLogic管理パスワード |
説明 | 変数 | ドキュメント内での値 | 実際の値 |
---|---|---|---|
ホスト名 |
|
||
SOAの仮想サーバー名 |
SOAHOSTxVHN |
||
Oracle Identity Managerの仮想サーバー名 |
OIMHOSTxVHN |
||
クローニングする既存のSOA管理対象サーバー |
|
|
|
クローニングする既存のOracle Identity Manager管理対象サーバー |
|
|
|
新しいSOA管理対象サーバー名 |
|
|
|
新しいOracle Identity Manager管理対象サーバー名 |
|
|
|
新しいJMSサーバー用の数値拡張 |
|
3 |
|
WebLogic管理ホスト |
|
IGDADMINVHN.mycompany.com |
|
WebLogic管理ポート |
|
7101 |
|
WebLogic管理ユーザー |
weblogic_idm |
||
WebLogic管理パスワード |
Oracle Adaptive Access Managerをスケーリングする前に次の情報を収集します。
説明 | 変数 | ドキュメント内での値 | 実際の値 |
---|---|---|---|
ホスト名 |
|
||
既存のOAAMサーバー |
|
||
新しいOAAMのサーバー名 |
|
|
|
サーバー・リスニング・アドレス |
|||
OAAM管理対象サーバーのポート |
|
14200 |
|
OAAM管理サーバーのポート |
|
14300 |
|
WebLogic管理ホスト |
|
IADADMINVHN.mycompany.com脚注 1 |
|
WebLogic管理ポート |
|
7001 |
|
WebLogic管理ユーザー |
weblogic_idm |
||
WebLogic管理パスワード |
脚注 1 これはスケーリングするドメインのことです。
OAMアプリケーション層のコンポーネントをスケール・アウトする前に、Middlewareホームをマウントして、新しいマシンを作成します。
Middlewareホームをマウントして新しいマシンを作成する手順:
新しいノードで、Oracle Fusion Middlewareのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。詳細は、第5.7項「共有記憶域のホストへのマウント」を参照してください。
共有記憶域内のIAD_ORACLE_HOME
をローカルのOracleインベントリに追加するには、次のコマンドを実行します。
cd IAD_ORACLE_HOME/oui/bin ./attachHome.sh -jreLoc JAVA_HOME
注意: この項では、例としてIAD_ORACLE_HOMEを使用します。同じ手順をIGD_ORACLE_HOMEに使用します。 |
Middlewareホーム・リストを更新するには、HOME
/bea/beahomelist
ファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAD_MW_HOME
/oui/bin
をこのファイルに追加します。
第15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMAccessDomainのWebLogic管理コンソールにログインします。
使用する新しいノード用の新しいマシンを作成して、そのマシンを次のようにドメインに追加します。
「ナビゲーション」メニューから「環境」→「マシン」を選択します。
「ロックして編集」をクリックします。
「マシン・サマリー」画面で「新規」をクリックします。
次の情報を入力します。
名前: マシンの名前(NEWHOSTn)
マシンのOS: UNIXを選択します。
「次へ」をクリックします。
「ノード・マネージャのプロパティ」ページで、次の情報を入力します。
タイプ: SSL。
リスニング・アドレス: NEWHOSTn
.
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
新しいホスト上のWebLogic管理対象サーバーを起動および停止するにはノード・マネージャを使用します。新しいホスト用の新しいノード・マネージャを作成するには次の手順を実行します。
新しいノード・マネージャ用の新しいディレクトリを既存のものをコピーして作成します。ディレクトリSHARED_CONFIG
/nodemanager/oamhost1.mycompany.com
をSHARED_CONFIG
/nodemanager/
newiamhost
.mycompany.com
にコピーします。
例:
cp -r $SHARED_CONFIG/nodemanager/oamhost1.mycompany.com $SHARED_CONFIG/nodemanager/newiamhost.mycompany.com
ディレクトリを新しく作成したディレクトリに変更します。
cd SHARED_CONFIG/nodemanager/NEWHOST3.mycompany.com
nodemanager.properties
ファイルを、OAMHOST1に対するエントリをすべてOAMHOST3
に変更するよう編集します。次に例を示します。
DomainsFile=/u01/oracle/config/nodemanager/OAMHOST1.mycompany.com/nodemanager.domain
は次のようになります。
DomainsFile=/u01/oracle/config/nodemanager/NEWHOST3.mycompany.com/nodemanager.domain
startNodeManagerWrapper.sh
ファイルを、OAMHOST1に対するエントリをすべてOAMHOST3に変更するよう編集します。たとえば、
NM_HOME=/u01/oracle/config/nodemanager/oamhost1.mycompany.com
は次のようになります。
NM_HOME=/u01/oracle/config/nodemanager/oamhost3.mycompany.com
次のコマンドを実行してノード・マネージャを起動します。
./startNodeManagerWrapper.sh
第14.5.3項「ノード・マネージャ構成の更新」の手順に従ってノード・マネージャ構成を更新し、新しいホスト用の証明書が作成されるようにします。
ドメインを新しい管理対象サーバーを含むように拡張するときには常に、ドメイン構成で必要になるものをASERVER_HOME
の場所からMSERVER_HOME
の場所へ抽出する必要があります。これは、スケール・アップおよびスケール・アウトのいずれにも適用されます。これを行うには、次の手順を実行します。
注意: 次の手順は、IAMAccessDomainの圧縮および解凍の例です。 |
管理サーバーのあるホスト上でドメインを圧縮します(たとえば、OAMHOST1では次のようにします)。
pack.sh -domain=IAD_ASERVER_HOME -template =/templates/managedServer.jar -template_name="template_name" -managed=true
pack.sh
スクリプトは、ORACLE_COMMON_HOME
/common/bin
にあります。
次のコマンドを使用して、スケール・アウトの場合は新しいホスト上で、スケール・アップの場合は既存のホスト上でドメインを解凍します。
unpack.sh -domain=IAD_MSERVER_HOME -template=/templates/managedServer.jar -app_dir=IAD_MSERVER_HOME/applications
unpack.sh
スクリプトは、ORACLE_COMMON_HOME
/common/bin
にあります。
スケール・アウトする場合、ノード・マネージャを起動して、プロパティ・ファイルを更新します。
第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャを起動および停止します。
ORACLE_COMMON_HOME
/common/bin
にあるスクリプトsetNMProps.sh
を実行して、ノード・マネージャのプロパティ・ファイルを更新します。たとえば、次のように指定します。
cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh
第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャをもう一度起動します。
この項には次のトピックが含まれます:
同じタイプの既存の管理対象サーバーをクローニングして新規管理対象サーバーを作成できます。Access Managerをスケール・アウト/アップするには、wls_oam1
をクローニングします。同様に、Identity Managerをスケール・アウト/アップするには、wls_oim1
をクローニングします。
次の例はAccess Managerの管理対象サーバーのクローニングの例ですが、手順はすべての製品で同じです。
15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、クローニングする管理対象サーバーのドメイン用のOracle WebLogic管理コンソールにログインします。この例では、ドメインはIAMAccessDomain
です。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」メニューで「ロックして編集」をクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1
)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3
です。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
スケール・アウトする場合、デフォルトのポート14100
(表7–1のOAM_PORT
)を使用できます。スケール・アップする場合には、一意のポートを選択します。
「OK」をクリックします。
新しく作成したサーバーWLS_OAM3をクリックします。
「マシン」を第14.3.2項「スケール・アウト時のMiddlewareホームのマウントと新しいマシンの作成」で作成したマシンになるように設定します。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3
管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとNEWHOST
内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。
「保存」をクリックします。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
この項では、Access Manager固有のスケーリング手順について説明します。
注意: 共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。 |
次の各項の手順を実行して、Oracle Access Management Access Managerをスケーリングします。
第 15.3.4項「圧縮/解凍の実行」で説明されているようにpack
およびunpack
を実行します。
Oracle Access Management Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをAccess Managerサーバーとして構成する必要があります。これはOracle Access Managementコンソールから行います。次のようにします。
8.9項「ユーザー名およびパスワードの設定」のエントリで特定されたユーザーとして、http://IADADMIN.mycompany.com/oamconsole
にあるAccess Managementコンソールにログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「アクション」メニューから「作成」を選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。
OAMプロキシ・ポート: Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: 既存のAccess Managerサーバーと同じモードに設定します。
「コヒーレンス」タブをクリックします。
「ローカル・ポート」をそのホストで一意の値に設定します。
「適用」をクリックします。
第15.1項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを再起動します。
新しく作成したAccess Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDM
、Webgate_IDM_11g
、IAMSuiteAgent
など)にそのサーバーを追加します。
たとえば、Webgate_IDM
にAccess Managerサーバーを追加するには、http://IADADMIN.mycompany.com/oamconsole
にあるAccess Managementコンソールにアクセスします。
次の手順を実行します。
Access Manager管理ユーザーとしてログインします。
「システム構成」タブをクリックします。
「Access Managerの設定」→「SSOエージェント」→「OAMエージェント」を開きます。
フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。
エージェントWebgate_IDMをクリックします。
「アクション」メニューから「編集」を選択します。
「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」
をクリックします。
「サーバー」リストから、新しく作成した管理対象サーバーを選択します。
「接続の最大数」を10
に設定します。
「適用」をクリックします。
Webgate_IDM_11g、IAMSuiteAgentおよび使用している可能性のあるその他すべてのWebゲートで、手順5から10を繰り返します。
これで第15.1項「コンポーネントの起動と停止」の手順に従い、新しい管理対象サーバーを起動できるようになります。
第14.3.6項「Oracle HTTP Server構成ファイルへの新しいWebLogic管理対象サーバーの追加」で説明されているように、新しく追加された管理対象サーバーのホスト名およびポートをWebLogicClusterパラメータのリストに追加します。
このファイルを保存し、第15.1項「コンポーネントの起動と停止」の説明に従ってOracle HTTP Serverを再起動します。
Oracle SOA SuiteおよびOracle Identity Managerのコンポーネントを使用して構成された管理対象サーバーを実行するノードがすでにあります。このノードには、Middlewareホーム、SOA Oracleホーム、Oracle Identity Manager Oracleホーム、および既存の管理対象サーバーのドメイン・ディレクトリが含まれています。新しい管理対象サーバーWLS_SOAおよびWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にOracle Identity and Access ManagementまたはOracle SOA Suiteバイナリをインストールする必要はありません。
スケール・アップする場合、既存のノードに管理対象サーバーWLS_SOAおよびWLS_OIMを追加します。
いずれの場合にも、圧縮と解凍を実行する必要があります。
トポロジをスケール・アウトする際は、Oracle Identity ManagerおよびSOAを使用して構成された新しい管理対象サーバーを新しいノードに追加します。まず、新しいノードがWebLogic Server、Oracle Identity ManagerおよびSOAの既存のホーム・ディレクトリにアクセスできることを確認します。圧縮および解凍を実行して、新しいノードでドメイン構成をブートストラップする必要はありません。
トポロジをスケーリングするには、次の各項の手順を実行してください。
新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。
第15.2項「Identity ManagementコンソールのURLについて」に記載されているように、IAMGovernanceDomainのWebLogic管理サーバーにログインし、「サービス」→「メッセージング」→「JMSサーバー」の順に移動します。
「新規」をクリックします。
「名前」に、BPMJMSServer_auto_3
などの値を入力します。
「新規ストアの作成」をクリックします。
リストからFileStore
を選択します。
「次へ」をクリックします。
「名前」に、BPMJMSFileStore_auto_3
などの値を入力します。
次の値を入力します。
ターゲット: 現在作成している新しいサーバー。
ディレクトリ: IGD_ASERVER_HOME
/jms/BPMJMSFileStore_auto_3
「OK」をクリックします。
「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。
「次へ」をクリックします。
次の画面で、「ターゲット」を作成しているサーバーに設定します。
「終了」をクリックします。
作成する管理対象サーバーに応じて、次のJMSキューを作成します。
サーバー | JMSサーバー名 | ファイル・ストア名 | ディレクトリ | ターゲット |
---|---|---|---|---|
WLS_SOAn |
BPMJMSServer_auto_n |
BPMJMSFileStore_auto_n |
|
WLS_SOAn |
WLS_SOAn |
SOAJMSServer_auto_n |
SOAJMSFileStore_auto_n |
|
WLS_SOAn |
WLS_SOAn |
UMSJMSServer_auto_n |
UMSJMSFileStore_auto_n |
|
WLS_SOAn |
WLS_OIMn |
JRFWSAsyncJmsServer_auto_n |
JRFWSAsyncFileStore_auto_n |
|
WLS_OIMn |
WLS_OIMn |
OIMJMSServer_auto_n |
OIMJMSFileStore_auto_n |
|
wls_OIMn |
WLS_SOAn |
PS6SOAJMSServer_auto_n |
PS6SOAJMSFileStore_auto_n |
|
wls_SOAn |
次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。
第15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMGovernanceDomainのWebLogic管理コンソールにログインします。
「サービス」→「メッセージング」→「JMSモジュール」に移動します。
SOAJMSModuleなどのJMSモジュールをクリックします。
「サブデプロイメント」タブをクリックします。
表示されたサブ・デプロイメントをクリックします。
注意: このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。 |
新しく作成したJMSサーバーを割り当てます(SOAJMSServer_autonなど)。
「保存」をクリックします。
これを、次の表に記載されている各JMSモジュールに対して実行します。
JMSモジュール | JMSサーバー |
---|---|
BPMJMSModule |
BPMJMSServer_auto_n |
JRFWSAsyncJmsModule |
JRFWSAsyncJmServer_auto_n |
OIMJMSModule |
OIMJMSServer_auto_n |
SOAJMSModule |
SOAJMSServer_auto_n |
UMSJMSSystemResource |
UMSJMSServe_auto_n |
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
この項は、スケール・アウトを行う際のみ必要になります。
第14.3.4項「圧縮/解凍の実行」で説明されているようにpack
およびunpack
を実行します。
コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。
ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。
注意: デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。 |
tangosol.coherence.wka
n
システム・プロパティを使用してノードを指定します(n
は1から9の番号)。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhost
システム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(例:SOAHOST3VHN)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhost
パラメータを追加します。また、既存のエントリに新しいサーバーを追加する必要もあります。
ヒント: SOAコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。 |
注意: SOAHOST3VHNは、SOAHOST3でWLS_SOA3がリスニングする仮想IPにマップされる仮想ホスト名です。 |
管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。
Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの設定ページが表示されます。
「ロックして編集」をクリックします。
「サーバーの起動」タブをクリックします。
「引数」フィールドで、WLS_SOA1、WLS_SOA2およびWLS_SOA3について次のように入力します。
WLS_SOA1については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST1VHN
WLS_SOA2については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST2VHN
WLS_SOA3については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST3VHN
注意: 異なる |
注意: デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。たとえば、次のようにします。 WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力): -Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST1VHN -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.wka3.port=8089 WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力): -Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST2VHN -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.wka3.port=8089 WLS_SOA3(「引数」フィールドに、改行なしで1行で次のように入力): -Dtangosol.coherence.wka1=SOAHOST1VHN -Dtangosol.coherence.wka2=SOAHOST2VHN -Dtangosol.coherence.wka3=SOAHOST3VHN -Dtangosol.coherence.localhost=SOAHOST3VHN -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.wka3.port=8089 Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。 |
「保存」→「変更のアクティブ化」をクリックします。
注意: これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます。)Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。 |
注意: マルチキャスト・アドレスとユニキャスト・アドレスは、クラスタ通信においてWebLogic Serverクラスタで使用するアドレスとは異なります。2つのエンティティ(コンポジットの配置先となるグループとWebLogic Serverクラスタ)における通信プロトコルが異なっていても、1つのWebLogic Serverクラスタに属するメンバーにコンポジットが配置されることがSOAで保証されます。 |
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
WebLogic管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOA
n
管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OIMHOST
n
のノード・マネージャとOracle WebLogic管理サーバーとの間の通信用のサーバー証明書を構成した後で、これを再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
ホスト名検証を無効にする手順は次のとおりです。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn
」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。
「保存」をクリックします。
WLS_OIM
n
の各管理対象サーバーでも、手順6a - 6hを繰り返してホスト名検証を無効にします。手順6dでは、表の「名前」列で「WLS_OIMn」
を選択します。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
第15.1項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを再起動します。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新規作成した管理対象サーバーであるWLS_SOA
nが稼働していることを確認します。
新しく作成した管理対象サーバー(http://vip:port/soa-infra
)上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
新しく作成した管理対象サーバーを、サーバー移行ができるように構成します。第13.6項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。
注意: この新しいノードでは既存の共有記憶域のインストール内容が使用されているため、このノードではすでにノード・マネージャが使用されているとともに、ネットマスク、インタフェースおよび |
この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。
管理対象サーバーWLS_SOA
nを停止します。
このためには、次のコマンドを実行します。
kill -9 pid
このコマンドでは、その管理対象サーバーのプロセスID (PID)を指定します。ノードのPIDを確認するには、次のコマンドを使用します。
ps -ef | grep WLS_SOAn
ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAn
の2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
WLS_OIMnに対し、aからdの手順を繰り返します。
Oracle Adaptive Access Managerでドメインを拡張し、Oracle Identity ManagerをOracle Adaptive Access Managerと統合している場合、Oracle Adaptive Access Managerを新しいOracle Identity Managerサーバーを認識するように更新する必要があります。詳細は、第12.13.3項「Oracle Identity Manager用のOracle Adaptive Access Managerプロパティの設定」を参照してください。
アプリケーション層のコンポーネントのスケーリングでは、通常、新しいWebLogic管理対象サーバーを作成する必要があります。トポロジに新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。
Web層では、WEB_ORACLE_INSTANCE
/config/OHS/componentname/moduleconf
に、admin_vh.conf
、sso_vh.conf
およびidminternal_vh.conf
などの構成ファイルがいくつかあります。それぞれに、ロケーション・ブロックのエントリが数多く含まれます。ブロックが2つのサーバー・インスタンスを参照しているときに3つ目を追加する場合、そのブロックを新しいサーバーを使用して更新する必要があります。
たとえば、新しいAccess Managerサーバーを追加する場合は、その新しい管理対象サーバーが含まれるようにsso_vh.conf
を更新する必要があります。新しいサーバーを、ファイル内のWebLogicCluster
ディレクティブに追加します。次に例を示します。
<Location /oam> SetHandler weblogic-handler WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100 </Location> <Location /oamfed> SetHandler weblogic-handler WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100 </Location>
を次のように変更します。
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST1.mycompany.com:14101
</Location>
<Location /oamfed>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST3.mycompany.com:14100
</Location>
構成ファイルを更新したら、第15.1項「コンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。
Web層には、Oracle HTTP Serverのインスタンスが実行されている1つのノードがすでにあります。既存のOracle HTTP Serverバイナリを使用して、新しいOracle HTTP Serverインスタンスを作成できます。
Oracle HTTP Serverをスケーリングするには、次の各項の手順を実行します。
Web層をスケーリングする前に次の情報を収集します。
説明 | 変数 | ドキュメント内での値 | 実際の値 |
---|---|---|---|
ホスト名 |
WEBHOST1.mycompany.com |
||
OHSポート |
|
7777 |
|
インスタンス名 |
|
|
|
コンポーネント名 |
|
|
|
WebLogic管理ホスト、IAMAccessDomain |
|
IADADMINVHN.mycompany.com |
|
Access Management WLSサーバー・ポート |
|
7001 |
|
WebLogic管理ユーザー |
weblogic_idm |
||
WebLogic管理パスワード |
新しいノードで、既存のMiddlewareホームをマウントします。
既存のWeb層構成のORACLE_INSTANCE
/config/OHS/
component
/moduleconf
内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。
次の手順を実行して、Oracle Web層を構成します。
Oracle HTTP Serverが使用するポートを含むファイルを作成します。インストール・メディアのDisk1で、ファイルstage/Response/staticports.ini
を探します。これをohs_ports.ini
というファイルにコピーします。ohs_ports.ini
からOHS PORT
とOPMN Local Port
を除くすべてのエントリを削除します。OPMN Local Port
の値を6700
に変更します。スケール・アウトする場合、OHS PORT
にデフォルト値7777
を使用できます。スケール・アップする場合には、マシン上のインスタンスに対して一意の値を選択する必要があります。
注意: ファイルのポート名が |
Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。
cd WEB_ORACLE_HOME/bin
構成ウィザードを起動します。
./config.sh
構成ウィザードに次の情報を入力します。
「ようこそ」画面で、「次へ」をクリックします。
「コンポーネントの構成」画面で「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」が選択されていることを確認します。
Oracle Web Cacheが選択されていないことを確認してください。
「次へ」をクリックします。
「WebLogicドメインの指定」画面で、次を入力します。
ドメイン・ホスト名: IADADMINVHN.mycompany.com
ドメインのポート番号: 7001
、ここで7001
は第7.1項「Identity and Access Managementのデプロイメントのための情報収集」のIAD_WLS_PORT
です。
ユーザー名: Weblogic管理ユーザー(たとえば、weblogic
)
パスワード: Weblogic管理ユーザー・アカウントのパスワード
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の値を指定します。
WEBHOSTnに次の値を入力します。ここでnは、新しいホストの番号です(たとえば3
など)。
インスタンス・ホームの場所: WEB_ORACLE_INSTANCE
(例: /u02/local/oracle/config/instances/ohs1
)
インスタンス名: web
n
OHSコンポーネント名: web
n
「次へ」をクリックします。
「ポートの構成」画面で、手順1で作成したohs_ports.ini
ファイルを使用して、使用するポートを指定します。こうすることによって、自動ポート構成をバイパスできます。
構成ファイルを使用してポートを指定を選択します。
「ファイル名」フィールドでohs_ports.ini
を指定します。
「保存」→「次へ」をクリックします。
セキュリティ更新の指定画面で、次の値を指定します。
電子メール・アドレス: My Oracle Supportアカウント用の電子メール・アドレスです。
My Oracle Supportパスワード: My Oracle Supportアカウント用のパスワードです。
「セキュリティ・アップデートをMy Oracle Support経由で受け取ります。」を選択します。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。
「構成」をクリックします。
「構成」画面で、複数のConfiguration Assistantが起動されます。このプロセスは、時間がかかることがあります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
Oracle Enterprise Manager Fusion Middleware Controlで新しいOracle HTTP Serverを管理および監視できるようにするには、Oracle HTTP ServerをIAMAccessDomainに登録する必要があります。これを行うには、新しいサーバーが実行しているホスト上で次のコマンドを実行して、WebLogic ServerにOracle HTTP Serverを登録する必要があります。
cd WEB_ORACLE_INSTANCE/bin
./opmnctl registerinstance -adminHost IADADMINVHN.mycompany.com \
-adminPort WLS_ADMIN_PORT
-adminUsername weblogic
新しいOracle HTTP Serverインスタンスを、HTTPインスタンス間でリクエストを分散するためにロード・バランサで定義された既存のサーバー・プールに追加します。
次のスケーリング後の手順を実行します。
デプロイメント中に、デプロイされたトポロジの詳細が含まれるトポロジ・ストアが作成されます。環境にパッチ適用する際、ライフサイクル・ツールは、パッチ計画を作成して実行するためにストアを読み取ります。トポロジをスケール・アウトまたはスケール・アップする場合、デプロイメントへの新しい追加に対応するストアへ新しいエントリを追加する必要があります。
これを行うには、付録C「スケーリングのためのトポロジ・ツール・コマンド」の手順に従います。
デプロイメントでは、ドメインで定義された管理対象サーバーを起動および停止する一連のスクリプトが作成されます。ドメインに新しい管理対象サーバーを作成する際には、新しく作成された管理対象サーバーもこれらの起動および停止スクリプトで起動できるように、ドメイン構成を更新する必要があります。
ドメイン構成を更新するには、SHARED_CONFIG
/scripts
ディレクトリにあるserverInstancesCustom.txt
ファイルを編集します。
次の各項の説明に従って、ノード・マネージャ構成を更新します。
新しいマシンでノード・マネージャを起動する場合には、次のようなエントリを追加します。
newmachine.mycompany.com NM nodemanager_pathname nodemanager_port
たとえば、次のようにします。
OAMHOST3.mycompany.com NM /u01/oracle/config/nodemanager/oamhost3.mycompany.com 5556
WLS_OIM3という管理対象サーバーを起動する場合には、次のようなエントリを追加します。
newmachine.mycompany.com OIM ManagedServerName
たとえば、次のようにします。
OAMHOST3 OIM WLS_OIM3
ファイルを保存します。
新しいノード・マネージャを追加した場合、第14.5.3.2項「エンタープライズ・デプロイメント用のノード・マネージャの設定」に従って、そのノードに対してSSLを有効にする必要があります。
この項では、Oracleのベスト・プラクティスの推奨事項に従ってノード・マネージャを構成する方法を説明します。この項の内容は次のとおりです。
この項では、ノード・マネージャと管理サーバーとの通信で使用するホスト名検証証明書を設定する方法について説明します。
この章で(例として)追加する証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリスニングし、WebLogic管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリスニングする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順を次のように拡張する必要があります。
証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合)。
アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。
次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。かわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。次の例では、HOST.mycompany.comとVIP.mycompany.comの証明書を構成します。すなわち、HOSTで物理ホスト名(HOST)と仮想ホスト名(VIP)の両方を使用することを想定しています。また、HOST.mycompany.comはノード・マネージャが使用するアドレスであり、VIP.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることも想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。
WL_HOME
/server/bin/setWLSEnv.shスクリプトを実行して、環境を設定します。Bourneシェルで、次のコマンドを実行します。
cd WL_HOME/server/bin
. ./setWLSEnv.sh
CLASSPATH
環境変数が設定されていることを確認します。
echo $CLASSPATH
証明書用のユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOME
ディレクトリにkeystoresという名前のディレクトリを作成します。証明書はWebLogicドメイン間で共有できることに注意してください。
cd SHARED_CONFIG
mkdir keystores
注意: キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。各種目的(HTTPの起動用のSSL設定など)で使用する証明書には、中央ストアまたは共有ストアを使用することをお薦めします。 |
ディレクトリを今しがた作成したディレクトリに変更します。
cd keystores
utils.CerGen
ツールを使用して、トポロジ内の各物理ホストおよび仮想ホストに対する証明書を作成します。
構文(すべて1行に記述):
java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name
[export | domestic] [Host_Name]
次に例を示します。
java utils.CertGen Key_Passphrase NEWHOST.mycompany.com_cert NEWHOST.mycompany.com_key domestic NEWHOST.mycompany.com
また新しい仮想ホストに対しても証明書を作成します。
java utils.CertGen Key_Passphrase NEWVHN.mycompany.com_cert NEWVHN.mycompany.com_key domestic NEWVHN.mycompany.com
新しいホストを追加する際には、次の手順を実行します。
utils.ImportPrivateKey
ユーティリティを使用して、appIdentityKeyStore
というIDキーストアを新しく作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ASERVER_HOME
/keystores
)とします。
注意: アイデンティティ・ストアは、 |
先ほど作成した証明書のそれぞれに対する証明書および秘密鍵を、アイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
構文(すべて1行に記述):
java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]
例:
java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityNEWHOST Key_Passphrase SHARED_CONFIG/keystores/NEWHOST.mycompany.com_cert.pem SHARED_CONFIG/keystores/NEWHOST.mycompany.com_key.pem
次の手順に従って、各新しいホストに対する新しいキーストアを作成します。
新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME
/server/libディレクトリにある標準のJavaキーストアCA証明書を、証明書が存在するディレクトリにコピーします。たとえば、次のようにします。
cp WL_HOME/server/lib/cacerts SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks
標準のJavaキーストアのデフォルトのパスワードはchangeit
です。デフォルトのパスワードは常に変更することをお薦めします。それには、keytool
ユーティリティを使用します。構文は次のとおりです。
keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
たとえば、次のようにします。
keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreNEWHOST.jks -storepass changeit
このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME
/server/lib
ディレクトリにあります。keytool
ユーティリティを使用して、このCA証明書をappTrustKeyStore
にインポートする必要があります。構文は次のとおりです。
keytool -import -v -noprompt -trustcacerts -alias Alias_Name
-file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password
たとえば、次のようにします。
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreNEWHOST.jks -storepass Key_Passphrase
新しいノード・マネージャを追加したら、それを第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」に記載の新しいカスタム・キーストアを使用するように構成する必要があります。カスタム・キーストアを使用するようにノード・マネージャを構成するには、SHARED_CONFIG
/nodemanager/
hostname
ディレクトリにあるnodemanager.properties
ファイルの最後に次の行を追加します(ここでhostname
は、ノード・マネージャが実行するホストの名前です)。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity_Keystore CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password CustomIdentityAlias=Identity_Keystore_Alias CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate
たとえば、次のようにします。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=SHARED_CONFIG/keystores/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=Key_Passphrase CustomIdentityAlias=appIdentityNEWHOST CustomIdentityPrivateKeyPassPhrase=Key_Passphrase
第15.1項「コンポーネントの起動と停止」の説明に従ってノード・マネージャを起動すると、nodemanager.properties
ファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.properties
ファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。このファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。
次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。
第15.2項「Identity ManagementコンソールのURLについて」で指定されたアドレスで拡張されたドメイン用のOracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
IDキーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。選択したサーバーの設定ページが表示されます。
「構成」をクリックし、「キーストア」をクリックします。
「キーストア」フィールドで、秘密鍵とデジタル証明書の組合せおよび信頼できるCA証明書の格納と管理のために「カスタムIDとカスタム信頼」メソッドを選択します。
「ID」セクションで、IDキーストアの次の属性を定義します。
カスタムIDキーストア: IDキーストアへの完全修飾パス。
SHARED_CONFIG/keystores/appIdentityKeyStore.jks
カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。
カスタムIDキーストアのパスフレーズ: 第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password
)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。
「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。
カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。
SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks
カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。
カスタム信頼キーストアのパスフレーズ: 第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
「構成」をクリックし、「SSL」をクリックします。
「ロックして編集」をクリックします。
「秘密鍵の別名」フィールドに、管理対象サーバーでリスニングするホスト名に使用した別名を入力します(例:appIdentityNEWHOST
)。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第14.5.3.2.3項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
第15.1項「コンポーネントの起動と停止」の説明に従って、変更を適用したサーバーを再起動します。
前述の手順を実行した後、影響を受ける管理対象サーバーのホスト名検証をBea Hostname Verifier
に設定します。これを行うには、IAMAccessDomainおよびIAMGovernanceDomainの両方で次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。(コンソールのURLは第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されています。)
「チェンジ・センター」で「ロックして編集」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で管理対象サーバーを選択します。選択したサーバーの設定ページが表示されます。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
ホスト名検証をBea Hostname Verifier
に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
次のコマンドを実行してノード・マネージャを起動します。
cd SHARED_CONFIG/nodemanager/hostname
./startNodeManagerWrapper.sh
注意: ノード・マネージャの出力にある適切なストアと別名を、そのノード・マネージャで使用していることを確認します。ノード・マネージャの起動時に次の内容が出力されます。
<Loading identity key store:
FileName=ASERVER_HOME/keystores/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>
テスト構成の変更を該当のサーバーに適用して、ノード・マネージャからSSLエラーが報告されることなく、それが正常に完了していれば、ホスト名検証は機能しています。 |