ダイナミッククラスタ

レガシーメールサーバーでは、多くの場合、ファイルサーバーにアカウントが格納されます。ファイ ルサーバーのシステムは通常、マルチプロセスシステムです（Unix）。そのため、シングルサーバー環 境でもマルチサーバー環境でも同期手法は同じです。つまり、オペレーティングシステム/ ファイル システムレベルのファイルロックを使って同期が行われます。

• アカウント/ メールボックスデータに関する処理はいずれも、ファイルロック処理/ 解除処理と 並行して実行されることが必要で、また、データの整合性の確保のため、追加のファイルシス テム処理も必要になります。その結果、ファイルシステム処理の数が3 ないし5 倍に増加し、サ イトの処理速度が低下します（通常、ファイル処理の速度によってサイトの処理速度が決まり ます）。
• 最近のファイルサーバーでは通常、ファイルロックメカニズムがまったくサポートされていな いか、サポートされていても、機能がかなり限定されています。そのため、サイトで最も重要 なコンポーネントであるアカウントストレージの信頼性が低下し、また、非フォールトトレラ ントの状態に置かれます。
• いずれかのサーバーに障害が発生した場合、サイト全体がダウンすることがあり（デッドロッ クが発生）、障害復旧もかなり困難です。
• 複数のクライアントから同一のアカウント/ メールボックスデータに対する同時アクセスは、 不可能か、可能であっても処理の信頼性は高くはありません。

上記のようにファイルロックには問題があるため、レガシーメールサーバーの中には、MailDir メール ボックスフォーマット（単一のメッセージについて単一のファイルが作成される方式） を使用し、ファ イルディレクトリ処理が「個別」に実行されるようにした製品（ファイルレベルのロックは不使用） もあります。この方式を採用することで、理論的には上記のような問題を解決できます（それでも、 実際には根本的解決にはなりません）。ただし、この方式の場合、ファイルサーバーのストレージの大 半が無駄になります。
つまり、多くのハイエンドサーバーでは、64 キロバイトブロックを使ってファイルが格納されますが、 メールメッセージの平均のサイズは約4 キロバイトです。そのため、メッセージをそれぞれ別個のファ イルに格納すると、結局、ファイルサーバーのディスクスペースの90％以上が無駄になってしまいま す。また、ファイルサーバーの内部ファイルテーブルもオーバーロード状態になります。さらに、ア プリケーションで小さいファイルが多数使われることになるため、ファイルサーバー自体の性能も大 幅に低下します。

Web サーバーの場合、オペレーティングシステム/ ファイルシステムのマルチアクセス機能をベース としたシンプルクラスタリング環境を構築することで、システムは効率よく動作します（ただし、デー タの変更が頻繁な場合には処理速度は低下します）。一方、メールサーバーでは、データ変更トラフィッ クとデータ取り出しトラフィックはほとんど同じであるため、処理速度は低下します。

シンプルクラスタリング環境では複雑な処理には向いておらず（シングルサービスイメージとは異な ります）、また、クラスタのサーバーの数が多いと管理が難しくなります。例えば、シンプルクラスタ リング環境のサーバー数が10 の場合、その管理は、独立したサーバーが10 の構成に比べて難しくな ります。

CommuniGate Pro サーバーのダイナミッククラスタでは、オペレーティングシステム/ ファイルシス テムレベルのロックを使ってアカウント処理の同期が行われることはありません。ダイナミッククラ スタの場合、任意の時点では、いずれか１ つのサーバーからいずれか１ つのアカウントに対して直接、 アクセスが行われます。この処理は、静的クラスタと同じです。

ただし、ダイナミッククラスタの場合、そのアカウントがオープンしており、そのアカウントに対し て別のサーバーからアクセスが試行された場合、そのサーバーを介して別のサーバーによるアクセス が実行されます。一方、そのアカウントがオープンしていないときには、別のサーバーによって直接、 そのアカウントのオープンが実行されます。

このアーキテクチャにより、最大限のアップタイムが保証されます。いずれかのバックエンドサーバー が停止しても、別のバックエンドサーバーからすべてのアカウントに対してアクセスできます。この 処理は自動で行われ、したがってオペレーターによる手動の操作は不要で、結果的にダウンタイムは 発生しません。つまり、サイトの稼働は続き、実際、いずれか１ つのバックエンドサーバーが動作し ていれば、全アカウントにアクセスが可能です。ダイナミッククラスタでは、いずれか１ つのバックエンドサーバーがクラスタコントローラ（Cluster Controller） として動作します。クラスタコントローラは、そのクラスタの他のサーバーの同期をとる という処理を行います。また、共有ドメインの作成、共有ドメインのアカウントの作成と削除といっ た処理を行う機能もあります。さらに、クラスタコントローラにはシングルサービスイメージ機能があり、この機能により、サイトのユーザーや管理者は、ダイナミッククラスタの任意のサーバーに接 続し、任意のアカウント処理（別のサーバー上でオープンされているアカウントについても処理が可 能）、また、任意のドメインレベルの処理（例えば、ドメイン設定の変更） を行うことができます。こ の場合、変更はクラスタの全サーバーに自動的に伝播されます。

注意: ドメインレベルの更新処理（ ドメイン設定、デフォルトアカウント設定、WebUser インター フェイス設定、ドメインレベルのアラートなどの更新処理） を行った場合、通常、その変更は30 秒以 内にクラスタの全サーバーに伝播されます。一方、アカウントレベルの設定の変更は、すぐに全サー バーで有効になります。

クラスタコントローラにより、各バックエンドサーバーの負荷に関する情報が収集されます。いずれ かのフロントエンドサーバーからクラスタコントローラにアカウントセッション要求が送信され、そ のアカウントがいずれかのバックエンドサーバーでオープンされていなかったときには、クラスタコ ントローラによって、そのフロントエンドサーバーが負荷の一番少ないバックエンドサーバーに接続 されます。この処理は、セカンドレベルロードバランシング（バックエンドサーバーを対象としたバ ランシング） と呼ばれています。セカンドレベルロードバランシングは、各バックエンドサーバーの 実際の負荷（ クラスタコントローラによって収集） をベースにしており、また、ファーストレベルロー ドバランシング（フロントエンドサーバーを対象としたバランシングで、DNS ラウンドロビンまたは トラフィックがベース） を補完する機能です。

ダイナミッククラスタにバックエンドサーバーが2 つ以上ある場合、クラスタコントローラによって、 いずれか１ つのバックエンドサーバーがクラスタコントローラのバックアップ処理を行うサーバーと して割り当てられます。このサーバーは、バックアップコントローラと呼ばれ、他のバックエンドサー バーはいずれも、このバックアップコントローラと常時、接続を保持します。その後、バックアップ コントローラが何らかの理由で動作を停止した場合、別のいずれかのバックエンドサーバーがバック アップコントローラとして選択されます。

クラスタコントローラが停止した場合、バックアップコントローラがクラスタコントローラとして動 作を開始します。同時に、各サーバーから、このバックアップコントローラ（新規のクラスタコント ローラ） に対して再同期情報が送信され、その結果、クラスタは継続して動作し、処理の中断も発生 しません。

最近のオペレーティングシステムでは、システム自体にクラスタ機能が搭載されています。こうした システムでは、「通常」の非クラスタアプリケーションをクラスタ対応アプリケーションとして使用 できます。また、クラスタ機能を搭載したオペレーティングシステムは、CommuniGate Pro でダイナ ミッククラスタを実装する上でも重要です。

• クラスタファイルシステム
• IP エイリアシング

クラスタファイルシステムとは、オペレーティングシステムのクラスタに属する全サーバー上で、同 一のファイルシステム（通常、共有デバイスに格納） をマウントし、使用できるようなファイルシス テムをいいます。クラスタファイルシステムの場合、ネットワークファイルシステム（NFS） とは異 なり、ネットワーク上に専用サーバーを置く必要はありません。また、ハイエンドSCSI ストレージ デバイスによるSCSI 複数接続が可能で、この接続を介して、ファイバーSAN （ストレージエリア ネットワーク） 上で複数のストレージデバイス間で直接、データを交換できます。さらに、高速サー バー間接続によって、ファイルシステムの整合性が保証されます。

ダイナミッククラスタには、共有ドメインに関するデフォルト設定（複数の設定のセット） がありま す。

• デフォルトドメイン設定。このドメイン設定は全共有ドメインで使用されます。
• デフォルトアカウント設定とデフォルトWebUser プレファレンス。どちらも、共有ドメインの 全アカウントで使用されます。
• クラスタワイドアラート。いずれも、共有ドメインの全アカウントに送信されます。

デフォルト設定は、サーバー管理者がWebAdmin インターフェイスを使って変更できます。WebAdmin インターフェイスのページにはリンクが表示されますので、このリンクを使って、サーバーワイドの 設定（非共有ドメインすべてについて有効） とクラスタワイドの設定を切り替えることができます。 クラスタワイドの設定を変更すると、その変更は、全クラスタメンバーについて自動的に有効になり ます。また、クラスタワイドの設定は、全共有ドメインについて有効です。

ダイナミッククラスタのシングルサービスイメージ機能は、シングルサービスイメージコンポーネ ントによって実装されます。この機能により、共有処理（アカウント設定とドメイン設定を超えた高 レベルのサーバー同期） が実行されます。

ダイナミッククラスタでは、ローリング（システム非停止） アップグレードがサポートされています。 そのため、サーバーのCommuniGate Pro ソフトウェアを新バージョンにアップグレードする場合、ダ イナミッククラスタのサーバーを１ つずつアップグレードできます。つまり、いずれかのサーバーを 停止し、新バージョンをインストールした後、クラスタに戻すという方法で、順にサーバーのアップ グレードが可能です。アップグレード中、サイトは通常どおり動作します。