Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Message Queue 3 2005Q1 技術の概要 

第 5 章
ブローカクラスタ

Message Queue Enterprise Edition は、連携動作してクライアントへのメッセージ配信サービスを提供する、ブローカクラスタをサポートしています。クラスタにより、メッセージサーバーは、複数のブローカ間でクライアントコネクションを分散させ、メッセージトラフィックの量に応じてその動作を拡張または縮小することができます。

この章では、ブローカクラスタのアーキテクチャと内部の仕組みについて説明します。次のトピックが含まれます。

ブローカクラスタの設定と管理を担当する管理者、またはクラスタを使用してメッセージングアプリケーションをテストする必要のある開発者は、この章の内容を必ずお読みください。


クラスタのアーキテクチャ

図 5-1 に、ブローカクラスタ構成の Message Queue のアーキテクチャを示します。1 つのクラスタ内のブローカそれぞれは、他のすべてのブローカと直接接続されています。各クライアント (メッセージプロデューサまたはコンシューマ) には 1 つのホームブローカがあります。クライアントは、ホームブローカがサーバー内の唯一のブローカであるかのようにしてメッセージを送受信し、直接通信します。背後では、そのホームブローカがクラスタ内の他のブローカと協調動作し、接続されたすべてのクライアントに配信サービスを提供するときの負荷を分散しています。

クラスタ内では、1 つのブローカをマスターブローカに指定することができます。マスターブローカは、設定変更レコードを保持し、クラスタの持続エンティティ (送信先と永続サブスクリプション) への変更点はそこに記録されます。このレコードを使用して、変更が加えられたときにオフラインだったブローカに変更情報を伝えます。詳細については、次の「クラスタの同期化」を参照してください。

図 5-1 クラスタのアーキテクチャ

図は、クラスタ化された 3 つのブローカを示す。その内 1 つはマスターブローカを示す。図は文字で説明されている。

次の節では、クラスタ内でメッセージ配信が実行される仕組み、および 1 つまたは複数のブローカがオフラインになっていてもブローカを設定および同期する方法について説明します。

メッセージ配信

クラスタ構成では、それぞれの送信先がクラスタ内のすべてのブローカで複製されます。各ブローカは、ほかのすべてのブローカの送信先に対して登録されたメッセージコンシューマを認識しています。これにより各ブローカは、ブローカに直接接続しているメッセージプロデューサから、リモートのメッセージコンシューマにメッセージをルーティングし、リモートのプロデューサから、ブローカに直接接続しているコンシューマにメッセージを配信することができます。

メッセージプロデューサが所有するホームブローカは、そのプロデューサによって作成されたメッセージの場合に、すべてのストレージとルーティングを担当し、すべてのクライアント通知を処理します。クラスタ内のメッセージトラフィックを最小限に抑えるため、メッセージは、ターゲットブローカに接続されたコンシューマにメッセージが配信されることになっている場合にのみ、1 つのブローカから別のブローカに送信されます。複数のコンシューマへのキュー配信などの場合には、ローカルコンシューマへの配信がリモートコンシューマへの配信よりも優先されるように指定して、トラフィックをさらに減らすことができます。クライアントとメッセージサーバーの間で、暗号化による安全なメッセージ配信が必要になる状況では、クラスタを設定して、ブローカ間でセキュリティ保護されたメッセージ配信を実行することも可能です。


いくつかの例外がありますが、クラスタ内の送信先プロパティは、個々の送信先インスタンスよりも、全体としてのクラスタに集合的に適用されます。特定の送信先プロパティについての詳細は、『Message Queue 管理ガイド』を参照してください。


クラスタ設定

起動時にクラスタ内のブローカどうしでコネクションを確立するには、マスターブローカが存在する場合はそれも含め、それぞれのブローカに他のすべてのブローカのホスト名とポート番号を渡す必要があります。この情報は、クラスタ設定プロパティのセットによって指定されます。このプロパティセットは、クラスタ内のすべてのブローカで統一する必要があります。それぞれのブローカの設定プロパティは個別に指定できますが、この方法だと誤りが発生しやすく、クラスタ設定の一貫性が失われる可能性が高くなります。代わりに、設定プロパティのすべてを、起動時に各ブローカが参照する中央の 1 つのクラスタ設定ファイルに記述する方法をお勧めします。これにより、すべてのブローカで確実に同じ設定情報を共有できます。

クラスタ設定プロパティについての詳細は、『Message Queue 管理ガイド』を参照してください。


クラスタ設定ファイルは、設定のために使用するのが本来の目的ですが、クラスタ内の他のすべてのブローカと共有する他のプロパティを保管するためにも便利な場所です。


クラスタの同期化

クラスタの設定が変更されると、どんな場合でも変更に関する情報がクラスタ内のすべてのブローカに自動的に伝播されます。伝播される設定変更には、次の情報が含まれます。

こうした設定変更情報は、変更が行われたときにオンラインになっている、クラスタ内のすべてのブローカに即座に伝播されます。ただし、クラッシュなどのためにオフラインになっているブローカは、変更が生じたときに変更の通知を受け取りません。オフラインブローカに対処するため、Message Queue はクラスタの設定変更記録を保持し、作成または破棄されたすべての持続エントリ (送信先および永続サブスクリプション) を記録します。オフラインからオンラインに戻ったブローカや、クラスタに新しく追加されたブローカは、この記録を参照して送信先および永続サブスクライバに関する情報を調べ、現在アクティブなメッセージコンシューマに関して他のブローカと情報を交換します。

マスターブローカに指定されたクラスタ内の 1 つのブローカは、設定変更記録を保守する役割を担います。他のブローカはマスターブローカなしで初期化を完了できないので、マスターブローカはクラスタ内で必ず最初に起動してください。マスターブローカがオフラインになると、他のブローカが設定変更記録にアクセスできないので、設定情報をクラスタ内全体に伝播できなくなります。このような状況では、送信先または永続サブスクリプションを作成または破棄しようとしたり、永続サブスクリプションの再有効化のような関連性のある操作を実行しようとしたりすると、例外が生じます。ただし、非管理メッセージ配信は、通常どおり動作を続けます。


開発環境

ブローカクラスタの使用方法は、開発環境と運用環境のどちらの環境に配備されているかによって異なります。

開発環境

クラスタをテストに使用し、スケーラビリティやブローカの復元が重視されない開発環境では、マスターブローカの必要性はほとんどありません。多くのテスト環境では、送信先が自動作成 (「自動作成の送信先」を参照) され、これらの送信先の永続サブスクリプションは、テスト対象のアプリケーションによって作成および破棄されます。マスターブローカが存在しない場合、Message Queue はほかのブローカを起動するために、マスターブローカを実行する要件を緩和し、送信先や永続サブスクリプションが変更されて実行中のすべてのブローカに伝播されるのを許可します。ただし、一度オフラインになってから復元された場合、ブローカはオフライン中に行われた変更情報によって同期されません。マスターブローカを使用するように環境を再設定すると、Message Queue は通常の要件を再適用します。

運用環境

スケーラビリティとブローカの復元が重要視される運用環境では、マスターブローカを使用して設定変更記録を保守することが欠かせません。これにより、ブローカが一度オフラインになってから復元された場合でも、オフライン中に行われた変更情報によってブローカを同期します。

実際、設定変更記録の偶発的な破損やマスターブローカで発生する障害から保護するため、設定変更記録を定期的にバックアップすることをお勧めします。Message Queue には、設定変更記録をバックアップして復元する場合のコマンド行オプションが用意されています。必要に応じて、マスターブローカとしてサービスを提供するブローカを変更することもできます。詳細は、『Message Queue 管理ガイド』を参照してください。



前へ      目次      索引      次へ     


Part No: 819-2221.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.