プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
12c (12.1.3)
E53006-03
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

19 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

この章では、Oracle WebLogic Serverのサーバー全体の移行およびサービス移行について述べ、さらにOracle Fusion Middlewareエンタープライズ・トポロジでそれらをどのように使用できるかについて説明します。

この章には次の項が含まれます:

19.1 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行について

Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

19.1.1 サーバー全体の移行とサービスの移行の違いの理解

Oracle WebLogic Serverの移行フレームワークでは、次の2つの種類の自動移行をサポートしています。

  • サーバー全体の移行。障害発生時に、管理対象サーバー・インスタンスが別の物理システムに移行されます。

    サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。

    このためには、サーバーはリスニング・アドレスとして浮動IPを使用する必要があり、必要なリソース(トランザクション・ログとJMS永続ストア)が候補マシンで利用できなければなりません。

    詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

  • サービスの移行。特定のサービスが、クラスタ内の別の管理対象サーバーに移行されます。

    サービスの移行を理解するには、固定サービスを理解することが重要です。

    WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスに均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連サービスやJTAトランザクション・リカバリ・サービス、ユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにホストされます。WebLogic Serverの移行フレームワークは、これらのサービスに対して、フェイルオーバーではなく、サービスの移行による障害回復をサポートしています。

    詳細は、『Oracle WebLogic Serverクラスタの管理』の「サービスの移行フレームワークの理解」を参照してください。

19.1.2 エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

サーバーまたはサービスが別のシステムで再起動されるときは、必要なリソース(サービス・データ、ログなど)が元のシステムとフェイルオーバー・システムの両方で利用できなければなりません。利用できなければ、サービスは、同じ操作をフェイルオーバー・システムで正常に再開できません。

このような理由から、サーバー全体の移行とサービスの移行の両方で、クラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。

これが、エンタープライズ・デプロイメントで共有記憶域が重要となる、もう1つの理由です。共有記憶域を適切に構成すると、手動フェイルオーバー(管理サーバーのフェイルオーバー)または自動フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生したときに、元のマシンとフェイルオーバー・マシンの両方が、サービスを変更しなくても、確実に同一のファイル・ストアにアクセスできるようになります。

自動サービス移行の場合、固定サービスの再開が必要になったときは、フェイルオーバー前に固定サービスによって使用されていたJMSとJTAのログにアクセスできる必要があります。

サーバー全体の移行の場合、共有記憶域のほかに、仮想IPアドレス(VIP)の入手と割当ても必要になります。管理対象サーバーが別のマシンにフェイルオーバーされると、VIPは新しいマシンに自動的に再割り当てされます。たとえば、第5章でSOAHOST1VHN1、SOAHOST2VHN1の仮想IPを取得するのはこのためです。

サービスの移行には、VIPは必要ありません。

19.1.3 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

Oracle SOA Suiteエンタープライズ・デプロイメント内の大部分の製品とコンポーネントでは、固定サービスを使用します。しかし、一部のコンポーネントでは、自動サービス移行によるこれらのサービスの透過的なフェイルオーバーはサポートしていません。場合によっては、JMSとJTAのリソースを使用しているソフトウェアは、固定サービスが別のサーバーに移行されるときに、固定サービスの起動をフェイルオーバーできません。

そのため、一部のコンポーネントは、フェイルオーバーとデータ損失ゼロを目的に、サーバー移行が構成されます。

表19-1は、サーバー全体の移行と自動サービス移行を構成する必要のある、Oracle SOA Suite製品とコンポーネントをまとめたものです。

表19-1 Oracle SOA Suiteエンタープライズ・デプロイメントのサーバー移行要件

コンポーネント サーバー全体の移行(WSM) 自動サービス移行(ASM)

Oracle Web Services Manager (OWSM)

NO

NO

Oracle SOA Suite

YES

NO

Oracle Service Bus

YES

NO

Oracle Business Process Management

YES

NO

Enterprise Enterprise Scheduler

NO

NO

Oracle Business Activity Monitoring

NO

YES

Oracle B2B

YES

NO

19.2 エンタープライズ・デプロイメント内の製品に対するサーバー全体の移行の構成

次の項では、エンタープライズ・デプロイメント内のサーバー全体の移行をサポートする製品に対して、サーバー全体の移行を構成する方法について説明します。

19.2.1 サーバー移行リース表のユーザーと表領域の設定

create tablespace leasingコマンドを使用して、サーバー移行リース・テーブルのユーザーおよび表領域を設定します。ドメイン名、クラスタ名およびサーバー名が競合しないかぎり、リース・テーブルは、サーバー移行が構成されている複数のクラスタで共有できます。リース・テーブルは、サーバーのタイム・スタンプとライブ・メッセージを保持するために使用されるため、使用されるデータベースの可用性が高いことと、データベース内のノードで同期されたクロックを使用することが重要になります。

次の手順を使用して、可用性の高いデータベースにユーザーとリース表領域を設定します。リース・テーブルは、サーバー全体の自動移行を有効にするために必要です。詳細は、『Oracle WebLogic Serverクラスタの管理』のリースに関する項を参照してください。

  1. Leasingという表領域を作成します。

    たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

    SQL> create tablespace Leasing
        logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
        size 32m autoextend on next 32m maxsize 2048m extent management local;

  2. Leasingというユーザー名を作成し、リース表領域に割り当てます。

    SQL> create user Leasing identified by password;

SQL> grant create table to Leasing;

SQL> grant create session to Leasing;

SQL> alter user Leasing default tablespace Leasing;

SQL> alter user Leasing quota unlimited on Leasing;

  3. leasing.ddlスクリプトを使用して、リース・テーブルを作成します。

    1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ホストにコピーします。

      WL_HOME/server/db/oracle/db_version/

      この例では、db_versionを、Oracleデータベースのバージョン番号に置き換えます。

    2. Leasingユーザーとしてデータベースに接続します。


      注意:

      リース・ユーザーとして接続する必要があります。sysdbaや他のユーザー・アカウントとして接続すると、スキーマが正常に作成されません。

    3. leasing.ddlをSQL*Plusで実行します。

      SQL> @script_location/leasing.ddl;

19.2.2 管理コンソールによるリース用のGridlinkデータ・ソースの作成

リース・テーブルを作成したら、Oracle WebLogic Server管理コンソールでリース・テーブルのデータ・ソースを作成する必要があります。

エンタープライズ・デプロイメントでは、GridLinkのデータ・ソースを使用する必要があります。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

  3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

  4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

    • 「名前」フィールドにデータ・ソースの論理名を入力します。たとえば、Leasingと入力します。

    • JNDIの名前を入力します。たとえば、jdbc/leasingです。

    • 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

    • 「次へ」をクリックします。

  5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。

    grid_global_trans_check_box.gifについては周囲のテキストで説明しています。

  6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

  7. 次の接続プロパティを入力します。

    • サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:

      soaedg.example.com

    • ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。例:

      db-scan.example.com:1521

      「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

      admincons_gridlink_hostport.jpgの説明が続きます
      図admincons_gridlink_hostport.jpgの説明

      SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

      SQL>show parameter remote_listener;

NAME                 TYPE        VALUE
 
--------------------------------------------------
 
remote_listener     string      db-scan.example.com

      注意:

      Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例: 
      dbhost1-vip.mycompany.com (port 1521)

      および

      dbhost2-vip.mycompany.com (1521)

      Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

    • データベース・ユーザー名: Leasingと入力します。

    • パスワード: たとえば、welcome1などを入力します。

    • パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

  8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.mycompany.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.

    「次へ」をクリックします。

  9. 「ONSクライアント構成」ページで、次の手順を実行します。

    • 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

    • ここにも、次のように、SCANアドレス: RACデータベースのONSリモート・ポート、データベースから報告されたONSリモート・ポートを入力し、「追加」をクリックします。

      [orcl@db-scan1 ~]$ srvctl config nodeapps -s
 
ONS exists: Local port 6100, remote port 6200, EM port 2016

    • 「次へ」をクリックします。


    注意:

    Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。 
    custdbhost1.mycompany.com (port 6200)

    および

    custdbhost2.mycompany.com (6200)

  10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for db-scan.mycompany.com:6200 succeeded.

    「次へ」をクリックします。

  11. 「ターゲットの選択」ページで、サーバー移行が構成されるクラスタをターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

    たとえば、Oracle SOA Suiteクラスタに対してサーバー全体の移行を構成している場合は、SOA_Clusterを選択します。サーバー全体の移行をサポートするコンポーネントについては、第19.1.3項「サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解」を参照してください。

  12. 「終了」をクリックします。

  13. 「変更のアクティブ化」をクリックします。

19.2.3 ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

この項では、サーバーが実行されている2つのノード上のノード・マネージャのプロパティ・ファイルを編集します。

  1. 次のファイルを探してテキスト・エディタで開きます。

    MSERVER_HOME/nodemanager/nodmeanager.properties

  2. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。

    これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

  3. 次のプロパティをnodemanager.propertiesファイルに追加して、サーバー移行が正常に動作するようにします。

    • Interface

      Interface=eth0

      このプロパティは浮動IP (eth0など)のインタフェース名を指定します。


      注意:

      サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。

      ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

    • NetMask

      NetMask=255.255.255.0

      このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

    • UseMACBroadcast

      UseMACBroadcast=true

      このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

  4. ノード・マネージャを再起動します。

  5. これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。適用されていないと、移行中に問題が発生する可能性があります。このコマンドの出力結果は、次のようになります。

    ...
SecureListener=true
LogCount=1
eth0=*,NetMask=255.255.255.0
...

19.2.4 wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定

この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。このスクリプトは、移行中に、IPアドレスをマシンからマシンに転送するために使用します。このスクリプトは、通常はスーパーユーザーのみが利用できるifconfigを実行できる必要があります。

wlisconfig.shスクリプトの詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の自動移行の構成に関する項を参照してください。

wlsifconfig.shスクリプトを実行するためにシステムを準備する手順は、次の項を参照してください。

19.2.4.1 wlsisconfig.shスクリプトのPATH環境変数の設定

表19-2に記載されているコマンドは、各ホスト・コンピュータのPATH環境変数に必ず含めてください。

表19-2 PATH環境変数に必要なファイル

ファイル ディレクトリの場所

wlsifconfig.sh

 
MSERVER_HOME/bin/server_migration

wlscontrol.sh

 
WL_HOME/common/bin

nodemanager.domains

 
MSERVER_HOME/nodemanager

19.2.4.2 wlsisconfig.shスクリプトに対する権限の付与

パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。


注意:

セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。

この必須の構成タスクを実行するためのsudo権限とsystem権限については、必要に応じてシステム管理者に問い合せてください。

/etc/sudoers内の次のエントリ例では、ifconfigとarpingを実行するために、oracleに対してsudo実行権限を付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

19.2.5 サーバー移行ターゲットの構成

クラスタ内の移行を構成する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

  3. 移行を構成するクラスタを、表の「名前」列でクリックします。

  4. 「移行」タブをクリックします。

  5. 「ロックして編集」をクリックします。

  6. 「移行可能サーバーの候補マシン」の「使用可能」フィールドで「SOAHOST1」と「SOAHOST2」を選択し、右矢印をクリックして「選択済み」に移動します。

  7. 自動移行に使用するデータ・ソースを選択します。この場合は、Leasingデータ・ソースを選択します。

  8. 「保存」をクリックします。

  9. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

    1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

    2. 移行を構成するサーバーを選択します。

    3. 「移行」タブをクリックします。

    4. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。

      これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

      アプリケーションとリソースのターゲット設定の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

    5. 「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。WLS_SOA1には「SOAHOST2」を選択します。WLS_SOA2には「SOAHOST1」を選択します。


    ヒント:

    「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

  10. 「変更のアクティブ化」をクリックします。

  11. 管理サーバーと、サーバー移行が構成されたサーバーを再起動します。

19.2.6 サーバー全体の移行のテスト

この項の手順を実行して、サーバー全体の自動移行が適切に機能していることを確認します。

ノード1からテストする手順は次のとおりです。

  1. 管理対象サーバーのプロセスを停止します。

    kill -9 pid

    pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

    ps -ef | grep WLS_SOA1

  2. ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。

  3. ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

  4. ノード・マネージャがサーバーを再起動し、サーバーが「実行中」状態になる前に、関連するプロセスを再度強制終了します。

    サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。


    注意:

    必要な再起動回数は、次の構成ファイルのRestartMaxパラメータで設定されます。 
    MSERVER_HOME/servers/WLS_SOA1/data/nodemanager/startup.properties

    デフォルト値はRestartMax=2です。

ノード2からテストする手順は次のとおりです。

  1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後に管理対象サーバーの再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、管理対象サーバーの浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

  2. 同じIPでsoa-infraコンソールにアクセスします。

管理コンソールからの検証

Oracle WebLogic Server管理コンソールを使用して、移行を検証することもできます。

  1. 管理コンソールにログインします。

  2. 左側のコンソールで、「ドメイン」をクリックします。

  3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

    「移行の状態」の表に、移行の状態に関する情報が表示されます。


注意:

サーバーの移行後、そのサーバーを元のマシンにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

19.3 エンタープライズ・デプロイメント内の製品に対する自動サービス移行の構成

一般的なOracle SOA Suiteエンタープライズ・デプロイメントでは、Oracle BAMソフトウェアのみに自動サービス移行を構成する必要があります。

詳細は、第16.8項「Oracle BAMサーバーの自動サービス移行の構成」を参照してください。

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