ヘッダーをスキップ
Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方
11g リリース 1 (10.3.1)
B55518-01
  目次
目次
戻る
戻る 		 次へ
次へ		  

7 サーバ全体の移行

以下の節では、WebLogic Server でサポートされているさまざまな移行メカニズムについて説明します。

これらの節では、サーバで障害が発生した場合にサーバ全体を移行する方法について重点的に説明します。サーバ全体の移行では、移行可能なサーバ インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。WebLogic Server では、サービスレベルの移行や、アプリケーション レベルでのレプリケーションおよびフェイルオーバもサポートされています。詳細については、「サービスの移行」および「クラスタのフェイルオーバとレプリケーション」を参照してください。

サーバおよびサービスの移行について

WebLogic Server クラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバ インスタンスに均一にデプロイされます。これにより、サーバ間の透過的なフェイルオーバが可能になります。対照的に、JMS や JTA トランザクション回復システムなどの「固定サービス」はクラスタ内の個々のサーバ インスタンスを対象にします。こうしたサービスのために、WebLogic Server では、フェイルオーバではなく移行を使用する障害からの回復がサポートされています。


注意 :

サーバ全体の移行はすべてのプラットフォームでサポートされているわけではありません。『Oracle WebLogic Server, WebLogic Portal and WebLogic Integration 10gR3 (10.3)』の「サーバの移行のサポート」を参照してください。

WebLogic Server での「移行」とは、クラスタ化された WebLogic Server インスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスです。「サーバ全体」の移行の場合は、障害が発生すると、サーバ インスタンスが物理的に別のマシンに移行されます。「サービスレベル」の移行の場合は、サービスをクラスタ内の別のサーバ インスタンスに移動します。「サービスの移行」を参照してください。

WebLogic Server には、JMS や JTA トランザクション システムの可用性を高めるための機能 (「移行可能なサーバ」) が用意されています。移行可能なサーバは、サービスレベルではなく、サーバレベルで自動または手動で移行できます。

移行可能なサーバが何らかの理由 (ハング、ネットワーク接続の消失、ホスト マシンの障害など) で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバは、可能であれば同じマシン上で自動的に再起動されます。障害が発生した同じマシン上で再起動できないときは、別のマシンに移行されます。また、管理者は手動でサーバ インスタンスの移行を開始することもできます。

移行関連の用語

サービスおよびサーバの移行では、以下の用語を使用します。

リース

リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタワイド エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に 1 つしか存在しません。また、サーバやクラスタの障害時には、リースをフェイルオーバさせることができます。これにより、シングル ポイント障害を回避できます。

リースを使用する機能

リースは、以下の WebLogic サーバ機能で使用します。

リースの種類

WebLogic Server では、2 種類のリース機能を実装できます。どちらを使用するかは、そのときどきの要件や環境によって決まります。

1 つの WebLogic Server インストールでは、1 種類のリースしか使用できません。1 つの環境において、リースを使用する複数の機能を実装することは可能ですが、各機能には同じ種類のリースを使用する必要があります。

あるリースの種類をもう一方の種類に切り替える場合は、管理サーバだけでなく、クラスタ全体を再起動する必要があります。リースの種類を動的に変更することはできません。

使用するリースの種類の決定

現在の WebLogic Server 環境にはどの種類のリースが適しているかを判断する場合は、以下の考慮事項を参考にしてください。

高可用性データベース リース

このタイプのリースでは、リース情報を高可用性データベースのテーブル内に保持します。リース情報を常に利用できるようにするため、可用性の高いデータベースが必要になります。リース情報にアクセスするため、クラスタの各メンバーからデータベースに接続できなければなりません。

このリース方法は、クラスタ化された環境にすでに高可用性データベースが存在する場合に便利です。この方法を使用すると、ノード マネージャを使用して環境内のサーバを管理していなくてもリース機能を利用できます。

以下では、リース用のデータベースをコンフィグレーションするために必要な手順の概略を示します。

  1. サーバの移行用にデータベースをコンフィグレーションします。この情報は、サーバが実行されているかどうかや、サーバを移行する必要があるかどうかを判別するために使用します。リースの詳細については、「リース」を参照してください。

    データベースは信頼性のあるものでなければなりません。サーバ インスタンスの信頼性は、このデータベースの信頼性で決まります。実験的な目的で使用する場合は、通常のデータベースで十分です。プロダクション環境で使用する場合は、高可用性データベースしかお勧めできません。データベースが停止すると、すべての移行可能なサーバが停止します。

    データベース内にリース テーブルを作成します。このテーブルは、サーバの移行を可能にするためのマシンとサーバの関連付けの格納に使用されます。このテーブルのスキーマは、WL_HOME/server/db/dbname/leasing.ddl にあります。ここで、dbname はデータベース ベンダの名前です。


    注意 :

    リース テーブルは高可用性データベースに格納する必要があります。移行可能なサーバの信頼性は、リース テーブルの格納に使用されるデータベースの信頼性で決まります。

  2. データ ソースを設定し、コンフィグレーションします。このデータ ソースは、前の手順でコンフィグレーションしたデータベースを指している必要があります。


    注意 :

    サーバの移行では、XA データ ソースはサポートされていません。

    JDBC データ ソースの作成の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。

コンセンサス (非データベース) リース

コンセンサス (非データベース) リースでは、リース情報がメモリ内に保持されます。そのため、リースを必要とする機能を使用するだけのために、高可用性データベースを用意する必要はありません。

クラスタのいずれか 1 つのメンバーをクラスタ リーダーとし、このメンバーにリース情報を保持する役割を付与します。クラスタ リーダーは、起動後の経過時間の長さに基づいて選択されます。クラスタ内の管理対象サーバのうち、起動後の経過時間が最も長いものがクラスタ リーダーとなります。その他のクラスタ メンバーは、クラスタ リーダーと通信してリース情報を識別します。フェイルオーバを可能にするため、リース テーブルはクラスタの他のノードにレプリケートされます。


注意 :

このリース方法では、ノード マネージャを使用してクラスタ内のサーバを管理する必要があります。ノード マネージャは、クラスタ内の管理対象サーバをホストするすべてのマシンで実行する必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「ノード マネージャを使用したサーバの制御」を参照してください。

サーバ全体の自動移行

この節では、サーバ全体の自動移行をコンフィグレーションする手順の概略を示し、WebLogic Server 環境内でサーバ全体の移行機能をどのように使用するかについて説明します。

以下の内容について説明します。

サーバ全体の自動移行の準備

サーバ全体の自動移行をコンフィグレーションする前に、以下の要件について確認します。

サーバ全体の自動移行のコンフィグレーション

サーバの移行をコンフィグレーションする前に、お使いの環境が「サーバ全体の自動移行の準備」で説明されている要件を満たしていることを確認してください。

クラスタ内の管理対象サーバに対してサーバの移行をコンフィグレーションするには、以下のタスクを行います。

  1. 移行を有効にする各管理対象サーバの浮動 IP アドレスを取得します。

    移行可能なサーバには、それぞれ浮動 IP アドレスを割り当てる必要があります。この IP アドレスは、物理的なマシンが変わってもサーバを追跡します。浮動 IP アドレスが割り当てられるすべてのサーバで、AutoMigrationEnabled を true に設定する必要もあります。


    注意 :

    移行可能な IP アドレスは、移行可能なサーバが起動されるまではどの候補マシンのインタフェースでも提示されないようにします。

  2. ノード マネージャをコンフィグレーションします。ノード マネージャは実行中でなければなりません。また、サーバの移行を許可するようにコンフィグレーションされている必要があります。

    Java バージョンのノード マネージャは Windows または UNIX でのサーバ移行に使用できます。SSH バージョンのノード マネージャは UNIX でのサーバ移行にのみ使用できます。

    Java のノード マネージャを使用する場合は、WL_HOME/common/nodemanager/ の nodemanager.properties を編集して、ご使用の環境の Interface および NetMask 値を追加する必要があります。nodemanager.properties の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「nodemanager.properties の検討」を参照してください。

    SSH バージョンのノード マネージャを使用する場合は、wlscontrol.sh を編集して、Interface 変数にネットワーク インタフェースの名前を設定します。

    サーバの移行でのノード マネージャの使用に関する全般的な情報については、「サーバ全体の移行におけるノード マネージャの役割」を参照してください。ノード マネージャの一般的な情報については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「ノード マネージャの一般的コンフィグレーション」を参照してください。

  3. データベースを使用してリース情報を管理する場合は、「高可用性データベース リース」の手順に従って、サーバの移行に使用するデータベースをコンフィグレーションします。リースの全般的な情報については、「リース」を参照してください。

  4. データベース リースをテスト環境内で使用しており、リース テーブルをリセットする必要がある場合は、leasing.ddl スクリプトを再実行する必要があります。リセットによって、適切なテーブルが削除されて再作成されます。

  5. データベースを使用してリース情報を格納する場合は、「高可用性データベース リース」の手順に従って、データ ソースを設定してコンフィグレーションします。

    各クラスタのコンフィグレーションで、DataSourceForAutomaticMigration をこのデータ ソースに設定してください。


    注意 :

    サーバの移行では、XA データ ソースはサポートされていません。

    JDBC データ ソースの作成の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。

  6. wlsifconfig.sh スクリプト (UNIX) または wlsifconfig.cmd スクリプト (Windows) にスーパーユーザ特権を付与します。

    このスクリプトは、移行時にマシン間での IP アドレスの転送に使用され、通常はスーパーユーザだけが使用できる ifconfig を実行できなければなりません。sudo を使用して起動されるように、このスクリプトを編集できます。

    Java ノード マネージャは wlsifconfig.cmd スクリプトを使用します。このスクリプトでは netsh ユーティリティが使用されます。

    wlsifconfig スクリプトは WL_HOME/common/bin ディレクトリにあります。

  7. 以下のコマンドが使用するマシンの PATH に含まれていることを確認してください。

    • wlsifconfig.sh (UNIX) または wlsifconfig.cmd (Windows)

    • wlscontrol.sh (UNIX)

    • nodemanager.domains

    wlsifconfig.sh、wlsifconfig.cmd、および wlscontrol.sh ファイルは WL_HOME/common/bin にあります。nodemanager.domains ファイルは WL_HOME/common/nodemanager にあります。

    .sh スクリプトの最初の行は、UNIX で使用するデフォルトのシェルに応じて編集する必要があります。

  8. この手順は UNIX のみに該当します。Windows を使用している場合は、手順 9 に進んでください。

    移行可能なサーバをホストするマシンは相互に信頼していなければなりません。移行が行われるためには、ユーザ名とパスワードを明示的に入力する必要なしに、マシン B から「ssh/rsh machine_A」を使用して (同様にマシン A から「ssh/rsh machine_B」を使用して) シェル プロンプトにアクセスできる必要があります。また、各マシンは SSH を使用して同じ方法で自身に接続できなければなりません。


    注意 :

    シェルが対話型である場合は、ログイン スクリプト (.cshrc、.profile、.login など) がシェル プロファイルからのメッセージのみをエコーすることを確認してください。WebLogic Server は、ssh コマンドを使用してログインし、server.state ファイルの内容をエコーします。この出力の最初の行だけがサーバの状態の判別に使用されます。

  9. サーバの移行用の候補マシンを設定します。サーバごとに異なる候補マシンのセットを設定することもできますし、すべてのサーバに同じセットを設定することもできます。

  10. 管理サーバを再起動します。

ステート データ用高可用性ストレージの使用

サーバの移行プロセスでは、サービスは移行されますが、障害の発生時に進行中だった作業に関連付けられたステート情報は移行されません。

高可用性を確保するには、こうした情報を移行後にサーバ インスタンスやそれがホストするサービスで使用できるようにすることが重要です。そうしないと、障害の発生時に進行中だった作業に関するデータが失われてしまうおそれがあります。移行可能なサーバによって保持されるステート情報 (トランザクション ログに格納されるデータなど) は、移行可能なサーバで障害が発生した場合にその移行先となる可能性のあるすべてのマシンからアクセスできる共有ストレージ システムに格納する必要があります。高い信頼性を実現するために、ストレージ エリア ネットワーク (SAN) などの、高可用性の備わっている共有ストレージ ソリューションを使用してください。

さらに、データベースを使用してリース情報を格納する場合は、移行可能なサーバの状態とそれらが使用可能かどうかの追跡に使用されるリース テーブル (以下の節を参照) も高可用性データベースに格納する必要があります。詳細については、「リース」を参照してください。

サーバの移行プロセスと通信

以下の節では、移行可能なサーバを含むクラスタにおける主要なプロセスについて説明します。

移行可能なサーバのあるクラスタの起動プロセス

図 7-1 に、移行可能なサーバを含むクラスタの起動時に発生するプロセスと通信を示します。

例のクラスタには 2 つの管理対象サーバが含まれており、それらは両方とも移行可能です。管理サーバと 2 つの管理対象サーバは、それぞれ別々のマシンで実行されています。4 つ目のマシンは、いずれかの移行可能なサーバで障害が発生した場合にバックアップとして使用できます。バックアップ マシンと移行可能なサーバが実行されている各マシンでは、ノード マネージャが実行されています。

図 7-1 移行可能なサーバのあるクラスタの起動

図 7-1 の説明については以下を参照
「図 7-1 移行可能なサーバのあるクラスタの起動」の説明

以下は、図 7-1 に示されている、クラスタの起動時に発生する主要な手順です。

  1. 管理者がクラスタを起動します。

  2. 管理サーバが、管理対象サーバ 1 を起動するためにマシン B 上のノード マネージャを呼び出し、管理対象サーバ 2 を起動するためにマシン C 上のノード マネージャを呼び出します。「サーバ全体の移行における管理サーバの役割」を参照してください。

  3. 各マシン上のノード マネージャが、そこで実行される管理対象サーバを起動します。「サーバ全体の移行におけるノード マネージャの役割」を参照してください。

  4. 管理対象サーバ 1 および 2 が、管理サーバにアクセスしてそれぞれのコンフィグレーションを取得します。「クラスタでの移行可能なサーバの動作」を参照してください。

  5. 管理対象サーバ 1 および 2 が、起動時のコンフィグレーションをキャッシュします。

  6. 管理対象サーバ 1 および 2 がそれぞれ、移行可能なサーバのリースをリース テーブルから取得します。管理対象サーバ 1 がまず起動するので、管理対象サーバ 1 はクラスタ マスターのリースも取得します。「サーバ全体の移行におけるクラスタ マスターの役割」を参照してください。

  7. 管理対象サーバ 1 および 2 が、リース テーブルの各自のリースを定期的に更新し、自身の状態と自身が使用可能であることを示します。

サーバ全体の自動移行のプロセス

図 7-2 に、管理対象サーバ 2 をホストしているマシンで障害が発生した後の自動移行のプロセスを示します。

図 7-2 障害が発生したサーバの自動移行

図 7-2 の説明については以下を参照
「図 7-2 障害が発生したサーバの自動移行」の説明

  1. 管理対象サーバ 2 をホストしているマシン C で障害が発生します。

  2. 次回の定期的なリース テーブルの確認時に、クラスタ マスターが管理対象サーバ 2 のリースが期限切れになっていることを検出します。「サーバ全体の移行におけるクラスタ マスターの役割」を参照してください。

  3. クラスタ マスターが、管理対象サーバ 2 を再起動するためにマシン C 上のノード マネージャにアクセスしようとしますが、マシン C はアクセスできなくなっているためアクセスは失敗します。


    注意 :

    サーバのハングが原因で管理対象サーバ 2 のリースが期限切れになっていて、マシン C にはアクセスできる場合、クラスタ マスターはノード マネージャを使用してマシン C 上の管理対象サーバ 2 を再起動します。

  4. クラスタ マスターが、マシン D 上のノード マネージャにアクセスします。マシン D はクラスタ内の移行可能なサーバのホストとして使用できるようにコンフィグレーションされています。

  5. マシン D 上のノード マネージャが管理対象サーバ 2 を起動します。「サーバ全体の移行におけるノード マネージャの役割」を参照してください。

  6. 管理対象サーバ 2 が起動し、管理サーバにアクセスして自身のコンフィグレーションを取得します。

  7. 管理対象サーバ 2 が、起動時のコンフィグレーションをキャッシュします。

  8. 管理対象サーバ 2 が、移行可能なサーバのリースを取得します。

移行する管理対象サーバのクライアントでは、移行中にサービスの短い中断が発生するおそれがあります。その場合、再接続が必要になることもあります。Solaris および Linux オペレーティング システムでは、ifconfig コマンドを使用して再接続を行うことができます。移行されたサーバのクライアントは、サーバの移行先の特定のマシンを認識する必要はありません。

移行されたサーバ インスタンスを移行前にホストしていたマシンが再び使用可能になった場合、移行プロセスの逆戻し (サーバ インスタンスを元のホスト マシンに移行して戻すこと) を行うことができます。これを、フェイルバックと呼びます。WebLogic Server ではフェイルバックのプロセスは自動化されていません。管理者は、サーバ インスタンスを元のホストに手動で戻すことでフェイルバックを実行できます。

サーバを元のホストに復元するおおまかな手順は次のとおりです。

  • サーバの新しいインスタンスを正常に停止します。

  • 障害が発生していたマシンを再起動した後に、ノード マネージャと管理対象サーバを再起動します。

細かな手順は、サーバおよびネットワーク環境によって異なります。

サーバ全体の手動移行のプロセス

図 7-3 に、管理者が移行可能なサーバを手動で移行するときに発生するプロセスと通信を示します。

図 7-3 サーバ全体の手動移行

図 7-3 の説明については以下を参照
「図 7-3 サーバ全体の手動移行」の説明

  1. 管理者が Administration Console を使用して、マシン C からマシン B への管理対象サーバ 2 の移行を開始します。

  2. 管理サーバがマシン C 上のノード マネージャにアクセスします。「サーバ全体の移行における管理サーバの役割」を参照してください。

  3. マシン C 上のノード マネージャが、管理対象サーバ 2 を停止します。

  4. 管理対象サーバ 2 がリース テーブルから自身の行を削除します。

  5. 管理サーバがマシン B 上のノード マネージャを呼び出します。

  6. マシン B 上のノード マネージャが、管理対象サーバ 2 を起動します。

  7. 管理対象サーバ 2 が管理サーバから自身のコンフィグレーションを取得します。

  8. 管理対象サーバ 2 が、起動時のコンフィグレーションをキャッシュします。

  9. 管理対象サーバ 2 がリース テーブルに行を追加します。

サーバ全体の移行における管理サーバの役割

以下に、移行可能なサーバを含むクラスタでの管理サーバの動作を示します。

  • 移行可能なサーバを起動するために、クラスタのメンバーをホストする各マシン上のノード マネージャを呼び出す。この動作は、サーバの移行性の前提条件です。最初にノード マネージャによって起動されていない場合、そのサーバ インスタンスは移行できません。

  • 移行可能なサーバを停止および起動するために、手動による移行プロセスに関係する各マシン上のノード マネージャを呼び出す。

  • 通常の停止時にサーバ インスタンスを停止するために、クラスタのメンバーをホストする各マシン上のノード マネージャを呼び出す。この動作は、サーバの移行性の前提条件です。ノード マネージャを使用せずにサーバ インスタンスを直接停止した場合、クラスタ マスターは、そのサーバ インスタンスが実行されていないことを検出したときに、ノード マネージャを呼び出してそのサーバ インスタンスを再起動します。

さらに管理サーバには、管理者によって発行されたコンフィグレーションの更新の保持、ドメインの実行時情報の表示などの、ドメイン内の移行可能なサーバも含めた通常のドメイン管理機能があります。

クラスタでの移行可能なサーバの動作

移行可能なサーバとは、移行可能としてコンフィグレーションされている、クラスタ化された管理対象サーバのことです。以下に、移行可能なサーバの主要な動作を示します。

  • データベースを使用してリース情報を管理する場合は、ノード マネージャによる起動時および再起動時にリース テーブルに行を追加する。移行可能なサーバの行には、タイムスタンプや、それが実行されているマシン名が格納されます。

    リースの詳細については、「リース」を参照してください。

  • データベースを使用してリース情報を管理する場合は、起動の結果としてデータベースに行を追加するときに、クラスタ マスターの役割を引き受けようとし、自身がクラスタに参加した最初のサーバ インスタンスである場合にクラスタ マスターとなる。

  • リース テーブルのタイムスタンプを更新することで、「リース」を定期的に更新する。

    デフォルトでは、移行可能なサーバは 30,000 ミリ秒ごとにリースを更新します。このデフォルト値は、以下の 2 つのコンフィグレーション可能な ServerMBean プロパティ値を掛け合わせた値です。

    • HealthCheckIntervalMillis (デフォルトは 10,000)

    • HealthCheckPeriodsUntilFencing (デフォルトは 3)

  • リース テーブルにアクセスできず、期限切れになる前にリースを更新できなかった場合は、Java System.exit を使用して、自身をできるだけ迅速に終了する。この場合、リース テーブルにはそのサーバ インスタンスの行が引き続き格納されます。この動作と自動移行の関連については、「サーバ全体の移行におけるクラスタ マスターの役割」を参照してください。

  • 動作時に、クラスタ マスターからのハートビートをリスンする。クラスタ マスターがハートビートを送信していないことを検出すると、移行可能なサーバはクラスタ マスターの役割を引き受けようとし、他のサーバ インスタンスがクラスタ マスターになることを要求していない場合にクラスタ マスターとなります。

サーバ全体の移行におけるノード マネージャの役割

ノード マネージャの使用は、サーバの移行に不可欠です。ホストとなる (またはホストとなる予定の) 各マシン上で実行されなければなりません。

ノード マネージャは、以下のようにサーバの移行を支援します。

  • 移行可能なサーバの最初の起動には、ノード マネージャを使用する必要がある。

    Administration Console から管理対象サーバの起動を開始すると、管理サーバがノード マネージャを使用してそのサーバ インスタンスを起動します。ノード マネージャを呼び出して、スタンドアロンのノード マネージャ クライアントを使用してサーバ インスタンスを起動することもできます。ただし、起動する管理対象サーバが自身のコンフィグレーションを取得するために管理サーバが使用可能になっていなければなりません。


    注意 :

    最初にノード マネージャによって起動されていないサーバ インスタンスの移行は失敗します。

  • 移行可能なサーバの中断、停止、または強制停止には、ノード マネージャを使用する必要がある。

  • ノード マネージャは、リースが期限切れになっている移行可能なサーバを障害の発生時に実行されていたマシン上で再起動しようとする。

    ノード マネージャは、サーバの起動、再起動、停止、IP アドレスの移行、およびディスクのマウントとアンマウントを行う、WebLogic Server に付属のカスタマイズ可能なシェル スクリプトを実行することでサーバの移行プロセスの手順を実行します。これらのスクリプトは、Solaris および Linux で使用できます。

    • 自動移行では、クラスタ マスターがノード マネージャを呼び出して移行を実行する。

    • 手動による移行では、管理サーバがノード マネージャを呼び出して移行を実行する。

サーバ全体の移行におけるクラスタ マスターの役割

移行可能なサーバを含むクラスタでは、1 つのサーバ インスタンスがクラスタ マスターとして機能します。クラスタ マスターは、サーバの移行プロセスを調整する役割を担います。クラスタ内のどのサーバ インスタンスもクラスタ マスターになることができます。移行可能なサーバを含むクラスタの起動時に、クラスタに参加した最初のサーバがクラスタ マスターになり、クラスタ マネージャ サービスを起動します。クラスタに移行可能なサーバが 1 つも含まれない場合はクラスタ マスターは不要です。クラスタ マスター サービスは起動されません。クラスタ マスターが存在しなくても、移行可能なサーバは動作を継続できますが、サーバの移行はできません。以下に、クラスタ マスターの主要な機能を示します。

  • クラスタ内の他のサーバに定期的なハートビートを発行する。

  • 定期的にリース テーブルを読み込み、移行可能なサーバのそれぞれに現在のリースがあることを確認する。期限切れになったリースによって、クラスタ マスターはその移行可能なサーバを再起動する必要があると認識します。

  • 移行可能なサーバのリースが期限切れになっていると判断するときには、ClusterMBean の FencingGracePeriodMillis で指定された期間、待機する。その後、リースが期限切れになっている移行可能なサーバをホストするマシン上でノード マネージャ プロセスを呼び出してその移行可能なサーバを再起動しようとします。

  • リースが期限切れになっている移行可能なサーバを再起動できない場合、クラスタ マスターは以下の方法で対象マシンを選択する。

  • 移行可能なサーバの優先送り先マシンのリストが作成されている場合は、リストでのマシンの並び順に従ってリストからマシンを選択する。

  • それ以外の場合は、クラスタ内の移行可能なサーバのホストとして使用できるようにコンフィグレーションされているマシンのリストからマシンを選択する。

    移行可能なサーバをホストできるマシンのリストは、2 つのレベル (クラスタ全体用と個々の移行可能なサーバ用) でコンフィグレーションできます。両方のレベルのマシン リストを定義できます。少なくとも一方のレベルのマシン リストを定義する必要があります。

  • 新しいマシンへのサーバ インスタンスの移行を実行するために、対象マシン上でノード マネージャ プロセスを呼び出してサーバ インスタンスのプロセスを作成する。

    移行の実行に必要な時間は、サーバのコンフィグレーションおよび起動時間によって異なります。

  • クラスタ マスターが移行可能なサーバを再起動するのにかかる最大時間は、(HealthCheckPeriodsUntilFencing * HealthCheckIntervalMillis) + FencingGracePeriodMillis。

  • サーバがクライアント リクエストに対して使用可能になるまでの合計時間は、サーバの起動時間およびアプリケーションのデプロイメント時間によって異なる。

  戻る
戻る 		 次へ
次へ
  目次
目次