WebLogic Server クラスタ ユーザーズ ガイド
|
 |
 |
|
この章の以降の節では、クラスタのコンフィグレーションを定義する情報が格納および維持される仕組みと、コンフィグレーション作業を実施する方法について説明します。
注意 : この章の情報の多くは、サーバ インスタンスがクラスタ化されていない WebLogic ドメインのコンフィグレーション プロセスに関連するものです。
config.xml ファイルは、WebLogic Server ドメインのコンフィグレーションを記述した XML ドキュメントです。config.xml ファイルの内容および構造は、関連付けられた文書型定義 (DTD) である config.dtd ファイルに定義されます。
config.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 は、カレント ディレクトリで検索されます。ドメイン作成時に別のディレクトリを指定しない限り、config.xml は以下の場所に格納されます。
BEA_HOME/user_projects/mydomain
mydomain はドメインに固有のディレクトリで、その名前はドメインと同じです。
管理サーバが正常に起動するたびに、config.xml.booted という名前のバックアップ コンフィグレーション ファイルがドメイン ディレクトリに作成されます。サーバ インスタンスの有効期間中に万一 config.xml ファイルが破損した場合、このファイルを使用して以前のコンフィグレーションに戻すことができます。
次の図は、1 つの管理サーバと複数の WebLogic Server インスタンスで構成される典型的なプロダクション環境を示しています。このようなドメインでサーバ インスタンスを起動すると、まず管理サーバが起動します。その他の各サーバ インスタンスは、起動時に管理サーバにアクセスしてそのコンフィグレーション情報を取得します。このように、管理サーバはドメイン全体のコンフィグレーションの一元的な制御エンティティとして動作します。
図 3-1 WebLogic Server のコンフィグレーション
ドメインの管理サーバで障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。管理対象のサーバ インスタンスが (クラスタ化されているかいないかには関係なく) 動作しているときにドメインの管理サーバが使用できなくなっても、その管理対象サーバは処理を続けます。ドメインにクラスタ化されたサーバ インスタンスがある場合は、管理サーバに障害が発生しても、ドメイン コンフィグレーションでサポートされているロード バランシングおよびフェイルオーバ機能を使用できます。
注意 : ホスト マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバに障害が発生した場合、同じマシン上の他のサーバ インスタンスも同様に影響を受けることがあります。ただし、管理サーバ自体で障害が発生しても、ドメイン内の管理対象サーバの動作には影響しません。
管理サーバの再起動の手順については、『WebLogic Server のコンフィグレーションと管理』の「管理対象サーバの動作中における管理サーバの再起動」を参照してください。
WebLogic Server では、ドメイン リソースのコンフィグレーション属性を動的に (サーバ インスタンスの動作中に) 変更できます。ほとんどの場合では、変更を有効にするためにサーバ インスタンスを再起動する必要はありません。属性をコンフィグレーションし直すと、新しい値は、実行時の現在の属性値と、config.xml に格納されている永続的な値の両方に直ちに反映されます。
コンフィグレーションへのすべての変更が動的に適用されるわけではありません。たとえば、管理対象サーバの ListenPort 値を変更した場合、新しいポートは管理対象サーバを次に起動するまで使用されません。更新された値は config.xml に保存されますが、実行時の値は影響を受けません。コンフィグレーション属性の実行時の値と、config.xml の値が異なるときは、Administration Console でその属性の隣に警告アイコン (三角形の中に感嘆符 (!)) が表示されます。このアイコンは、コンフィグレーションの変更を有効にするためにはサーバ インスタンスの再起動が必要であることを知らせます。
Administration Console は、範囲外エラーやデータ型の不一致エラーをチェックして属性の変更を検証し、エラーがあるエントリではエラー メッセージを表示します。
Administration Console の起動後に、管理サーバに割り当てられたリスン ポートを別のプロセスが獲得した場合、ポートを獲得したプロセスを停止することをお勧めします。リスン ポートを獲得したプロセスを削除できない場合、config.xml ファイルを編集して、ListenPort 値を変更します。
この節では、アプリケーションのデプロイメント プロセスについて簡単に説明します。デプロイメントの詳細については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。
一般的なデプロイメント作業の実行手順については、「アプリケーションをデプロイする」を参照してください。
以下の方法で、クラスタにアプリケーションをデプロイすることができます。
WebLogic Builder は、J2EE コンポーネントをアセンブルし、そのデプロイメント記述子を作成および編集し、コンポーネントを WebLogic Server にデプロイするためのグラフィカル ツールです。
これらのデプロイメント ツールについては、『WebLogic Server アプリケーションのデプロイメント』の「デプロイメント ツールのリファレンス」で説明しています。
どのデプロイメント ツールを使用するかに関係なく、デプロイメント プロセスを開始するときは、デプロイするコンポーネントと、デプロイメント先の対象 (クラスタ、あるいはクラスタまたはドメイン内部の個別のサーバ インスタンス) を指定します。
ドメインの管理サーバはプロセス全体を通じて、クラスタ内の管理対象サーバと通信することによってデプロイメント プロセスを管理します。各管理対象サーバはデプロイメント対象のコンポーネントをダウンロードし、ローカルでのデプロイメント タスクを開始します。デプロイメントの状態は、デプロイメント対象のコンポーネントと関連付けられた MBean に維持されます。詳細については、デプロイメント管理 API を参照してください。.
注意 : コンポーネントは、WebLogic Server にデプロイする前にパッケージ化します。詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server アプリケーションの作成」でパッケージ化のトピックを参照してください。
WebLogic Server 7.0 以降では、アプリケーションは 2 つのフェーズでデプロイされます。開始する前に、WebLogic Server はクラスタ内の管理対象サーバの可用性を確認します。
デプロイメントの第 1 フェーズでは、アプリケーション コンポーネントが対象のサーバ インスタンスに配信され、計画されたデプロイメントが検証されて、アプリケーション コンポーネントが正常にデプロイされることを確認します。このフェーズの間、デプロイ中のアプリケーションに対するユーザからのリクエストは受け付けられません。
配信および検証プロセス中に障害が発生すると、(検証が成功したサーバ インスタンスを含む) すべてのサーバ インスタンスでデプロイメントが中止されます。ステージングされたファイルは、削除されません。ただし、準備中に行われたコンテナ側での変更は元に戻されます。
アプリケーション コンポーネントは、対象に配信および検証された後で、対象のサーバ インスタンスに完全にデプロイされます。デプロイされたアプリケーションはクライアントから利用可能になります。
このプロセス中に障害が発生すると、そのサーバ インスタンスへのデプロイメントはキャンセルされます。1 つの管理対象サーバでそのような障害があっても、クラスタ化されている他のサーバ インスタンスで正常なデプロイメントが妨げられることはありません。
クラスタ メンバーがアプリケーションのデプロイメントに失敗した場合、クラスタの一貫性を確保するためにそのメンバーは起動できなくなります (管理対象サーバ上でクラスタにデプロイされたアプリケーションに障害があると、その管理対象サーバは起動が中止されます)。
デプロイメント プロセスの間は、クラスタ内のすべての管理対象サーバが実行されて利用可能になっているのが理想です。クラスタの一部のメンバーが利用できない状態でアプリケーションをデプロイすることはお勧めしません。クラスタにアプリケーションをデプロイする前に、できる限り、クラスタ内のすべての管理対象サーバが管理サーバからアクセスできる状態にあるようにしてください。
WebLogic Server 8.1 では、デプロイメント時に分割された管理対象サーバ (動作していても管理サーバからアクセスできない) にアプリケーションをデプロイした場合、その管理対象サーバがクラスタに復帰したときにその管理対象サーバにアクセスできないことがあります。同期の間、クラスタ化されている他の管理対象サーバがその以前に分割されたサーバ インスタンスとの通信を再確立する一方で、デプロイされているアプリケーションへのユーザ リクエストおよびそのサーバ インスタンスでセカンダリ セッションを作成しようとする試みは失敗します。このような問題が起こるリスクは、ClusterConstraintsEnabled を設定することで減少します (『WebLogic Server アプリケーションのデプロイメント』の「2 フェーズ デプロイメントによるクラスタ制約の強制」を参照)。
デプロイメント プロセスの間は、クラスタのメンバシップが変わらないようにしてください。デプロイメントが始まったら、以下のことはしないでください。
WebLogic Server 7.0 では、クラスタへのデプロイメントで以下のような制限が課されていました。
WebLogic Server 7.0 SP01 では、上記のデプロイメント ルールが緩和されており、デプロイメントにおいてユーザの自由裁量が認められています。この姿勢は、WebLogic Server 8.1 でも変わっていません。
デフォルトの 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.
アクセス不能な管理対象サーバが利用可能になると、そのサーバ インスタンスへのデプロイメントが開始されます。デプロイメント プロセスが完了するまで、その管理対象サーバでは欠けているクラスまたは古いクラスに関連する障害が発生する可能性があります。
ClusterConstraintsEnabled を設定すると、クラスタ内のすべての管理対象サーバがアクセス可能な場合にのみデプロイメントが実行されるようにすることができます。ClusterConstraintsEnabled が「true」に設定されていると、クラスタ内のすべてのメンバーがアクセス可能であり、指定したファイルがデプロイ可能な場合にのみ、クラスタへのデプロイメントが成功します。『WebLogic Server アプリケーションのデプロイメント』の「2 フェーズ デプロイメントによるクラスタ制約の強制」を参照してください。
クラスタ内の複数の管理対象サーバを固定サービスの対象にすることができます。この操作はお勧めしません。固定サービスをクラスタ内の複数の管理対象サーバにデプロイすると、クラスタのロード バランシング機能とスケーラビリティが悪影響を受けるおそれがあります。複数の管理対象サーバを固定サービスの対象とすると、次のメッセージがサーバ ログに出力されます。
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.
クラスタをコンフィグレーションする複数の方法が用意されています。
新しいドメインまたはクラスタの作成は、ドメイン コンフィグレーション ウィザードを使用して行うことをお勧めします。ウィザードを使用して実行できるタスクの一覧については、この章で後から説明する「ドメイン コンフィグレーション ウィザードの機能」を参照してください。
Administration Console は、BEA Administration Service にアクセスするためのグラフィカル ユーザ インタフェース (GUI) です。コンソールからは、各種のドメイン コンフィグレーションおよびモニタ機能を実行できます。コンソールを使用して実行できるタスクの一覧については、「Administration Console の機能」を参照してください。
WebLogic Server に付属するコンフィグレーション API に基づいて、コンフィグレーション属性を変更するプログラムを記述することができます。この方法は、初期のクラスタ実装に対してはお勧めできません。
ドメイン コンフィグレーション ウィザードでは、あらかじめ定義済みのドメイン テンプレートを使用して、ドメインとそのサーバ インスタンスの作成プロセスを簡素化しています。ウィザードではドメイン テンプレートを選択し、作成するサーバ インスタンスのマシン アドレス、名前、ポート番号などの重要な情報を指定します。
注意 : ドメイン コンフィグレーション ウィザードでは、リモート マシン上で動作する管理対象サーバ上のドメインに適したディレクトリ構造およびスクリプトを、管理サーバからインストールすることができます。この機能は、管理対象サーバをドメインのバックアップ管理サーバとして使用する必要がある場合に役立ちます。
ウィザードでは、4 つの典型的なドメイン コンフィグレーションから 1 つを選択します。
目的のコンフィグレーション タイプを選択したら、ドメインとそのサーバ インスタンスについての関連情報を指定します。
ドメイン コンフィグレーション ウィザードの使用方法については、『WebLogic Server のコンフィグレーションと管理』の「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
Administration Console オンライン ヘルプの以下のセクションでは、WebLogic Server Administration Console を使用して実行できるクラスタ関連のコンフィグレーション タスクが説明されています。
|
|
|
