| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 12c (12.2.1.1) E77231-01 |
|
 前 |
 次 |
Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。
Oracle WebLogic Serverの移行フレームワークでは、次の2つの種類の自動移行をサポートしています。
サーバー全体の移行。障害発生時に、管理対象サーバー・インスタンスが別の物理システムに移行されます。
サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。
このためには、サーバーはリスニング・アドレスとして浮動IPを使用する必要があり、必要なリソース(トランザクション・ログとJMS永続ストア)が候補マシンで利用できなければなりません。
詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
サービスの移行。特定のサービスが、クラスタ内の別の管理対象サーバーに移行されます。
サービスの移行を理解するには、固定サービスを理解することが重要です。
WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連サービスやJTAトランザクション・リカバリ・サービス、ユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにホストされます。WebLogic Serverの移行フレームワークは、これらのサービスに対して、フェイルオーバーではなく、サービスの移行による障害回復をサポートしています。
詳細は、『Oracle WebLogic Serverクラスタの管理』の「サービスの移行フレームワークの理解」を参照してください。
サーバーまたはサービスが別のシステムで再起動されるときは、必要なリソース(サービス・データ、ログなど)が元のシステムとフェイルオーバー・システムの両方で利用できなければなりません。利用できなければ、サービスは、同じ操作をフェイルオーバー・システムで正常に再開できません。
このような理由から、サーバー全体の移行とサービスの移行の両方で、クラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。
これが、エンタープライズ・デプロイメントで共有記憶域が重要となる、もう1つの理由です。共有記憶域を適切に構成すると、手動フェイルオーバー(管理サーバーのフェイルオーバー)または自動フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生したときに、元のマシンとフェイルオーバー・マシンの両方が、サービスを変更しなくても、確実に同一のファイル・ストアにアクセスできるようになります。
自動サービス移行の場合、固定サービスの再開が必要になったときは、フェイルオーバー前に固定サービスによって使用されていたJMSとJTAのログにアクセスできる必要があります。
サーバー全体の移行の場合、共有記憶域のほかに、仮想IPアドレス(VIP)の入手と割当ても必要になります。管理対象サーバーが別のマシンにフェイルオーバーされると、VIPは新しいマシンに自動的に再割り当てされます。
サービスの移行には、VIPは必要ありません。
表には、推奨されるベスト・プラクティスがリストされています。サーバー全体の移行または自動サーバー移行をサポートするコンポーネントで、これらを使用することはかまいません。
| コンポーネント | サーバー全体の移行(WSM) | 自動サービス移行(ASM) |
|---|---|---|
Oracle Web Services Manager(OWSM) |
いいえ |
いいえ |
Oracle SOA Suite |
いいえ |
はい |
Oracle Service Bus |
いいえ |
はい |
Oracle Business Process Management |
いいえ |
はい |
Enterprise Enterprise Scheduler |
いいえ |
いいえ |
Oracle Business Activity Monitoring |
いいえ |
はい |
Oracle B2B |
いいえ |
はい |
サーバー全体の移行と自動サービス移動の両方とも、リポジトリ作成ユーティリティ(RCU)によってOracle WebLogic Serverスキーマの一部として自動的に作成される表領域であるリース表のデータ・ソースが必要です。
エンタープライズ・デプロイメントでは、GridLinkデータ・ソースを作成する必要があります。
サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:
soaedg.example.com
ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。例:
db-scan.example.com:1521
「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。
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は、最初のエンタープライズ・マネージャ・ドメインを構成する際、スキーマの作成時に使用した接頭辞です。
Oracle Fusion Middlewareの前のバージョンでは、移行リース表のために手動でユーザーと表領域を作成する必要がありました。Fusion Middleware 12c (12.2.1)では、リース表はリポジトリ作成ユーティリティ(RCU)でWLSスキーマを作成する際に自動的に作成されます。
パスワード: RCUでWLSスキーマを作成した際に使用したパスワードを入力します。
パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。
サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。詳細は、次の各項を参照してください。
この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。このスクリプトは、移行中に、IPアドレスをマシンからマシンに転送するために使用します。通常スーパーユーザーのみが利用可能なifconfigの実行が可能でなければなりません。
wlsifconfig.shスクリプトの詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の自動移行の構成に関する項を参照してください。
wlsifconfig.shスクリプトを実行するためにシステムを準備する手順は、次の項を参照してください。
次の表に記載されているコマンドは、各ホスト・コンピュータのPATH環境変数に必ず含めてください。
| ファイル | ディレクトリの場所 |
|---|---|
|
MSERVER_HOME/bin/server_migration
|
|
WL_HOME/common/bin
|
|
MSERVER_HOME/nodemanager
|
パスワードによる制限を設けずに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
クラスタ内の移行を構成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
移行を構成するクラスタを、表の「名前」列でクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「移行基盤」として「データベース」を選択します。ドロップダウン・リストから、「自動移行に使用するデータ・ソース」として「リース」を選択します。
「移行可能サーバーの候補マシン」の「使用可能」フィールドでクラスタ内の管理対象サーバーを選択し、右矢印をクリックして「選択済み」に移動します。
「リース用のGridLinkデータ・ソースの作成」で作成したリース・データ・ソースを選択します。
「保存」をクリックします。
サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
アプリケーションとリソースのターゲット設定の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
この手順では、現在のホストを使用できなくなったときの、管理対象サーバーのフェイルオーバー先のホストを識別します。たとえば、HOST1上の管理対象サーバーにはHOST2を選択し、HOST2の管理対象サーバーにはHOST1を選択します。
ヒント:
「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。
「変更のアクティブ化」をクリックします。
管理サーバーと、サーバー移行が構成されたサーバーを再起動します。
この項の手順を実行して、サーバー全体の自動移行が適切に機能していることを確認します。
ノード1からテストする手順は次のとおりです。
管理対象サーバーのプロセスを停止します。
kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
ps -ef | grep WLS_SOA1
ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。
ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動し、サーバーが「実行中」状態になる前に、関連するプロセスを再度強制終了します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
注意:
必要な再起動回数は、次の構成ファイルのRestartMaxパラメータで設定されます。
MSERVER_HOME/servers/WLS_SOA1/data/nodemanager/startup.properties
デフォルト値はRestartMax=2です。
ノード2からテストする手順は次のとおりです。
ローカルのノード・マネージャのコンソールを確認します。ノード1で最後に管理対象サーバーの再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、管理対象サーバーの浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
同じIPアドレスを使用して製品URLにアクセスします。URLが正常な場合、移行は成功です。
管理コンソールからの検証
Oracle WebLogic Server管理コンソールを使用して、移行を検証することもできます。
注意:
サーバーの移行後、そのサーバーを元のマシンにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。
エンタープライズ・デプロイメント内の特定のサービスに自動サービス移行を構成するには、この項のトピックを参照してください。
注意:
このSOA Suite機能は、Oracle Integration Continuous Availabilityの一部です。Oracle SOA Suite for Middlewareオプションの詳細は、『Oracle Fusion Middlewareライセンス情報』を参照してください。
注意:
次の手順は、「リース用のGridLinkデータ・ソースの作成」に説明されているとおりに、リース・データ・ソースがすでに作成されていることを前提としています。
クラスタにリース・メカニズムとデータ・ソースを設定した後、サービス移行を構成する管理対象サーバーに対して、自動JTA移行を有効化できます。この項は、JTAサービスをエンタープライズ・デプロイメントの一部としてデプロイする場合にのみ該当します。
自動サービス移行を構成する際は、クラスタごとにサービス移行ポリシーを選択します。この項では、サービス移行ポリシーを選択する際のガイドラインと考慮事項を示します。
たとえば、シングルトンを実行するまたはパス・サービスを使用する製品またはコンポーネントは、必ず1回自動移行ポリシーのメリットを享受することができます。このポリシーにより、候補サーバーのリストにある管理ターゲット・サーバーが1つ以上動作している場合、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。これにより、複数の同種のサービスが起動時に1つのサーバー上で終了することがあります。
このポリシーを使用している場合は、クラスタの起動を監視して、各サーバー上でどのサーバーが実行されているかを特定する必要があります。その後、必要に応じて手動フェイルバックを実行し、システムをバランスのとれた構成にすることができます。
他のFusion Middlewareコンポーネントは、自動移行障害リカバリ・サービス・ポリシーに適しています。このポリシーでは、移行可能ターゲットのユーザー優先サーバー(UPS)が起動している場合にのみ、移行可能ターゲットでホストされているサービスが起動できます。
これらのガイドラインに基づき、Oracle SOA Suiteエンタープライズ・トポロジには次のポリシーが推奨されます。
SOA_Cluster: 自動移行障害リカバリ・サービス
OSB_Cluster: 必ず1回のサービスを自動移行
BAM_Cluster: 必ず1回のサービスを自動移行
詳細は、『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。
自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。
そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。
サービスを元のサーバーにフェイルバックするには、次の手順を実行します。
まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。
1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。
「制御」タブをクリックします。
チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。
「移行」をクリックします。
「新しいホスト・サーバー」ドロップダウンを使用して、元の管理対象サーバーを選択します。
「OK」をクリックします。
JMS関連サービスを移行するためのリクエストが発行され、構成編集ロックが解除されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。
特定の移行可能なターゲットを移行するには、「移行可能なターゲットの概要」ページで、次の手順を実行します。
移行する移行可能なターゲットを選択します。
「制御」タブをクリックします。
再度、移行する移行可能なターゲットを選択します。
「移行」をクリックします。
「新しいホスト・サーバー」ドロップダウンを使用して、移行可能なターゲットのための新しいサーバーを選択します。
「OK」をクリックします。
