test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

第 9 章 Messaging Server ソフトウェアの紹介

Sun Java System Messaging Server は、企業とサービスプロバイダの両方で要求される大容量で信頼性の高いメッセージング処理のために設計された、強力なインターネットメッセージングサーバーです。サーバーはモジュール化された、個別に構成可能な複数のコンポーネントから成り立っています。これらのコンポーネントは、さまざまな電子メールプロトコルをサポートしています。

Messaging Server は、ユーザー、グループ、およびドメインについての情報を格納するために一元化された LDAP データベースを使用します。サーバー設定についてのいくつかの情報は LDAP データベースに格納されます。また、ローカル設定ファイルに格納される情報もあります。

Messaging Server 製品群には、ユーザーのプロビジョニングやサーバーの構成をサポートするツールが含まれています。

この章には、次の節があります。

メッセージングシステムとは

すぐれた電子メールシステムアーキテクチャーでは、埋め込まれたサウンド、画像、ビデオファイル、HTML 形式とともに電子メールが迅速に配信され、将来のアップグレードへの対応とスケーラビリティを提供します。単純化すると、Messaging Server アーキテクチャーは次の機能を備える必要があります。

電子メールシステムアーキテクチャーの中心はメッセージングサーバー自体で、これはメッセージの送信と配信に使用されるコンポーネントの集合体です。Messaging Server で提供されるコンポーネントとは別に、電子メールシステムでは LDAP サーバーと DNS サーバーも必要となります。DNS サーバーは、電子メールシステムを配備する前に配置しておく必要があります。

効率性とスケーラビリティ以外にも、いくつかの要素が Messaging Server アーキテクチャーに影響を与えます。これらの要素を次に示します。

これらのトピックの詳細については、第 11 章「Messaging Server アーキテクチャーの開発」を参照してください。

Messaging Server がサポートする標準と機能

この節では、Messaging Server がサポートする標準について説明するほか、Messaging Server がサポートするその他の機能についても説明します。

標準プロトコルのサポート

Messaging Server は、電子メッセージングに関連するほとんどの国内規格、国際規格、および業界規格をサポートしています。完全なリストは、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の付録 A「Supported Standards」を参照してください。

ホストされているドメインのサポート

Messaging Server は、ISP にアウトソースされた電子メールドメインのようなホストされているドメインを完全にサポートしています。つまり、ISP は組織の電子メールサービスをリモートで操作および管理することにより組織をホスティングする電子メールドメインを提供します。ホストしているドメインは、ほかのホストしているドメインと同じ Messaging Server ホストを共有することができます。初期の LDAP ベースの電子メールシステムでは、1 つのドメインが 1 つまたは複数の電子メールサーバーホストによってサポートされていました。Messaging Server では、複数のドメインを単一のサーバーでホストできます。ホストされている各ドメインには、そのドメインのユーザーとグループのコンテナを指し、さまざまなドメイン固有のデフォルト設定を提供する LDAP エントリがあります。

ドメインを定義する場合、そのドメインに対応するドメインエントリがディレクトリ内に存在する必要があります。つまり、そのドメインに対する LDAP エントリを作成する必要があります。mailAlternateAddress や mailEquivalentAddress などの属性は、ディレクトリ内のドメインエントリの存在に依存します。これは、バニティドメインの場合とは対照的です。バニティドメインは、特定のサーバーやホストされたドメインに関連付けられるのではなく、特定のユーザーに関連付けられたドメイン名です。バニティドメインの場合、そのドメイン名に対する LDAP エントリは存在しません。

注 –

バニティドメインを使用すると処理時のオーバーヘッドが増大します。したがって、その使用はお勧めできません。

ユーザーのプロビジョニングのサポート

Messaging Server は、ユーザー、グループ、およびドメインについての情報を格納するために一元化された LDAP データベースを使用します。現在、Messaging Server は Sun Java System LDAP スキーマバージョン 1 (スキーマ 1) と Sun Java System LDAP スキーマバージョン 2 (スキーマ 2) の 2 つのスキーマオプションをサポートしています。プロビジョニングオプションは、選択されたスキーマにより異なります。詳細については、第 15 章「Messaging Server インストール前の考慮事項と手順について」を参照してください。

スキーマ 2 の Messaging Server プロビジョニングは、Delegated Administrator を使って行います。これについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。

スキーマ 1 は、メッセージング用 iPlanet Delegated Administrator 製品によってサポートされています。この製品には、組織内のユーザー、グループ、およびドメインを管理するために、グラフィカルユーザーインタフェースとコマンド行ユーティリティーが用意されています。スキーマ 1 におけるユーザー、グループ、およびドメイン管理については、以前のリリースのソフトウェアに関する次のマニュアルを参照することもできます。

注 –

Access Manager コンソールは、Messaging Server と Calendar Server の LDAP ユーザーエントリに対し、Access Manager サービスによる最小限のプロビジョニング機能を提供します。インタフェースには入力を確認する機能がないため、電子メールを受け取ることができないユーザーエントリや動作しないユーザーエントリが、エラーが報告されることなく作成されてしまいます。そのため、このインタフェースはデモの目的でだけ使用します。

『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』で説明している Delegated Administrator は、Communications Services ユーザーをプロビジョニングするための推奨メカニズムです。

統一されたメッセージングのサポート

Messaging Server は完全な、統一されたメッセージングソリューションの基盤となります。統一されたメッセージングとは、電子メール、ボイスメール、FAX、ビデオ、およびそのほかの通信形態に関して単一のメッセージストアを使用するという概念です。

Web メールのサポート

Messaging Server は現在、次の 2 つのクライアント向けユーザーインタフェース (UI) をサポートしています。

今後、Messenger Express ユーザーインタフェースに新機能が追加されることはありません。Messaging Server は非推奨となり、代わって Communications Express が推奨のユーザーインタフェースとなりました。Sun Microsystems, Inc. は後日、Messenger Express の生産中止スケジュールを発表する予定です。

詳細については、Communications Express のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1312.1

Messaging Server のセキュリティとアクセス制御

Messaging Server には、次のセキュリティとアクセス制御の機能があります。

Messaging Server の管理ユーザーインタフェース

Messaging Server はモジュール化された、個別に構成可能な複数のコンポーネントから成ります。これらのコンポーネントは、電子メールの転送とアクセスプロトコルをサポートしています。

メッセージ転送エージェント (MTA) を設定するために、Messaging Server には、サーバー上にローカルに格納されたコマンド行ユーティリティーと設定ファイルの完全なセットが用意されています。また、メッセージストアおよびメッセージアクセスサービスを設定するために、コンソールグラフィカルユーザーインタフェースとコマンド行ユーティリティーの完全なセットが用意されています。

詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

Messaging Server のソフトウェアアーキテクチャー

図 9–1 は、スタンドアロンの Messaging Server を簡略化して示しています。この特別な配備は、スケーラビリティが低いため、大規模配備にはお勧めできませんが、Messaging Server の個々のコンポーネントを示しています。

図 9–1 スタンドアロンの Messaging Server の簡略化したコンポーネント表示

この図は、Messaging Server ソフトウェアコンポーネントを簡略化して示したものです。

この図は、次の Messaging Server ソフトウェアコンポーネントを示しています。

簡略化した Messaging Server システムを通したメッセージパス

インターネットまたはローカルクライアントからの受信メッセージは、Simple Mail Transport Protocol (SMTP) を通じて MTA によって受信されます。内部アドレスの場合、すなわち Messaging Server ドメイン内の場合は、MTA はメッセージをメッセージストアに配信します。メッセージが外部宛て、すなわち Messaging Server の制御外のドメイン宛ての場合、MTA はメッセージをインターネット上の別の MTA にリレーします。

UNIX システムの場合に限り、/var/mail ファイルシステムにメールを配信することも可能ですが、ローカルメッセージは通常、より最適化された Messaging Server メッセージストアに配信されます。次に、IMAP4、POP3 、または HTTP メールクライアントプログラムがメッセージを取得します。

メールクライアントからの送信メッセージは MTA に直接送られ、そこでインターネット上の適切なサーバーに送信されます。アドレスがローカルの場合は、MTA はメッセージをメッセージストアに送信します。

新しいユーザーとグループは、ディレクトリにユーザーとグループのエントリを追加することで作成されます。Communications Services Delegated Administrator ユーティリティーを使用するか、LDAP を使用してディレクトリを変更することで、エントリを作成または変更することができます。

Messaging Server コンポーネントは、管理サーバーコンソールを使って管理できます。さらに、Messaging Server には一連のコマンド行インタフェースと設定ファイルも用意されています。より一般的な管理タスクとしては、メールシステムへのユーザーやグループの追加、変更、削除や、MTA、ディレクトリサーバー、およびメッセージングストアの操作の設定があります。

メッセージ転送エージェント (MTA)

MTA は、Messaging Server に宛てられたインターネットメールメッセージのルーティング、転送、および配信を行います。メールは、「チャネル」と呼ばれるインタフェース内を通過します。各チャネルは、1 つまたは 1 組のエージェントプログラムと一連の設定情報とで構成されます。エージェントプログラムには、チャネルに入ってきたメールを処理する「スレーブプログラム」と、チャネルを出ていくメールを処理する「マスタープログラム」があります。任意のチャネルに関連付けられた 1 つ以上のインタフェースに送られるメッセージを格納するためのメッセージキューがあります。Messaging Server には、次のような数多くのチャネルがデフォルトで用意されています。

図 9–2 は、このプロセスを示したものです。チャネルを個別に設定し、アドレスに基づいてメールを特定のチャネルに送ることもできます。

図 9–2 チャネルアーキテクチャー

この図は、Messaging Server のチャネルアーキテクチャーを示します。

チャネルプログラムは、次の 2 つの機能の 1 つを実行します。

チャネルの設定は、imta.cnf 設定テキストファイルを使用して行います。チャネル設定を通じて、さまざまな「チャネルキーワード」を設定してメッセージの処理方法を制御できます。チャネルキーワードは、パフォーマンスの調整とシステムのレポーティング面に影響を与えます。たとえば、複数のチャネルを定義してトラフィックを送信先別に分類し、メッセージサイズを制限してトラフィックを制限し、業務のニーズに応じて配信状態通知規則を定義します。診断属性もチャネル単位で設定可能です。かなりの数の設定パラメータが、チャネルベースで設定可能です。

MTA の概念の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 8 章「MTA の概念」を参照してください。

LDAP 直接検索

MTA は、情報の検索を LDAP サーバーに対して直接行います。直接検索により、MTA と LDAP サーバーとの関係がスケーラブルで高速かつ設定可能になります。LDAP クエリの結果は設定可能なサイズと時間でプロセスにキャッシュされるため、パフォーマンスの調整が可能です。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

書き換え規則

メールは、「ドメイン書き換え規則」(略して「書き換え規則」) が適用された送信先アドレスの実行結果に基づいて、チャネルにルーティングされます。書き換え規則は、アドレスを真のドメインアドレスに変換し、それに対応するチャネルを決定するために使用されます。これらの規則は、「トランスポート層」と「メッセージヘッダー」の両方に表示されるアドレスを書き換えるために使用されます。トランスポート層は、メッセージのエンベロープです。ルーティング情報はユーザーには見えない形で含まれていますが、実際の情報はメッセージを適切な受信者に配信するのに使用されます。

書き換え規則とチャネルのテーブルは、協力してそれぞれのアドレスの処置を決定します。書き換えプロセスの結果により、アドレスとルーティングシステム、すなわちメッセージが送信またはキューイングされるシステム (チャネル) が書き換えられます。ネットワークのトポロジ次第で、ルーティングシステムはメッセージが送信先までにたどるパスの最初のステップである場合もあれば、最終の送信先システムである場合もあります。

書き換えプロセスが終了すると、imta.cnf ファイルのチャネル部分に対してルーティングシステムの検索が行われます。それぞれのチャネルには、チャネルに関連付けられた 1 つ以上のホスト名があります。ルーティングシステム名がそれぞれのホスト名と比較されて、メッセージがどのチャネルのキューに入れられるかが決定されます。次に簡単な書き換え規則を示します。

example.com     $U%example.com@tcp_siroe-daemon

この規則は、ドメイン example.com のアドレスだけを検索します。一致したアドレスは、次に示すテンプレート$U%$D を使用して書き換えられます。

$U

アドレスのユーザーの部分またはアドレスの左側 (@ の前) を示します

%

@ 符号を示します

$D

アドレスのドメインの部分またはアドレスの右側 (@ の後ろ) を示します

このように、wallaby@thor.example.com の形式のメッセージが wallaby@example.com に書き換えられ、tcp_siroe-daemon をチャネルホスト名に持つチャネルに送信されます。

書き換え規則は、マッピングテーブル、LDAP ディレクトリ検索、およびデータベース参照に基づいて、高度な置換を行うこともできます。暗号のようなわかりにくいものになる場合もありますが、書き換え規則が低レベルで動作し、処理サイクルへの直接のオーバーヘッドがほとんどない点が便利です。書き換え規則の詳細と書き換えプロセスで利用できる機能については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 11 章「書き換えルールの設定」を参照してください。

ジョブコントローラ

マスターチャネルプログラムは、ジョブコントローラの制御下で実行されます。ジョブコントローラは、メッセージキューを制御し、実際のメッセージ配信を行うチャネルプログラムを呼び出すプログラムです。ジョブコントローラはマルチスレッドプロセスであり、Messaging Server システムに常駐している数少ないプロセスの 1 つです。チャネル処理ジョブ自体は、ジョブコントローラにより作成されますが、一時的なジョブで、実行する作業がない場合は存在しなくなります。

ジョブコントローラの設定により、チャネル処理プログラムのインスタンスが常に少なくとも 1 つ存在するかどうかが決まります。多くの場合は、すぐに実行する作業がなくてもサービスプログラムのインスタンスが少なくとも 1 つは常に存在するように設定されます。それ以外の場合は、現在行うべき作業がなくなってから一定期間の間インスタンスが存在することになります。

外部メッセージを受け入れたスレーブチャネルは、メッセージをキューイングすることにより、新しいメッセージファイルが作成されたことをジョブコントローラに通知します。ジョブコントローラは、この情報を内部データ構造に入力し、必要に応じてそのキュー内のメッセージを処理するマスターチャネルジョブを作成します。ジョブコントローラで、既存のチャネルジョブが新しくキューイングされたメッセージファイルを処理できるように設定されている場合は、このジョブを作成する必要はありません。マスターチャネルジョブは、ジョブが開始されると、ジョブコントローラからメッセージ割り当てを取得します。メッセージの処理を終了すると、マスターチャネルはその処理のステータスに応じてジョブコントローラを更新します。そのステータスは、メッセージが正常にキューから削除されたか、メッセージの再配信スケジュールが組まれたかのいずれかになります。

ジョブコントローラは、メッセージの優先度と失敗した配信に関する情報を維持し、チャネルジョブに優先的なスケジュールを許可します。ジョブコントローラは、各ジョブの状態の追跡も行います。ジョブの状態は、アイドル、アイドルの時間、ジョブがビジーであるかどうかです。状態の追跡により、ジョブコントローラはチャネルジョブの最適なプールを維持できます。

注 –

現時点で存在しているスレーブチャネルは、SMTP スレーブと LMTP スレーブの 2 つだけです。次に、これらのプログラムを制御するディスパッチャーについて説明します。

ディスパッチャー

ディスパッチャーは、Messaging Server システムに常駐しているもう 1 つのプロセスです。これはマルチスレッドのトラフィックディスパッチャーであり、着信した SMTP 接続または LMTP 接続を、プロトコル固有の処理が行えるように SMTP サーバースレッドまたは LMTP サーバースレッドのプールへと振り分けます。SMTP サーバープログラムと LMTP サーバープログラムは、ディスパッチャーによって制御されるワークスレッドのプールを提供します。メッセージ処理 (メッセージの拒否または送信先チャネルへのメッセージのキューイング) が完了すると、ワークスレッドは、ディスパッチャーから別の作業を受け入れられる状態になります。

ディスパッチャーは IP アドレスに基づいて着信トラフィックをブロックできるため、サービス拒否攻撃を回避することができます。また、ディスパッチャーは、負荷と設定に基づく SMTP サーバープロセスまたは LMTP サーバープロセスの作成およびシャットダウンも行います。このように、SMTP または LMTP のスレーブチャネルプログラムは、ジョブコントローラの制御下ではなく、ディスパッチャーの制御下にあります。

Local Mail Transfer Protocol (LMTP)

Messaging Server 6.0 リリースでは、複数階層配備におけるメッセージストアに配信を行う LMTP 設定が可能になりました。インバウンドリレーとバックエンドメッセージストアが使用されるこのような環境では、アドレス拡張、自動返信や転送などの配信方法、およびメーリングリストの拡張などに関してリレーが重要な役割を果たします。

バックエンドストアへの配信はこれまで SMTP 上で行われてきました。SMTP では、バックエンドシステムで LDAP ディレクトリの受取人アドレスを再度調べる必要があるため、MTA の全機能が使用されます。速度と効率性を向上するために、MTA では SMTP ではなく LMTP を使用してバックエンドストアにメッセージを配信できます。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 15 章「LMTP 配信」を参照してください。

注 –

LMTP は、複数階層配備で使用されるように設計されています。LMTP を単一システム配備で使用することはできません。Messaging Server に実装されている LMTP サービスは、ほかの LMTP サーバーまたは LMTP クライアントと連携して動作するように設計されていません。

メッセージストア

メッセージストアは、インターネットメールメッセージの配信、取得、および操作の ための専用のデータストアです。メッセージストアは IMAP4 および POP3 クライアントアクセスサーバーとともに動作し、メッセージへの柔軟で容易なアクセスを提供します。また、メッセージストアは HTTP サーバー (mshttpd) 経由でも動作します。これにより、Web ブラウザ内の Communications Express に対してメッセージング機能が提供されます。詳細については、この節のほかに、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

メッセージストアは、一連のフォルダまたはユーザーメールボックスとして構成されます。フォルダまたはメールボックスは、メッセージのコンテナです。それぞれのユーザーには、新しく受信したメールが入る INBOX があります。それぞれの IMAP ユーザーまたは Web メールユーザーには、メールを格納できる 1 つ以上のフォルダがあります。フォルダには、他のフォルダを階層構造で含めることができます。個別のユーザーが所有するメールボックスは非公開フォルダです。非公開フォルダは、所有者の判断で、同じメッセージストア内のほかのユーザーと共有できます。Messaging Server は、IMAP プロトコルによる複数ストア間でのフォルダ共有をサポートします。

メッセージストアには、ユーザーファイルとシステムファイルの 2 つの一般領域があります。ユーザー領域では、それぞれのユーザーの INBOX の位置が 2 階層ハッシングアルゴリズムを使用して決定されます。それぞれのユーザーのメールボックスまたはフォルダは、その親フォルダ内の別のディレクトリとして表されます。各メッセージは 1 つのファイルとして格納されます。フォルダ内に大量のメッセージがある場合は、システムによりフォルダのハッシュディレクトリが作成されます。ハッシュディレクトリを使用することで、フォルダに大量のメッセージがある場合にファイルシステムが抱える負担が軽減されます。メッセージストアでは、メッセージ自体のほかに、メッセージヘッダー情報の索引とキャッシュ、およびその他の頻繁に使用されるデータが維持されるため、クライアントはメールボックスの情報を迅速に取得し、個別のメッセージファイルにアクセスすることなく一般的な検索を実行できます。

メッセージストアには、多くのユーザーファイル用メッセージストアパーティションを含めることができます。メッセージストアパーティションは、ファイルシステムボリュームに格納されます。ファイルシステムがいっぱいになると、追加のファイルシステムボリュームを作成し、それらのファイルシステムボリューム上に新しいユーザーを格納するためのメッセージストアパーティションを作成できます。

注 –

パーティションがいっぱいになると、そのパーティション上のユーザーは、新たなメッセージを格納できなくなります。この問題を解決するには、次の方法があります。

詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 18 章「メッセージストアを管理する」を参照してください。

メッセージストアは、パーティションごとにメッセージそれぞれのコピーを 1 つずつだけ維持します。これは、シングルコピーメッセージストアとも呼ばれます。メッセージストアが複数のユーザー、グループ、または配信リストに宛てられたメッセージを受信した場合、それぞれのユーザーの INBOX にそのメッセージへの参照を追加します。メッセージストアでは、メッセージのコピーをそれぞれのユーザーの INBOX に保存するのではなく、同じデータを重複して保存しないようにしています。既読、返信済み、削除などの個別メッセージステータスのフラグは、それぞれのユーザーのフォルダごとに維持されます。

システム領域には、メッセージストア全体の情報が特定のデータベース形式で格納されており、高速なアクセスを実現しています。システム領域内の情報は、ユーザー領域から再構築できます。Messaging Server にはデータベーススナップショット機能が含まれています。必要な場合には、データベースを既知の状態に迅速に回復できます。Messaging Server には高速回復機能もあり、データベースが破損した場合には、データベース再構築のために長い時間待つことなく、メッセージストアをシャットダウンして、すぐに元の状態に戻すことができます。

メッセージストアはユーザー単位の割り当てをサポートします。割り当ての拡張は有効にすることも無効にすることもできます。ユーザー割り当ては、バイト数またはメッセージ数を使用して設定できます。しきい値を設定して、割り当てがしきい値に達した場合には、ユーザーに警告を出すこともできます。ユーザーが割り当てを超過した場合は、猶予期間中の新規メッセージは保留され、再試行されます。猶予期間の後で、割り当てを超過したユーザーに送信されたメッセージは、未送信通知と共に送信者に返されます。

割り当てを使用する特別なアプリケーションで、ユーザーの割り当てステータスに関係なくメッセージが配信されなければならない場合には、保証メッセージ配信チャネルがあります。このチャネルは、割り当てステータスに関係なくすべてのメッセージを配信するのに使用できます。割り当て使用率のレポートと割り当て警告の送信を行うユーティリティーも用意されています。

Messaging Server とディレクトリサービス

Messaging Server は、Sun Java System Directory Server にバンドルされています。Directory Server は、LDAP (Lightweight Directory Access Protocol) ディレクトリサービスです。Directory Server は、Messaging Server の運用に不可欠な情報のための中央リポジトリを提供します。この情報には、ユーザープロファイル、配信リスト、およびその他のシステムリソースなどが含まれます。

ディレクトリ情報ツリー

ディレクトリは、ディレクトリ情報ツリー (DIT) として知られるツリー形式でデータを格納します。DIT は、ツリーの最上部に 1 つの主要ブランチがあり、その下にブランチおよびサブブランチがある階層構造です。DIT は、組織のニーズに合わせた配備の設計を可能にする柔軟性を備えています。たとえば、実際の業務組織構造に従った DIT の配置を選択することも、業務の地理的なレイアウトに従って選択することもできます。また、使用する DNS レイヤーに 1 対 1 でマッピングした DIT を設計することもできます。実稼働後の DIT の変更は大変な作業となるため、DIT の設計は慎重に行なってください。

DIT は、幅広い管理シナリオに適応する柔軟性も備えています。DIT は、集中型でも分散型でも管理できます。集中型の管理では、1 つの権限で DIT 全体を管理します。集中型管理の場合は、DIT 全体を 1 つのメールサーバー上に配置して使用します。分散型管理では、複数の権限で DIT を管理します。通常は、DIT がいくつかの部分、サブツリー、または異なるメールサーバーに分割された場合に分散型管理を用います。

DIT が大規模な場合、またはメールサーバーが地理的に分散されている場合は、DIT の一部の管理を委託することも検討します。通常は、DIT のそれぞれのサブツリーを管理する権限を割り当てます。Messaging Server では、1 つの権限で複数のサブツリーの管理が可能です。ただしセキュリティ上の理由で、権限は、その権限が所有する DIT のサブツリーの変更だけが可能となっています。

Access Manager が使用されない場合に Messaging Server が使用するデフォルトのスキーマは、Access Manager が使用するスキーマとは異なります。Messaging Server は、Sun Java System LDAP スキーマ 1 および 2 をサポートしており、スキーマの切り替えと移行も可能です。

ディレクトリのレプリケーション

Directory Server はレプリケーションをサポートしており、冗長性と効率性を実現するさまざまな設定が可能です。1 つのホストから別のホストへの DIT の全部または一部をレプリケーションすることで、次の設定機能が利用できます。

ディレクトリのレプリケーション、ディレクトリパフォーマンスの調整、DIT 構造と設計の詳細については、Sun Java System Directory Server のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1316.1

メッセージングユーザーのプロビジョニング

Messaging Server ユーザーに対するスキーマとプロビジョニングのオプションについては、第 8 章「スキーマとプロビジョニングのオプションについて」を参照してください。