プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド
リリース12.2.1.2
E85892-01
目次へ移動
目次
前
前 		次
次

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

Oracle WebLogic Serverの移行フレームワークでは、サーバー全体の移行とサービスの移行をサポートしています。次の各項では、Oracle Fusion Middlewareエンタープライズ・トポロジでのこれらの機能の使用方法について説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の表に、移行機能の使用が役立つFMW製品およびコンポーネントと、このリリースでのベストプラクティス推奨をまとめます。移行可能と記載されたコンポーネントでは、サーバー全体の移行または自動サービス移行を使用できます。

この表は、推奨されるベスト・プラクティスを示していることに注意してください。サーバー全体の移行または自動サーバー移行をサポートするコンポーネントでこれらの機能を使用できなくなるわけではありません。

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

Oracle Web Services Manager(OWSM)

いいえ

いいえ

Oracle WebCenter Portal

いいえ

いいえ

Oracle WebCenter Portalのポートレットおよびページレット・プロデューサ

いいえ

いいえ

Oracle WebCenter Content

はい

はい(推奨)

Oracle WebCenter Inbound Refinery

いいえ

いいえ

Oracle SOA Suite

はい

はい(推奨)

Oracle Enterprise Scheduler

いいえ

いいえ

18.2 リース用のGridLinkデータ・ソースの作成

サーバー全体の移行および自動サービス移行では、リーシング表のデータ・ソースが必要です。リーシング表は、リポジトリ作成ユーティリティ(RCU)によって、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. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。
    「グローバル・トランザクションのサポート」チェックボックス
  6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
  7. 次の接続プロパティを入力します。

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

      wcpedg.example.com

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

      db-scan.example.com:1521

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

      GUID-4EE8C869-7B58-4D2E-8525-8AFB9F9A3879-default.jpgの説明が続きます
      図GUID-4EE8C869-7B58-4D2E-8525-8AFB9F9A3879-default.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データベースに接続します。マルチ・データ・ソースの構成の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

    • データベース・ユーザー名: 次のように入力します。

      FMW1221_WLS_RUNTIME

      この例では、FMW1221は、初期Enterprise Managerドメインを構成する準備をしたときに、スキーマの作成で使用した接頭辞です。

      前のバージョンのOracle Fusion Middlewareでは、移行リース表のユーザーおよび表領域を手動で作成する必要がありました。Fusion Middleware 12c (12.2.1)では、リポジトリ作成ユーティリティ(RCU)でWLSスキーマを作成すると、リーシング表が自動的に作成されます。

    • パスワード: RCUでWLSスキーマを作成したときに使用したパスワードを入力します。

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

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

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

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

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

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

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

    • 「ONSホストとポート」フィールドにSCANアドレスを入力して、「追加」、「追加」の順にクリックします。

      この値は、RACデータベースのONSホストおよび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.example.com (port 6200)

    および

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

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

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

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

  11. 「ターゲットの選択」ページで、サーバー全体の移行または自動サービス移行を構成するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。
  12. 「終了」をクリックします。
  13. 「変更のアクティブ化」をクリックします。

18.3 エンタープライズ・デプロイメントでのサーバー全体の移行の構成

サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。

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

この項では、サーバーが実行されている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
...

18.3.2 wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

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

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

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

18.3.2.1 wlsifconfig.shスクリプトのPATH環境変数の設定

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

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

wlsifconfig.sh

 
MSERVER_HOME/bin/server_migration

wlscontrol.sh

 
WL_HOME/common/bin

nodemanager.domains

 
MSERVER_HOME/nodemanager

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

パスワードによる制限を設けずにsudo権限をオペレーティング・システム・ユーザー(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

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

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

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

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

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

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

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

  6. 「移行基盤」に「データベース」を選択します。「自動移行に使用するデータ・ソース」としてドロップダウン・リストからリースを選択します。

  7. 「移行可能サーバーの候補マシン」の「使用可能」フィールドでクラスタ内の管理対象サーバーを選択し、右矢印をクリックして「選択済み」に移動します。

  8. 「リース用のGridLinkデータ・ソースの作成」で作成したリーシング・データ・ソースを選択します。

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

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

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

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

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

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

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

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

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

      この手順では、現在のホストを使用できない場合に管理対象サーバーのフェイルオーバー先となるホストを識別します。たとえば、HOST1の管理対象サーバーの場合はHOST2を選択し、HOST2の管理対象サーバーの場合はHOST1を選択します。

    ヒント:

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

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

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

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

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

ノード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アドレスを使用して、製品URLにアクセスします。URLが正常な場合は、移行が成功したことを示します。

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

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

  1. 管理コンソールにログインします。
  2. 左側のコンソールで、「ドメイン」をクリックします。
  3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

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

注意:

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

18.4 エンタープライズ・デプロイメントでの自動サービス移行の構成

エンタープライズ・デプロイメント内の特定のサービスに対して自動サービス移行を構成することが必要になる場合があります。

18.4.1 エンタープライズ・デプロイメント・クラスタでのリース・メカニズムとデータ・ソースの設定

自動サービス移行を構成する前に、自動サービス移行機能によって使用されるリーシング・メカニズムおよびデータ・ソースを確認する必要があります。

注意:

次の手順は、「リース用のGridLinkデータ・ソースの作成」の説明に従ってリーシング・データ・ソースを作成していることを前提としています。

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「ロックして編集」をクリックします。
  3. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
    「クラスタのサマリー」ページが表示されます。
  4. 表の「名前」列で、移行を構成するクラスタをクリックします。
  5. 「移行」タブをクリックします。
  6. 「移行基盤」ドロップダウン・メニューで「データベース」が選択されていることを確認します。
  7. 「自動移行に使用するデータ・ソース」ドロップダウン・メニューから、「リース用のGridLinkデータ・ソースの作成」で作成したリーシング・データ・ソースを選択します。
  8. 「保存」をクリックします。
  9. 変更をアクティブ化します。
  10. 管理対象サーバーを再起動します。

18.4.2 クラスタ内の管理対象サーバーの移行設定の変更

クラスタのリーシング・メカニズムとデータ・ソースを設定した後に、サービス移行に対して構成する管理対象サーバーのJTAの自動移行を有効にすることができます。このトピックは、エンタープライズ・デプロイメントの一部としてJTAサービスをデプロイしている場合にのみ適用されます。

クラスタ内の管理対象サーバーの移行設定を変更する手順は次のとおりです。
  1. 管理コンソールにログインしていない場合は、ログインして、「ロックして編集」をクリックします。
  2. 「ドメイン構造」ペインの「環境」ノードを開き、「サーバー」をクリックします。
    「サーバーのサマリー」ページが表示されます。
  3. 表の「名前」列で、変更するサーバーの名前をクリックします。
    選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
  4. 「移行」タブをクリックします。
  5. 「JTA移行ポリシー」ドロップダウン・メニューから「障害リカバリ」を選択します。
  6. ページの「JTA候補サーバー」セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、「移動」ボタンをクリックして、「選択済み」リスト・ボックスに移動します。
  7. このページの「JMSサービスの候補サーバー」セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、移動ボタンをクリックして、「選択済み」リスト・ボックスに移します。
  8. 「保存」をクリックします。
  9. すべての管理対象サーバーと管理サーバーを再起動します。

18.4.3 サービス移行ポリシーの選択について

自動サービス移行を構成する場合は、クラスタごとにサービス移行ポリシーを選択します。このトピックでは、サービス移行ポリシーを選択する際のガイドラインと考慮事項を説明します。

たとえば、シングルトンを実行するか、またはパス・サービスを使用する製品やコンポーネントには、必ず1回の自動移行ポリシーが役立ちます。このポリシーでは、候補サーバーのリストにある管理対象サーバーが1つ以上動作している場合、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。これにより、起動時に複数の同種サービスが1つのサーバーに存在する場合があります。

このポリシーを使用する場合は、クラスタの起動を監視して、各サーバーで実行されているサーバーを識別する必要があります。その後、必要に応じて手動のフェイルバックを実行して、バランスの取れた構成にシステムを配置できます。

その他のFusion Middlewareコンポーネントには、障害回復サービスの自動移行ポリシーの方が適しています。

これらのガイドラインに基づいて、Oracle WebCenter Contentエンタープライズ・デプロイメントでクラスタに対して「障害回復サービスの自動移行」を使用する必要があります。

詳細は、『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。

18.4.4 クラスタ内の各管理対象サーバーでのサービス移行ポリシーの設定

クラスタ内の各サーバーの移行設定を変更した後、WebLogic管理コンソールを使用して、サービスを識別し、クラスタ内の各管理対象サーバーの移行ポリシーを設定できます。
  1. 管理コンソールにログインしていない場合は、ログインして、「ロックして編集」をクリックします。
  2. 「ドメイン構造」ペインで、「環境」、「クラスタ」、「移行可能なターゲット」の順に展開します。
  3. クラスタで最初の管理対象サーバーの名前をクリックします。
  4. 「移行」タブをクリックします。
  5. 「サービス移行ポリシー」ドロップダウン・メニューからクラスタ用の適切なポリシーを選択します。
    詳細は、「サービス移行ポリシーの選択について」を参照してください。
  6. 「保存」をクリックします。
  7. クラスタ内の追加の管理対象サーバーごとに手順2から6を繰り返します。
  8. 変更をアクティブ化します。
  9. クラスタ内の管理対象サーバーを再起動します。

18.4.5 自動サービス移行の検証

クラスタおよび管理対象サーバーの自動サービス移行を構成した後に、次のように構成を検証します。
  1. 管理コンソールにログインしていない場合は、ログインします。
  2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に選択します。
  3. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。
  4. 「移行可能なターゲット」をクリックします。
  5. 「制御」タブをクリックします。
    コンソールに移行可能なターゲットおよびその現在のホスト・サーバーのリストが表示されます。
  6. 「移行可能なターゲット」表で、移行可能なターゲットのいずれか1つの行を選択します。
  7. 「現在のホスト・サーバー」列の値に注意してください。
  8. オペレーティング・システムのコマンドラインを使用して、最初の管理対象サーバーを停止します。

    次のコマンドを使用して、管理対象サーバー・プロセスを終了し、クラッシュ・シナリオをシミュレートします。

    kill -9 pid

    この例では、pidを、管理対象サーバーのプロセスID (PID)に置き換えます。次のUNIXコマンドを実行すると、PIDを確認できます。

    ps -ef | grep managed_server_name

    プロセスを強制終了した後に、管理対象サーバーが、最初にプロセスを強制終了した後に自動的に起動するよう構成されている場合があります。この場合、再度kill –9コマンドを使用して、2番目のプロセスを強制終了する必要があります。

  9. ノード・マネージャが動作しているターミナル・ウィンドウ(コンソール)を確認します。

    選択した管理対象サーバーでエラーが発生したことを示すメッセージが表示されます。次のようなメッセージが表示されます。

    <INFO> <domain_name> <server_name> 
<The server 'server_name' with process id 4668 is no longer alive; waiting for the process to die.>
<INFO> <domain_name> <server_name> 
<Server failed during startup. It may be retried according to the auto restart configuration.>
<INFO> <domain_name> <server_name>
<Server failed but will not be restarted because the maximum number of restart attempts has been exceeded.>
  10. Oracle WebLogic Server管理コンソールに戻り、移行可能なターゲットの表をリフレッシュし、移行可能なターゲットがクラスタ内の残りの実行中の管理対象サーバーに転送されていることを確認します。
    • 強制終了したプロセスの現在のホスト・サーバーが更新され、別のホストに移行されたことが表示されていることを確認します。
    • プロセスの「最後の移行のステータス」列の値が「成功」であることを確認します。
  11. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認し、JTAエラーまたはJMSエラーを探します。

    注意:

    JMSテストの場合は、宛先からメッセージ数を取得し、移行可能ターゲットにスタック・メッセージがないことを確認することをお薦めします。

    たとえば、共通分散宛先(UDD)の場合は次のとおりです。

    1. 管理コンソールのJMSサブデプロイメント・モジュールにアクセスします。

      「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順に選択します。

    2. 「JMSモジュール」をクリックします。

    3. 「リソースのサマリー」表で宛先をクリックし、「宛先」->「モニタリング」を選択して「メッセージ総数」と「保留メッセージ数」を取得します

    4. 「モニタリング」タブを選択し、「宛先」表の「メッセージ総数」と「保留メッセージ数」の値を確認します。

18.4.6 自動サービス移行後のサービスのフェイルバック

自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。

そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。

サービスを元のサーバーにフェイルバックするには、次の手順を実行します。

  1. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

  2. 「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。

  3. 1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。

    1. 「制御」タブをクリックします。

    2. チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。

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

    4. 「新しいホスト・サーバー」ドロップダウンを使用して、元の管理対象サーバーを選択します。

    5. 「OK」をクリックします。

      JMS関連サービスを移行するためのリクエストが発行され、構成編集ロックが解除されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。

  4. 特定の移行可能なターゲットを移行するには、「移行可能なターゲットの概要」ページで、次の手順を実行します。

    1. 移行する移行可能なターゲットを選択します。

    2. 「制御」タブをクリックします。

    3. 再度、移行する移行可能なターゲットを選択します。

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

    5. 「新しいホスト・サーバー」ドロップダウンを使用して、移行可能なターゲットのための新しいサーバーを選択します。

    6. 「OK」をクリックします。

前
前 		次
次
目次へ移動
目次