|
|
以下の節では、WebLogic Server でサポートされているさまざまな移行メカニズムについて説明します。
これらの節では、サーバで障害が発生した場合にサーバ全体を移行する方法について重点的に説明します。サーバ全体の移行では、移行可能なサーバ インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。WebLogic Server では、サービスレベルの移行や、アプリケーション レベルでのレプリケーションおよびフェイルオーバもサポートされています。詳細については、「サービスの移行」および「クラスタのフェイルオーバとレプリケーション」を参照してください。
| 注意 : | サーバ全体の移行はすべてのプラットフォームでサポートされているわけではありません。『WebLogic Platform 10g Release 3 (10.3) でサポート対象のコンフィグレーション』の「サーバの移行のサポート」を参照してください。 |
WebLogic Server クラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバ インスタンスに均一にデプロイされます。これにより、サーバ間の透過的なフェイルオーバが可能になります。対照的に、JMS や JTA トランザクション回復システムなどの「固定サービス」はクラスタ内の個々のサーバ インスタンスを対象にします。こうしたサービスのために、WebLogic Server では、フェイルオーバではなく移行を使用する障害からの回復がサポートされています。
WebLogic Server での「移行」とは、クラスタ化された WebLogic Server インスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスです。「サーバ全体」の移行の場合は、障害が発生すると、サーバ インスタンスが物理的に別のマシンに移行されます。「サービスレベル」の移行の場合は、サービスをクラスタ内の別のサーバ インスタンスに移動します。「サービスの移行」を参照してください。
WebLogic Server には、JMS や JTA トランザクション システムの可用性を高めるための機能 (「移行可能なサーバ」) が用意されています。移行可能なサーバは、サービスレベルではなく、サーバレベルで自動または手動で移行できます。
移行可能なサーバが何らかの理由 (ハング、ネットワーク接続の消失、ホスト マシンの障害など) で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバは、可能であれば同じマシン上で自動的に再起動されます。障害が発生した同じマシン上で再起動できないときは、別のマシンに移行されます。また、管理者は手動でサーバ インスタンスの移行を開始することもできます。
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタワイド エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に 1 つしか存在しません。また、サーバやクラスタの障害時には、リースをフェイルオーバさせることができます。これにより、シングル ポイント障害を回避できます。
リースは、以下の WebLogic サーバ機能で使用します。
リースを使用することで、クラスタ マスターが常に実行されており、しかもクラスタ内のいずれか 1 つのサーバでのみ実行されていることが保証されます。クラスタ マスターの詳細については、「サーバ全体の移行におけるクラスタ マスターの役割」を参照してください。
| 注意 : | ジョブ スケジューラにはコンセンサス リース (非データベース リース) を使用できますが、その場合はフェイルオーバやレプリケーションの情報を保持するための外部データベースが必要になります。 |
| 注意 : | 基本的なコンフィグレーションだけでなく、リース機能のほとんどは WebLogic Server 内部で処理されます。 |
WebLogic Server では、2 種類のリース機能を実装できます。どちらを使用するかは、そのときどきの要件や環境によって決まります。
1 つの WebLogic Server インストールでは、1 種類のリースしか使用できません。1 つの環境において、リースを使用する複数の機能を実装することは可能ですが、各機能には同じ種類のリースを使用する必要があります。
あるリースの種類をもう一方の種類に切り替える場合は、管理サーバだけでなく、クラスタ全体を再起動する必要があります。リースの種類を動的に変更することはできません。
現在の WebLogic Server 環境にはどの種類のリースが適しているかを判断する場合は、以下の考慮事項を参考にしてください。
このタイプのリースは、Oracle RAC のような高可用性データベースを必要としないリース基盤オプション (コンセンサス) を提供します。高可用性データベースを使用する必要がない点は、サーバ全体の自動移行における直接的なメリットです。つまり、サーバの自動移行を有効にするために必要なコンフィグレーションが少なくなります。
コンセンサス リース基盤では、ノード マネージャをコンフィグレーションして実行する必要があります。ノード マネージャは、サーバ全体の自動移行においても IP の移行および別のマシンでのサーバの再起動のため必要になります。つまり、コンセンサス リースの場合は、追加の要件がないうえに、負荷の高い要件を排除できます。
JMS ストアの回復などの機能を使用するために Oracle RAC のような高可用性データベースをすでに所有している場合は、データベース リース基盤も依然として有用です。追加のコンフィグレーションを最小限に抑えつつ、高可用性データベース インスタンスでリースをサポートできます。データベース リースは、システムでノード マネージャを実行しない場合には特に有用です。
このタイプのリースでは、リース情報を高可用性データベースのテーブル内に保持します。リース情報を常に利用できるようにするため、可用性の高いデータベースが必要になります。リース情報にアクセスするため、クラスタの各メンバーからデータベースに接続できなければなりません。
このリース方法は、クラスタ化された環境にすでに高可用性データベースが存在する場合に便利です。この方法を使用すると、ノード マネージャを使用して環境内のサーバを管理していなくてもリース機能を利用できます。
以下では、リース用のデータベースをコンフィグレーションするために必要な手順の概略を示します。
データベースは信頼性のあるものでなければなりません。サーバ インスタンスの信頼性は、このデータベースの信頼性で決まります。実験的な目的で使用する場合は、通常のデータベースで十分です。プロダクション環境で使用する場合は、高可用性データベースしかお勧めできません。データベースが停止すると、すべての移行可能なサーバが停止します。
データベース内にリース テーブルを作成します。このテーブルは、サーバの移行を可能にするためのマシンとサーバの関連付けの格納に使用されます。このテーブルのスキーマは、次の場所にあります。
WL_HOME/server/db/dbname/leasing.ddl
| 注意 : | リース テーブルは高可用性データベースに格納する必要があります。移行可能なサーバの信頼性は、リース テーブルの格納に使用されるデータベースの信頼性で決まります。 |
| 注意 : | サーバの移行では、XA データ ソースはサポートされていません。 |
JDBC データ ソースの作成の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。
コンセンサス (非データベース) リースでは、リース情報がメモリ内に保持されます。そのため、リースを必要とする機能を使用するだけのために、高可用性データベースを用意する必要はありません。
クラスタのいずれか 1 つのメンバーをクラスタ リーダーとし、このメンバーにリース情報を保持する役割を付与します。クラスタ リーダーは、起動後の経過時間の長さに基づいて選択されます。クラスタ内の管理対象サーバのうち、起動後の経過時間が最も長いものがクラスタ リーダーとなります。その他のクラスタ メンバーは、クラスタ リーダーと通信してリース情報を識別します。フェイルオーバを可能にするため、リース テーブルはクラスタの他のノードにレプリケートされます。
| 注意 : | このリース方法では、ノード マネージャを使用してクラスタ内のサーバを管理する必要があります。ノード マネージャは、クラスタ内の管理対象サーバをホストするすべてのマシンで実行する必要があります。詳細については、『ノード マネージャ管理者ガイド』の「ノード マネージャを使用したサーバの制御」を参照してください。. |
この節では、サーバ全体の自動移行をコンフィグレーションする手順の概略を示し、WebLogic Server 環境内でサーバ全体の移行機能をどのように使用するかについて説明します。
サーバ全体の自動移行をコンフィグレーションする前に、以下の要件について確認します。
| 警告 : | サーバ全体の自動移行は Solaris ゾーン機能を使用する Solaris 10 システムではサポートされていません。詳細については、『WebLogic Platform でサポート対象のコンフィグレーション』の「Sun Solaris 10 のマルチゾーン操作におけるサポート」を参照してください。 |
マルチキャストの詳細については、「下位互換性の維持を目的とした IP マルチキャストの使用」を参照してください。ユニキャストの詳細については、「ユニキャストを使用した 1 対多通信」を参照してください。
ifconfig に対して同じ機能がサポートされている必要がある。wlscontrol.sh のローカル バージョンをコンフィグレーションします。
wlscontrol.sh の詳細については、『ノード マネージャ管理者ガイド』の「ノード マネージャを使用したサーバの制御」を参照してください。
domain_dir/bin の内容が各マシンにコピーされていることを確認する必要があります。 nmEnroll() WLST コマンドで各マシンにコピーされている必要がある。詳細については、『ノード マネージャ管理者ガイド』の「ノード マネージャを使用したサーバの制御」を参照してください。.
サーバの移行をコンフィグレーションする前に、お使いの環境が「サーバ全体の自動移行の準備」で説明されている要件を満たしていることを確認してください。
クラスタ内の管理対象サーバに対してサーバの移行をコンフィグレーションするには、以下のタスクを行います。
移行可能なサーバには、それぞれ浮動 IP アドレスを割り当てる必要があります。この IP アドレスは、物理的なマシンが変わってもサーバを追跡します。浮動 IP アドレスが割り当てられるすべてのサーバで、AutoMigrationEnabled を true に設定する必要もあります。
| 注意 : | 移行可能な IP アドレスは、移行可能なサーバが起動されるまではどの候補マシンのインタフェースでも提示されないようにします。 |
Java バージョンのノード マネージャは Windows または UNIX でのサーバ移行に使用できます。SSH バージョンのノード マネージャは UNIX でのサーバ移行にのみ使用できます。
Java のノード マネージャを使用する場合は、WL_HOME/common/nodemanager/ の nodemanager.properties を編集して、ご使用の環境の Interface および NetMask 値を追加する必要があります。nodemanager.properties の詳細については、『ノード マネージャ管理者ガイド』の「Java ノード マネージャのコンフィグレーション」を参照してください。
SSH バージョンのノード マネージャを使用する場合は、wlscontrol.sh を編集して、Interface 変数にネットワーク インタフェースの名前を設定します。
サーバの移行でのノード マネージャの使用に関する全般的な情報については、「サーバ全体の移行におけるノード マネージャの役割」を参照してください。ノード マネージャの一般的な情報については、『ノード マネージャ管理者ガイド』の「ノード マネージャの一般的なコンフィグレーション」を参照してください。
leasing.ddl スクリプトを再実行する必要があります。リセットによって、適切なテーブルが削除されて再作成されます。
各クラスタのコンフィグレーションで、DataSourceForAutomaticMigration をこのデータ ソースに設定してください。
| 注意 : | サーバの移行では、XA データ ソースはサポートされていません。 |
JDBC データ ソースの作成の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。
wlsifconfig.sh スクリプト (UNIX) または wlsifconfig.cmd スクリプト (Windows) にスーパーユーザ特権を付与します。
このスクリプトは、移行時にマシン間での IP アドレスの転送に使用され、通常はスーパーユーザだけが使用できる ifconfig を実行できなければなりません。sudo を使用して起動されるように、このスクリプトを編集できます。
Java ノード マネージャは wlsifconfig.cmd スクリプトを使用します。このスクリプトでは netsh ユーティリティが使用されます。
wlsifconfig スクリプトは WL_HOME/common/bin ディレクトリにあります。
移行可能なサーバをホストするマシンは相互に信頼していなければなりません。移行が行われるためには、ユーザ名とパスワードを明示的に入力する必要なしに、マシン B から「ssh/rsh machine_A」を使用して (同様にマシン A から「ssh/rsh machine_B」を使用して) シェル プロンプトにアクセスできる必要があります。また、各マシンは SSH を使用して同じ方法で自身に接続できなければなりません。
| 注意 : | シェルが対話型である場合は、ログイン スクリプト (.cshrc、.profile、.login など) がシェル プロファイルからのメッセージのみをエコーすることを確認してください。WebLogic Server は、ssh コマンドを使用してログインし、server.state ファイルの内容をエコーします。この出力の最初の行だけがサーバの状態の判別に使用されます。 |
サーバの移行プロセスでは、サービスは移行されますが、障害の発生時に進行中だった作業に関連付けられたステート情報は移行されません。
高可用性を確保するには、こうした情報を移行後にサーバ インスタンスやそれがホストするサービスで使用できるようにすることが重要です。そうしないと、障害の発生時に進行中だった作業に関するデータが失われてしまうおそれがあります。移行可能なサーバによって保持されるステート情報 (トランザクション ログに格納されるデータなど) は、移行可能なサーバで障害が発生した場合にその移行先となる可能性のあるすべてのマシンからアクセスできる共有ストレージ システムに格納する必要があります。高い信頼性を実現するために、ストレージ エリア ネットワーク (SAN) などの、高可用性の備わっている共有ストレージ ソリューションを使用してください。
さらに、データベースを使用してリース情報を格納する場合は、移行可能なサーバの状態とそれらが使用可能かどうかの追跡に使用されるリース テーブル (以下の節を参照) も高可用性データベースに格納する必要があります。詳細については、「リース」を参照してください。
以下の節では、移行可能なサーバを含むクラスタにおける主要なプロセスについて説明します。
図 7-1 に、移行可能なサーバを含むクラスタの起動時に発生するプロセスと通信を示します。
例のクラスタには 2 つの管理対象サーバが含まれており、それらは両方とも移行可能です。管理サーバと 2 つの管理対象サーバは、それぞれ別々のマシンで実行されています。4 つ目のマシンは、いずれかの移行可能なサーバで障害が発生した場合にバックアップとして使用できます。バックアップ マシンと移行可能なサーバが実行されている各マシンでは、ノード マネージャが実行されています。
以下は、図 7-1 に示されている、クラスタの起動時に発生する主要な手順です。
図 7-2 に、管理対象サーバ 2 をホストしているマシンで障害が発生した後の自動移行のプロセスを示します。
| 注意 : | サーバのハングが原因で管理対象サーバ 2 のリースが期限切れになっていて、マシン C にはアクセスできる場合、クラスタ マスターはノード マネージャを使用してマシン C 上の管理対象サーバ 2 を再起動します。 |
移行する管理対象サーバのクライアントでは、移行中にサービスの短い中断が発生するおそれがあります。その場合、再接続が必要になることもあります。Solaris および Linux オペレーティング システムでは、ifconfig コマンドを使用して再接続を行うことができます。移行されたサーバのクライアントは、サーバの移行先の特定のマシンを認識する必要はありません。
移行されたサーバ インスタンスを移行前にホストしていたマシンが再び使用可能になった場合、移行プロセスの逆戻し (サーバ インスタンスを元のホスト マシンに移行して戻すこと) を行うことができます。これを、フェイルバックと呼びます。WebLogic Server ではフェイルバックのプロセスは自動化されていません。管理者は、サーバ インスタンスを元のホストに手動で戻すことでフェイルバックを実行できます。
サーバを元のホストに復元するおおまかな手順は次のとおりです。
細かな手順は、サーバおよびネットワーク環境によって異なります。
図 7-3 に、管理者が移行可能なサーバを手動で移行するときに発生するプロセスと通信を示します。
以下に、移行可能なサーバを含むクラスタでの管理サーバの動作を示します。
さらに管理サーバには、管理者によって発行されたコンフィグレーションの更新の保持、ドメインの実行時情報の表示などの、ドメイン内の移行可能なサーバも含めた通常のドメイン管理機能があります。
移行可能なサーバとは、移行可能としてコンフィグレーションされている、クラスタ化された管理対象サーバのことです。以下に、移行可能なサーバの主要な動作を示します。
リースの詳細については、「リース」を参照してください。
デフォルトでは、移行可能なサーバは 30,000 ミリ秒ごとにリースを更新します。このデフォルト値は、以下の 2 つのコンフィグレーション可能な ServerMBean プロパティ値を掛け合わせた値です。
System.exit を使用して、自身をできるだけ迅速に終了する。この場合、リース テーブルにはそのサーバ インスタンスの行が引き続き格納されます。この動作と自動移行の関連については、「サーバ全体の移行におけるクラスタ マスターの役割」を参照してください。
ノード マネージャの使用は、サーバの移行に不可欠です。ホストとなる (またはホストとなる予定の) 各マシン上で実行されなければなりません。
ノード マネージャは、以下のようにサーバの移行を支援します。
Administration Console から管理対象サーバの起動を開始すると、管理サーバがノード マネージャを使用してそのサーバ インスタンスを起動します。ノード マネージャを呼び出して、スタンドアロンのノード マネージャ クライアントを使用してサーバ インスタンスを起動することもできます。ただし、起動する管理対象サーバが自身のコンフィグレーションを取得するために管理サーバが使用可能になっていなければなりません。
| 注意 : | 最初にノード マネージャによって起動されていないサーバ インスタンスの移行は失敗します。 |
ノード マネージャは、サーバの起動、再起動、停止、IP アドレスの移行、およびディスクのマウントとアンマウントを行う、WebLogic Server に付属のカスタマイズ可能なシェル スクリプトを実行することでサーバの移行プロセスの手順を実行します。これらのスクリプトは、Solaris および Linux で使用できます。
移行可能なサーバを含むクラスタでは、1 つのサーバ インスタンスがクラスタ マスターとして機能します。クラスタ マスターは、サーバの移行プロセスを調整する役割を担います。クラスタ内のどのサーバ インスタンスもクラスタ マスターになることができます。移行可能なサーバを含むクラスタの起動時に、クラスタに参加した最初のサーバがクラスタ マスターになり、クラスタ マネージャ サービスを起動します。クラスタに移行可能なサーバが 1 つも含まれない場合はクラスタ マスターは不要です。クラスタ マスター サービスは起動されません。クラスタ マスターが存在しなくても、移行可能なサーバは動作を継続できますが、サーバの移行はできません。以下に、クラスタ マスターの主要な機能を示します。
ClusterMBean の FencingGracePeriodMillis で指定された期間、待機する。その後、リースが期限切れになっている移行可能なサーバをホストするマシン上でノード マネージャ プロセスを呼び出してその移行可能なサーバを再起動しようとします。
  
|