Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.3.0) E61956-03 |
|
前 |
次 |
サーバー移行を構成すると、Oracle Identity and Access Managementで管理されているサーバーをあるホストから別のホストに移行できるようになります。これにより、いずれかのサーバーをホストしているノードに障害が発生しても、他のノードでサービスを継続できます。この章では、Identity and Access Managementのエンタープライズ・デプロイメントでサーバー移行を構成する方法について説明します。
この章のトピックは、次のとおりです:
WLS_OIM1、WLS_SOA1、WLS_BI1、WLS_OIM2、WLS_SOA2およびWLS_BI2の各管理対象サーバーのサーバー移行を構成します。管理対象サーバーWLS_OIM1、WLS_SOA1およびWLS_BI1は、障害発生時にOIMHOST2上で再起動されるように構成されます。管理対象サーバーWLS_OIM2、WLS_SOA2およびWLS_BI2は、障害発生時にOIMHOST1上で再起動されるように構成されます。WLS_OIM1、WLS_SOA1、WLS_BI1、WLS_OIM2、WLS_SOA2およびWLS_BI2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
次の項の手順を実行し、WLS_OIM1、WLS_SOA1、WLS_BI1、WLS_OIM2、WLS_SOA2およびWLS_BI2の管理対象サーバーのサーバー移行を構成します。
この項では、サーバー移行leasing表のためのユーザーと表領域を設定します。
注意: 同一ドメイン内の他のサーバーがサーバー移行用にすでに構成されている場合には、同じ表領域とデータ・ソースを使用できます。その場合、データベースleasing用のデータソースおよびマルチ・データソースを再作成する必要はありませんが、サーバー移行で構成されているクラスタを再度ターゲットに設定する必要があります。 |
leasing
という表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。
create tablespace leasing logging datafile size 32m autoextend on;
注意: これは、Oracle Managed Filesが構成されている場合の例です。Oracle Managed Filesを使用しない場合、表領域の作成方法に関する情報については、データベース管理者ガイドを参照してください。 |
leasing
という名前のユーザーを作成し、そのユーザーにleasing
表領域を割り当てます。
create user leasing identified by password;
grant create table to leasing;
grant create session to leasing;
alter user leasing default tablespace leasing;
alter user leasing quota unlimited on leasing;
leasing.ddl
スクリプトを使用してleasing
表を作成します。
次のいずれかのディレクトリにあるleasing.ddl
ファイルを、データベース・ノードにコピーします。
WL_HOME/server/db/oracle/817 WL_HOME/server/db/oracle/920
leasing
ユーザーとしてデータベースに接続します。
SQL*Plusでleasing.ddlスクリプトを実行します。
@Copy_Location/leasing.ddl;
この時点では、変更はまだコミットされていません。ツールの実行が完了したら、SQL*Plusプロンプトに次のように入力します。
commit;
この項では、Oracle WebLogic Server管理コンソールでリース表のGridLinkデータ・ソースを作成します。
GridLinkデータ・ソースを作成する手順は次のとおりです。
第31.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、IAMGovernanceDomainのOracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。
名前: データ・ソースの論理名を入力します。たとえば、leasing
です。
「JNDI」: JNDIの名前を入力します。たとえば、jdbc/leasing
と入力します。
データベース・ドライバ: データベース・ドライバには、Oracle Driver (Thin) for GridLink Connections Versions: 11以上を選択します。
「次」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。
「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
次の接続プロパティを入力します。
サービス名: データベースのサービス名(OIM_DB_SERVICENAME
)を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば、IGDEDG.example.com
です。
ホスト名とポート: 使用中のRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。
show parameter remote_listener; NAME TYPE VALUE -------------------------------------------------- remote_listener string IADDBSCAN.example.com:1521
注意: |
データベース・ユーザー名: leasing。
パスワード: たとえば、welcome1などを入力します。
パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。
「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。接続が成功したときに表示される通知の一例を示します。
Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=IADDBSCAN.example.com) (PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=IGDEDG.example.com))) succeeded.
ポート1521はDB_LSNR_PORT、oimedg.example.com
はOIM_DB_SERVICENAME
です。
「次」をクリックします。
「ONSクライアント構成」ページで、次の手順を実行します。
「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。
ここにも、データベースから報告されたRACデータベースのSCANアドレスおよびONSリモート・ポートを次のように入力し、「追加」をクリックします。
srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016
「次」をクリックします。
注意: Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。IADDBHOST1.example.com (port 6200) および IADDBHOST2.example.com (port 6200) |
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続が成功したときに表示される通知の一例を示します。
Connection test for IADDBSCAN.example.com:6200 succeeded.
「次」をクリックします。
「ターゲットの選択」ページで、ターゲットとしてoim_cluster、soa_clusterおよびbi_clusterを選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
この項では、ノード・マネージャのプロパティ・ファイルを編集します。この操作は、サーバーが実行されているノード上のノード・マネージャに対して行う必要があります(OIMHOST1およびOIMHOST2)。
nodemanager.properties
ファイルは次のディレクトリにあります。
SHARED_CONFIG_DIR/nodemanager/hostname.domain
次のプロパティを追加してサーバー移行が正常に動作するようにします。
Interface:
Interface=bond0
このプロパティは浮動IPのインタフェース名を指定します。これは、ほとんどのトポロジでbond0
になります。外部Oracle HTTPサーバーが使用されている場合、管理対象サーバーはbond1
でリスニングしています。この場合、bond1
インタフェースをここで使用する必要があります。
NetMask:
NetMask=255.255.254.0
このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。このネット・マスクは、インタフェースのネット・マスクと同じにする必要があります。
UseMACBroadcast:
UseMACBroadcast=true
このプロパティは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、言い換えれば、arping
コマンドで-b
フラグを使用するかどうかを指定します。
これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。
StateCheckInterval=500 bond0=*,NetMask=255.255.254.0 UseMACBroadcast=true
注意: サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。 |
nodemanager.properties
ファイルのStartScriptEnabled
プロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。
SHARED_CONFIG_DIR
/nodemanager/hostName.domain
ディレクトリにあるstartNodeManagerWrapper.sh
スクリプトを実行し、OIMHOST1とOIMHOST2でノード・マネージャを起動するか、第31.1.4.1項「ノード・マネージャの起動」で説明されている手順を使用します。
Linuxでは、wlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定する必要があります。この手順は、OIMHOST1とOIMHOST2の両方で実行します。
表21-1に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。
表21-1 PATH環境変数に必要なファイル
ファイル | 格納されているディレクトリ |
---|---|
|
|
|
|
|
|
パスワードによる制限を設けずにsudo
権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfig
バイナリおよび/sbin/arping
バイナリの実行権限を付与します。
セキュリティ上の理由から、sudo
を、wlsifconfig.sh
スクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
注意: この手順の実行に適するsudo 権限とシステム権限については、システム管理者に問い合せてください。 |
スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。sudo実行権限をoracle
およびifconfig
とarping
に付与するエントリを記述した/etc/sudoers
の例を次に示します。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfig
バイナリおよび/sbin/arping
バイナリの実行権限を付与します。
Defaults:oracle !requiretty oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
この項では、サーバー移行ターゲットを構成します。クラスタ移行を構成することにより、DataSourceForAutomaticMigration
プロパティがtrue
に設定されます。
クラスタ内の移行を構成する手順は次のとおりです。
第31.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、IAMGovernanceDomainのOracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ(oim_cluster)をクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行先として許可するマシン(OIMHOST1およびOIMHOST2)を選択して、右向き矢印をクリックします。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
「変更のアクティブ化」をクリックします。
SOAクラスタおよびBIクラスタについて手順2 - 13を繰り返します。
第31.1項「エンタープライズ・デプロイメント・コンポーネントの起動と停止」の説明に従って、WebLogic管理サーバー、ノード・マネージャ、およびサーバー移行を構成したサーバーを再起動します。
この項では、サーバーの移行が適切に機能していることをテストします。
サーバーの移行を検証するには、31.1.4.1項「ノード・マネージャの起動」の説明に従って、コンソール・ウィンドウでノード・マネージャを手動で起動することをお薦めします。
OIMHOST1からテストするには:
WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。
kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
ps -ef | grep WLS_OIM1
ノード・マネージャの端末を確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
OIMHOST2からテストするには:
ローカルのノード・マネージャのコンソールを確認します。OIMHOST1でのWLS_OIM1の再起動が前回試行されてから30秒間経過した後に、WLS_OIM1の浮動IPが表示されサーバーをこのノードで再起動することを示すメッセージがOIMHOST2のノード・マネージャにより表示されます。
仮想ホスト名を使用してOracle Identity Managerコンソールにアクセスします(例: http://OIMHOST1VHN.example.com:14000/identity
)。
前述の手順に従い、管理対象サーバーWLS_OIM2、WLS_SOA1およびWLS_SOA2に対してサーバーの移行をテストします。
表21-2は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。
表21-2 管理対象サーバーの移行
管理対象サーバー | 移行元 | 移行先 |
---|---|---|
WLS_OIM1 |
OIMHOST1 |
OIMHOST2 |
WLS_OIM2 |
OIMHOST2 |
OIMHOST1 |
WLS_SOA1 |
OIMHOST1 |
OIMHOST2 |
WLS_SOA2 |
OIMHOST2 |
OIMHOST1 |
WLS_BI1 |
OIMHOST1 |
OIMHOST2 |
WLS_BI2 |
OIMHOST2 |
OIMHOST1 |
WebLogic管理コンソールからの検証:
移行は管理コンソールで確認することもできます。
31.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMGovernanceDomainのWebLogic管理コンソールにログインします。
左側のペインでIAMGovernanceDomainをクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルバックするには、Oracle WebLogic管理コンソールから移行される管理対象サーバーを停止し、適切なノード・サーバーが、元々割り当てられていたマシン上の管理対象サーバーを起動することを確認します。 |
第31.5.3項「インストール時および構成時のバックアップの実行」の説明に従って、データベースとWebLogicドメインをバックアップします。