| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3クラスタの管理 12c (12.1.3) E56248-06 |
|
 前 |
 次 |
この章では、WebLogic Server 12.1.3でサポートされている様々な移行メカニズムについて説明します。
この章の内容は次のとおりです。
これらの項では、サーバーで障害が発生した場合にサーバー全体を移行する方法について重点的に説明します。サーバー全体の移行では、移行可能サーバー・インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。WebLogic Serverでは、サービス・レベルの移行や、アプリケーション・レベルでのレプリケーションおよびフェイルオーバーもサポートされています。詳細は、第8章「サービスの移行」および第6章「クラスタのフェイルオーバーとレプリケーション」を参照してください。
WebLogic Serverクラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバー・インスタンスに均一にデプロイされます。これにより、サーバー・インスタンス間の透過的なフェイルオーバーが可能になります。対照的に、JMSやJTAトランザクション・リカバリ・システムなどの「固定サービス」はクラスタ内の個々のサーバー・インスタンスがターゲットとなります - これらのサービスについては、WebLogic Serverでは、フェイルオーバーではなく移行による障害リカバリがサポートされています。
WebLogic Serverでの移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたサーバー・インスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスです。サーバー全体の移行の場合は、障害が発生すると、サーバー・インスタンスが物理的に別のマシンに移行されます。サービス・レベルの移行の場合は、サービスをクラスタ内の別のサーバー・インスタンスに移動します。第8章「サービスの移行」を参照してください。
JMSおよびJTAトランザクション・システムの可用性を高めるために、WebLogic Serverでは移行可能サーバーが用意されています。移行可能なサーバーは、サービス・レベルではなくサーバー・レベルで、自動と手動のどちらでも移行できます。
移行可能サーバーがハング、ネットワーク接続の消失、ホスト・マシンの障害などにより使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能サーバーは、可能であれば同じマシン上で自動的に再起動されます。障害が発生した同じマシン上で再起動できないときは、別のマシンに移行されます。また、管理者は手動でサーバー・インスタンスの移行を開始することもできます。
サービスおよびサーバーの移行では、次の用語を使用します。
移行可能サーバー - ホストするすべてのサービスとともにそのまま全部移行する、クラスタ化サーバー・インスタンスのことです。移行可能なサーバーは、JMSサーバーやJTAトランザクション・リカバリ・サーバーなどの固定サービスをホストすることを目的としたものですが、クラスタ化可能なサービスもホストできます。移行可能サーバー上で実行されるすべてのサービスには高可用性が備わっています。
サーバー全体の移行 - 障害が発生すると、WebLogic Serverインスタンスは手動または自動で、物理的に別のマシンに移行されます。
サーバーの移行:
サービスの手動移行 - サービスをホストするサーバー・インスタンスがエラーになった後、JTAやJMS関連の固定サービス(JMSサーバー、SAFエージェント、パス・サービスおよびカスタム・ストアなど)の手動移行のことです。第8章「サービスの移行」を参照してください。
サービスの自動移行 - JMS関連サービス、シングルトン・サービスおよびJTAトランザクション・リカバリ・サービスは、メンバー・サーバー・インスタンスで障害が発生したり再起動されたときに、別のメンバー・サーバー・インスタンスに自動的に移行するよう構成できます。第8章「サービスの移行」を参照してください。
クラスタ・リーダー - クラスタ内の過半数のサーバー・インスタンスによって選択される1つのサーバーです。このサーバー・インスタンスは、リース情報を保持します。「コンセンサス(非データベース)リース」を参照してください。
クラスタ・マスター - 移行可能サーバーを含むクラスタ内の1つのサーバー・インスタンスがクラスタ・マスターとして機能し、障害の発生時にサーバーの自動移行プロセスを調整します。固定サービスのホストであるかどうかに関係なく、クラスタ内のどの管理対象サーバーもクラスタ・マスターになることができます。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。
シングルトン・マスター - 自動移行可能な他のサービスをモニターする軽量シングルトン・サービスです。その時点でシングルトン・マスターをホストしているサーバー・インスタンスは、各移行可能サービスに関連付けられた移行タスクを開始および停止する役割を担います。「シングルトン・マスター」を参照してください。
候補マシン - クラスタ内で移行先のターゲットになる可能性のあるマシンのユーザー定義リストです。
ターゲット・マシン - 移行可能サーバーの優先ホストとして指定されている一連のマシンです。
ノード・マネージャ - 管理サーバーやスタンドアロンのノード・マネージャ・クライアントが使用するWebLogicサーバーのユーティリティで、移行可能なサーバーを起動または停止します。ノード・マネージャはクラスタ・マスターによって起動され、必要に応じて、移行可能なサーバーを停止または再起動します。ノード・マネージャの基本的な情報およびノード・マネージャが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の移行および別のマシンでのサーバーの再起動のために必要となります。つまり、コンセンサス・リースの場合は、追加の要件がないうえに、負荷の高い要件を排除できます。
このタイプのリースでは、リース情報を高可用性データベースの表内に保持します。サーバー・インスタンスがリース情報を常に利用できるようにするため、可用性の高いデータベースが必要になります。リース情報にアクセスし、リースを更新するために、クラスタの各メンバーがデータベースに接続できる必要があります。データベースが使用不能になり、リースを更新できなくなると、サーバー・インスタンスでは障害が発生します。
このリース方法は、クラスタ環境にすでに高可用性データベースが存在する場合に便利です。このメソッドにより、ノード・マネージャを必要としないリース機能を使用して、環境内のサーバー・インスタンスを管理できます。
次の手順は、リース用のデータベースを構成するために必要なステップの概要を示しています。
サーバーの移行用にデータベースを構成します。データベースには、サーバー・インスタンスが実行中であるかどうか、サーバーを移行する必要があるかどうかを決定するために使用されるリース情報が格納されます。
データベースには信頼性がある必要があります。サーバー・インスタンスは唯一信頼性のあるデータベースです。試験的な目的で使用する場合は、通常のデータベースで十分です。本番環境では、高可用性データベースのみ使用することをお薦めします。データベースが停止すると、すべての移行可能サーバーが停止します。
データベース内にリース表を作成します。この表は、サーバーの移行を可能にするためのマシンとサーバーの関連付けの格納に使用されます。この表のスキーマは、WL_HOME/server/db/dbname/leasing.ddlにあります。ここで、dbnameはデータベース・ベンダーの名前です。
|
注意: リース表は高可用性データベースに格納する必要があります。移行可能サーバーの信頼性は、リース表の格納に使用されるデータベースの信頼性で決まります。 |
データ・ソースを設定し、構成します。このデータ・ソースは、前の手順で構成したデータベースを指している必要があります。
|
注意: サーバーの移行では、XAデータ・ソースはサポートされていません。 |
JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。
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.>
Oracle Grid Infrastructureインストレーション・ガイドのクラスタの時間同期の構成に関する項を参照してください。
|
注意: コンセンサス・リースでは、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを管理する必要があります。障害が発生した移行可能サーバーの候補マシンを含め、クラスタ内の管理対象サーバーをホストしているすべてのマシンで、ノード・マネージャが実行されている必要があります。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。 |
コンセンサス・リースは可用性の高いデータベースを必要としません。クラスタ・リーダーは、メモリー内にリースを保持します。すべてのサーバー・インスタンスがクラスタ・リーダーに接続することでリースを更新しますが、フェイルオーバーの場合は、リース表がクラスタの別のノードにレプリケートされます。
クラスタ・リーダーは、クラスタ内のすべての実行中のサーバー・インスタンスによって選出されます。サーバー・インスタンスは、過半数のサーバー・インスタンスから承認を受けた場合のみ、クラスタ・リーダーになります。ノード・マネージャがあるサーバー・インスタンスを停止として報告した場合、クラスタ・リーダーは、過半数のサーバー・インスタンスを数えると、このサーバー・インスタンスがリーダーとしてその報告を承認したと見なします。
コンセンサス・リースは、過半数のサーバー・インスタンスが機能し続けることを必要とします。ネットワークがパーティション化されている場合、多数派のパーティションに含まれるサーバー・インスタンスは継続して実行されますが、少数派のパーティションに含まれるサーバー・インスタンスは、クラスタ・リーダーと通信できないか、サーバー・インスタンスの過半数が得られず新しいクラスタ・リーダーを選出できないために、自主的に停止します。パーティション化の結果サーバー・インスタンスが同数に分割されている場合は、クラスタ・リーダーを含むパーティションのサーバー・インスタンスは継続して実行されますが、もう一方のパーティションのサーバー・インスタンスは失敗します。コンセンサス・リーシングは、到達可能なサーバー・インスタンスの過半数の一部としてカウントするため、ノード・マネージャと通信してそれが管理するサーバー・インスタンスのステータスを受信する機能に依存します。ネットワーク接続が失われたか、ハードウェアの障害のため、ノード・マネージャに接続できない場合、管理対象のサーバー・インスタンスは、たとえ実行されていても、過半数を構成するサーバーとしてカウントされません。
|
注意: クラスタに含まれるサーバー・インスタンスが2つのみである場合、多数派のパーティションがクラスタ・リーダーになります(ネットワーク分割が発生した場合)。クラスタ・リーダーが失敗すると、正常に実行されているサーバー・インスタンスは、ノード・マネージャを通じてそのステータスを確認しようとします。正常に実行されているサーバー・インスタンスが、失敗したクラスタ・リーダーのステータスを特定できる場合、クラスタ・リーダーのロールを引き受けます。マシンの障害またはネットワーク分割のため、正常に実行されているサーバー・インスタンスがクラスタ・リーダーのステータスを確認できない場合、自身が多数派であると確信が持てないため、自主的に停止します。このようなシナリオを避けるため、最低でも、別のマシン上で実行されている3つのサーバー・インスタンスの使用をお薦めします。 |
サーバーの自動移行が有効化されている場合、サーバー・インスタンスはクラスタ・リーダーと通信して定期的にリースを更新する必要があります。リースを更新できなかった場合、サーバー・インスタンスは自らを停止します。次に、不具合のあるサーバー・インスタンスは、多数派のパーティションに含まれるマシンに自動的に移行されます。
この項では、サーバー全体の自動移行を構成する手順の概略を示し、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に対して同じ機能がサポートされていることを確認してください。
サーバー全体の自動移行では、IPの移行および別のマシンでのサーバーの再起動のために、ノード・マネージャが構成されて実行している必要があります。
移行可能サーバーで使用するプライマリ・インタフェース名が同じです。環境内で異なるインタフェース名を使用しなければならない場合は、移行可能サーバーごとに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使用率が影響されることに注意してください。1つのマシンが同時に一定数のサーバー・インスタンスの同時実行を処理できるという理由で、同じマシンが同数のサーバー・インスタンスの同時起動を処理できると見なすことはできません。
サーバーの移行を構成する前に、お使いの環境が「サーバー全体の自動移行の準備」で説明されている要件を満たしていることを確認してください。
クラスタ内の管理対象サーバーに対してサーバーの移行を構成するには、次のタスクを実行します。
移行を有効にする各管理対象サーバーの浮動IPアドレスを取得します。
移行可能サーバーには、それぞれ浮動IPアドレスを割り当てる必要があります。このIPアドレスは、物理的なマシンが変わってもサーバー・インスタンスを追跡します。浮動IPアドレスが割り当てられるすべてのサーバー・インスタンスでは、AutoMigrationEnabledをtrueに設定することも必要です。
|
注意: 移行可能なIPアドレスは、移行可能サーバーが起動されるまではどの候補マシンのインタフェースでも提示されないようにします。 |
ノード・マネージャを構成します。ノード・マネージャは実行中でなければなりません。また、サーバーの移行を許可するように構成されている必要があります。
Javaバージョンのノード・マネージャはWindowsまたはUNIXでのサーバー移行に使用できます。スクリプトベースのバージョンのノード・マネージャはUNIXでのサーバー移行にのみ使用できます。
Javaベースのノード・マネージャを使用する際には、nodemanager.propertiesを編集してInterface値とNetMask値を使用環境に追加する必要があります。
環境に最適なInterface値を決定するには、オペレーティング・システム・ユーティリティを使用して、マシンで使用できるネットワーク・インタフェースのリストを検索します。Unixプラットフォームでは、通常ifconfigコマンドです。Windowsプラットフォームでは、通常ipconfigコマンドです。
NetMaskを決定するには、同じサブネット上ですべてのトラフィックを発生させるために、その同じインタフェースのアドレスに対してすでに構成されている同じNetMask値を使用できます。また、共通のNetMask値を指定することもできるため、すべてのWebLogic Serverトラフィックに対するサブネットを指定できます。
nodemanager.propertiesファイルは、NodeManagerHomeで指定されるディレクトリ(通常ORACLE_HOME\user_projects\domains\domain_name\nodemanagerまたはORACLE_HOME\oracle_common\common\nodemanager)に格納されています。nodemanager.propertiesの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のnodemanager.propertiesの検討に関する項を参照してください。
スクリプトベースのバージョンのノード・マネージャを使用する場合は、wlscontrol.shを編集して、Interface変数をネットワーク・インタフェースの名前に設定します。
サーバーの移行でのノード・マネージャの使用に関する一般的な情報は、「サーバー全体の移行におけるノード・マネージャの役割」を参照してください。ノード・マネージャに関する一般的な情報は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。
データベースを使用してリース情報を管理する場合は、「高可用性データベース・リース」の手順に従って、サーバーの移行に使用するデータベースを構成します。リースの全般的な情報については、「リース」を参照してください。
データベース・リースをテスト環境内で使用しており、リース表をリセットする必要がある場合は、leasing.ddlスクリプトを再実行する必要があります。リセットによって、適切な表が削除されて再作成されます。
データベースを使用してリース情報を格納する場合は、「高可用性データベース・リース」の手順に従って、データ・ソースを設定して構成します。
各クラスタの構成で、DataSourceForAutomaticMigrationをこのデータ・ソースに設定してください。
|
注意: サーバーの移行では、XAデータ・ソースはサポートされていません。 |
JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。
wlsifconfig.shスクリプト(UNIX)またはwlsifconfig.cmdスクリプト(Windows)にスーパーユーザー権限を付与します。
このスクリプトは移行中、IPアドレスを一つのマシンから別のマシンへ転送するとき使用されます。通常スーパーユーザーのみが利用可能なifconfigの実行が可能でなければなりません。sudoを使用して起動されるように、このスクリプトを編集できます。
Javaベースのノード・マネージャはwlsifconfig.cmdスクリプトを使用します。このスクリプトではnetshユーティリティが使用されます。
wlsifconfigスクリプトは、WL_HOME/common/binディレクトリまたはDOMAIN_HOME/bin/server_migrationディレクトリにあります。
次のコマンドが使用するマシンのPATHに含まれていることを確認してください。
wlsifconfig.sh (UNIX)またはwlsifconfig.cmd (Windows)
wlscontrol.sh (UNIX)
nodemanager.domains
wlsifconfig.shファイル、wlsifconfig.cmdファイルおよびwlscontrol.shファイルは、WL_HOME/common/binまたはDOMAIN_HOME/bin/server_migrationにあります。nodemanager.domainsファイルは、NodeManagerHomeで指定されているディレクトリにあります。Javaベースのノード・マネージャの場合、NodeManagerHomeは通常ORACLE_HOME\user_projects\domains\domain_name\nodemanagerまたはORACLE_HOME\oracle_common\common\nodemanagerにあります。スクリプト・ベースのノード・マネージャの場合、このファイルのデフォルトのNodeManagerHomeの場所は、WL_HOME/common/nodemanagerです。ここで、WL_HOMEはWebLogic Serverがインストールされている場所(ORACLE_HOME/wlserverなど)です。
.shスクリプトの最初の行は、UNIXで使用するデフォルトのシェルに応じて編集する必要があります。
この手順は、スクリプトベースのバージョンのノード・マネージャとUNIXにのみ適用されます。Windowsを使用している場合は、ステップ9に進んでください。
移行可能サーバーをホストするマシンは相互に信頼性がある必要があります。移行が行われるためには、ユーザー名とパスワードを明示的に入力する必要なしに、マシン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に示されているように、クラスタの起動時には、次の主要なステップが発生します。
管理者がクラスタを起動します。
管理サーバーが、管理対象サーバー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では、動的クラスタおよび複合クラスタでのサーバー全体の移行がサポートされています。動的クラスタ内の動的サーバーで障害が発生すると、構成済クラスタまたは複合クラスタ内で構成済のサーバーと同じように、サーバー・インスタンスが別の物理マシンへ移行されます。クラスタの種類に応じて構成は異なりますが、サーバー全体の移行の動作はすべてのクラスタで同じです。動的クラスタおよび複合クラスタに関する詳細は、第11章「動的クラスタ」を参照してください。
サーバー全体の自動移行ではリースを使用して、クラスタ・マスターが選出されます。クラスタ・マスターは、別のクラスタ・メンバーのモニターおよび別の物理マシンでホストされるメンバーに障害が発生した場合の再起動を担当します。クラスタ構成でリースを構成します。詳細は、「リース」を参照してください。
構成済クラスタに対してサーバー全体の自動移行を構成する際には、移行できるようにするサーバー・インスタンスを個別に選択します。障害発生時にサーバー・インスタンスを移行するために使用可能なマシンのサブセットも選択します。
動的クラスタでは、サーバー・テンプレートでサーバー全体の自動移行を有効または無効にします。動的クラスタは、単一のサーバー・テンプレートを使用してその構成を定義し、動的クラスタ内のすべての動的サーバー・インスタンスがテンプレートの構成を継承します。動的クラスタのサーバー・テンプレート内でサーバー全体の自動移行が有効な場合、そのサーバー・テンプレートに基づいたすべての動的サーバー・インスタンスがサーバー全体の自動移行に対して有効になります。動的サーバー・インスタンスを個別に選択して移行することはできません。
また、移行先のマシンは選択できません。サーバー・テンプレートで動的クラスタに対してサーバー全体の自動移行を有効化すると、移行のために使用できるすべてのマシンが自動的に選択されます。
サーバー・テンプレートで候補マシンがリストされていないため、動的クラスタが指定する移行の候補マシンのリストを制限することはできません。各動的サーバーに対する候補マシンのリストは、次のように計算されます。
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管理コンソールの左ペインで、「環境」→「クラスタ」→「サーバー・テンプレート」の順に選択します。
「サーバー・テンプレート」表で、動的クラスタのサーバー・テンプレートを選択します。
「構成」→「移行」の順に選択します。
「サーバーの自動移行を有効化」属性を選択します。
