デプロイメント ガイド
|
 |
 |
|
以下の節では、AquaLogic Service Bus をクラスタ化環境でコンフィグレーションおよびデプロイする方法を説明します。内容は以下のとおりです。
クラスタ化によって、AquaLogic Service Bus をサーバのグループで実行でき、そのグループを単体ユニットとして管理できます。クラスタ環境では、複数のマシンが負荷を分担します。AquaLogic Service Bus にはロード バランス機能があるので、リソース要求はすべてのマシンに均等に分散されます。AquaLogic Service Bus デプロイメントは、クラスタ化とロード バランスを使用してノードに負荷を分散させることにより、スケーラビリティを向上できます。クラスタ化により、単一サーバよりもスケーラビリティの高いデプロイメント プラットフォームを構築できます。
WebLogic Server クラスタのドメインは、1 台の管理サーバと、1 つまたは複数の管理対象サーバで構成されます。AquaLogic Service Bus ドメインの管理対象サーバを 1 つのクラスタにまとめることができます。AquaLogic Service Bus のクラスタ対応リソースをコンフィグレーションする場合、通常はそのリソースのデプロイ対象とするクラスタを指名します。クラスタをリソース デプロイメントの対象として指定すると、管理対象サーバをクラスタに追加することによって能力を動的に増大できるという利点が得られます。
注意 : AquaLogic Service Bus ドメインでは単一のクラスタをサポートできます。ドメイン内のすべての管理対象サーバがそのクラスタに属する必要があります。
ここでは、クラスタ環境で AquaLogic Service Bus をコンフィグレーションする場合に必要な情報について説明します。WebLogic Server でサポートしているクラスタ化についての予備的な情報も含まれていますが、主に、クラスタ化環境で AquaLogic Service Bus をコンフィグレーションする手順を説明します。
読み進む前に、WebLogic Server マニュアルの以下の節の内容を確認し、クラスタ化について十分に理解しておくことをお勧めします。
以下の節では、クラスタ デプロイメントの設計に必要な情報について説明します。
クラスタ化されたドメインに合わせてアーキテクチャを設計する前に、WebLogic Server クラスタがどのように運用されるかを知っておく必要があります。
ドメインとクラスタの作成は、Configuration Wizard を使用して基本および拡張ドメイン テンプレートからドメインを生成することにより、簡単に実行できます。ユーザのクエリに対する応答を基に、Configuration Wizard によって、ドメイン、サーバ、エンタープライズ アプリケーションなどが、コンフィグレーション済みの適切なコンポーネントおよび資産を含めて生成されます。Configuration Wizard を使用した AquaLogic Service Bus ドメインの作成については、『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』の「新規 WebLogic ドメインの作成」を参照してください。
サーバには管理対象サーバと管理サーバがあります。管理サービスを実行している WebLogic Server は、管理サーバと呼ばれ、WebLogic Server Administration Console のホストとなります。複数の WebLogic Server が稼働しているドメインでは、そのうち 1 つのみが管理サーバで、他のサーバは管理対象サーバと呼ばれます。各管理対象サーバは、起動時に管理サーバからコンフィグレーションを取得します。
WebLogic クラスタの一般情報については、WebLogic Server ドキュメント セットの『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。このドキュメントでは、推奨される基本、多層、およびプロキシ アーキテクチャの詳細について説明されています。WebLogic クラスタ設計のセキュリティに関する考慮事項については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アーキテクチャ」にある「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。
クラスタ化されたドメインの各サーバに対して、そのドメイン内のサーバの機能を定義するさまざまな属性をコンフィグレーションできます。これらの属性は、Configuration Wizard で AquaLogic Service Bus ドメインを作成すると、自動的にコンフィグレーションされます。また上級ユーザの場合は、WebLogic Server Administration Console の [サーバ] ノードを使用して手動でコンフィグレーションすることもできます。
AquaLogic Service Bus デプロイメントのコンフィグレーション可能なリソースの一覧については、「AquaLogic Service Bus デプロイメントのリソース」を参照してください。ここでは、クラスタ化された AquaLogic Service Bus ドメインの各リソースのデフォルトの対象指定について説明し、WebLogic Server Administration Console の各リソースへの移動方法を示しています。
AquaLogic Service Bus で使用されるほとんどのリソースはクラスタ内に均一にデプロイされますが、正しく動作させるには単一の管理対象サーバに固定する必要があるリソースがあります。以下の表に、これらのコンポーネント、その対象指定の方法、および詳細情報へのリンクを示します。
|
|
|
|
AquaLogic Service Bus データ集約機能は、クラスタ内 1 台の管理対象サーバでシングルトン サービスとして実行されます。データの収集は、ドメインの各管理対象サーバで実行されます。集約機能は、ドメインのすべての管理対象サーバからデータを収集し、集約します。集約されたデータは処理され、AquaLogic Service Bus コンフィグレーションごとに分類されます。
AquaLogic Service Bus コンフィグレーションには、システム パフォーマンスのサービス レベル アグリーメント (SLA) を定義するルールを含めることができます。Alert Manager ではルールを格納し、集約されたクラスタ データについてルールを評価します。ルールが true と評価された場合、Alert Manager ではルールに関連付けられているアクションに従って、電子メール メッセージの送信、JMS キューへのメッセージのポスト、またはメッセージのロギングを行います。
これらの機能の詳細については、『AquaLogic Service Bus Console の使い方』の「モニタ」を参照してください。
クラスタのコンフィグレーションを変更できるのは (たとえば、クラスタへの新しいノードの追加やビジネス サービス コンフィグレーションの変更など)、その管理サーバがアクティブな場合のみです。
あるクラスタの管理サーバが使用できなくなると、デプロイ要求やアンデプロイ要求は中断されますが、管理対象サーバは要求の処理を続行します。各管理対象サーバは、必要なコンフィグレーション ファイル (msi-config.xml および SerializedSystemIni.dat) およびオプションの boot.properties がその管理対象サーバのルート ディレクトリに存在する限り、既存のコンフィグレーションを使用して起動および再起動することができます。
注意 : 管理サーバなしで起動された管理対象サーバは、管理対象サーバ独立 (MSI) モードで稼働します。AquaLogic Service Bus では MSI モードの処理をサポートしていません。MSI モードの無効化については、WebLogic Server の『Administration Console オンライン ヘルプ』の「管理対象サーバ独立の無効化」を参照してください。
AquaLogic Service Bus アプリケーションをクラスタ化する目的の 1 つは、スケーラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバを十分に活用する必要があります。ロード バランスにより、クラスタ内のすべてのサーバ間で負荷が均等に分散され、各サーバがそれぞれ最大能力で動作できるようになります。以下の節では、AquaLogic Service Bus クラスタの着信メッセージ処理のロード バランスについて説明します。
着信メッセージのロード バランスの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでのロード バランシング」を参照してください。ビジネス サービスのロード バランスのコンフィグレーションについては、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」で、「ビジネス サービスの追加」の「ビジネス サービスを追加するには - 転送コンフィグレーション」を参照してください。
Web サービス (SOAP または XML over HTTP) では HTTP ロード バランスを使用できます。外部ロード バランスは、WebLogic HttpClusterServlet、WebServer プラグイン、またはハードウェア ルータによって実現できます。ロード バランスを含めたクラスタ トポロジの概要については、図 5-1 を参照してください。
WebLogic Server は、HTTP セッション ステートおよびクラスタ オブジェクトのロード バランスをサポートしています。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでの通信」を参照してください。
AquaLogic Service Bus で使用されるほとんどの JMS キューは分散送り先としてコンフィグレーションされています。この例外は、単一の管理対象サーバに割り当てられている JMS キューです。
JMS ロード バランスの詳細については、『WebLogic JMS のコンフィグレーションと管理』で「WebLogic JMS のチューニング」の「JMS サーバおよび送り先のメッセージのフロー制御」を参照してください。
メッセージ駆動型 Bean は、JMS 送り先からのメッセージを消費します。多くのメッセージ駆動型 Bean が、AquaLogic Service Bus の各送り先にデプロイされます。AquaLogic Service Bus の送り先 (JMS キューおよびトピック) をすべて掲載した一覧については、表 B-1 のサービスのリソース タイプ JMS を参照してください。
複数の物理送り先を 1 つの分散送り先グループのメンバーとしてコンフィグレーションできるため、WebLogic JMS を実装にきわめて高い可用性がもたらされます。具体的には、管理者がクラスタ内の各ノードに対して、各分散送り先に物理送り先を 1 つコンフィグレーションする必要があります。クラスタ内のあるノードに障害が発生して、そのノードの物理送り先が使用できなくなった場合、分散送り先のメンバーとしてコンフィグレーションされた他の物理送り先が、JMS のプロデューサとコンシューマにサービスを提供することができます。この方法で、Configuration Wizard はクラスタのドメインを生成します。
メッセージ駆動型 Bean は、分散送り先からのメッセージを消費します。分散送り先には、WebLogic Server のインスタンスごとに 1 つの物理送り先が含まれます。分散キューの各メッセージ プロデューサは、それぞれ 1 つの物理送り先にバインドされています。メッセージ駆動型 Bean は、デプロイ先のサーバ内の物理送り先にバインドされています (サーバ親和性)。
詳細については、「AquaLogic Service Bus の高可用性について」を参照してください。
コンフィグレーションをデプロイするには、AquaLogic Service Bus Console からエクスポートされた 1 つまたは複数の JAR ファイルの内容をインポートします。クラスタ環境に AquaLogic Service Bus コンフィグレーションをデプロイするときは、単一サーバのデプロイメントと同じ手順に従います。デプロイメント手順については、「手順 4. AquaLogic Service Bus コンフィグレーションのデプロイ」を参照してください。
プロダクション クラスタ環境への AquaLogic Service Bus コンフィグレーションのデプロイメントを準備するときは、単一サーバのテスト環境またはステージング環境の場合より多くのシステム管理タスクが必要になります。プロダクション クラスタ デプロイメントで必要な手順の詳細については、「クラスタ デプロイメントのコンフィグレーション」を参照してください。
|
|
|