Swivel仮想アプライアンスがサポートするハイパーバイザーは、VMware, Xen Server, HyperV の3種類ですが、それぞれの仮想アプライアンスには下記の3つの種類があります。
Standard Applianceは、1つのサーバでシステムを構成できるオールインワンパッケージのサーバです。他のサーバと同様にOS,認証エンジン,ユーザDB等を全て含みますので、基本的に他のシステムを導入する必要はありません。
ただし、冗長化することは不可能です。
A-A Applianceは、サーバを冗長化することで可用性を高めたものです。冗長化はVIPの共有によって実現していますので、Active-Activeではなく、Active-Standbyの構成となります。
各サーバの構成情報のHeartbeatによる共有、ユーザDBのReplicationの機能も含みますので、上位に負荷分散サーバを置く必要はありません。
DR Applianceは、Standard ApplianceまたはA-A Applianceと組み合わせて使用します。通常はメインサイトとは異なるDRサイトに配置し、災害時にメインサイトが使用不可になった際のバックアップとして使用します。
通常運用時に、メインサイトからサーバ設定情報や、ユーザDB情報をDRサーバに通常は専用回線を使用して送ります。(回線はお客様でご準備いただきます。)
DR Applianceからメインサイトへの(逆方法の)情報送信はサポートしていません。またDR Applianceは単独で導入・運用することはできません。
まず、Standard ApplianceかA-A Applianceのどちらかを選択する必要があります。
これはユーザ数とは基本的に関係がありません。Standard Applianceでも10,000ユーザ規模での実績を持っていますし、仮想サーバ上で動作しますので、仮想サーバ自体のHA機能が有効です。
お客様が求める可用性が、おのHA機能による再起動時間(約1〜5分程度)が許容できない場合にA-A Applianceをご選択いただきます。
なお、国内のエンタープライズユーザ様では厳しい可用性を求められるケースが多いため、日本国内ではA-A Applianceをご選択いただくケースが多いです。
次に、それぞれのサーバを1組の構成にするか、2組の構成にするかをご選択いただきます。
Swivelサーバをインターネットセグメント(DMZ)に配置する必要がある場合、そこにユーザ情報を格納するのは危険なため、サーバを2台構成にして、それぞれをAPサーバ(認証サーバ / フロントサーバ)、DBサーバとして定義します。
この構成はStandard ApplianceでもA-A Applianceでも実現可能で、ご発注の際に、それぞれの数量を「2」と指定していただきます。
APサーバもDBサーバも同じアプライアンスサーバで、設定が異なるだけです。
なお、DRサーバを2台構成にすることはできません。
以上、今回はSwivelのサーバ選択と構成時の基本的な留意点についてご説明しました。