| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server クラスタ ユーザーズ ガイド > クラスタのコンフィグレーションとアプリケーションのデプロイメント |
|
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 に格納されている永続的な値の両方に直ちに反映されます。
コンフィグレーションへのすべての変更が動的に適用されるわけではありません。たとえば、WebLogic Server インスタンスの ListenPort 値を変更した場合、新しいポートは対象のサーバ インスタンスを次に起動するまで使用されません。更新された値は XML ファイルに保存されますが、実行時の現在の値は影響を受けません。コンフィグレーション属性の実行時の値と、config.xml に格納されている値が異なるとき、Administration Console でその属性の隣に警告アイコンが表示され、コンフィグレーションの変更を有効にするためにはサーバ インスタンスの再起動が必要であることを知らせます。 
Administration Console では、ユーザが変更した各属性に対して検証チェックが行われます。実行される検証には、範囲外エラーおよびデータ型不一致エラーのチェックがあります。どちらのエラーが見つかった場合にも、そのことを知らせるダイアログ ボックスが表示されます。
Administration Console の起動後に、管理サーバに割り当てられたリスン ポートを別のプロセスが獲得した場合、ポートを獲得したプロセスを停止することをお勧めします。リスン ポートを獲得したプロセスを削除できない場合、config.xml ファイルを編集して、ListenPort 値を変更します。
この節では、アプリケーションのデプロイメント プロセスについて簡単に説明します。デプロイメントの詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server デプロイメント」を参照してください。
一般的なデプロイメント作業の実行手順については、アプリケーションをデプロイするを参照してください。
以下の方法で、クラスタにアプリケーションをデプロイすることができます。
これらのデプロイメント ツールについては、『WebLogic Server アプリケーションの開発』の「デプロイメント ツールおよび手順」で説明しています。
どのデプロイメント ツールを使用するかに関係なく、デプロイメント プロセスを開始するときは、デプロイするコンポーネントと、デプロイメント先の対象 (クラスタ、あるいはクラスタまたはドメイン内部の個別のサーバ インスタンス) を指定します。
ドメインの管理サーバはプロセス全体を通じて、クラスタ内の管理対象サーバと通信することによってデプロイメント プロセスを管理します。各管理対象サーバはデプロイメント対象のコンポーネントをダウンロードし、ローカルでのデプロイメント タスクを開始します。デプロイメントの状態は、デプロイメント対象のコンポーネントと関連付けられた MBean に維持されます。詳細については、『WebLogic Server アプリケーションの開発』の「デプロイメント管理 API」を参照してください。
注意: コンポーネントは、WebLogic Server にデプロイする前にパッケージ化します。アプリケーションのパッケージ化の詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server アプリケーションのパッケージ化」を参照してください。
WebLogic Server 7.0 のアプリケーションのデプロイメントには、準備と活性化の 2 つのフェーズがあります。
ユーザがクラスタへのアプリケーションのデプロイメントを開始すると、準備フェーズが開始される前に、まず WebLogic Server がクラスタ内の管理対象サーバの可用性を確認します。
デプロイメントの準備フェーズでは、ユーザの選択に従ってアプリケーション コンポーネントが対象のサーバ インスタンスに配信され、計画されたデプロイメントが検証されます。クラスタでは、アプリケーションは、個々の管理対象サーバではなく、クラスタに割り当てられる必要があります。準備フェーズの目的は、アプリケーション コンポーネントを正常にデプロイできるかどうかを検証することです。このフェーズの間、デプロイ中のアプリケーションに対するユーザからのリクエストは受け付けられません。
準備フェーズの開始後に障害が発生すると、(準備が正常に完了したサーバ インスタンスを含む) すべてのサーバ インスタンスでデプロイメントが中止されます。ステージングされたファイルは、削除されません。ただし、準備中に行われたコンテナ側での変更は元に戻されます。
活性化の間、アプリケーションとそのコンポーネントが対象のサーバ インスタンスに完全にデプロイされ、デプロイされたアプリケーションがクライアントから利用可能になります。
活性化フェーズの間にサーバ インスタンスで障害が発生すると、そのインスタンスへのデプロイメントはキャンセルされます。1 つの管理対象サーバでそのような障害があっても、クラスタ化されている他のサーバ インスタンスでデプロイメントの活性化が妨げられることはありません。
クラスタ メンバーがアプリケーションのデプロイメントに失敗した場合、クラスタの一貫性を確保するためにそのメンバーは起動できなくなります (管理対象サーバ上でクラスタにデプロイされたアプリケーションに障害があると、その管理対象サーバは起動が中止されます)。
デプロイメント プロセスの間は、クラスタ内のすべての管理対象サーバが実行されて利用可能になっているのが理想です。クラスタの一部のメンバーが利用できない状態でアプリケーションをデプロイすることはお勧めしません。クラスタにアプリケーションをデプロイする前に、できる限り、クラスタ内のすべての管理対象サーバが管理サーバからアクセスできる状態にあるようにしてください。
デプロイメント プロセスの間は、クラスタのメンバシップが変わらないようにしてください。デプロイメントが始まったら、以下のことはしないでください。
WebLogic Server 7.0 のデプロイメントの制限
WebLogic Server 7.0 では、以下の節で説明されているようにクラスタへのデプロイメントで制限が課されていました。
WebLogic Server 7.0 ではクラスタの一部分へのデプロイメントはできない
WebLogic Server 7.0 では、クラスタの一部分へのデプロイメントはできません。クラスタ内の 1 つまたは複数の管理対象サーバが利用できない場合、デプロイメント プロセスは終了し、エラー メッセージが生成されます。そのメッセージは、デプロイメントを試みる前に、アクセス不能な管理対象サーバを再起動するか、クラスタから削除する必要があることを示します。
WebLogic Server 7.0 では固定サービスの複数の管理対象サーバへのデプロイメントはできない
WebLogic Server 7.0 では、クラスタ内の複数の管理対象サーバに固定サービスをデプロイすることはできません。WebLogic Server 7.0 では、アプリケーションがクラスタにデプロイされない場合に、そのアプリケーションをクラスタ内の 1 つの管理対象サーバ (かつその 1 つだけ) にデプロイできます。
WebLogic Server 7.0 SP1 以降でのデプロイメント ルールの「緩和」
WebLogic Server 7.0 SP01 では、WebLogic Server 7.0 のデプロイメントの制限で説明されているデプロイメント ルールが緩和されました。デプロイメントにおいてユーザの自由裁量が認められています。詳細については、以下の節を参照してください。
WebLogic Server 7.0 SP01 以降ではクラスタの一部分にデプロイできる
デフォルトの WebLogic Server 7.0 SP01 以降では、クラスタの一部分にデプロイできます。クラスタの 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 Server 7.0 SP1 以降でのクラスタ全体へのデプロイメント
weblogic.Deployer で enforceClusterConstraints フラグを設定すると、クラスタ内のすべての管理対象サーバがアクセス可能な場合にのみデプロイメントが実行されるようにすることができます。enforceClusterConstraints が「true」の場合は、WebLogic Server 7.0 のデプロイメントの制限で説明されているルールに従ってデプロイメントが実行されます。
WebLogic Server 7.0 SP01 以降での固定デプロイメント
WebLogic Server 7.0 SP01 以降では、クラスタ内の複数の管理対象サーバを固定サービスの対象とすることができます。この操作はお勧めしません。固定サービスをクラスタ内の複数の管理対象サーバにデプロイすると、クラスタのロード バランシング機能とスケーラビリティが悪影響を受けるおそれがあります。複数の管理対象サーバを固定サービスの対象とすると、次のメッセージがサーバ ログに出力されます。
Adding server servername of cluster clustername as a target for
module modulename. This module also includes server servername that
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.
config.xml 内のコンフィグレーション情報を修正する複数の方法が用意されています。
新しいドメインまたはクラスタの作成は、ドメイン コンフィグレーション ウィザードを使用して行うことをお勧めします。ウィザードを使用して実行できるタスクの一覧については、この章で後から説明するドメイン コンフィグレーション ウィザードの機能を参照してください。
Administration Console は、BEA Administration Service にアクセスするためのグラフィカル ユーザ インタフェース (GUI) です。コンソールからは、各種のドメイン コンフィグレーションおよびモニタ機能を実行できます。コンソールを使用して実行できるタスクの一覧については、Administration Console の機能を参照してください。
ドメイン コンフィグレーション ウィザードでは、あらかじめ定義済みのドメイン テンプレートを使用して、ドメインとそのサーバ インスタンスの作成プロセスを簡素化しています。ウィザードではドメイン テンプレートを選択し、作成するサーバ インスタンスのマシン アドレス、名前、ポート番号などの重要な情報を指定します。
注意: ドメイン コンフィグレーション ウィザードでは、リモート マシン上で動作する管理対象サーバ上のドメインに適したディレクトリ構造およびスクリプトを、管理サーバからインストールすることができます。この機能は、管理対象サーバをドメインのバックアップ管理サーバとして使用する必要がある場合に役立ちます。
ウィザードでは、4 つの典型的なドメイン コンフィグレーションから 1 つを選択します。
目的のコンフィグレーション タイプを選択したら、ドメインとそのサーバ インスタンスについての関連情報を指定します。
ドメイン コンフィグレーション ウィザードの使用方法について、詳しくは『WebLogic Server ドメイン管理』の「コンフィグレーション ウィザードを使用した新しいドメインの作成」を参照してください。
この節では、WebLogic Server Administration Console を使用して実行できるタスクの概要を示します。コンソールを使用してこれらのタスクを実行する具体的な手順については、Administration Console オンライン ヘルプを参照してください。
WebLogic Server のコンフィグレーション タスク
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
