Version 5.1
クラスタ |
|---|
| |||||||
|
|
Version 5.1 |
|||||||||||||||||||||||||||||
|
|
スタティッククラスタは複数のサーバーで構成され、各サーバーに共有ドメインを置きます。共有 ドメインの作成方法は通常のCommuniGate Pro のドメインの場合と同じです。各サーバーの共有ド メイン（下図のdomain1.com、各サーバーに分散して置きます） には、全アカウントを分散して格納 します（例えば、domain1.com の全アカウントを3 つのdomain1.com に3 分の1 ずつ配置します）。 したがって、共有ドメインのアカウントにはそれぞれ、そのアカウントのホストサーバー（例えば、 server SV1） があることになります。サーバーのアカウントには、そのサーバーからのみ物理アクセスが可能です。 つまり、スタティッククラスタの場合、ディスクストレージは普通の独立したディスクストレージ （非共有ストレージ） です。また、スタティッククラスタでは、各サーバーによって、そのサーバー に存在するアカウントが認識されなければなりません。そのためのメカニズムとしては、通常、共有 ディレクトリ（サーバー） を使用します。このメカニズムは、CommuniGate Pro の分散ドメインの場 合と同じです。
上記のようにして指定した場合、CommuniGate Pro のクラスタリングメカニズムを使って、指定され ているアドレスのバックエンドサーバーに接続が行われ、そのバックエンドサーバーで要求された処 理が実行されます。
上記のセットアップ方法は、バックエンドサーバーとフロントエンドサーバーのどちらの場合も基本 的には同じです。ただし、フロントエンドサーバーには共有ドメイン（また、その共有ドメインのア カウント） は作成しません（処理上、不要です）。つまり、共有ドメインは、バックエンドサーバーに だけ作成します。
スタティッククラスタのコンピュータは、それぞれオペレーティングシステムが異なってもかまいま せん。
フロントエンドサーバーとバックエンドサーバーで構成されるクラスタの場合、通常、ロードバラン サ（Load Balancer） を使用します。また、ネットワークも複数存在します。下図は、このシステム構成です。
フロントエンド/ バックエンドクラスタでは、フロントエンドサーバーを介して直接インターネット に接続できます。また、負荷は、DNS ラウンドロビンメカニズムを使ってバランシングが可能です。 なお、この構成の場合、フロントエンドサーバーとバックエンドサーバーの間には、できるだけファ イアウォールを設置するようにします。
既存のスタティッククラスタには、必要に応じてフロントエンドサーバー/ バックエンドサーバーを 追加できます。
スタティッククラスタへのサーバーの追加は、次の手順で行います。スタティッククラスタに追加したサーバーがフロントエンドサーバーの場合、ロードバランサまたは ラウンドロビンDNSサーバーを再設定し、受信要求が追加したサーバーにも送られるようにします。
一方、追加したサーバーがバックエンドサーバーの場合、そのサーバーの共有ドメインにアカウント を作成します。
スタティッククラスタのバックエンドサーバーのうち、いずれかがシャットダウン（停止） すると、 そのサーバーのアカウントはすべて利用できなくなります。こういったアカウントに対して送信され たメッセージはいずれも、フロントエンドサーバーのキューに保存され、その後、そのバックエンド サーバーが復帰した時点、または、そのサーバーのアカウントが別のバックエンドサーバーで利用で きるようになった時点（フェイルオーバー、下記を参照） で配信されます。
スタティッククラスタのバックエンドサーバーがシャットダウン（障害またはハードウェアアップグ レードなど） すると、そのサーバー上のアカウントはすべて利用できなくなります（ただし、別のバッ クエンドサーバーのアカウントは通常どおり使用できます）。
こうしたバックエンドサーバーのアカウントにアクセスする場合、そのアカウントのストレージを別 のバックエンドサーバーに接続します。この接続は、次のいずれかの方法で可能です。上記の2 番目（デュアルアクセスRAID デバイス） の場合、「兄弟」バックエンドサーバー上で、停 止したバックエンドサーバーのアカウントストレージに物理的にアクセスできる状態になれば、ディ レクトリの内容を修正しなければなりません。この修正により、兄弟バックエンドサーバーのアカウ ントストレージに対して他のサーバーからアクセスが可能になります。修正はLDAP ユーティリ ティを使って行い、ドメインサブツリーのレコードのうち、停止したサーバーの名前（属性 hostServer の値） が格納されているレコードをすべて修正します。具体的には、LDAP ユーティリティを使って、こういったレコードの属性hostServer の値を新規のホ ストサーバー（兄弟バックエンドサーバー） の名前に変更し、また、属性oldHostServer を追加しま す。属性oldHostServer の値としては、停止したサーバーの名前を指定します。この操作により、停 止したサーバーの名前が属性hostServer の値として取り込まれると同時に、そのサーバーのアカ ウントストレージが接続されます。ディレクトリの修正にかかる時間は、CommuniGate Pro をサイト のディレクトリサーバーとして使用しており、レコード数が100,000 の場合、1 ～ 2 分です。