Version 5.1
クラスタ |
|---|
| |||||||
|
|
Version 5.1 |
|||||||||||||||||||||||||||||
|
|
サイトのドメインの数が多いときには、独立したCommuniGate Pro サーバーを複数使用し、ドメイ ンを各サーバーに分散することで、負荷の分散が可能です。この方法を使う場合、CommuniGate Pro サーバーのクラスタ機能を使用する必要はありません。ただし、単一のドメインのアカウント数が 100,000 を超えるようなときには、一般にクライアントからサーバーに対する接続は必ずしも効率的 には実行されず、また、動的ロードバランシングと高いアベイラビリティが要求されます。こう いった場合、CommuniGate Pro のクラスタ機能を使うことが必要です。
クラスタという語は、単にフェイルオーバーやホットスタンバイ（障害時代替サーバー環境） の意 味で使われることが多いようです。CommuniGate Pro サーバーは、このフェイルオーバー環境のサー バーのほか、分散ドメイン環境のサーバーとしても使用できます。ただし、こういった環境は、厳 密にはCommuniGate Pro のクラスタ環境とは異なります。
CommuniGate Pro のクラスタ環境とは、複数のコンピュータで構成され、各コンピュータ（サー バー） でサイトのメールロード（ メール処理負荷） が一括して処理されるような環境をいいます。 クラスタに属するサーバーではそれぞれ、通常の非共有ドメイン（複数のセット） の一部（例えば、 CommuniGate Pro のメインドメイン。メインドメインは必ず非共有ドメインとして扱われます）、共 有ドメイン（複数のセット） の一部に関する処理も実行されます。
なお、CommuniGate Pro サーバーをクラスタ環境で使用する場合、CommuniGate Pro クラスタライセ ンスが別途、必要です。
メールサーバーの負荷の予測、また、CommuniGate Pro サーバーをクラスタ（複数サーバー） 環境で 使用する場合の設定などについては、「拡張性」のセクションに説明があります。
クラスタ環境の種類としては、静的クラスタ環境とダイナミッククラスタ環境の2 つがあります。
静的クラスタとは、共有ドメインのアカウントが、いずれかのサーバーに作成され、またホストされ るような環境をいいます。作成されたアカウントに対しては、そのサーバー（ホストサーバー） から のみ直接アクセスが可能です。ホストサーバーのアカウントに対して、静的クラスタの別のサーバー からアクセスが必要になった場合、別のサーバーからホストサーバーに対してTCP/IP 接続が確立さ れ、ホストサーバーを介してアカウントのデータにアクセスが実行されます。静的クラスタの場合、 ローカル（非共有） ストレージデバイスにアカウントのデータを格納できます。
注意: ベンダーによっては、「メールマルチプレックサ」製品を提供しています。このタイプの製品で は、通常、静的クラスタフロントエンド機能（サブセット） がサポートされています。
ダイナミッククラスタとは、共有ドメインのアカウントが共有ストレージに格納されるような環境を いいます。この共有ストレージのアカウントのデータに対しては、ダイナミッククラスタに属する各 サーバー（ クラスタサーバーと呼びます。ただし、フロントエンドサーバーは除きます。下記を参 照） から直接アクセスが可能です。クラスタサーバーのうち、いずれか１ つがクラスタコントローラ として動作し、このコントローラによって、共有ドメインのアカウントに対するアクセス処理の同期 がとられます。いずれかのクラスタサーバーで、別のサーバー上でオープンされているアカウントについて何らかの 処理が必要になった場合、クラスタサーバーから別のサーバー（カレントのホストサーバー） に対し てTCP/IP 接続が確立され、そのホストサーバーを介してアカウントのデータにアクセスが行われま す。ダイナミッククラスタでは、最高のアベイラビリティ（少なくてもサーバーが１ つ動作していれ ば、すべてのアカウントにアクセスが可能です） が得られ、また、ストレージデバイスに対してファ イルロック処理を行う必要はありません。
クラスタ環境では、静的クラスタまたはダイナミッククラスタのいずれでも通常、フロントエンドサー バーが存在します。フロントエンドサーバーは特殊なサーバーで、フロントエンドサーバーからアカ ウントのデータに直接アクセスすることはできません。その代わり、フロントエンドサーバーは、別 のサーバー（バックエンドサーバー） と常時接続されており、この接続を介して、アカウントのデー タに対して処理が実行されます。
フロントエンドサーバーの主な機能は、クライアントコンピュータからのTCP/IP 接続要求（通常、イ ンターネット経由） の受け取りです。したがって、典型的なフロントエンド/ バックエンド構成の場 合、フロントエンドサーバーにアカウントが作成されることはありません。ただし、必要であれば、 フロントエンドサーバーに直接、ドメインを格納することもできます（ ドメインとともにアカウント とメーリングリストの格納も可能です）。
クライアントからフロントエンドサーバーに対して接続が確立され、認証情報（アカウント名） が送 信されると、フロントエンドサーバー上で、そのアカウントのオープンが可能なバックエンドサーバーが検出されます。検出後、そのバックエンドサーバーとフロントエンドサーバーとの間で接続が確立 されます。
接続の確立後、フロントエンドサーバーでは次のような処理が実行されます。フロントエンドサーバーがインターネットに直接暴露されると、フロントエンドサーバーのオペレー ティングシステムのセキュリティが脆弱化し、その結果、不法な第三者がフロントエンドサーバーの オペレーティングシステムにアクセスできる可能性が発生します。ただし、その場合でも、サイトの セキュリティが完全に脆弱化することはありません。これは、フロントエンドサーバーのディスクに はアカウント情報（ メールボックスやパスワード） は存在せず、アカウント情報が盗まれることはな いためです。そのため、不法な第三者（ クラッカー） は、ファイアウォールを通過し、バックエンド サーバーのオペレーティングシステムのセキュリティを破るという方法でしか、アカウント情報にア クセスできません。この方法も、フロントエンドサーバーとバックエンドサーバーとの間のネットワー ク通信をすべて無効にし、CommuniGate Pro のサーバー間通信だけを残すことで防御できます。
静的クラスタとダイナミッククラスタはどちらも、専用のフロントエンドサーバーなしで動作します。 このシステム形態は対称構成と呼ばれており、このシステム形態の場合、各クラスタサーバーがフロ ントエンドサーバーとバックエンドサーバーの両方の機能を担当します。
例えば、静的クラスタ環境でクラスタサーバーが3 つあり（SV1、SV2、SV3）、この3 つのサーバー
にdomain1.dom とdomain2.dom の2 つのドメインのアカウントが分散して格納されており、各サー
バーで、この2 つのドメインに対する受信接続が受け付けられるとします（後述の「静的クラスタ」
の説明を参照）。ここで、サーバーSV1 で、サーバーSV2 のアカウントkate@domain1.dom に対す
る接続要求が受信されたとします。その場合、サーバーSV1 がフロントエンドサーバーとして処理
を開始し、このサーバーSV1 からサーバーSV2 に接続が実行され、その後の処理が行われます。つ
まり、サーバーSV2 がバックエンドサーバーとして動作し、要求されたアカウントに関する処理を
実行することになります。
また、サーバーSV2 にも外部接続を確立する機能があり、この接続を介して、例えばサーバーSV1 の
アカウントada@domain1.dom にアクセスが実行されます。この場合、サーバーSV2 は、フロント
エンドサーバーとしてサーバーSV1 に接続します。つまり、このケースではサーバーSV1 がバックエ
ンドサーバーとして動作し、そのアカウントに関する処理が行われます。
対称構成では、サーバー間通信（例えば、SV1、SV2、SV3 の各サーバー間の通信） の数は通常、外部 （ユーザー） アクセスタイプの接続（POP、IMAP、HTTP） の数と同じです。一方、CommuniGate Pro の対称静的クラスタでは、サーバー間接続の平均数はM × (N-1)/N です。ここで、M は外部（ユー ザー） 接続の数、N は静的クラスタのサーバーの数です。また、CommuniGate Pro の対称ダイナミッ ククラスタの場合、サーバー間接続の平均数はM × (N-1)/N × A/T で表されます。T は共有ドメイン のアカウントの総数、A は単一のサーバーでオープンされるアカウントの平均数です。なお、大規模 のISP サイトまたはポータルサイトの場合、A/T 比は小さくなります（通常、1:100 以下）。
典型的なフロントエンド/ バックエンド構成では、サーバー間接続の数は、一般に外部（ユーザー） 接続の数と同じです。つまり、単一の外部接続についてそれぞれ、フロントエンドサーバーとバック エンドサーバーとの間で接続がオープンされます。また、接続の数は限られますが、バックエンド サーバー同士でサーバー間接続をオープンすることもできます。
共有ドメインのアカウントに対するアクセスは、少なくてもいずれか１ つのフロントエンドサーバー が動作していれば中断なしに継続されます。
いずれかのフロントエンドサーバーの動作が停止しても、アカウントには通常どおりアクセスでき、 メールが消失することもありません。例えば、POP セッションまたはIMAP セッションの場合、動作 が停止したフロントエンドサーバーを介して実行されているセッションは一時的に中断されますが、 WebUser インターフェイスセッションは、そのままアクティブの状態が続きます。これは、WebUser インターフェイスクライアントが残りのフロントエンドサーバーを使って動作するためです。また、POP セッションまたはIMAP セッションのユーザーも、その後、残りのフロントエンドサーバーを介 して、すぐに接続を再度確立できます。
フロントエンドサーバーが停止し、その復旧に時間がかかる場合、そのサーバーのキューを別のサー バーで処理できます。この処理については、「PIPE モジュール」のセクションのフォリンキューに説 明があります。
ここでは、CommuniGate Pro サーバーを静的（スタティック） クラスタまたはダイナミッククラスタ で使用する場合の設定方法について説明します。クラスタでのサーバー間通信は、この設定によって コントロールされます。
CommuniGate Pro サーバーをクラスタ環境で使用する場合、まず、クラスタを構成するサーバーマシ ンにそれぞれCommuniGate Pro サーバーソフトウェアをインストールします。この場合、 CommuniGate Pro サーバー（ クラスタサーバー） の名前は、最初のドメイン名（ ドメイン名の先頭） だけを別にし、それ以外は同じに設定します。例えば、次のようになります。WebAdmin インターフェイスを使って、インストールしたバックエンドサーバー（例えば、上記の back1.isp.dom とback2.isp.dom） の［Cluster］ ページを開きます（［Settings］ -> ［General］）。 この作業は、インストールしたバックエンドサーバーすべてについて行います。［Cluster］ ページが 開いたら、ページの［Backend Server Addresses］ フィールドにすべてのバックエンドサーバー（ この バックエンドサーバーと接続するバックエンドサーバー） のIP アドレスを入力します。また、 ［Frontend Server Addresses］ フィールドにすべてのフロントエンドサーバー（ このバックエンドサー バーと接続するフロントエンドサーバー） のIP アドレスを入力します。これで、このバックエンド サーバーでは、ここで指定したIP アドレスからの接続に限って受け付けられるようになります。な お、フロントエンドサーバーによっては、専用のネットワークインターフェイスカード（NIC） を 使ってバックエンドサーバーと通信が行われるものもありますが、その場合、そのフロントエンドサーバーの内部ネットワークのIP アドレスを指定します。
値を［first IP］ に設定しておくと、このサーバーのローカルIP アドレスのうちの最初のア ドレスが使われます。
このオプションの設定を変更した場合、サーバーの再起動後、設定が有効になります。
CommuniGate Pro のクラスタでは、その種類（静的クラスタまたはダイナミッククラスタ） にかかわ らず、バックエンドサーバーに対して、フロントエンドサーバーのほか、バックエンドサーバーから も接続が実行、確立されます。
下記のパネルで、バックエンドサーバーのメールサービス用のポートの設定を行います。変更した場 合、［Update］ ボタンをクリックします
例えば、バックエンドサーバーで、WebUser インターフェイス接続のポートとして非標準ではなく標 準のポート（80） を使用する場合、［HTTPU］ フィールドに80 を入力し、［Update］ ボタンをクリッ クします。
サーバー間接続は、その後のサービスに再利用されます。つまり、処理が完了した後も接続は閉じら れず、オープンしたままの状態で内部キャッシュに格納されます。その後、接続元のサーバーから接 続先のサーバーに対して接続が必要になったときに、その接続が再使用されます。［Cache］ オプショ ンを使って、接続の格納に使われるキャッシュのサイズを指定できます。キャッシュに格納される接 続の数が多く、このサイズを超えたときには、古い接続から順に閉鎖され、削除されます。
クラスタメンバー（ クラスタサーバー） ではそれぞれ、PWD プロトコルを介してリモートで他のクラ スタメンバーに関する管理処理（ ログ記録） が実行されます。管理処理の際、他のクラスタメンバー に接続が実行されますが、その接続で使用されるポート番号を［PWD］ オプション（PWD プロトコル 接続ポート） で指定できます。また、管理処理のログレベルを［Object Admin］ オプション（オブジェ クト管理） と［Cluster Admin］ オプション（ クラスタ管理） で指定できます。
ダイナミッククラスタの場合、サーバーではいずれも、そのクラスタの他のバックエンドサーバーの SMTP モジュールを介して、リモートへのメッセージの配信が実行されます（ただし、サーバー間通 信で使われるプロトコルは、SMTP プロトコルではありません） 。このメッセージの配信に使われる ポート番号を［Delivery］ オプションで指定できます。このポートが、他のバックエンドメンバーの SMTP で使用されます。
ユーザーセッションがいずれかのクラスタメンバーで実行されており、そのセッションでフォリン メールボックスに対してアクセスが必要になったときには、そのクラスタメンバー上では、フォリン メールボックスが属しているアカウントはオープンできません。この場合、クラスタメールボックス マネージャを介して、そのメールボックスにリモートでアクセスが実行されます。クラスタメール ボックスマネージャは、IMAP ポートを使って、他のクラスタメンバーに接続し、メールボックスに アクセスするという処理を行います。クラスタメールボックスマネージャによる処理はログに記録さ れますが、そのログレベルは、［Mailboxes］ オプションを使って指定できます。
CommuniGate Pro のクラスタは、複数の共有ドメインに対応しています。その場合、各共有ドメイン （また、各サーバー） に専用のIP アドレスを割り当てることができます。CommuniGate Pro で、ユー ザーがPOP クライアントまたはIMAP クライアントを介して共有ドメインのアカウントにアクセスで きる環境を構築する場合、IP アドレスを割り当てることで、クライアントアプリケーションの設定が 簡単になります。POP、IMAP によるアカウントへのアクセスなどについては、詳しくは「アカウントへのアクセス」のセクションを参照してください。
フロントエンドサーバーがある場合、フロントエンドサーバーにだけ共有ドメインのIP アドレスを設 定します。サーバー間通信は、正式なアカウント名（ アカウント名@ ドメイン名） を使って行われる ため、バックエンドサーバーには共有ドメインのIP アドレスを割り当てる必要はありません。
DNS ラウンドロビンメカニズムでサイトの負荷を分散する場合、各共有ドメインにそれぞれN 個の IP アドレスを割り当てます（N は、フロントエンドサーバーの数です）。また、割り当てたIP アドレスがラウンドロビンで返るようにDNS サーバーを設定します。下は、この構成の例です。
上の例では、クラスタにdomain1.dom とdomain2.dom の2 つの共有ドメインがあり、フロントエンド サーバーは3 つです。DNS サーバーテーブル（ ラウンドロビン） では、2 つの共有ドメインにそれぞ れ3 つのIP アドレスが割り当てられており、したがって、クライアントから共有ドメインのA レコー ドの要求があった場合、3 つのIP アドレスが返ります。また、3 つのIP アドレスは、DNS サーバーか らの応答のたびに順番が「回転」し、その結果、DNS ラウンドロビンによるロードバランシングが実 行されます（ クライアントアプリケーションでは通常、DNS サーバーの応答に格納されているIP アド レスのうち最初のIP アドレスが使われ、残りのIP アドレスは、最初のIP アドレスによるTCP/IP 接 続が失敗したときに使用されます）。
CommuniGate Pro サーバーで2 つの共有ドメインを扱い、フロントエンドサーバーが3 つで、また、 DNS ラウンドロビンによる負荷分散を行う場合、上記のように各共有ドメインについてそれぞれ3 つ のIP アドレス（フロントエンドサーバーの数に等しい数のIP アドレス） を割り当てます。
一方、ロードバランサを使ってサイトの負荷を分散するときには、各共有ドメインのDNS レコード にそれぞれ単一の「外部」IP アドレスを割り当てます。また、フロントエンドサーバーにそれぞれ、 各共有ドメインの「仮想」IP アドレスを割り当てます。
この例では、クラスタにdomain1.dom とdomain2.dom の2 つの共有ドメインがあり、クラスタのフロ ントエンドサーバーは3 つです。DNS サーバーテーブルでは、2 つの共有ドメインにそれぞれ単一の IP アドレスが割り当てられています。この2 つのIP アドレスをそれぞれ、ロードバランサの外部 （ インターネット） IP アドレスとして指定します。また、ロードバランサの設定で、この2 つの外部 IP アドレスについていずれも、3 つのIP アドレス（3 つのフロントエンドサーバーの各IP アドレス） を指定します。
以上のように、CommuniGate Pro サーバーで2 つの共有ドメインを扱い、フロントエンドサーバーが 3 つで、また、ロードバランサで負荷分散を行う場合、各共有ドメインにそれぞれ3 つの内部IP ア ドレス（フロントエンドサーバーの数に等しい数のIP アドレス、ただし、IP アドレスは内部IP アド レス） を割り当てます。
上記のどちらの場合も、DNS の共有ドメインのMX レコードは、共有ドメインのA レコードを指し ていなければなりません。
フロントエンド/ バックエンドトポロジーには、サイトのデータとバックエンドサーバーを保護する 機能があります。この保護は、ネットワーク攻撃などによってフロントエンドサーバーがクラッシュ したときだけでなく、フロントエンドサーバーのOS に不法な第三者が侵入し、OS のセキュリティ ホールを使ってフロントエンドサーバーのOS に「完璧」に（つまりルートまで） アクセスできたと きでも同様です。
ただし、場合によっては、バックエンドサーバーにまで不法なアクセスが行われることもあり、この 問題を防ぐため、次の点に注意が必要です。上記のように設定した場合でも、ドメイン管理権限を持ったユーザー（ ドメイン管理者） は通常どお り、そのドメインの管理を行うことができます（WebAdmin インターフェイスまたはCLI インター フェイスを使用します）。また、一般のユーザーは、PWD モジュールを介して自分のパスワードを変 更できます。
サイトに対するDoS 攻撃は、SMTP、POP、IMAP、リスナーの各設定（オプション） のうち、「同一 のIP アドレスからの接続の最大数」を使うことで防御できます。具体的には、［Maximum Connections from same Addresses］ オプションを使用します。なお、この制限は、フロントエンド サーバーでだけ必要です。フロントエンドサーバーは同一のIP からの接続（DoS 攻撃） に晒される ことはありますが、バックエンドサーバーに対する接続はフロントエンドサーバーからの接続に限ら れるためです。
通常、バックエンドサーバーには、インターネットから直接、アクセスすることはできません。ただ
し、場合によっては、「外部（インターネットなど）」からバックエンドサーバーにアクセスし、その
設定やモニタリングを行いたい場合もあります。こういったときには、いずれかのフロントエンドサー
バーのWebUser インターフェイスを使います。WebUser インターフェイスで次のURL を入力するこ
とで、バックエンドサーバーにアクセスが可能です。
http://Frontendaddress:8010/Cluster/12.34.56.78/
上で、12.34.56.78 は、アクセス先のバックエンドサーバーの（内部） IP アドレスです。
通常の（POP/IMAP） クライアントで作成された送信メールトラフィック（ メッセージ） は、送信先 のサイトのドメインのA レコードを使って、そのサイトに送信されます。したがって、送信された メッセージはまず、フロントエンドサーバーに送られ、その後、配信されます。
一方、WebUser クライアント（WebUser インターフェイス） で作成されたメッセージ、また、自動的 に生成されたメッセージ（自動メール処理ルールによって作成されたメッセージ） は、バックエンド サーバーで処理されます。この場合、バックエンドサーバーは一般にファイアウォールの背後にあり、 また、バックエンドサーバーでは、処理効率の点から、SMTP キュー処理にリソースを使うのはでき るだけ避けなければなりません。こういった理由から、上記のメッセージについては、CommuniGate Pro のSMTP モジュールの転送機能を使ってメッセージをフロントエンドサーバーに転送するように します。
メッセージをフロントエンドサーバーに転送する場合、SMTP モジュールの設定ページの［Forward To］ フィールドにアステリスク（*） を入力します。これで、メッセージはいずれも、バックエンド サーバーからクラスタの全フロントエンドサーバーに送られ、その後、配信されます。転送先のフロ ントエンドサーバーを指定したい場合、そのフロントエンドサーバーのIP アドレスを［Forward To］ フィールドに入力します。フロントエンドサーバーは複数指定することもでき、その場合、各IP ア ドレスをコンマで区切ります。
RPOP 処理は、静的クラスタの場合はバックエンドサーバー、ダイナミッククラスタの場合はクラス タコントローラで発生します。そのため、必要な場合、リモートサーバーに対して送信TCP 接続が開始されるように、バックエンドサーバーまたはクラスタコントローラを設定しておかなければなり ません。また、バックエンドサーバーがファイアウォールの背後のプライベートLAN に接続されて いるときには、そのLAN 上にNAT サーバーソフトウェアをインストールし、さらにバックエンド サーバー上で非ローカルパケットがNAT サーバーにルートされるようにバックエンドサーバーを設 定しておくことが必要です（ この設定は、バックエンドサーバーのOS のTCP/IP 設定を使って行い ます）。NAT サービスは、フロントエンドサーバーを使って動作させます。
FTP モジュールは、バックエンドサーバーに対して接続が実行された際、「プロキシ」として動作す ることはありません。代わりに、CLI を使ってバックエンドサーバーに接続が実行され、アカウント のパーソナルWeb サイトの処理が行われます。この仕様により、バックエンドサーバー上で、FTP 接 続がクライアントに対して直接オープンされるという問題は発生しません。
FTP サーバーの場合、背後にロードバランサまたはNAT があると処理モードに問題が生じますが、 クラスタのフロントエンドサーバーでFTP モジュールが動作しており、その背後にロードバランサ やNAT があるときにも同様の問題が発生します。つまり、この構成でFTP アクティブモードをサ ポートしたい場合、フロントエンドサーバー上でクライアントのFTP ポートに対する送信接続が正 常に開かれるように設定します（NAT がある場合、「アドレス使用中」エラーが発生しないように NAT ソフトウェアを設定します）。また、FTP パッシブモードをサポートする場合、ロードバランサ の設定をチェックし、クライアントからフロントエンドサーバーのポート（ クライアントからの要求 時、FTP によってオープンされるポート） に直接、接続が実行されるようにします。
LDAP モジュールは、バックエンドサーバーに対して接続が実行された際、「プロキシ」として動作 することはありません。代わりに、まず、CLI を使ってユーザー認証が行われ、その後、LDAP プロ ビジョニング処理が実行されます（設定によります）。すべてのLDAP 接続がフロントエンドサー バーに集中した場合、バックエンドサーバーのLDAP サービスが停止するように設定することもで きます。
RADIUS モジュールは、バックエンドサーバーに対して接続が実行された際、「プロキシ」として動 作することはありません。代わりに、まず、CLI を使ってユーザー認証が行われ、その後、統計デー タの更新が実行されます。すべてのRADIUS 接続がフロントエンドサーバーに集中した場合、バックエンドサーバーのRADIUS サービスが停止するように設定することもできます。
See the Cluster Signals section.
バックエンドサーバーのメインドメインには"postmaster （ポストマスター） " アカウントがあり ますが、このアカウントは削除しないようにします。クラスタの他のサーバーからバックエンドサー バーに対して接続が必要になった場合、そのバックエンドサーバーのポストマスターアカウントが直 接、その名前を使ってオープン（つまり、ルータをバイパスしてオープン） されます。したがって、 ポストマスターアカウントを削除すると、接続が正常に行われなくなります。また、ポストマスター アカウントのアクセス権は、［Can Modify All Domains and Accounts Settings］ （全ドメイン/ アカウン ト設定の変更可能） 以上の権限でなければなりません。
常に大規模なサイト（稼働アカウント数が5,000,000 を超えるようなサイト） の場合、通常、複数の ダイナミッククラスタで構成される静的クラスタを構築します。この構成は、フロントエンドサー バーのある静的クラスタと基本的には同じですが、バックエンドサーバーの場所にダイナミッククラ スタを設置します。静的クラスタでは、一般にリダンダンシー問題が発生しますが、この構成では、 この問題は起こりません。また、極端に大容量の共有ストレージデバイスは不要で、大規模なダイナ ミッククラスタで見られるような過剰ネットワークトラフィックも発生しません。
この構成（ クラスタのクラスタ） の場合、フロントエンドサーバーからディレクトリにアクセスが実 行され、この部分が静的クラスタとして機能します。フロントエンドサーバーによる処理は、ディレ クトリの情報の読み取りだけです。一方、アカウントの追加や名前の変更、削除が発生した場合、バッ クエンドサーバーによってディレクトリの内容が変更されます。ディレクトリのアカウントレコード の属性hostServer には、そのアカウントの処理に関係するバックエンドサーバーのダイナミッククラ スタの名前（つまり、バックエンドサーバーの名前から最初の要素を除外した名前）が格納されます。
トラフィックをもとに、複数のフロントエンドサーバーをサブセットに分割することもできます。そ の場合、各サブセットにそれぞれロードバランサを設置し、また、各サブセットをスイッチを介して ダイナミッククラスタ（バックエンドサーバーのセット） と接続します（図を参照）。
設置するフロントエンドサーバーの数が多い場合（例えば、50 以上）、通常、ディレクトリサーバー がサイトのボトルネックになります。この問題を回避（また、ディレクトリレベルでリダンダンシー を確保） するには、ディレクトリサーバーを複数設置します（フロントエンドサーバーのサブセット １ つまたは数個について、ディレクトリサーバーを１ つ使用します）。この場合、いずれかのディレ クトリサーバーを「マスター」として使用し、各バックエンドサーバーでは、このマスターディレク トリサーバーに対してのみ更新が実行されるようにします。マスター以外のディレクトリサーバーは、複製メカニズムを使ってマスターディレクトリサーバーと 同期をとります。もしくは、バックエンドサーバーによる更新の際、全ディレクトリサーバーが一括 して変更されるようにバックエンドサーバーを設定します。