7 サーバー全体の移行
次の項では、サーバーで障害が発生した場合にサーバー全体を移行する方法について重点的に説明します。サーバー全体の移行では、移行可能サーバー・インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。WebLogic Serverでは、サービス・レベルの移行や、アプリケーション・レベルでのレプリケーションおよびフェイルオーバーもサポートされています。詳細は、「サービスの移行」および「クラスタのフェイルオーバーとレプリケーション」を参照してください。
この章の内容は次のとおりです。
- サーバーおよびサービスの移行の理解
WebLogic Serverクラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバー・インスタンスに均一にデプロイされます。これにより、サーバー・インスタンス間の透過的なフェイルオーバーが可能になります。対照的に、JMSやJTAトランザクション・リカバリ・システムなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにターゲット指定されます。WebLogic Serverは、これらのサービスに対して、フェイルオーバーではなく、移行による障害回復をサポートしています。 - 移行関連の用語
サーバーおよびサービスの移行に関する用語を学習します。 - リース
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。 - サーバー全体の自動移行
サーバー全体の自動移行を構成する手順を示し、WebLogic Server環境内でサーバー全体の移行機能をどのように使用するかを学習します。 - 動的クラスタおよび複合クラスタでのサーバー全体の移行
WebLogic Serverでは、動的クラスタおよび複合クラスタでのサーバー全体の移行がサポートされています。
サーバーおよびサービスの移行の理解
WebLogic Serverクラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバー・インスタンスに均一にデプロイされます。これにより、サーバー・インスタンス間の透過的なフェイルオーバーが可能になります。対照的に、JMSやJTAトランザクション・リカバリ・システムなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにターゲット指定されます。WebLogic Serverは、これらのサービスに対して、フェイルオーバーではなく、移行による障害回復をサポートしています。
WebLogic Serverでの移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたサーバー・インスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスです。サーバー全体の移行の場合は、障害が発生すると、サーバー・インスタンスが物理的に別のマシンに移行されます。サービス・レベルの移行の場合は、サービスをクラスタ内の別のサーバー・インスタンスに移動します。詳細は、「サービスの移行」を参照してください。
JMSおよびJTAトランザクション・システムの可用性を高めるために、WebLogic Serverでは移行可能サーバーが用意されています。移行可能サーバーは、サーバー・レベルで自動および手動で移行できます。サービス・レベルではありません。
移行可能なサーバーがなんらかの理由(ハング、ネットワークからの切断、ホスト・マシンの障害など)で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能サーバーは、可能であれば同じマシン上で自動的に再起動されます。障害が発生した同じマシン上で再起動できないときは、別のマシンに移行されます。また、管理者は手動でサーバー・インスタンスの移行を開始することもできます。
親トピック: サーバー全体の移行
移行関連の用語
サーバーおよびサービスの移行に関する用語を学習します。
-
移行可能サーバー: ホストするすべてのサービスとともにそのまま全部移行する、クラスタ化サーバー・インスタンスのことです。移行可能なサーバーは、JMSサーバーやJTAトランザクション・リカバリ・サーバーなどの固定サービスをホストすることを目的としたものですが、クラスタ化可能なサービスもホストできます。移行可能サーバー上で実行されるすべてのサービスには高可用性が備わっています。
-
サーバー全体の移行: 障害が発生すると、WebLogic Serverインスタンスは手動または自動で、物理的に別のマシンに移行されます。
-
サーバーの移行:
-
クラスタ・リーダー: クラスタ内の過半数のサーバー・インスタンスによって選択される1つのサーバーです。このサーバー・インスタンスは、リース情報を保持します。「コンセンサス(非データベース)リース」を参照してください
-
クラスタ・マスター: 移行可能サーバーを含むクラスタ内の1つのサーバー・インスタンスがクラスタ・マスターとして機能し、障害の発生時にサーバーの自動移行プロセスを調整します。固定サービスのホストであるかどうかに関係なく、クラスタ内のどの管理対象サーバーもクラスタ・マスターになることができます。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください
-
シングルトン・マスター: 自動移行可能な他のサービスをモニターする軽量シングルトン・サービスです。その時点でシングルトン・マスターをホストしているサーバー・インスタンスは、各移行可能サービスに関連付けられた移行タスクを開始および停止する役割を担います。「シングルトン・マスター」を参照してください。
-
候補マシン: クラスタ内で移行先のターゲットになる可能性のあるマシンのユーザー定義リストです。
-
ターゲット・マシン: 移行可能サーバーの優先ホストとして指定されている一連のマシンです。
-
ノード・マネージャ: 管理サーバーやスタンドアロンのノード・マネージャ・クライアントが使用するWebLogicサーバーのユーティリティで、移行可能なサーバーを起動または停止します。ノード・マネージャはクラスタ・マスターによって起動され、必要に応じて、移行可能なサーバーを停止または再起動します。ノード・マネージャの基本的な情報およびノード・マネージャがWebLogic Server環境に組み込まれる方法は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャの概要を参照してください。
-
リース表: 移行可能サーバーがそれぞれの状態を維持するデータベース表です。クラスタのマスターはこのデータベース表をモニターして、移行可能サーバーのヘルス状態とそれらが使用可能かどうかを確認します。「リース」を参照してください。
-
管理サーバー: 移行可能サーバーとターゲット・マシンの構成、移行可能サーバーの実行時状態の取得、および手動による移行プロセスの調整に使用します。
-
浮動IPアドレス: ある物理マシンから別の物理マシンに移行してもサーバー・インスタンスについて行くIPアドレス。
親トピック: サーバー全体の移行
リース
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。
リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時には、リースをフェイルオーバーさせることができます。これにより、シングル・ポイント障害を回避できます。
リースを使用する機能
リースは、次のWebLogicサーバー機能で使用されます。
-
サーバー全体の自動移行: クラスタ・マスターを選択するためにリースを使用します。クラスタ・マスターは、別のクラスタ・メンバーのモニター、および別の物理マシンでホストされるメンバーに障害が発生した場合にそのメンバーの再起動を担当します。
リースを使用することで、クラスタ・マスターが常に実行され、しかもクラスタ内のいずれか1つのサーバー・インスタンスでのみ実行されていることが保証されます。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください
-
自動サービス移行: JMS関連サービス、シングルトン・サービスおよびJTAトランザクション・リカバリ・サービスは、ヘルス・モニタリング・サブシステムを利用して、異常のあるホスト・サーバー・インスタンスから正常なアクティブ・サーバー・インスタンスに自動的に移行するよう構成できます。移行可能ターゲットを移行すると、そのターゲットにホストされている固定サービスも移行されます。移行可能ターゲットでは、リースを使用してサービスの自動移行を実現しています。「サービスの移行」を参照してください。
-
シングルトン・サービス: シングルトン・サービスはクラスタ内で実行され、複数のメンバーで同時に実行することはできないサービスです。この条件を満たすために、シングルトン・サービスではリースを使用します。「シングルトン・マスター」を参照してください。
-
ジョブ・スケジューラ: クラスタ内で使用する永続タイマーです。ジョブ・スケジューラでは、タイマー・マスターを使用して、クラスタ間でのタイマーのロード・バランシングを行います。
この機能には、フェイルオーバーやレプリケーション情報を保持するために外部のデータベースが必要です。ただし、ジョブ・スケジューラでは非データベースのコンセンサス・リースを使用できます。詳細は、「非データベースのコンセンサス・リース」を参照してください
ノート:
リース機能のほとんどは、基本的な構成の及ばない場所で、WebLogic Serverにより内部的に処理されます。
リースの種類
WebLogic Serverには、要件と環境に応じて、2種類のリース機能が用意されています。
-
高可用性データベース・リース - このタイプのリースでは、リース情報を格納するために高可用性データベースが必要です。一般的な要件と構成は、「高可用性データベース・リース」を参照してください。
-
非データベースのコンセンサス・リース: このタイプのリースは、リース情報をクラスタ・メンバーのメモリー内に格納します。非データベースのコンセンサス・リースでは、クラスタのすべてのサーバー・インスタンスがノード・マネージャによって起動される必要があります。「非データベースのコンセンサス・リース」を参照してください。
1つのWebLogic Serverインストールでは、1種類のリースしか使用できません。1つの環境において、リースを使用する複数の機能を実装することは可能ですが、各機能には同じ種類のリースを使用する必要があります。
あるリースの種類をもう一方の種類に切り替える場合は、管理サーバーだけでなく、クラスタ全体を再起動する必要があります。リースの種類を動的に変更することはできません。
親トピック: リースを使用する機能
使用するリースの種類の決定
現在のWebLogic Server環境にどの種類のリースが適しているかを判断する場合は、次の考慮事項を参考にしてください。
-
高可用性データベース・リース
データベース・リース基盤は、JMSストアのリカバリなどの機能を使用するためにOracle Real Application Clusters (RAC)のような高可用性データベースがすでにある環境では有用です。最小限の追加の構成を行って、高可用性データベース・インスタンスがリースをサポートするように構成できます。これは、ノード・マネージャがシステムで実行されていない場合に、特に便利です。
-
非データベースのコンセンサス・リース
このタイプのリースは、高可用性データベースを必要としないリースの選択肢(コンセンサス)を提供します。これは、サーバー全体の自動移行の場合に便利です。高可用性データベースを必要としないため、コンセンサス・リースでは、サーバーの自動移行を実行するために必要な構成が少なくなります。
コンセンサス・リースでは、ノード・マネージャを構成して実行する必要があります。ノード・マネージャは、サーバー全体の自動移行においてもIPの移行および別のマシンでのサーバーの再起動のために必要となります。つまり、コンセンサス・リースの場合は、追加の要件がないうえに、負荷の高い要件を排除できます。
ノート:
ベスト・プラクティスとして、コンセンサス・リースのかわりにデータベース・リースを構成することをお薦めします。親トピック: リース
高可用性データベース・リース
この種類のリースでは、リース情報を高可用性データベースの表内に保持します。リース情報をいつでもサーバー・インスタンスで使用できるようにするために、高可用性データベースが必要です。リース情報にアクセスし、リースを更新するために、クラスタの各メンバーがデータベースに接続できる必要があります。データベースにアクセスできなかった場合は、サーバー・インスタンスで障害が発生し、リースを更新できなくなります。
高可用性データベース・リースが役立つのは、クラスタ環境にすでに高可用性データベースを保持している場合です。データベース・リースにより、ノード・マネージャを必要としないリース機能を使用して、環境内のサーバー・インスタンスを管理できます。
次の手順は、リース用のデータベースを構成するために必要なステップの概要を示しています。
表7-1 データベース・リースのClusterMBean構成オプション
ClusterMBeanの属性 | デフォルト | 説明 |
---|---|---|
MigrationBasis |
consensus |
サーバーおよびサービスの移行で使用するクラスタ・リースの種類( データベース・リースを有効にするには、この属性を 必要に応じて、次の属性を設定することもできます。
ノート: データベース・リースを有効にし、AutoMigrationTableCreationPolicy をAlways に設定しない場合は、ステップ1の説明に従って、手動でデータベースのリース表を作成する必要があります。
|
DataSourceForAutomaticMigration |
none |
データベース・リースがデータベースとの接続に使用するデータ・ソースを指定します。この属性には既存の非XAデータソースを指定する必要があります。 この設定は、 |
AutoMigrationTableName |
ACTIVE |
データベース・リースに使用する表の名前を指定します。 この設定は、 ノート:
|
AutoMigrationTableCreationPolicy |
Disabled |
データベース・リースのための自動リース表作成の動作を制御します。 この設定は、 有効な値は次のとおりです。
ノート: |
AutoMigrationTableCreationDDLFile |
「説明」を参照 |
自動移行データベース表の作成に使用するカスタムDDLファイルの絶対パスを指定します。この設定は、次の条件が満たされる場合のみ適用されます。
次に注意してください:
|
RACクラスタ上でのデータベース・リースによるサーバーの移行
RACクラスタ上でデータベース・リースによるサーバー移行を使用する場合は、環境内のすべてのRACノードを同期することをお薦めします。ノードが同期化されない場合、リースを更新している管理対象サーバーは、RACノードのクロックの値がリース表のタイムアウト値よりも大きいかどうかを評価する場合があります。これが30秒を超える場合、サーバー・インスタンスに不具合が生じて再起動し、次のログ・メッセージが表示されます。
<Mar 29, 2013 2:39:09 PM EDT> <Error> <Cluster> <BEA-000150> <Server failed to get a connection to the database in the past 60 seconds for lease renewal. Server will shut itself down.>
詳細は、『インストレーションおよびアップグレード・ガイドfor Microsoft Windows』の「クラスタの時刻同期の構成」を参照してください。
親トピック: 高可用性データベース・リース
非データベースのコンセンサス・リース
ノート:
コンセンサス・リースでは、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを管理する必要があります。障害が発生した移行可能サーバーの候補マシンを含め、クラスタ内の管理対象サーバーをホストしているすべてのマシンで、ノード・マネージャが実行されている必要があります。詳細は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャを使用したサーバーの制御に関する項を参照してください。
コンセンサス・リースは可用性の高いデータベースを必要としません。クラスタ・リーダーは、メモリー内にリースを保持します。すべてのサーバー・インスタンスがクラスタ・リーダーに接続することでリースを更新しますが、フェイルオーバーの場合は、リース表がクラスタの別のノードにレプリケートされます。
クラスタ・リーダーは、クラスタ内のすべての実行中のサーバー・インスタンスによって選出されます。サーバー・インスタンスは、過半数のサーバー・インスタンスから承認を受けた場合のみ、クラスタ・リーダーになります。ノード・マネージャがあるサーバー・インスタンスを停止として報告した場合、クラスタ・リーダーは、過半数のサーバー・インスタンスを数えると、このサーバー・インスタンスがリーダーとしてその報告を承認したと見なします。
コンセンサス・リースは、過半数のサーバー・インスタンスが機能し続けることを必要とします。ネットワーク分割の際に、多数派のパーティションに含まれるサーバー・インスタンスは継続して実行されますが、少数派のパーティションに含まれるサーバー・インスタンスは、クラスタ・リーダーと通信できないか、サーバー・インスタンスの過半数が得られず新しいクラスタ・リーダーを選出できないために、自主的に停止します。パーティション化の結果サーバー・インスタンスが同数に分割されている場合は、クラスタ・リーダーを含むパーティションのサーバー・インスタンスは継続して実行されますが、もう一方のパーティションのサーバー・インスタンスは失敗します。コンセンサス・リースはノード・マネージャと接続する機能を利用し、管理しているサーバー・インスタンスのステータスを受信し、それらをアクセス可能サーバー・インスタンスの過半数に含めるようにカウントします。ネットワーク接続が失われたか、ハードウェアの障害のため、ノード・マネージャに接続できない場合、管理対象のサーバー・インスタンスは、たとえ実行されていても、過半数を構成するサーバーとしてカウントされません。
ノート:
クラスタに含まれるサーバー・インスタンスが2つのみである場合、多数派のパーティションがクラスタ・リーダーになります(ネットワーク分割が発生した場合)。クラスタ・リーダーが失敗すると、正常に実行されているサーバー・インスタンスは、ノード・マネージャを通じてそのステータスを確認しようとします。正常に実行されているサーバー・インスタンスが、失敗したクラスタ・リーダーのステータスを特定できる場合、クラスタ・リーダーのロールを引き受けます。マシンの障害またはネットワーク分割のため、正常に実行されているサーバー・インスタンスがクラスタ・リーダーのステータスを確認できない場合、自身が多数派であると確信が持てないため、自主的に停止します。
このようなシナリオを避けるため、異なるマシン上で実行される3つ以上のサーバー・インスタンスの使用をお薦めします。
サーバーの自動移行が有効化されている場合、サーバー・インスタンスはクラスタ・リーダーと通信して定期的にリースを更新する必要があります。リースを更新できなかった場合、サーバー・インスタンスは自らを停止します。停止したサーバー・インスタンスは、多数派のパーティションに自動的に移行されます。
親トピック: リース
サーバー全体の自動移行
サーバー全体の自動移行を構成する手順を示し、WebLogic Server環境内でサーバー全体の移行機能をどのように使用するかを学習します。
サーバー全体の自動移行の準備
サーバー全体の自動移行を構成する前に、次の要件について確認します。
-
Oracle Solarisゾーンでサーバー全体の移行を使用するには、My Oracle Supportで提供されている『Solaris 10ゾーン構成ガイドv1.0によるサーバー全体の移行』に記載されている排他的IPゾーンを使用する必要があります。
-
各管理対象サーバーで、同じサブネット・マスクを使用します。サーバー間のユニキャスト通信およびマルチキャスト通信では、各サーバー・インスタンスが同じサブネットを使用している必要があります。マルチキャスト通信またはユニキャスト通信を構成しないと、サーバーの移行は機能しません。
「IPマルチキャストの使用」および「ユニキャストを使用した1対多通信」を参照してください。
-
移行可能サーバーをホストするすべてのサーバー・インスタンスの時刻が同期していることを確認します。移行はサーバー・インスタンスの時刻が同期していなくても機能しますが、クラスタ化された環境では時刻が同期したサーバー・インスタンスをお薦めします。
-
移行可能サーバー間でオペレーティング・システムのバージョンが異なる場合は、すべてのバージョンで
ifconfig
に対して同じ機能がサポートされていることを確認してください。 -
サーバー全体の自動移行では、IPの移行および別のマシンでのサーバーの再起動のために、ノード・マネージャが構成されて実行している必要があります。
-
移行可能サーバーで使用するプライマリ・インタフェース名が同じです。環境内で異なるインタフェース名を使用しなければならない場合は、移行可能サーバーごとに
wlscontrol.sh
のローカル・バージョンを構成します。wlscontrol.sh
の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。 -
サポートされているデータベースのリストは、『Oracle Fusion Middlewareでサポートされるシステム構成』の「WebLogic Serverの機能をサポートするデータベース」を参照してください。
-
ファイルをマシン間で転送するための、信頼できる組込みのメカニズムはありません。ファイルの可用性を確保するには、すべてのマシンからアクセス可能なディスクを使用することをお薦めします。サーバー・インスタンス間でディスクを共有できない場合は、
domain_dir
/bin
の内容が各マシンにコピーされていることを確認する必要があります。 -
nmEnroll()
WLSTコマンドを使用して、ノード・マネージャのセキュリティ・ファイルが各マシンにコピーされていることを確認します。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャによるサーバーの制御に関する項を参照してください。 -
状態データの格納に、高可用性ストレージを使用します。高い信頼性を実現するために、ストレージ・エリア・ネットワーク(SAN)などの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。「状態データ用高可用性ストレージの使用」を参照してください
-
永続的なファイル・ストア・データには、中心的な共有ディレクトリを使用します。『WebLogic永続ストアの管理』のファイル・ストアの高可用性のための追加要件に関する項を参照してください。
-
本番環境でのキャパシティ・プランニングについては、移行中のサーバーの起動によってCPU使用率が上がることに注意してください。1つのマシンが同時に一定数のサーバー・インスタンスの同時実行を処理できるという理由で、同じマシンが同数のサーバー・インスタンスの同時起動を処理できると見なすことはできません。
親トピック: サーバー全体の自動移行
サーバー全体の自動移行の構成
サーバーの移行を構成する前に、お使いの環境が「サーバー全体の自動移行の準備」で説明されている要件を満たしていることを確認してください
クラスタ内の管理対象サーバーに対してサーバーの移行を構成するには、次のタスクを実行します。
親トピック: サーバー全体の自動移行
状態データ用高可用性ストレージの使用
サーバーの移行プロセスでは、サービスは移行されますが、障害の発生時に進行中だった作業に関連付けられた状態情報は移行されません。
高可用性を確保するには、こうした状態情報を移行後にサーバー・インスタンスやそれがホストするサービスで使用できるようにすることが重要です。そうしないと、障害の発生時に進行中だった作業に関するデータが失われてしまうおそれがあります。移行可能サーバーによって保持される状態情報(トランザクション・ログに格納されるデータなど)は、移行可能サーバーで障害が発生した場合にその移行先となる可能性のあるすべてのマシンからアクセスできる共有ストレージ・システムに格納する必要があります。高い信頼性を実現するために、SANなどの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。詳細は、『WebLogic永続ストアの管理』の「高可用性ファイル・ストアの追加要件」を参照してください。
また、データベースを使用してリース情報を格納する場合は、リース表(次の項を参照)も高可用性データベースに格納する必要があります。リース表は移行可能なサーバーのヘルスや利用の可能性を追跡します。「リース」を参照してください。
親トピック: サーバー全体の自動移行
サーバーの移行プロセスと通信
これ以降の項では、移行可能なサーバーを含むクラスタにおける主要なプロセスについて説明します。
- 移行可能サーバーのあるクラスタの起動プロセス
- サーバー全体の自動移行のプロセス
- サーバー全体の手動移行のプロセス
- サーバー全体の移行における管理サーバーの役割
- クラスタでの移行可能サーバーの動作
- サーバー全体の移行におけるノード・マネージャの役割
- サーバー全体の移行におけるクラスタ・マスターの役割
親トピック: サーバー全体の自動移行
移行可能サーバーのあるクラスタの起動プロセス
図7-1に、移行可能なサーバーを含むクラスタの起動時に発生するプロセスと通信を示します。
例のクラスタには2つの管理対象サーバーが含まれており、それらは両方とも移行可能です。管理サーバーと2つの管理対象サーバーは、それぞれ別々のマシンで実行されています。4つ目のマシンは、いずれかの移行可能サーバーで障害が発生した場合にバックアップとして使用できます。バックアップ・マシンと移行可能サーバーが実行されている各マシンでは、ノード・マネージャが実行されています。
図7-1に示されているように、クラスタの起動時には、次の主要なステップが発生します。
-
管理者がクラスタを起動します。
-
管理サーバーが、管理対象サーバー1を起動するためにマシンB上のノード・マネージャを呼び出し、管理対象サーバー2を起動するためにマシンC上のノード・マネージャを呼び出します。「サーバー全体の移行における管理サーバーの役割」を参照してください
-
各マシン上のノード・マネージャのインスタンスが、そのマシン上で実行する管理対象サーバーを起動します。「サーバー全体の移行におけるノード・マネージャの役割」を参照してください
-
管理対象サーバー1および2が、管理サーバーにアクセスしてそれぞれの構成を取得します。「クラスタでの移行可能サーバーの動作」を参照してください
-
管理対象サーバー1と2が、起動時の構成をキャッシュします。
-
管理対象サーバー1および2がそれぞれ、移行可能サーバーのリースをリース表から取得します。管理対象サーバー1がまず起動するので、管理対象サーバー1はクラスタ・マスターのリースも取得します。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください
-
管理対象サーバー1および2が、リース表の各自のリースを定期的に更新し、自身のヘルス状態と自身が使用可能であることを示します。
親トピック: サーバーの移行プロセスと通信
サーバー全体の自動移行のプロセス
図7-2に、管理対象サーバー2をホストしているマシンで障害が発生した後の自動移行のプロセスを示します。
-
管理対象サーバー2をホストしているマシンCで障害が発生します。
-
次回の定期的なリース表の確認時に、クラスタ・マスターが管理対象サーバー2のリースが期限切れになっていることを検出します。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください
-
クラスタ・マスターが、管理対象サーバー2を再起動するためにマシンC上のノード・マネージャにアクセスしようとしますが、マシンCはアクセスできなくなっているためアクセスは失敗します。
ノート:
サーバーのハングが原因で、管理対象サーバー2のリースが期限切れになったとき、マシンCにアクセスできる場合は、クラスタ・マスターはノード・マネージャを使用してマシンC上の管理対象サーバー2を再起動します。
-
クラスタ・マスターが、マシンD上のノード・マネージャにアクセスします。マシンDはクラスタ内の移行可能サーバーのホストとして使用できるように構成されています。
-
マシンD上のノード・マネージャが管理対象サーバー2を起動します。「サーバー全体の移行におけるノード・マネージャの役割」を参照してください
-
管理対象サーバー2が起動し、管理サーバーにアクセスして自身の構成を取得します。
-
管理対象サーバー2は、起動時の構成をキャッシュします。
-
管理対象サーバー2が、移行可能サーバーのリースを取得します。
移行する管理対象サーバーのクライアントでは、移行中にサービスの短い中断が発生するおそれがあります。その場合、再接続が必要になることもあります。SolarisおよびLinuxオペレーティング・システムでは、ifconfig
コマンドを使用して再接続を行うことができます。移行されたサーバーのクライアントは、サーバーの移行先の特定のマシンを認識する必要はありません。
移行が行われたマシン(以前にサーバー・インスタンスをホストしていたマシン)が再び使用可能になると、移行プロセスが逆方向で行われます(サーバー・インスタンスを元のホスト・マシンに移行して戻します)。これはフェイルバックと呼ばれます。WebLogic Serverではフェイルバックのプロセスは自動化されていません。管理者は、サーバー・インスタンスを元のホストに手動で戻すことでフェイルバックを実行できます。
サーバー・インスタンスを元のホストに復元する一般的な手順は次のとおりです。
-
サーバーの新しいインスタンスを正常に停止します。
-
障害が発生していたマシンを再起動した後に、ノード・マネージャと管理対象サーバーを再起動します。
行う手順は、サーバー・インスタンスおよびネットワーク環境によって異なります。
親トピック: サーバーの移行プロセスと通信
サーバー全体の手動移行のプロセス
図7-3に、管理者が移行可能サーバーを手動で移行するときに発生するプロセスと通信を示します。
-
管理者がWebLogic Server管理コンソールを使用して、マシンCからマシンBへの管理対象サーバー2の移行を開始します。
-
管理サーバーがマシンC上のノード・マネージャにアクセスします。「サーバー全体の移行における管理サーバーの役割」を参照してください
-
マシンC上のノード・マネージャが、管理対象サーバー2を停止します。
-
管理対象サーバー2がリース表から自身の行を削除します。
-
管理サーバーがマシンB上のノード・マネージャを呼び出します。
-
マシンB上のノード・マネージャが、管理対象サーバー2を起動します。
-
管理対象サーバー2が管理サーバーから自身の構成を取得します。
-
管理対象サーバー2は、起動時の構成をキャッシュします。
-
管理対象サーバー2がリース表に行を追加します。
親トピック: サーバーの移行プロセスと通信
サーバー全体の移行における管理サーバーの役割
移行可能サーバーを含むクラスタで、管理サーバーは次を行います:
-
移行可能サーバーを起動するために、クラスタのメンバーをホストする各マシン上のノード・マネージャを呼び出します。これは、サーバーを移行する際の前提条件です。サーバー・インスタンスは、最初にノード・マネージャで起動しないと移行できません。
-
移行可能サーバーを停止および起動するために、手動による移行プロセスに関係する各マシン上のノード・マネージャを呼び出します。
-
通常の停止時にサーバー・インスタンスを停止するために、クラスタのメンバーをホストする各マシン上のノード・マネージャを呼び出します。これは、サーバーを移行する際の前提条件です。ノード・マネージャを使用しないでサーバー・インスタンスを直接停止した場合、サーバー・インスタンスが稼働していないことがクラスタ・マスターで検出されると、ノード・マネージャが呼び出されて、そのサーバー・インスタンスが再起動してしまいます。
さらに管理サーバーには、管理者によって発行された構成の更新の保持、ドメインの実行時情報の表示などの、ドメイン内の移行可能サーバーも含めた通常のドメイン管理機能があります。
親トピック: サーバーの移行プロセスと通信
クラスタでの移行可能サーバーの動作
移行可能サーバーとは、移行可能として構成されている、クラスタ化された管理対象サーバーのことです。移行可能なサーバーには、次の主要な動作があります。
-
データベースを使用してリース情報を管理する場合は、ノード・マネージャによる起動時および再起動時にリース表に行を追加します。移行可能サーバーの行には、タイムスタンプや、それが実行されているマシン名が記載されます。「リース」を参照してください。
-
データベースを使用してリース情報を管理する場合には、移行可能なサーバーにより起動の結果としてデータベースに1行追加されます。クラスタ・マスターのロールの取得を試行し、それがクラスタに最初に参加するサーバー・インスタンスの場合には成功します。
-
リース表のタイム・スタンプを更新することで、リースを定期的に更新します。
デフォルトでは、移行可能サーバーは30,000ミリ秒ごとにリースを更新します。このデフォルト値は、次の2つの構成可能な
ServerMBean
プロパティ値を掛け合わせた値です。-
HealthCheckIntervalMillis
(デフォルトは10,000) -
HealthCheckPeriodsUntilFencing
(デフォルトは3)
-
-
期限切れになる前にリース表にアクセスしてリースを更新できなかった場合は、移行可能サーバーはJava
System.exit
を使用してできるだけ迅速に終了します。この場合は、リース表にはそのサーバー・インスタンス用の行が引き続き格納されます。この動作と自動移行の関連の詳細は、「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください -
動作時に、クラスタ・マスターからのハートビートをリスニングします。クラスタ・マスターがハートビートを送信していないことを検出すると、移行可能なサーバーはクラスタ・マスターのロールを引き受けようとし、他のサーバー・インスタンスがクラスタ・マスターになることをリクエストしていない場合にクラスタ・マスターとなります。
ノート:
サーバー移行時に、サーバー起動によってCPU使用率が上昇することに注意してください。1つのマシンが同時に一定数のサーバー・インスタンスの同時実行をサポートできるという理由で、同じマシンが同数のサーバー・インスタンスの同時起動をサポートできると見なすことはできません。
親トピック: サーバーの移行プロセスと通信
サーバー全体の移行におけるノード・マネージャの役割
ノード・マネージャの使用は、サーバーの移行に不可欠です。ホストする(またはホストする予定の)各マシン上で実行する必要があります。
ノード・マネージャは、次のようにサーバーの移行をサポートします。
-
移行可能サーバーの最初の起動には、ノード・マネージャを使用する必要があります。
WebLogic Server管理コンソールから管理対象サーバーの起動を開始すると、管理サーバーがノード・マネージャを使用してそのサーバー・インスタンスを起動します。ノード・マネージャを呼び出して、スタンドアロンのノード・マネージャ・クライアントを使用してサーバー・インスタンスを起動することもできます。ただし、起動する管理対象サーバーが自身の構成を取得するために管理サーバーが使用可能になっている必要があります。
ノート:
最初にノード・マネージャによって開始していないサーバー・インスタンスの移行は失敗します。
-
ノード・マネージャを使用して、移行可能なサーバーを一時停止、停止または強制停止する必要があります。
-
ノード・マネージャは、リースが期限切れになっている移行可能サーバーを障害の発生時に実行されていたマシン上で再起動しようとします。
ノード・マネージャは、WebLogic Serverに用意されたカスタマイズ可能なシェル・スクリプトを実行することで、サーバーの移行プロセスのステップを実行します。これらのスクリプトは、サーバー・インスタンスを起動、再起動、停止し、IPアドレスを移行し、ディスクをマウントおよびアンマウントすることが可能です。これらのスクリプトは、SolarisおよびLinuxで使用できます。
-
自動移行では、クラスタ・マスターがノード・マネージャを呼び出して移行を実行します。
-
手動による移行では、管理サーバーがノード・マネージャを呼び出して移行を実行します。
-
親トピック: サーバーの移行プロセスと通信
サーバー全体の移行におけるクラスタ・マスターの役割
移行可能サーバーを含むクラスタでは、1つのサーバー・インスタンスがクラスタ・マスターとして機能します。クラスタ・マスターは、サーバーの移行プロセスを調整する役割を担います。クラスタ内のどのサーバー・インスタンスもクラスタ・マスターになることができます。移行可能サーバーを含むクラスタの起動時に、クラスタに参加した最初のサーバー・インスタンスがクラスタ・マスターになり、クラスタ・マネージャ・サービスを起動します。クラスタに移行可能サーバーが1つも含まれない場合はクラスタ・マスターは不要で、クラスタ・マネージャ・サービスは起動されません。クラスタ・マスターが存在しなくても、移行可能サーバーは動作を継続できますが、サーバーの移行はできません。クラスタ・マスターは、次の主要な機能を実行します。
-
クラスタ内の他のサーバー・インスタンスに定期的なハートビートを発行します。
-
定期的にリース表を読み込み、移行可能サーバーのそれぞれに現在のリースがあることを確認します。期限切れになったリースによって、クラスタ・マスターはその移行可能サーバーを再起動する必要があると認識します。
-
移行可能サーバーのリースが期限切れになっていると判断すると、クラスタ・マスターは
ClusterMBean
のFencingGracePeriodMillis
で指定された期間、待機します。その後、リースが期限切れになっている移行可能サーバーをホストするマシン上でノード・マネージャ・プロセスを呼び出してその移行可能サーバーの再起動を試行します。 -
リースが期限切れになっている移行可能サーバーを再起動できない場合、クラスタ・マスターは次の方法でターゲット・マシンを選択します。
-
移行可能サーバーの優先宛先マシンのリストが作成されている場合は、クラスタ・マスターは、リストでのマシンの並び順に従ってリストからマシンを選択します。
-
それ以外の場合は、クラスタ内の移行可能サーバーのホストとして使用できるように構成されているマシンのリストからマシンを選択します。
移行可能なサーバーをホストできるマシンのリストは、2つのレベル(クラスタ全体用と個々の移行可能なサーバー用)で構成できます。両方のレベルのマシン・リストを定義できますが、少なくとも一方のレベルでマシン・リストを定義する必要があります。
-
-
新しいマシンへのサーバー・インスタンスの移行を実行するために、クラスタ・マスターは、ターゲット・マシン上でノード・マネージャ・プロセスを呼び出してサーバー・インスタンスのプロセスを作成します。
移行の実行に必要な時間は、サーバーの構成および起動時間によって異なります。
-
クラスタ・マスターが移行可能サーバーを再起動するのにかかる最大時間は、(
HealthCheckPeriodsUntilFencing
*HealthCheckIntervalMillis
) +FencingGracePeriodMillis
です。 -
サーバー・インスタンスがクライアント・リクエストに対して使用可能になるまでの合計時間は、サーバーの起動時間およびアプリケーションのデプロイメント時間によって決まります。
-
親トピック: サーバーの移行プロセスと通信
動的クラスタおよび複合クラスタでのサーバー全体の移行
WebLogic Serverでは、動的クラスタおよび複合クラスタでのサーバー全体の移行がサポートされています。
動的クラスタ内の動的サーバーで障害が発生すると、構成済クラスタまたは複合クラスタ内で構成済のサーバーと同じように、サーバー・インスタンスが別の物理マシンへ移行されます。クラスタの種類に応じて構成は異なりますが、サーバー全体の移行の動作はすべてのクラスタで同じです。「動的クラスタ」を参照してください。
サーバー全体の自動移行ではリースを使用して、クラスタ・マスターが選出されます。クラスタ・マスターは、別のクラスタ・メンバーのモニターおよび別の物理マシンでホストされるメンバーに障害が発生した場合の再起動を担当します。クラスタ構成でリースを構成します。「リース」を参照してください。
動的クラスタでのサーバー全体の移行の構成
構成済クラスタに対してサーバー全体の自動移行を構成する際には、移行しようとするサーバー・インスタンスを個別に選択します。障害発生時にサーバー・インスタンスを移行するために使用可能なマシンのサブセットも選択できます。
動的クラスタでは、サーバー・テンプレートでサーバー全体の自動移行を有効または無効にできます。動的クラスタは、単一のサーバー・テンプレートを使用してその構成を定義し、動的クラスタ内のすべての動的サーバー・インスタンスがテンプレートの構成を継承します。動的クラスタのサーバー・テンプレート内でサーバー全体の自動移行が有効な場合、そのサーバー・テンプレートに基づいたすべての動的サーバー・インスタンスがサーバー全体の自動移行に対して有効になります。動的サーバー・インスタンスを個別に選択して移行することはできません。
また、移行先のマシンは選択できません。サーバー・テンプレートで動的クラスタに対してサーバー全体の自動移行を有効化すると、移行のために使用できるすべてのマシンが自動的に選択されます。
サーバー・テンプレートで候補マシンがリストされていないため、動的クラスタが指定する移行の候補マシンのリストを制限することはできません。各動的サーバーに対する候補マシンのリストは、次のように計算されます。
ClusterMBean.CandidateMachinesForMigratableServers = { M1, M2, M3 } dyn-server-1.CandidateMachines = { M1, M2, M3} dyn-server-2.CandidateMachines = { M2, M3, M1 } dyn-server-3.CandidateMachines = { M3, M1, M2 } dyn-server-4.CandidateMachines = { M1, M2, M3 }
WebLogic Server管理コンソールを使用して動的クラスタに対してサーバー全体の自動移行を有効にするには:
- WebLogic Server管理コンソールの左ペインで、「環境」→「クラスタ」→「サーバー・テンプレート」の順に選択します。
- 「サーバー・テンプレート」表で、動的クラスタのサーバー・テンプレートを選択します。
- 「構成」→「移行」の順に選択します。
- 「サーバーの自動移行を有効化」属性を選択します。
親トピック: 動的クラスタおよび複合クラスタでのサーバー全体の移行
複合クラスタでのサーバー全体の移行の構成
複合クラスタには動的サーバーと構成済サーバーの両方が含まれます。複合クラスタに対してサーバー全体の自動移行を有効にするには:
親トピック: 動的クラスタおよび複合クラスタでのサーバー全体の移行