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