ブローカー・ドメインの設計

新規の WebSphere Message Broker ドメインを計画するとき、まず最初にリソース命名規則、WebSphere MQ インフラストラクチャーの設計、およびパフォーマンス問題について考慮する必要があります。以下のトピックでは、これらの考慮事項について説明します。

ブローカー・ドメインを設計する際には、以下の要因を考慮してください。

  1. ブローカー: ドメインが必要とするブローカー数は、以下の要因に依存しています。
    1. パフォーマンス: 必要なメッセージ・スループット (メッセージ・フロー・スループットの最適化を参照)。処理中のメッセージのサイズはどのくらいか? 大容量のメッセージは処理するのに多くの時間がかかります。 少ないブローカー数で多くのメッセージを処理することは、ブローカー・ドメインのパフォーマンスに影響することがあります。ドメイン内のパフォーマンスに関する考慮事項を参照してください。
    2. 相互からアプリケーションを分離する必要があるか? 例えば、技術者用や金融用といった異なる機能を提供するアプリケーションを分離することもできます。
    3. ブローカーはパブリッシュ/サブスクライブを処理する必要があるか?パブリッシュ/サブスクライブ・アプリケーションの開発を参照してください。
  2. ユーザー・ネーム・サーバー: ブローカー・ドメインにユーザー・ネーム・サーバーがある場合、以下を考慮してください。
    1. パフォーマンス: ご使用のブローカー・ドメインに多くのブローカー数がある場合、複数のユーザー・ネーム・サーバーがあれば、ブローカーがユーザー・ネーム・サーバーに送信する要求をさらに早く処理することができます。 ブローカー・ドメインが複雑な場合にも、複数のユーザー・ネーム・サーバーを使用すると有益かもしれません (ネットワーク・トラフィックに関連して)。
    2. 回復力: WebSphere Message Broker はスタンバイ・メカニズムを提供していませんが、最初のユーザー・ネーム・サーバーのシステムでシステム・エラーが発生した場合、2 番目のユーザー・ネーム・サーバーに要求をリダイレクトすることもできます。
  3. 構成マネージャー: これは、ドメインの構成リポジトリーおよびブローカーのセットとワークベンチ間のインターフェースとして機能します。 これは、WebSphere MQ メッセージを使用してブローカーと通信するので、ブローカー・ドメインの多くのブローカーは (きちんと設計されていなければ) 構成マネージャーで輻輳 (ふくそう) を引き起こす可能性があります。 これを解決するためには、ブローカーを、関連したブローカーを保持する複数のドメインに分割することを考慮してください。 各ドメインとの接続を確立できます (ドメイン接続の作成を参照)。
関連概念
ブローカー
ブローカー・ドメイン
構成マネージャー
ユーザー・ネーム・サーバー
関連タスク
パブリッシュ/サブスクライブ・アプリケーションの開発
ワークベンチでのブローカー・ドメインの構成
ブローカー・ドメイン・コンポーネントの構成
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ae03250_