7 サーバー全体の移行

この章では、WebLogic Serverでサポートされている様々な移行メカニズムについて説明します。

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

• 移行関連の用語

• リース

• サーバー全体の自動移行

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

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

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

注意: サーバー全体の移行はすべてのプラットフォームでサポートされているわけではありません。Oracle WebLogic Server、WebLogic PortalおよびWebLogic Integration 10gR3 (10.3)のサーバー移行のサポートに関する情報を参照してください。

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

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

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

移行関連の用語

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

• 移行可能サーバー - ホストするすべてのサービスとともにそのまま全部移行する、クラスタ化サーバー・インスタンスのことです。移行可能サーバーは、JMSサーバーやJTAトランザクション・リカバリ・サーバーなどの固定サービスをホストすることを目的としたものですが、クラスタリング可能なサービスもホストできます。移行可能サーバー上で実行されるすべてのサービスには高可用性が備わっています。

• サーバー全体の移行 - 障害が発生すると、WebLogic Serverインスタンスは手動または自動で、物理的に別のマシンに移行されます。

• サーバーの移行:

  • サービスの手動移行 - サービスをホストするサーバー・インスタンスがエラーになった後、JTAやJMS関連の固定サービス(JMSサーバー、SAFエージェント、パス・サービスおよびカスタム・ストアなど)の手動移行のことです。第8章「サービスの移行」を参照してください。

  • サービスの自動移行 - JMS関連サービス、シングルトン・サービス、JTAトランザクション・リカバリ・サービスは、メンバー・サーバーが失敗するか再起動したときに、別のメンバー・サーバーに自動的に移行されるように構成できます。第8章「サービスの移行」を参照してください。

• クラスタ・リーダー - クラスタ内の多数のサーバーによって選択される1つのサーバーです。このサーバーは、リース情報を保持します。「コンセンサス(非データベース)リース」を参照してください。

• クラスタ・マスター - 移行可能サーバーを含むクラスタ内の1つのサーバー・インスタンスがクラスタ・マスターとして機能し、障害の発生時にサーバーの自動移行プロセスを調整します。固定サービスのホストであるかどうかに関係なく、クラスタ内のどの管理対象サーバーもクラスタ・マスターになることができます。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。

• シングルトン・マスター - 自動移行可能な他のサービスをモニターする軽量シングルトン・サービスです。その時点でシングルトン・マスターをホストしているサーバーは、各移行可能サービスに関連付けられた移行タスクを開始および停止する役割を担います。「シングルトン・マスター」を参照してください。

• 候補マシン - クラスタ内で移行先のターゲットになる可能性のあるマシンのユーザー定義リストです。

• ターゲット・マシン - 移行可能サーバーの優先ホストとして指定されている一連のマシンです。

• ノード・マネージャ - 移行可能サーバーを起動および停止するために管理サーバーまたはスタンドアロンのノード・マネージャ・クライアントによって使用されるWebLogic Serverユーティリティです。また、必要に応じて、移行可能サーバーを停止および再起動するためにクラスタ・マスターによって呼び出されます。ノード・マネージャの基本的な情報およびノード・マネージャがWebLogic Server環境に組み込まれる方法は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの一般的な構成に関する項を参照してください。

• リース表 - 移行可能サーバーがそれぞれの状態を維持するデータベース表です。クラスタのマスターはこのデータベース表をモニターして、移行可能サーバーの状態とそれらが使用可能かどうかを確認します。リースの詳細は、「リース」を参照してください。

• 管理サーバー - 移行可能サーバーとターゲット・マシンの構成、移行可能サーバーの実行時状態の取得、および手動による移行プロセスの調整に使用します。

• 浮動IPアドレス - ある物理的マシンから別の物理的マシンへの移行後もサーバーを追跡するIPアドレスです。

リース

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

リースを使用する機能

リースは、次のWebLogicサーバー機能で使用されます。

• サーバー全体の自動移行 - クラスタ・マスターを選択するためにリースを使用します。クラスタ・マスターはクラスタの他のメンバーを監視します。また、別の物理マシンでホストされたメンバーで障害が発生したときに、そのメンバーを再起動します。

  リースを使用することで、クラスタ・マスターが常に実行されており、しかもクラスタ内のいずれか1つのサーバーでのみ実行されていることが保証されます。クラスタ・マスターの詳細は、「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。

• サービスの自動移行 - JMS関連サービス、シングルトン・サービス、およびJTAトランザクション・リカバリ・サービスは、ヘルス・モニタリング・サブシステムを使用することで、異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されるように構成できます。移行可能ターゲットを移行すると、そのターゲットにホストされている固定サービスも移行されます。移行可能ターゲットでは、リースを使用してサービスの自動移行を実現しています。第8章「サービスの移行」を参照してください。

• シングルトン・サービス - クラスタ内の複数のメンバーで同時に実行できないサービスです。この条件を満たすために、シングルトン・サービスではリースを使用します。「シングルトン・マスター」を参照してください。

• ジョブ・スケジューラ - クラスタ内で使用する永続タイマーです。ジョブ・スケジューラでは、タイマー・マスターを使用して、クラスタ間でのタイマーのロード・バランシングを行います。

  ジョブ・スケジューラでは、非データベース・バージョン(コンセンサス・リース)を使用できますが、その場合はフェイルオーバーやレプリケーションの情報を保持するための外部データベースが必要になります。

  
  

  注意: リース機能のほとんどは、基本的な構成の及ばない場所で、WebLogic Serverにより内部的に処理されます。

  
  

リースの種類

WebLogic Serverでは、2種類のリース機能を提供します。どの機能を使用するかは、要件および環境によって決まります。

• 高可用性データベース・リース - このバージョンのリースは、リース情報を格納するために高可用性データベースを必要とします。一般的な要件と構成は、「高可用性データベース・リース」を参照してください。

• 非データベースのコンセンサス・リース - リース情報をクラスタ・メンバーのメモリー内に格納するリースです。このリースは、ノード・マネージャがクラスタ内のすべてのサーバーを起動することを必要とします。「非データベースのコンセンサス・リース」を参照してください。

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

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

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

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

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

  データベース・リースは、JMSストアのリカバリなどの機能を使用するためにOracle RACのような高可用性データベースがすでにある環境では有用です。最小限の追加の構成を行って、高可用性データベース・インスタンスがリースをサポートするように構成できます。これは、ノード・マネージャがシステムで実行されていない場合に、特に便利です。

• 非データベースのコンセンサス・リース

  このタイプのリースは、高可用性データベースを必要としないリースの選択肢(コンセンサス)を提供します。これは、サーバー全体の自動移行の場合に便利です。高可用性データベースを必要としないため、コンセンサス・リースでは、サーバーの自動移行を実行するために必要な構成が少なくなります。

  コンセンサス・リースでは、ノード・マネージャを構成して実行する必要があります。ノード・マネージャは、サーバー全体の自動移行においてもIPの移行および別のマシンでのサーバーの再起動のため必要になります。つまり、コンセンサス・リースの場合は、追加の要件がないうえに、負荷の高い要件を排除できます。

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

このタイプのリースでは、リース情報を高可用性データベースの表内に保持します。サーバーがリース情報を常に利用できるようにするため、可用性の高いデータベースが必要になります。リース情報にアクセスし、リースを更新するために、クラスタの各メンバーがデータベースに接続できる必要があります。データベースにアクセスできなかった場合は、サーバーで障害が発生し、リースを更新できなくなります。

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

次の手順は、リース用のデータベースを構成するために必要なステップの概要を示しています。

1. サーバーの移行用にデータベースを構成します。データベースには、サーバーが実行中であるかどうか、サーバーを移行する必要があるかどうかを決定するために使用されるリース情報が格納されます。

   データベースには信頼性がある必要があります。サーバー・インスタンスは唯一信頼性のあるデータベースです。試験的な目的で使用する場合は、通常のデータベースで十分です。本番環境では、高可用性データベースのみ使用することをお薦めします。データベースが停止すると、すべての移行可能サーバーが停止します。

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

   
   

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

   
   

2. データ・ソースを設定し、構成します。このデータ・ソースは、前の手順で構成したデータベースを指している必要があります。

   
   

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

   
   

   JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCの構成と管理』のJDBCデータ・ソースの構成に関する項を参照してください。

非データベースのコンセンサス・リース

注意: コンセンサス・リースでは、ノード・マネージャを使用してクラスタ内のサーバーを管理する必要があります。ノード・マネージャは、クラスタ内の管理対象サーバーをホストするすべてのマシンで実行されている必要があります。詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

コンセンサス・リースは可用性の高いデータベースを必要としません。クラスタ・リーダーは、メモリー内にリースを保持します。すべてのサーバーがクラスタ・リーダーに接続してリースを更新しますが、フェイルオーバーの場合は、リース表がクラスタの別のノードにレプリケートされます。

クラスタ・リーダーは、クラスタ内のすべての実行中のサーバーによって選出されます。サーバーは、過半数のサーバーから承認を受けた場合のみ、クラスタ・リーダーになります。あるサーバーが停止していることがノード・マネージャによって報告された場合、クラスタ・リーダーは、そのサーバーがリーダーとして受け入れたものと見なして過半数の判断を行います。

コンセンサス・リースは、過半数のサーバーが機能し続けることを必要とします。ネットワークがパーティション化されている場合、多数派のパーティションに含まれるサーバーは継続して実行されますが、少数派のパーティションに含まれるサーバーは、クラスタ・リーダーと通信できないか、または、サーバーの過半数が得られず新しいクラスタ・リーダーを選出できないために、失敗します。パーティション化の結果サーバーが同数に分割されている場合は、クラスタ・リーダーを含むパーティションのサーバーは継続して実行されますが、もう一方のパーティションのサーバーは失敗します。

サーバーの自動移行が有効化されている場合、サーバーはクラスタ・リーダーとコンタクトをとって定期的にリースを更新する必要があります。リースを更新できなかった場合、サーバーは自らを停止します。次に、失敗したサーバーは、多数派のパーティションに含まれるマシンに自動的に移行されます。

サーバー全体の自動移行

この項では、サーバー全体の自動移行を構成する手順の概略を示し、WebLogic Server環境内でサーバー全体の移行機能をどのように使用するかについて説明します。

次のトピックを扱います。

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

• サーバー全体の自動移行の構成

• 状態データ用高可用性ストレージの使用

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

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

サーバー全体の自動移行を構成する前に、次の要件について確認します。

• 使用するプラットフォームでサーバー全体の移行がサポートされていることを確認します。Oracle WebLogic Server、 WebLogic Portal および WebLogic Integration 10gR3 (10.3)のサーバー移行のサポートに関する情報を参照してください。

  
  

  警告: Solarisゾーン機能を使用してSolaris 10システムでのサーバー全体の自動移行のサポートは、http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.htmlの注意3:「Sun Solaris 10のマルチ・ゾーン操作におけるサポート」を参照してください。

  
  

• 各管理対象サーバーで、同じサブネット・マスクを使用します。サーバー間のユニキャスト通信およびマルチキャスト通信では、各サーバーが同じサブネットを使用している必要があります。マルチキャスト通信またはユニキャスト通信を構成しないと、サーバーの移行は機能しません。

  マルチキャストの詳細は、「下位互換性の維持を目的としたIPマルチキャストの使用」を参照してください。ユニキャストの詳細は、「ユニキャストを使用した1対多通信」を参照してください。

• 移行可能サーバーをホストするすべてのサーバーの時刻が同期しています。移行はサーバーの時刻が同期していない場合でも機能しますが、クラスタ化された環境ではサーバーの時刻を同期させておくことをお薦めします。

• 移行可能サーバー間でオペレーティング・システムのバージョンが異なる場合は、すべてのバージョンでifconfigに対して同じ機能がサポートされている必要があります。

• 移行可能サーバーで使用するプライマリ・インタフェース名が同じです。環境内で異なるインタフェース名を使用しなければならない場合は、移行可能サーバーごとにwlscontrol.shのローカル・バージョンを構成します。

  wlscontrol.shの詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

• WebLogic Serverでサーバーの自動移行がサポートされるデータベースのリストは、Oracle WebLogic Server、WebLogic PortalおよびWebLogic Integration 10gR3 (10.3)のWebLogic Server機能をサポートするデータベースに関する情報を参照してください。

• 移行可能サーバー上には、異なるリスニング・アドレスを持つチャネルおよびネットワーク・アクセス・ポイントを作成できません。

• ファイルをマシン間で転送するための、信頼できる組込みのメカニズムはありません。ファイルの可用性を確保するには、すべてのマシンからアクセス可能なディスクを使用することをお薦めします。サーバー間でディスクを共有できない場合は、domain_dir/binの内容が各マシンにコピーされていることを確認する必要があります。

• nmEnroll() WLSTコマンドを使用して、ノード・マネージャのセキュリティ・ファイルが各マシンにコピーされていることを確認します。詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

• 状態データの格納に、高可用性ストレージを使用します。高い信頼性を実現するために、ストレージ・エリア・ネットワーク(SAN)などの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。「状態データ用高可用性ストレージの使用」を参照してください。

• 本番環境における容量を計画する時、サーバー起動によってCPU使用率が影響されることに注意してください。あるマシンが同時に実行中のX台のサーバーをサポートできるので、そのマシン上で同時に起動する同じ数のサーバーもサポートできるとはかぎりません。

サーバー全体の自動移行の構成

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

クラスタ内の管理対象サーバーに対してサーバーの移行を構成するには、次のタスクを実行します。

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 WebLogic Serverノード・マネージャ管理者ガイド』のnodemanager.propertiesの検討に関する項を参照してください。

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

   サーバーの移行でのノード・マネージャの使用に関する一般的な情報は、「サーバー全体の移行におけるノード・マネージャの役割」を参照してください。ノード・マネージャの構成に関する一般的な情報は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの一般的な構成に関する項を参照してください。

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

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

5. データベースを使用してリース情報を格納する場合は、「高可用性データベース・リース」の手順に従って、データ・ソースを設定して構成します。

   各クラスタの構成で、DataSourceForAutomaticMigrationをこのデータ・ソースに設定してください。

   
   

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

   
   

   JDBCデータ・ソースの作成の詳細は、『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. この手順は、SSHバージョンのノード・マネージャと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に示されている、クラスタの起動時に発生する主要なステップです。

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 障害が発生したサーバーの自動移行」の説明

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 サーバー全体の手動移行」の説明

1. 管理者が管理コンソールを使用して、マシン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を使用してできるだけ迅速に終了します。この場合は、リース表にはそのサーバー・インスタンス用の行が引き続き格納されます。この動作と自動移行の関連の詳細は、「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。

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

  
  

  注意: サーバー移行時に、サーバー起動によってCPU使用率が上昇することに注意してください。あるマシンが同時に実行中のX台のサーバーをサポートできるので、そのマシン上で同時に起動する同じ数のサーバーもサポートできるとはかぎりません。

  
  

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

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

ノード・マネージャは、次のようにサーバーの移行をサポートします。

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

  管理コンソールから管理対象サーバーの起動を開始すると、管理サーバーがノード・マネージャを使用してそのサーバー・インスタンスを起動します。ノード・マネージャを呼び出して、スタンドアロンのノード・マネージャ・クライアントを使用してサーバー・インスタンスを起動することもできます。ただし、起動する管理対象サーバーが自身の構成を取得するために管理サーバーが使用可能になっている必要があります。

  
  

  注意: 最初にノード・マネージャによって開始していないサーバー・インスタンスの移行は失敗します。

  
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  移行の実行に必要な時間は、サーバーの構成および起動時間によって異なります。

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

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