| Oracle® Fusion Middleware高可用性ガイド 11gリリース2(11.1.2) B69538-02 |
|
 前 |
 次 |
この章では、Oracle Fusion Middlewareの高可用性を実現するOracle WebLogic Serverの高可用性機能について説明します。
WebLogic Serverのクラスタリングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じシステム上で実行することも、複数のシステムに配置することもできます。クラスタの能力は、既存のシステム上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのシステムをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同じバージョンのWebLogic Serverが動作している必要があります。
クラスタとは、特定のWebLogic Serverドメインの一部です。ドメインとは、1つのユニットとして管理されるWebLogic Serverリソースの相互に関係するセットです。ドメインには1つ以上のWebLogic Serverインスタンスが含まれ、それらのインスタンスは、クラスタ化することもしないことも、あるいはその両方を混在させることもできます。1つのドメインに複数のクラスタを含めることができます。また、ドメインには、そのドメインにデプロイされたアプリケーション・コンポーネント、それらのアプリケーション・コンポーネントに必要なリソースとサービス、およびドメインのサーバー・インスタンスも含まれています。アプリケーションおよびサーバー・インスタンスで使用するリソースとサービスの例には、システムの定義、オプションのネットワーク・チャネル、コネクタおよび起動クラスなどがあります。
各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバー(ドメイン内のその他すべてのサーバー・インスタンスおよびリソースを構成、管理および監視するサーバー・インスタンス)として動作します。各管理サーバーは、1つのドメインのみを管理します。ドメインに複数のクラスタが含まれている場合は、ドメイン内の各クラスタは同じ管理サーバーを持つことになります。
クラスタ内のサーバー・インスタンスはすべて、同じドメイン内にある必要があります。複数のドメインにまたがってクラスタを分割することはできません。同様に、構成されたリソースやサブシステムをドメイン間で共有することはできません。たとえば、あるドメインにJDBC接続プールを作成する場合、それを別のドメインのサーバー・インスタンスやクラスタで使用することはできませんかわりに、2番目のドメインに同様の接続プールを作成する必要があります。
クラスタ化されたWebLogic Serverインスタンスは、フェイルオーバーおよびロード・バランシングが可能になること以外は、クラスタ化されていないインスタンスと同様に動作します。クラスタ化されたWebLogic Serverインスタンスを構成するために使用するプロセスおよびツールは、クラスタ化されていないインスタンスを構成するものと同じです。ただし、クラスタ化によって可能になるロード・バランシングおよびフェイルオーバーの利点を実現するには、クラスタ構成の特定のガイドラインに従う必要があります。
WebLogic Serverクラスタを利用することによってもたらされる利点には、次のものがあります。
スケーラビリティ
WebLogic Serverクラスタにデプロイされるアプリケーションの能力を、必要に応じて動的に増強することができます。サービスを中断させることなく、すなわち、クライアントおよびエンド・ユーザーへ影響を与えることなくアプリケーションの動作を維持しながら、クラスタにサーバー・インスタンスを追加できます。
高可用性
WebLogic Serverクラスタでは、サーバー・インスタンスで障害が発生してもアプリケーションの処理を継続できます。アプリケーション・コンポーネントのクラスタ化は、クラスタ内の複数のサーバー・インスタンス上にコンポーネントをデプロイすることによって行います(このため、コンポーネントが動作しているサーバー・インスタンスに障害が発生した場合、このコンポーネントがデプロイされている別のサーバー・インスタンスがアプリケーションの処理を継続できます)。
WebLogic Serverインスタンスのクラスタ化は、アプリケーション開発者およびクライアントからは意識されません。ただし、クラスタ化を可能にする技術インフラストラクチャを理解しておくことは、プログラマおよび管理者が、各自が扱うアプリケーションのスケーラビリティと可用性を最大限に高める上で役立ちます。
この項では、スケーラビリティおよび高可用性を実現するための主要なクラスタリング機能を定義します。この項の項目は次のとおりです。
フェイルオーバーとは、特定のジョブ(処理するタスクのなんらかのセット)を実行するアプリケーション・コンポーネント(以降、オブジェクトと一般的に呼びます)がなんらかの理由で使用できなくなった場合に、障害の発生したオブジェクトのコピーがジョブを終了することです。
障害の発生したオブジェクトを新しいオブジェクトが引き継げるようにするには、次の条件が必要です。
ジョブを引き継ぐために、障害の発生したオブジェクトのコピーが使用可能である必要があります。
すべてのオブジェクトの場所および操作ステータスを定義する情報が、他のオブジェクトおよびフェイルオーバーを管理するプログラムで使用できる必要があり、これによって、そのジョブが終了する前に、最初のオブジェクトに障害が発生したことが確認できます。
処理中のジョブの進捗に関する情報が、他のオブジェクトおよびフェイルオーバーを管理するプログラムで使用できる必要があり、これによって、中断されたジョブを引き継ぐオブジェクトは、最初のオブジェクトが失敗する前に完了したジョブ数を認識できます。例として、変更されたデータや、プロセスにおける完了したステップが挙げられます。
WebLogic Serverは標準ベースの通信手法および機能(IPソケットやJava Naming and Directory Interface(JNDI)など)を使用して、クラスタ内のオブジェクトの可用性に関する情報を共有および保持します。これらの手法により、ジョブを終了する前にオブジェクトが停止したこと、および中断したジョブを完了するためのオブジェクトのコピーがある場所を、WebLogic Serverで判別できます。
ジョブに対して何が実行されたかに関する情報は、状態と呼ばれています。WebLogic Serverでは、セッション・レプリケーションおよびレプリカ対応スタブと呼ばれる手法を使用して、状態の情報を保持します。オブジェクトでジョブの実行が予期せず停止すると、レプリケーション手法によって、障害の発生したオブジェクトが停止した箇所をオブジェクトのコピーで特定し、ジョブを終了できます。
WebLogic Serverでは、あるシステムから別のシステムに、クラスタ化されたサーバー・インスタンスを自動または手動で移行できます。サーバー移行処理では、事前定義された使用可能なホスト・システムのいずれかに、管理対象サーバーが(IPアドレスやホストするアプリケーションを含めて)そっくりそのまま再配置されます。この機能は、高可用性が要求される環境向けに設計されています。サーバー移行は、次の点で有用です。
シングルトン・サービス(ホストとして機能しているサーバー・インスタンスで障害が発生した場合に、常に1つのサーバー・インスタンス上でのみ実行される必要があるサービス)の、継続的な可用性の確保。障害が発生した場合、自動移行が構成されている管理対象サーバーは別のシステムに自動的に移行されます。
(計画的なシステム管理プロセスの一環として)管理対象サーバーとそれがホストするすべてのサービスの再配置プロセスの簡略化。管理コンソールまたはコマンドラインから管理対象サーバーの移行を開始します。
ロード・バランシングとは、環境内のコンピューティングおよびネットワーキング・リソース全体において、ジョブとそれに関係する通信を均等に分散することです。ロード・バランシングの要件は次となります。
特定のジョブを実行できるオブジェクトの複数のコピー。
すべてのオブジェクトの場所および操作ステータスに関する情報。
WebLogic Serverを使用すると、代替オブジェクトで同じジョブを実行できるように、オブジェクトをクラスタ化できます(複数のサーバー・インスタンスにデプロイできます)。WebLogic Serverでは、ユニキャスト、IPソケットおよびJNDIを使用して、デプロイされたオブジェクトの可用性および場所が共有および保持されます。
クラスタ化されたアプリケーションまたはアプリケーション・コンポーネントは、クラスタ内の複数のWebLogic Serverインスタンスで使用できます。オブジェクトがクラスタ化されていると、そのオブジェクトのフェイルオーバーおよびロード・バランシングが可能になります。クラスタ内のすべてのサーバー・インスタンスにオブジェクトを均一にデプロイして、クラスタの管理、保守およびトラブルシューティングを簡略化します。
Webアプリケーションは、 Enterprise Java Bean(EJB)、サーブレット、 Java Server Page(JSP)など、様々なタイプのオブジェクトで構成できます。それぞれのオブジェクト・タイプには、制御、起動、およびアプリケーション内での動作方法に関連して、一意の動作セットがあります。そのため、WebLogic Serverがクラスタリングをサポートして、ロード・バランシングおよびフェイルオーバーを実現するために使用する方法は、オブジェクトのタイプによって異なります。WebLogic Serverデプロイ時に、このようなオブジェクト・タイプをクラスタ化できます。
サーブレット
JSP
EJB
リモート・メソッド呼出し(RMI)オブジェクト
Java Messaging Service(JMS)宛先
異なるオブジェクト・タイプにおいて、一部の動作は共通になることがあります。この場合、類似のオブジェクト・タイプに関するクラスタリングのサポートおよび実装の考慮事項は、同じとなる可能性があります。次の各項では、このようなオブジェクトの説明および手順を組み合せています。
サーブレットとJSP
EJBとRMIオブジェクト
クラスタ内のWebLogic Serverインスタンスは、次の2つの基本的なネットワーク・テクノロジを使用して、相互に通信します。
IPソケット。これは、クラスタ化されたサーバー・インスタンス間のピアツーピア通信のパイプです。
IPのユニキャストまたはマルチキャスト。これらは、サービスの可用性、および継続的な可用性を示すハートビートをブロードキャストするために、サーバー・インスタンスによって使用されます。クラスタを新規作成する場合は、クラスタ内のメッセージングにユニキャストを使用することをお薦めします。以前のバージョンのWebLogic Serverとの下位互換性を保つには、クラスタ間の通信にマルチキャストを使用する必要があります。
|
注意: WebLogic Serverクラスタでユニキャスト・プロトコルを使用する場合、クラスタの一部であるサーバーでは、リスニング・アドレスを指定する必要があります。サーバーは、ANYでリスニングすることはできません(これは、管理コンソールの「リスニング・アドレス」フィールドが空白のままになっている場合と同じです)。 |
クラスタ化されていないWebLogic Serverサーバー・インスタンスのクライアントは、JNDIに準拠したネーミング・サービスを使用してオブジェクトおよびサービスにアクセスします。JNDIネーミング・サービスには、サーバー・インスタンスが提供する公開サービスのリストがツリー構造の形で含まれています。WebLogic Serverインスタンスで新しいサービスを提供するには、そのサービスを表す名前をJNDIツリーにバインドします。クライアントがそのサービスを取得するには、そのサーバー・インスタンスに接続し、バインドされたサービスの名前を検索します。
クラスタ内のサーバー・インスタンスは、クラスタワイドのJNDIツリーを利用します。クラスタワイドのJNDIツリーは、使用可能なサービスのリストをツリーが格納しているという点では、1つのサーバー・インスタンスのJNDIツリーに似ています。ただし、クラスタワイドのJNDIツリーには、ローカル・サービスの名前以外に、クラスタ内の他のサーバー上にあるクラスタ化されたオブジェクト(EJBやRMIクラス)が提供するサービスも格納されています。
クラスタ内のWebLogic Serverインスタンスはそれぞれ、クラスタワイドの論理JNDIツリーのローカル・コピーを作成して保持します。クラスタワイドのJNDIツリーを作成するには、まずローカルJNDIツリーに各サーバー・インスタンスをバインドします。サーバー・インスタンスが起動すると(または新しいサービスが、稼働中のサーバー・インスタンスに動的にデプロイされると)、まずそれらのサービスの実装がローカルJNDIツリーにバインドされます。同じ名前の他のサービスが他に存在しなければ、その実装がJNDIツリーにバインドされます。
サーバー・インスタンスでローカルJNDIツリーへのサービスのバインドに成功すると、レプリカ対応スタブを使用するクラスタ化されたオブジェクトに対して追加の手順が実行されます。クラスタ化されたオブジェクトの実装をローカルJNDIツリーにバインドした後、サーバー・インスタンスはオブジェクトのスタブをクラスタの他のメンバーに送信します。クラスタの他のメンバーは、マルチキャスト・アドレスまたはユニキャスト・アドレスを監視し、リモート・サーバー・インスタンスが新しいサービスを提供したときに検出します。
クラスタで高可用性を実現するには、サービスの障害からリカバリ可能である必要があります。クラスタ内のWebLogic Serverインスタンスは、ピア・サーバー・インスタンスの障害を検出するために次を監視します。
ピア・サーバーへのソケット接続
WebLogic Serverインスタンスは、障害を直ちに検出するために、ピア・サーバー・インスタンス間でIPソケットが使用されているかを監視します。サーバーがクラスタ内のピアのいずれかに接続し、ソケットを使用してデータ転送を始めた場合、そのソケットが突然クローズされると、ピア・サーバーが「エラー」としてマークされ、その関連サービスがJNDIネーミング・ツリーから削除されます。
定期的な サーバーのハートビート・メッセージ
クラスタ化されたサーバー・インスタンスで、ピアツーピア通信用にソケットが開いていない場合には、障害が発生したサーバーは、WebLogic Serverのハートビートを使用して検出することもできます。クラスタ内のサーバー・インスタンスはすべて、マルチキャストまたはユニキャストを使用して、定期的なサーバーのハートビート・メッセージをクラスタの他のメンバーにブロードキャストします。
それぞれのハートビート・メッセージには、メッセージの送信元サーバーを一意に識別するデータが含まれています。サーバーは、自身のハートビート・メッセージを10秒間隔でブロードキャストします。クラスタ内の各サーバーはそれを受けて、マルチキャスト・アドレスまたはユニキャスト・アドレスを監視して、すべてのピア・サーバーのハートビート・メッセージが送信されていることを確認します。
マルチキャスト・アドレスまたはユニキャスト・アドレスを監視中のサーバーにピア・サーバーからのハートビートが3回届かなかった場合(つまり、監視中のサーバーが送信元サーバーから30秒以上ハートビートを受信していない場合)には、監視側のサーバーはピア・サーバーを「エラー」としてマークします。次に、必要に応じてローカルJNDIツリーを更新して、障害が発生したサーバーでホストされていたサービスを取り消します。
ユーザーのセッション・データは、ステートフル・セッションEJBまたはHTTPセッションという標準的な2つの方法で、Java EEアプリケーションに格納できます。それらの方法自体がクラスタのスケーラビリティに影響することはほとんどありません。ただし、高可用性を実現するために必要な セッション・レプリケーション・メカニズムとともに使用すると、ボトルネックが発生します。Java EEアプリケーションにWebコンポーネントおよびEJBコンポーネントがある場合には、ユーザーのセッション・データはHTTPセッションで格納する必要があります。
HTTPセッション管理には、レプリケーション、共有データベース、ファイルなど、フェイルオーバーを処理するオプションがさらに用意されています。
スケーラビリティが優れています。
HTTPセッション状態のレプリケーションは、トランザクションの外側で実行されます。ステートフル・セッションBeanのレプリケーションは、より多くのリソースが集中するトランザクションで実行されます。
HTTPセッション・レプリケーション・メカニズムは、ステートフル・セッションBeanレプリケーションと比較すると、より洗練されていて、より多様な状況で最適化されます。
WebLogic Serverクラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバー・インスタンスに均一にデプロイされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMSやJTAトランザクション・リカバリ・システムなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにターゲット指定されます - WebLogic Serverは、これらのサービスに対して、フェイルオーバーではなく、移行による障害回復をサポートしています。
WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスです。サーバー全体の移行の場合は、障害が発生すると、サーバー・インスタンスが物理的に別のシステムに移行されます。サービスレベルの移行の場合は、サービスをクラスタ内の別のサーバー・インスタンスに移動します。WebLogic Serverには、JMSやJTAトランザクション・システムの可用性を高めるための機能(移行可能なサーバー)が用意されています。移行可能なサーバーは、サービスレベルではなく、サーバーレベルで自動または手動で移行できます。
移行可能なサーバーがなんらかの理由(ハング、ネットワークからの切断、ホスト・システムの障害など)で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバーは、可能であれば同じシステム上で自動的に再起動されます。障害が発生した同じシステム上で再起動できないときは、別のシステムに移行されます。また、管理者は手動でサーバー・インスタンスの移行を開始することもできます。
サーバー移行にはノード・マネージャが必要です。ノード・マネージャは、それをホストするか、またはホストすることを目的とした各システムで実行する必要があります。
ノード・マネージャでは、サーバーの移行が次のようにサポートされます。
移行可能なサーバーの最初の起動には、ノード・マネージャを使用する必要があります。
管理コンソールから管理対象サーバーの起動を開始すると、管理サーバーでは、サーバー・インスタンスの起動にノード・マネージャが使用されます。スタンドアロンのノード・マネージャ・クライアントを使用し、ノード・マネージャを起動してサーバー・インスタンスを開始することもできます。ただし、管理対象サーバーが管理サーバーの構成を取得できるように、管理サーバーが使用可能になっている必要があります。
|
注意: 最初にノード・マネージャで開始されていないサーバー・インスタンスは、移行できなくなります。 |
移行可能なサーバーの中断、停止、または停止の強制には、ノード・マネージャを使用する必要があります。
ノード・マネージャは、リース期間が切れた移行可能なサーバーを、障害の発生時にそのサーバーが稼働していたシステムで再起動しようとします。
ノード・マネージャは、カスタマイズ可能なシェル・スクリプトを実行して、サーバー移行処理のステップを実行します。このスクリプトはWebLogic Serverに同梱されていて、サーバーの起動、再起動および停止を行い、IPアドレスを移行し、ディスクのマウントおよびアンマウントを行うものです。このスクリプトは、Solaris版とLinux版が用意されています。
自動移行では、移行を実行するために、クラスタ・マスターによってノード・マネージャが起動されます。
手動移行では、移行を実行するために、管理サーバーによってノード・マネージャが起動されます。
次の項では、移行可能なサーバーを含むクラスタでの主要な処理について説明します。
図3-1に、移行可能なサーバーを含むクラスタの起動時に発生する処理および通信を示します。
例のクラスタには、2つの管理対象サーバーが含まれていて、どちらのサーバーも移行可能です。管理サーバーと2つの管理対象サーバーは、それぞれ異なるマシンで稼働しています。4番目のマシンは、移行可能なサーバーのいずれかに障害が発生した場合にバックアップとして使用できます。ノード・マネージャは、バックアップ・マシンおよび移行可能なサーバーが稼働している各マシンで稼働しています。
図3-1に示されているクラスタの起動時に発生する主要な手順は、次のとおりです。
管理者がクラスタを起動します。
管理サーバーがマシンBおよびCでノード・マネージャを起動し、それぞれ管理対象サーバー1および2を起動します。第3.9.2.4項「サーバー全体の移行における管理サーバーの役割」を参照してください。
各マシンのノード・マネージャは、そこで稼働する管理対象サーバーを起動します。第3.9.1項「サーバー全体の移行におけるノード・マネージャの役割」を参照してください。
管理対象サーバー1および2は、その構成を管理サーバーに問い合せます。第3.9.2.5項「クラスタ内の移行可能なサーバーの動作」を参照してください。
管理対象サーバー1および2は、起動した構成をキャッシュします。
管理対象サーバー1および2はそれぞれ、移行可能なサーバーのリースをリース表から取得します。管理対象サーバー1は、最初に起動するためクラスタ・マスターのリースも取得します。第3.9.2.6項「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。
管理対象サーバー1および2は、リース表のリースを定期的に更新して、ヘルスおよび稼働状況を証明します。
図3-2に、管理対象サーバー2をホストするマシンに障害が発生した後の自動移行処理を示します。
管理対象サーバー2をホストするマシンCに障害が発生します。
リース表の次回の定期確認時に、クラスタ・マスターは管理対象サーバー2のリース期限が切れていることを検出します。第3.9.2.6項「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。
クラスタ・マスターが、マシンCのノード・マネージャにアクセスして管理対象サーバー2の再起動を試行しますが、マシンCにアクセスできないため失敗します。
|
注意: 管理対象サーバー2のリース期限切れの原因が管理対象サーバー2のハングだけで、マシンCにはアクセス可能な場合は、クラスタ・マスターはノード・マネージャを使用して、マシンCの管理対象サーバー2を再起動します。 |
クラスタ・マスターが、マシンDのノード・マネージャにアクセスします。マシンDは、クラスタ内の移行可能なサーバーに使用可能なホストとして構成されています。
マシンDのノード・マネージャによって、管理対象サーバー2が起動されます。第3.9.1項「サーバー全体の移行におけるノード・マネージャの役割」を参照してください。
管理対象サーバー2が起動し、管理サーバーにアクセスして、その構成を取得します。
管理対象サーバー2が、起動時に使用した構成をキャッシュします。
管理対象サーバー2が、移行可能なサーバーのリースを取得します。
移行する管理対象サーバーのクライアントでは、移行時にサービスが短時間中断することがあり、その場合は再接続する必要があります。オペレーティング・システムがSolarisおよびLinuxの場合は、ifconfigコマンドを使用して再接続できます。移行されるサーバーのクライアントは、移行先のマシンを認識する必要はありません。
移行されたサーバー・インスタンスを以前ホストしていたマシンが再度使用可能になると、移行処理が戻されます(サーバー・インスタンスを元のホスト・マシンに移行します)。これをフェイルバックと呼びます。WebLogic Serverでは、フェイルバックの処理は自動化されません。そのサーバー・インスタンスを元のホストに手動で戻すことにより、フェイルバックを実現できます。
サーバーを元のホストに戻すための一般的な手順は、次のとおりです。
サーバーの新しいインスタンスを正常に停止します。
障害の発生したマシンを再起動したら、ノード・マネージャと管理対象サーバーを再起動します。
実際に行う詳細な手順は、サーバーとネットワーク環境によって異なります。
図3-3に、移行可能なサーバーを管理者が手動で移行する際の処理を示します。
管理者は管理コンソールを使用して、マシンCからマシンBへの管理対象サーバー2の移行を開始します。
管理サーバーが、マシンCのノード・マネージャにアクセスします。第3.9.2.4項「サーバー全体の移行における管理サーバーの役割」を参照してください。
マシンCのノード・マネージャによって、管理対象サーバー2が停止されます。
管理対象サーバー2によって、リース表から対象の行が削除されます。
管理サーバーによって、マシンBのノード・マネージャが起動されます。
マシンBのノード・マネージャによって、管理対象サーバー2が起動されます。
管理対象サーバー2が、管理サーバーからその構成を取得します。
管理対象サーバー2が、起動時に使用した構成をキャッシュします。
管理対象サーバー2によって、リース表に行が追加されます。
移行可能なサーバーを含むクラスタにおいて、管理サーバーは各システムの、次のノード・マネージャを起動します。
移行可能なサーバーを起動するクラスタ・メンバーをホストしているノード・マネージャ。これは、サーバーを移行する際の前提条件です。最初にノード・マネージャでサーバー・インスタンスを起動しないと、サーバーを移行できません。
移行可能なサーバーをいったん停止して起動する手動移行処理に関わるノード・マネージャ。
正常停止時にサーバー・インスタンスを停止するクラスタ・メンバーをホストしているノード・マネージャ。これは、サーバーを移行する際の前提条件です - ノード・マネージャを使用しないでサーバー・インスタンスを直接停止した場合、サーバー・インスタンスが稼働していないことがクラスタ・マスターで検出されると、ノード・マネージャが呼び出されて、そのサーバー・インスタンスが再起動してしまいます。
また、管理サーバーには通常のドメイン管理機能が用意されています。これは、管理者が発行した構成の更新を永続的に保持し、ドメインに含まれる移行可能なサーバーを含め、ドメインの実行時ビューを表示できます。
移行可能なサーバーは、移行可能として構成された、クラスタ化された管理対象サーバーです。移行可能なサーバーの主要な動作は、次のとおりです。
リース情報の管理にデータベースを使用している場合、ノード・マネージャによる起動および再起動時に、移行可能なサーバーによってリース表に行が追加されます。移行可能なサーバーの行には、タイムスタンプおよびそのサーバーが稼働しているマシンが含まれています。
リース情報の管理にデータベースを使用すると、移行可能なサーバーは起動の結果としてデータベースに行を追加し、クラスタ・マスターの役割を担当しようとします。このサーバーがクラスタに参加する最初のサーバー・インスタンスであれば成功します。
サーバーは定期的に、リース表のタイムスタンプを更新することで、その「リース」を更新します。
デフォルトでは、移行可能なサーバーは30,000ミリ秒ごとにそのリースを更新します。この値は次の2つのServerMBeanプロパティの積です。
HealthCheckIntervalMillis: デフォルトでは10,000です。
HealthCheckPeriodsUntilFencing: デフォルトでは3です。
移行可能なサーバーがリース表にアクセスできず、リースの期限が切れる前にそのリースを更新できないと、Java System.exitを使用して迅速に終了します。その場合、リース表にはそのサーバー・インスタンスの行が残ります。これが自動移行にどのように関連しているかの詳細は、第3.9.2.6項「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。
運用時には、移行可能なサーバーが、クラスタ・マスターからのハートビートをリスニングします。クラスタ・マスターがハートビートを送信していないことを検出すると、クラスタ・マスターの役割を引き継ごうとします。その役割を主張するサーバー・インスタンスが他になければ成功します。
移行可能なサーバーを含むクラスタにおいて、1つのサーバー・インスタンスがクラスタ・マスターとして動作します。その役割は、サーバー移行処理を調整することです。クラスタ内の任意のサーバー・インスタンスが、クラスタ・マスターの機能を果たすことができます。移行可能なサーバーを含むクラスタを起動すると、クラスタに最初に参加したサーバーがクラスタ・マスターになり、クラスタ・マネージャのサービスを開始します。移行可能なサーバーがクラスタに1つも含まれていない場合、クラスタ・マスターは不要であり、クラスタ・マスターのサービスは開始されません。クラスタ・マスターがなくても、移行可能なサーバーは引き続き稼働できますが、サーバーの移行はできません。主なクラスタ・マスターの機能は次となります。
クラスタ内の他のサーバーにハートビートを定期的に発行します。
リース表を定期的に読み取り、それぞれの移行可能なサーバーに最新のリースがあることを確認します。期限切れのリースがあると、移行可能なサーバーを再起動する必要があることがクラスタ・マスターに示されます。
移行可能なサーバーのリースの期限が切れていると判断された時点で、ClusterMBeanのFencingGracePeriodMillisで指定された期間にわたって待機した後、リースの期限が切れた移行可能なサーバーをホストするマシンのノード・マネージャのプロセスを起動して、移行可能なサーバーの再起動を試行します。
現在のマシンでリース期間が切れた移行可能なサーバーを再起動できない場合、クラスタ・マスターは次のようにターゲット・マシンを選択します。
移行可能なサーバーの優先的な移行先マシンのリストを構成する場合、クラスタ・マスターは、そのリストに表示されている順にマシンを選択します。そのリストを構成していない場合、クラスタ・マスターは、クラスタ内の移行可能なサーバーのホストに使用できるように構成されているマシンのリストからマシンを選択します。
移行可能なサーバーをホストできるマシンのリストは、「クラスタ全体」と「個々の移行可能なサーバー」という2つのレベルで構成できます。マシンのリストは、両方のレベルで定義できます。マシンのリストは、少なくとも1つのレベルで定義する必要があります。
新しいマシンへのサーバー・インスタンスを移行するには、クラスタ・マスターでターゲット・マシンのノード・マネージャ・プロセスを起動して、サーバー・インスタンスのプロセスを作成します。
移行の実行に必要な時間は、サーバーの構成および起動時間によって異なります。
移行可能なサーバーをクラスタ・マスターによって再起動するときの最大所要時間は、(HealthCheckPeriodsUntilFencing * HealthCheckIntervalMillis)+FencingGracePeriodMillisです。
クライアントのリクエストに対してサーバーを使用できるようになるまでの合計時間は、サーバーの起動時間とアプリケーションのデプロイ所要時間によって異なります。
移行可能ターゲット(クラスタ内のサーバーから別のサーバーに移行できる特別なターゲット)を使用すると、JMSサービスやJTAサービスを構成して可用性を高めることができます。移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。
移行可能なJMSサービスを移行できるように構成するには、そのサービスを移行可能ターゲットにデプロイする必要があります。移行可能ターゲットでは、ターゲットをホストできるサーバーのセットを指定します。必要に応じて、そのサービスを優先的にホストするサーバーを指定したり、その優先サーバーで障害が発生した場合のバックアップ・サーバー候補を順序付けしたリストを指定したりできます。ただし、移行可能ターゲットを同時に複数のサーバーでホストすることはできません。
移行可能ターゲットを使用するようにサービスを構成すると、そのサービスは、現時点でそれをホストしているサーバー・メンバーから独立した存在になります。たとえば、JMSキューがデプロイされているJMSサーバーを、移行可能ターゲットを使用するように構成した場合、そのキューは、特定のサーバー・メンバーが使用可能かどうかに依存せずに動作します。つまり、このキューは、移行可能ターゲットがクラスタ内のいずれかのサーバーでホストされているかぎり、常に使用できます。
管理者は、サーバーの障害への対応として、または定期的に計画されるメンテナンスの一環として、固定された移行可能サービスをクラスタ内のサーバー・インスタンスから別のサーバー・インスタンスに手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのWebLogic Serverインスタンスにも移行できます。
JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバー(UPS: User-Preferred Server)のターゲットを選択できます。また、移行可能ターゲットを構成する場合は、ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS: Constrained Candidate Server)を指定することもできます。移行可能ターゲットに控えの候補サーバーが指定されていない場合、JMSサーバーをクラスタ内で使用可能な任意のサーバーに移行できます。
WebLogic Serverでは、JMSサービスごとに別々の移行可能ターゲットを作成できます。これにより、必要に応じて、クラスタ内の別々のサーバーで常に各サービスを実行し続けることが可能になります。また逆に、JTAとJMS両方の控えの候補サーバーとして同じサーバー群を選択し、両方のサービスが確実にクラスタ内の同じサーバーに配置されるように構成することもできます。
JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再起動の動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーおよび再起動後に異なる問題が発生する可能性があります。
サーバーの再起動の動作を確認するには、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させます。
サーバーをサーバー移行用に構成した場合、フェイルオーバー期間の経過後に、サーバーはフェイルオーバー・ノードで自動的に起動します。
サーバーをサーバー移行用に構成しなかった場合、ノードが完全に再起動した後、同じホスト上でWebLogic Serverを手動で再起動できます。
予期しないマシン障害後にWebLogic Serverが再起動しない場合、サーバー・ログ・ファイルに次のエラー・エントリが表示されます。
<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent
store "_WLS_server_soa1" could not be deployed:
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource
temporarily unavailable, errno=11
このエラーは、NFSv3システムでファイル・ストア上のロックが解放されていない場合に発生します。WebLogic Serverは、同じ管理対象サーバーの2つのインスタンスを間違って起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログを格納しているファイルに対するロックを保持します。NFSv3ストレージ・デバイスはロック所有者を追跡しないため、ロック所有者が失敗した場合、NFSはロックを無期限に保持します。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverがロックを取得しようとしても、失敗する可能性があります。
このエラーの解決方法は、NFS環境によって異なります(このトピックの更新については、『Oracle Fusion Middlewareリリース・ノート』を参照してください)。
NFSv4環境の場合、サーバー移行を完了する所要時間内にロックを解放するよう、NASサーバーでチューニング・パラメータを設定できます(この項の手順に従う必要はありません)。ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックに関する情報は、使用しているストレージのベンダーのドキュメントを参照し、結果をテストしてください。
NFSv3環境の場合、次の項で、デフォルト・ファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストア、診断ファイル・ストアに対するWebLogicのファイル・ロック・メカニズムを無効化する方法について説明します。
|
警告: NFSv3のファイル・ロックにより、複数の管理対象サーバーが任意の時点で同じファイル・ストアに書込みを行う場合に、深刻なファイルの破損が発生しないようにします。 NFSv3のファイル・ロックを無効化する場合は、特定のファイル・ストアに書込みを行う管理対象サーバーが1つのみとなるよう、管理手順や管理ポリシーを実装する必要があります。破損は、同じクラスタまたは別のクラスタ、同じノードまたは別のノード、あるいは同じドメインまたは別のドメインに管理対象サーバーが2つ存在することにより発生する可能性があります。 ポリシーの例としては、ドメインをコピーしない、WLS構成オブジェクト(サーバーやストア)の一意のネーミング・スキームを強制しない、各ドメインに独自の記憶域ディレクトリを必ず含める、2つのドメインに同じディレクトリを参照する同じ名前のストアを含めることはできない、などがあげられます。 ファイル・ストアを使用する管理対象サーバーをサーバー移行用に構成している場合は、必ずデータベース・ベースのリース・オプションを構成してください。このオプションにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、特定の管理対象サーバーの複数のインスタンスが自動的に再起動しなくなります。 |
デフォルト・ファイル・ストアのファイル・ロックの無効化
管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーのサマリー」リストで、変更するサーバーを選択します。
「構成」→「サービス」タブを選択します。
「デフォルト・ストア」セクションを下にスクロールし、「詳細」をクリックします。
下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlのエントリは、次のようになります。
<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>
カスタム・ファイル・ストアのファイル・ロックの無効化
管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを開いて「永続ストア」を選択します。
「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。
カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックします。
下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
カスタム・ファイル・ストアが使用中の場合、変更を反映するにはサーバーを再起動します。
生成されるconfig.xmlのエントリは、次のようになります。
<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>
JMSページング・ファイル・ストアのファイル・ロックの無効化
管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを開き、次に「メッセージング」ノードを開いて「JMSサーバー」を選択します。
「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。
JMSサーバーの「構成」→「全般」タブで、下にスクロールして「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlファイルのエントリは、次のようになります。
<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>
診断ファイル・ストアのファイル・ロックの無効化
管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「診断」ノードを開いて「アーカイブ」を選択します。
「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。
「<サーバー名>の設定」ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlファイルは、次のようになります。
<server>
<name>examplesServer</name>
...
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-store-file-locking-enabled>false</diagnostic-store-file-locking-
enabled>
<diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>100</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
</server-diagnostic-config>
</server>
管理サーバーは、そのドメイン内のWebLogic Serverインスタンス群を構成および管理するWebLogic Serverインスタンスです。
ドメインには複数のWebLogic Serverクラスタと、クラスタ化されないWebLogic Serverインスタンスが存在できます。ドメインは1つのWebLogic Serverインスタンスのみで構成できますが、この場合、各ドメインには必ず1つの管理サーバーが存在する必要があるため、その唯一のサーバー・インスタンスが管理サーバーとなります。
管理サーバーのサービスを起動して構成タスクを実行するには、様々な方法があります。いずれの方法を使用するにしても、構成を変更する際はクラスタの管理サーバーが稼働している必要があります。
|
注意: 複数のMiddlewareホームまたはOracleホームを使用したシステムの場合は特に、管理サーバーのリスニング・アドレスに、そのクライアントがサーバーにアクセスするのに必要なホスト名を設定することをお薦めします。 |
ドメインの管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。管理対象のサーバー・インスタンスが(クラスタ化されているかいないかには関係なく)稼働しているときにドメインの管理サーバーが使用できなくなっても、管理対象サーバーは稼働し続けます。ドメインにクラスタ化されたサーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。
|
注意: ホスト・マシンのハードウェア障害またはソフトウェア障害によって管理サーバーに障害が発生した場合は、同じマシンの他のサーバー・インスタンスも同様に影響を受けることがあります。ただし、管理サーバー自体で障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。 |
管理サーバーを再起動する手順については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
ロード・バランシング構成は、3つの情報(使用するロード・バランシング・アルゴリズム、ローカル・アフィニティを適用するかどうかを示すインジケータ、およびトポロジの各メンバーに割り当てられる重み(重みを利用する任意のルーティング・アルゴリズムに影響))で構成されます。
ロード・バランシング・アルゴリズムによって、コンポーネント間でリクエストをロード・バランシングする方法を指定します。Oracle Fusion Middlewareでは、次の3つのロード・バランシング方法を使用します。
ラウンド・ロビン: 使用可能なサーバーのリストから順番に選択して、一連のサーバーにリクエストを分散します。
ランダム: リクエストごとに、使用可能なサーバーのリストからサーバーをランダムに選択して、一連のサーバーにリクエストを分散します。
重み付け: 使用可能なサーバーのリストの中の各サーバーに割り当てられた重みを使用して、それぞれに送信されるリクエストの割合を決定することで、一連のサーバーにリクエストを分散します。
ローカル・アフィニティは、ネットワーク待機時間を回避するために、同じマシンで稼働するサーバーに対してクライアントが優先度を示すかどうかを決定します。このフラグがtrueに設定されていると、ローカル・サーバーのいずれかが使用可能な場合、ロード・バランシング・アルゴリズムを使用して、ローカル・マシン上の一連のサーバーにわたってリクエストがルーティングされます。使用可能なローカル・サーバーがない場合には、ロード・バランシング・アルゴリズムに従って、すべての使用可能なリモート・サーバーにリクエストがルーティングされます。ローカル・アフィニティがfalseに設定されていると、ロード・バランシング・アルゴリズムに基づいて、(ローカルおよびリモートの)すべての使用可能なサーバーにわたってリクエストがルーティングされます。
重みは、コンポーネント・インスタンスに関連付けられる単一の整数値として構成します。重みは、現在グループにないコンポーネントにも割り当てることができますが、そのコンポーネントがグループのメンバーとして後で構成され、重みが付けられたロード・バランシング・アルゴリズムが選択されないと、その重みは使用されません。重みは単位のない数値です。各メンバーに送信されるリクエストの割合は、使用可能なメンバーすべての重みを合計し、その重みの合計で各メンバーの重みを割って計算します。
単一のGridLinkデータ・ソースにより、WebLogic ServerとOracle Database Real Application Clusters(RAC)間の接続が可能となります。これは、Oracle RACにおける状態変化に適応して対処するために、Oracle Notification Service(ONS)を使用します。これはFANイベントに応答して、高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング(RCLB)、およびRACインスタンスの正常な停止を提供します。また、アフィニティ機能もあります。
GridLinkデータ・ソースの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの使用に関する説明を参照してください。
マルチ・データ・ソースとは、データ・ソースのグループの抽象概念です。これによって、ロード・バランシングまたはフェイルオーバーは、接続要求時に、マルチ・データ・ソースに関連付けられたデータ・ソースの間で処理されます。マルチ・データ・ソースは、単純なデータ・ソースがJNDIツリーにバインドされるように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされます。アプリケーションは、単純なデータ・ソースと同様に、JNDIツリーまたはローカル・アプリケーション・コンテキスト(java:comp/env)でマルチ・データ・ソースを検索してから、データベース接続を要求します。マルチ・データ・ソースによって、マルチ・データ・ソース構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用するデータ・ソースが決定します。
マルチ・データ・ソースは、データ・ソースのプールと考えることができます。マルチ・データ・ソースは、冗長なデータベースやOracle RACなど、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用するのが最適です。
config.xmlファイルは、WebLogic Serverドメインの構成を記述しているXMLドキュメントです。config.xmlのdomain要素はトップレベルの要素であり、ドメイン内のすべての要素はdomain要素の子です。domain要素には、server、cluster、applicationなどの子要素があります。子要素の中にさらに子要素がある場合もあります。たとえば、server要素には、子要素としてWebServer、SSLおよびLogを記述できます。Application要素には、子要素としてEJBComponentとWebAppComponentがあります。
各要素には、1つ以上の構成可能な属性があります。config.dtdに定義されている属性には、構成APIに対応する属性があります。たとえば、Server要素にはListenPort属性があり、同様にWeblogic.management.configuration.ServerMBeanにもListenPort属性があります。構成できる属性は読み書きが可能です。たとえば、ServerMBeanにはgetListenPort()メソッドとsetListenPort()メソッドがあります。
config.xmlの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
シングルトン・サービスとは、ホストとして機能しているサーバー・インスタンスで障害が発生した場合に、常に1つのサーバー・インスタンス上でのみ実行される必要があるサービス(JMSやJTAトランザクション・リカバリ・システムなど)です。障害が発生した場合、自動移行が構成されている管理対象サーバーは別のマシンに自動的に移行されます。
高可用性環境では、次のような理由でWebLogic ServerはLDAPにアクセスできる必要があります。
WebLogic ServerでフェイルオーバーをサポートするLDAPに格納されているユーザーおよびグループにアクセスするため。
LDAP認証プロバイダのフェイルオーバーの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のLDAP認証プロバイダのフェイルオーバーの構成に関する項を参照してください。
LDAPベースのポリシー・ストアおよび資格証明ストアにアクセスするため。
LDAPベースのポリシー・ストアを使用するドメインの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPベースのポリシー・ストアを使用するドメインの構成に関する項を参照してください。
LDAPベースの資格証明ストアを使用するドメインの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPベースの資格証明ストアを使用するドメインの構成に関する項を参照してください。
