|
| |
| Sun Java System Message Queue 3.5 SP1 管理ガイド | |
付録 E
技術的な注意点この付録では、次のトピックについての簡単な説明があります。
システムの時計の設定Message Queue システムを使用するときには、システムの時計を同期させ、システムの時計を逆戻りさせないように注意してください。
同期の推奨
Message Queue システムとやり取りするすべてのホストの時計を同期させることをお勧めします。メッセージの有効期限 (TimeToLive) を使用する場合には、これが特に重要です。ホストの時計が同期していないと、メッセージが配信されないなど、TimeToLive が期待どおりに動作をしません。時計は、すべてのブローカを起動する前に同期させる必要があります。
Solaris リモートホストと同期させようとするローカルホスト上で、rdate コマンドを実行できます。このコマンドを実行するには、スーパーユーザー (root) としてログインする必要があります。たとえば次のコマンドは、ローカルホスト (Host 2 とする) を、リモートホストである Host1 と同期させます。
Linux このコマンドは Solaris と似ていますが、次のように -s オプションをつける必要があります。
Windows ローカルホストをリモートホストと同期させるには、net コマンドに time サブコマンドを指定して実行します。たとえば次のコマンドは、ローカルホスト (Host 2 とする) を、リモートホストである Host1 と同期させます。
システムの時計を逆戻りさせない
Message Queue ブローカを実行するシステムでは、システムの時計の設定を逆戻りさせないようにする必要があります。Message Queue では、トランザクションや永続サブスクリプションなどの内部オブジェクトを識別するのにタイムスタンプを使用します。システムの時計の設定が逆戻りすると、論理的には重複した内部識別子が生成されてしまう可能性があります。ブローカは、多少のランダム性を見込んで実行時の時計のずれを検出することにより、これを補うようにしています。しかし、ブローカの実行時以外にシステムの時計が大きく逆戻りした場合は、識別子の重複の危険性がわずかながら発生します。
ブローカを実行するシステムでシステムの時計の設定を数秒以上逆戻りさせる必要がある場合は、トランザクションや永続サブスクリプションがないときに行うようにします。あるいは、ブローカの実行時以外にこれを行い、逆戻りさせた分の時間が経ってからブローカを起動します。
ただし理想的な方法は、すべてのブローカを起動する前に時計を同期させ、導入後は適切な技術を使用して、時計が大きく変動しないようにすることです。
OS で定義されるファイル記述子の制限事項Solaris および Linux プラットフォームでは、クライアントやブローカが実行されるシェルによって、クライアントが使用できるファイル記述子の数に対する弱い制限値があります。Message Queue システムでは、クライアントが行うコネクション、あるいはブローカが受け付けるコネクションはすべて、これらのファイル記述子のどれかを使用します。持続メッセージを持つ送信先もすべて、ファイル記述子を使用します。
その結果、これらの要因によってコネクション数が制限されます。ファイル記述子の制限を変更しないかぎり、ブローカまたはクライアントが、Solaris では 256、Linux では 1024 を超えるコネクションを実行することはできません。持続性のためにファイル記述子を使用したことで生じるコネクション数の制限は、実際にはこの値より小さくなります。
ファイル記述子の制限を変更するには、ulimit マニュアルページを参照してください。クライアントまたはブローカが実行されるそれぞれのシェルに対して、この制限を変更する必要があります。
持続データの保護ブローカは、持続ストアを使用します。ここには、ほかの情報とともに、一時的に保存されるメッセージファイルを保存できます。データストアには、メッセージとともに専有情報を保持できるため、認可されていないアクセスからデータストアを保護することをお勧めします。
ブローカでは、組み込みまたはプラグインのどちらの持続性も利用できます。
組み込み持続ストア
組込みの持続性を利用しているブローカは、プラットフォームに依存するディレクトリ内にある単層ファイルのデータストアに持続データを書き込みます (付録 A 「Message Queue データの場所」を参照)。
instanceName には、ブローカインスタンスを識別する名前が入ります。
instanceName/filestore/ ディレクトリは、ブローカインスタンスがはじめて開始されたときに作成されます。このディレクトリを保護するための手順は、ブローカを実行しているオペレーティングシステムによって異なります。
Solaris および Linux IMQ_VARHOME/instances/instanceName/filestore/ ディレクトリのアクセス権は、そのブローカインスタンスを開始したユーザーの umask によって決まります。したがって、ブローカインスタンスの開始および持続ファイルの読み取りを行うためのアクセス権は、umask を適切に設定することによって制限できることになります。あるいは、スーパーユーザーである管理者は、IMQ_VARHOME/instances ディレクトリのアクセス権を 700 に設定することによって、持続データを保護できます。
Windows IMQ_VARHOME/instances/instanceName/filestore/ ディレクトリのアクセス権は、使用中の Windows オペレーティングシステムが提供するメカニズムを使って設定できます。通常は、そのディレクトリ用のプロパティダイアログが開かれます。
プラグイン持続ストア
プラグインの持続性を使用するブローカは、JDBC に準拠したデータベースに持続データを書き込みます。
Oracle データベースなど、データベースサーバーによって管理されるデータベースについては、Message Queue のデータベーステーブルにアクセスするためのユーザー名とパスワードを作成することをお勧めします。このようなデータベーステーブルには、「IMQ」で始まる名前が付いています。データベースで個々のテーブルの保護ができない場合、Message Queue ブローカだけが使用する専用のデータベースを作成します。ユーザー名とパスワードのアクセス権を作成する方法については、データベースベンダーのマニュアルを参照してください。
データベースコネクションを開くためにブローカが求めるユーザー名とパスワードは、ブローカ設定プロパティとして与えることができます。ただし、ブローカの起動時にコマンド行オプションとして入力するほうがより安全です。『Message Queue 管理ガイド』の付録 A 「プラグイン持続の設定」を参照してください。
Cloudscape データベースなど、データベースの JDBCTM ドライバ経由でブローカが直接アクセスする組み込みデータベースについては、持続データが保存されるディレクトリにファイルアクセス権を設定することによって、通常セキュリティ保護されます。上記の「組み込み持続ストア」を参照してください。ただし、ブローカと imqdbmgr ユーティリティのどちらもがデータベースの読み取りと書き込みができるようにするには、両方を同一のユーザーが実行する必要があります。