WebLogic Server クラスタ ユーザーズ ガイド
|
 |
 |
|
この章の以下の節では、クラスタのコンフィグレーションを定義する情報が格納および保持される仕組みと、コンフィグレーション作業を実施する方法について説明します。
注意 : この章の情報の多くは、サーバ インスタンスがクラスタ化されていない WebLogic ドメインのコンフィグレーション プロセスに関連するものです。
config.xml ファイルは、WebLogic Server ドメインのコンフィグレーションを記述した XML ドキュメントであり、一連の XML 要素で構成されます。Domain 要素はトップレベルの要素であり、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 の詳細については、『ドメインのコンフィグレーションについて』の「ドメイン コンフィグレーション ファイル」を参照してください。
管理サーバは、そのドメイン内の WebLogic Server インスタンス群をコンフィグレーションおよび管理する WebLogic Server インスタンスです。
ドメインには複数の WebLogic Server クラスタと、クラスタ化されない WebLogic Server インスタンスが存在できます。厳密に言うと、ドメインは 1 つの WebLogic Server インスタンスだけでも構成できます。ただしその場合、各ドメインには必ず 1 つの管理サーバが存在しなければならないため、その唯一のサーバ インスタンスが管理サーバになります。
管理サーバのサービスを呼び出してコンフィグレーション作業を実施する方法は、「クラスタをコンフィグレーションする方法」で説明するようにいくつか用意されています。どの方法を用いる場合でも、コンフィグレーションを修正するときはクラスタの管理サーバが稼働している必要があります。
管理サーバが起動すると、ドメインの config.xml がロードされます。config.xml は、次のディレクトリで検索されます。
BEA_HOME/user_projects/domains/<domain_name>/config
domain_name はドメインに固有のディレクトリで、その名前はドメインと同じです。
管理サーバが正常に起動するたびに、config.xml.booted という名前のバックアップ コンフィグレーション ファイルがドメイン ディレクトリに作成されます。サーバ インスタンスの有効期間中に万一 config.xml ファイルが破損した場合、このファイルを使用して以前のコンフィグレーションに戻すことができます。
次の図は、1 つの管理サーバと複数の WebLogic Server インスタンスで構成される典型的なプロダクション環境を示しています。このようなドメインでサーバ インスタンスを起動すると、まず管理サーバが起動します。その他の各サーバ インスタンスは、起動時に管理サーバにアクセスしてそのコンフィグレーション情報を取得します。このように、管理サーバはドメイン全体のコンフィグレーションの一元的な制御エンティティとして動作します。
図 4-1 WebLogic Server のコンフィグレーション
ドメインの管理サーバで障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。管理対象のサーバ インスタンスが (クラスタ化されているかいないかには関係なく) 動作しているときにドメインの管理サーバが使用できなくなっても、その管理対象サーバは処理を続けます。ドメインにクラスタ化されたサーバ インスタンスがある場合は、管理サーバに障害が発生しても、ドメイン コンフィグレーションでサポートされているロード バランシングおよびフェイルオーバ機能を使用できます。
注意 : ホスト マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバに障害が発生した場合、同じマシン上の他のサーバ インスタンスも同様に影響を受けることがあります。ただし、管理サーバ自体で障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。
管理サーバを再起動する手順については、『サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」を参照してください。
WebLogic Server では、ドメイン リソースのコンフィグレーション属性を動的に (サーバ インスタンスの動作中に) 変更できます。ほとんどの場合では、変更を有効にするためにサーバ インスタンスを再起動する必要はありません。属性をコンフィグレーションし直すと、新しい値は、実行時の現在の属性値と、config.xml に格納されている永続的な値の両方に直ちに反映されます。
コンフィグレーションへのすべての変更が動的に適用されるわけではありません。たとえば、管理対象サーバの ListenPort 値を変更した場合、新しいポートは管理対象サーバを次に起動するまで使用されません。更新された値は config.xml に保存されますが、実行時の値は影響を受けません。
Administration Console は、範囲外エラーやデータ型の不一致エラーをチェックして属性の変更を検証し、エラーがあるエントリではエラー メッセージを表示します。
Administration Console の起動後に、管理サーバに割り当てられたリスン ポートを別のプロセスが獲得した場合、ポートを獲得したプロセスを停止することをお勧めします。リスン ポートを獲得したプロセスを削除できない場合、config.xml ファイルを編集して、ListenPort 値を変更します。
この節では、アプリケーションのデプロイメント プロセスについて簡単に説明します。デプロイメントの詳細については、『WebLogic Server 9.1 アプリケーションのデプロイメント』を参照してください。
一般的なデプロイメント作業の実行手順については、「アプリケーションをデプロイする」を参照してください。
以下の方法で、クラスタにアプリケーションをデプロイすることができます。
weblogic.Deployer ユーティリティは、WebLogic Server デプロイメント API にコマンドライン インタフェースを提供する Java ベースのデプロイメント ツールです。
これらのデプロイメント ツールについては、『WebLogic Server 9.1 アプリケーションのデプロイメント』の「デプロイメント ツールの概要」で説明しています。
どのデプロイメント ツールを使用するかに関係なく、デプロイメント プロセスを開始するときは、デプロイするコンポーネントと、デプロイメント先の対象 (クラスタ、あるいはクラスタまたはドメイン内部の個別のサーバ インスタンス) を指定します。
ドメインの管理サーバはプロセス全体を通じて、クラスタ内の管理対象サーバと通信することによってデプロイメント プロセスを管理します。各管理対象サーバはデプロイメント対象のコンポーネントをダウンロードし、ローカルでのデプロイメント タスクを開始します。デプロイメントの状態は、デプロイメント対象のコンポーネントと関連付けられた MBean に保持されます。詳細については、デプロイメント管理 API を参照してください。
注意 : アプリケーションは、WebLogic Server にデプロイする前にパッケージ化する必要があります。詳細については、『WebLogic Server アプリケーションの開発』の「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
WebLogic Server では、アプリケーションは 2 つのフェーズでデプロイされます。開始する前に、WebLogic Server はクラスタ内の管理対象サーバの可用性を確認します。
デプロイメントの第 1 フェーズでは、アプリケーション コンポーネントが対象のサーバ インスタンスに配信され、計画されたデプロイメントが検証されて、アプリケーション コンポーネントが正常にデプロイされることを確認します。このフェーズの間、デプロイ中のアプリケーションに対するユーザからのリクエストは受け付けられません。
配信および検証プロセス中に障害が発生すると、(検証が成功したサーバ インスタンスを含む) すべてのサーバ インスタンスでデプロイメントが中止されます。ステージングされたファイルは、削除されません。ただし、準備中に行われたコンテナ側での変更は元に戻されます。
アプリケーション コンポーネントは、対象に配信および検証された後で、対象のサーバ インスタンスに完全にデプロイされます。デプロイされたアプリケーションはクライアントから利用可能になります。
このプロセス中に障害が発生すると、そのサーバ インスタンスへのデプロイメントはキャンセルされます。1 つの管理対象サーバでそのような障害があっても、クラスタ化されている他のサーバ インスタンスで正常なデプロイメントが妨げられることはありません。
クラスタ メンバーがアプリケーションのデプロイメントに失敗した場合、クラスタの一貫性を確保するためにそのメンバーは起動できなくなります (管理対象サーバ上でクラスタにデプロイされたアプリケーションに障害があると、その管理対象サーバは起動が中止されます)。
デプロイメント プロセスの間は、クラスタ内のすべての管理対象サーバが実行されて利用可能になっているのが理想です。クラスタの一部のメンバーが利用できない状態でアプリケーションをデプロイすることはお勧めしません。クラスタにアプリケーションをデプロイする前に、できる限り、クラスタ内のすべての管理対象サーバが管理サーバからアクセスできる状態にあるようにしてください。
注意 : デプロイメント時に分割された管理対象サーバ (動作していても管理サーバからアクセスできない) にアプリケーションをデプロイした場合、その管理対象サーバがクラスタに復帰したときにその管理対象サーバにアクセスできないことがあります。同期の間、クラスタ化されている他の管理対象サーバがその以前に分割されたサーバ インスタンスとの通信を再確立する一方で、デプロイされているアプリケーションへのユーザ リクエストおよびそのサーバ インスタンスでセカンダリ セッションを作成しようとする試みは失敗します。このような問題が起こるリスクは、enforceClusterConstraints フラグを設定することで減少します (「WebLogic Server でのクラスタ全体へのデプロイメント」を参照)。
デプロイメント プロセスの間は、クラスタのメンバシップが変わらないようにしてください。デプロイメントが始まったら、以下のことはしないでください。
WebLogic Server の旧バージョンでは、クラスタへのデプロイメントで以下のような制限が課されていました。
デフォルトの WebLogic Server では、クラスタの一部分にデプロイできます。クラスタの 1 つまたは複数の管理対象サーバが利用できない場合は、次のメッセージが表示されます。
Cannot deploy to the following server(s) because they are
unreachable: "managed_server_n".Make sure that these servers are
currently shut down.Deployment will continue on the remaining
servers in the cluster "clustering".Once deployment has commenced,
do not attempt to start or shutdown any servers until the
application deployment completes.
アクセス不能な管理対象サーバが利用可能になると、そのサーバ インスタンスへのデプロイメントが開始されます。デプロイメント プロセスが完了するまで、その管理対象サーバでは欠けているクラスまたは古いクラスに関連する障害が発生する可能性があります。
weblogic.Deployer で enforceClusterConstraints フラグを設定すると、クラスタ内のすべての管理対象サーバがアクセス可能な場合にのみデプロイメントが実行されるようにすることができます。enforceClusterConstraints が「true」の場合は、WebLogic Server の旧バージョンで適用されていたルールに従ってデプロイメントが実行されます。
クラスタ内の複数の管理対象サーバを固定サービスの対象にすることができます。この操作はお勧めしません。固定サービスをクラスタ内の複数の管理対象サーバにデプロイすると、クラスタのロード バランシング機能とスケーラビリティが悪影響を受けるおそれがあります。複数の管理対象サーバを固定サービスの対象とすると、次のメッセージがサーバ ログに出力されます。
Adding serverservernameof clusterclusternameas a target for
modulemodulename.This module also includes serverservernamethat
belongs to this cluster as one of its other targets.Having multiple
individual servers a cluster as targets instead of having the entire
cluster as the target can result in non-optimal load balancing and
scalability.Hence this is not usually recommended.
クラスタをコンフィグレーションする複数の方法が用意されています。
新しいドメインまたはクラスタの作成は、コンフィグレーション ウィザードを使用して行うことをお勧めします。『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』の「コンフィグレーション ウィザードを使用した新しいドメイン作成の概要」を参照してください。クラスタの作成とコンフィグレーションについては、「環境のカスタマイズ」を参照してください。
Administration Console は、BEA Administration Service にアクセスするためのグラフィカル ユーザ インタフェース (GUI) です。コンソールからは、各種のドメイン コンフィグレーションおよびモニタ機能を実行できます。
WebLogic Server に付属するコンフィグレーション API に基づいて、コンフィグレーション属性を変更するプログラムを記述することができます。この方法は、初期のクラスタ実装に対してはお勧めできません。
WebLogic Scripting Tool (WLST) は、システム管理者やオペレータが、WebLogic Server インスタンスおよびドメインのモニタと管理に使用する、コマンドライン スクリプト インタフェースです。詳細については、『WebLogic Scripting Tool ガイド』を参照してください。
|
|
|
