6.1 Calendar Server バージョン 6.3 の高可用性の選択の概要
高可用性は複数の方法で設定できます。ここでは、3 つのタイプの高可用性の概要について説明し、必要に適したタイプを選択するために役立つ情報を紹介します。
この節の内容は次のとおりです。
6.1.1 Calendar Server バージョン 6.3 の非対称型高可用性について
単純な非対称型高可用性システムには 2 つの物理ノードがあります。プライマリノードは常にアクティブであり、もう一方のノードはバックアップノードとして機能して、プライマリノードに障害が生じた場合に処理を継続できるようになっています。フェイルオーバーを行う場合、共有ディスクアレイがバックアップノードによって制御されるように切り替えられます。Calendar Server プロセスは、障害の発生したプライマリノードで停止し、バックアップノードで起動します。
このタイプの高可用性システムにはいくつかの長所があります。1 つの長所は、バックアップノードが専用であり、完全にプライマリノード用として確保されているという点です。したがって、フェイルオーバーの実行時に、バックアップノード上でリソースが競合することがありません。もう 1 つの長所は順次アップグレードを行えるということです。つまり、一方のノードでアップグレードを行いながら、他方のノードで Calendar Server ソフトウェアを実行し続けられます。1 番目のノードのアップグレード中に ics.conf ファイルを変更しても、設定ファイルは起動時に一度読み込まれるだけなので、その変更はセカンダリノードで実行しているもう一方の Calendar Server インスタンスには影響しません。新しい設定を有効にするには、カレンダプロセスを停止してから再起動する必要があります。もう一方のノードをアップグレードする場合は、アップグレードしたプライマリノードへのフェイルオーバーを実行し、セカンダリノード上でアップグレードを開始します。
注 –
もちろん、最初にセカンダリノードをアップグレードしてからプライマリノードをアップグレードすることもできます。
非対称型高可用性モデルにはいくつかの短所もあります。1 つの短所は、バックアップノードがほとんど常にアイドル状態になっているため、リソースが十分に活用されないという点です。もう 1 つの短所は、ストレージアレイが単一であるということです。単純な非対称型高可用性システムでは、ディスクアレイに障害が発生すると、バックアップが利用できなくなります。
6.1.2 Calendar Server バージョン 6.3 の対称型高可用性について
単純な対称型高可用性システムには 2 つのアクティブな物理ノードがあり、独自のディスクアレイを備えています。各ディスクアレイは 2 つのストレージボリュームから構成され、一方のボリュームにはローカルカレンダストアが、もう一方のボリュームには他方のノードのカレンダストアのミラーイメージが格納されます。それぞれのノードは他方のバックアップノードとして動作します。一方のノードからバックアップノードへのフェイルオーバーが行われると、Calendar Server の 2 つのインスタンスがバックアップノード上で並列して動作しますが、それぞれのインスタンスは独自のインストールディレクトリから実行され、独自のカレンダストアにアクセスします。共有するものは、バックアップノードの演算能力だけです。
このタイプの高可用性システムの長所は、両方のノードが同時にアクティブになるため、マシンのリソースが十分に活用されるという点です。ただし、障害が発生すると、バックアップノードは両方のノードから Calendar Server のサービスを実行するので、リソースの競合が多くなります。
対称型高可用性はバックアップストレージアレイも実現します。ディスクアレイに障害が発生した場合に備え、その冗長イメージをバックアップノード上のサービスで取得しておくことができます。
注 –
対称型高可用性システムを設定するには、共有ディスク上に Calendar Server バイナリをインストールします。この場合、順次アップグレードを実行できなくなる可能性があります。順次アップグレードは、Calendar Server パッチリリースによるシステム更新時のダウンタイムをゼロまたは最小にする機能であり、Calendar Server の今後のリリースで予定されています。
6.1.3 N+1 (N 対 1) について: Calendar Server バージョン 6.3 の複数の非対称型高可用性
この章で説明した 2 種類の高可用性システム以外にも、2 つを組み合わせて 3 番目のタイプも構成できます。このタイプが、複数ノードの非対称型高可用性システムです。このタイプでは、「N」個のディスクアレイと「N」個のノードがすべて、将来の使用のために確保され通常はアクティブでない同一のバックアップノードを使用します。このバックアップノードは「N」個のうちどのノードの Calendar Server でも実行できます。前述の図に示すように、バックアップノードは「N」個のノードの各ディスクアレイを共有します。同時に複数のノードに障害が発生した場合、バックアップノードには、最高「N」個の Calendar Server インスタンスを並列して実行する能力が必要になります。「N」個のノードにはそれぞれ独自のディスクアレイが割り当てられています。
N+1 モデルの長所は、Calendar Server の負荷を複数のノードに分散でき、すべてのノードの障害に対処するために必要なバックアップノードが 1 つで済むことです。
このタイプの高可用性の短所は、非対称型システムと同じく、バックアップノードがほとんど常にアイドル状態になっていることです。さらに、N+1 高可用性システムのバックアップノードは、複数の Calendar Server インスタンスを実行する必要が生じる場合に備え、余分な能力を備えている必要があります。つまり、非常に高価なマシンをアイドル状態で待機させておくことになります。ただしマシンのアイドル率は 1:N であり、一方、単一の非対称型システムの場合は 1:1 になります。
このタイプのシステムを設定するには、「N」個の各ノードとバックアップノードに対して、非対称型高可用性システムの手順を適用します。その都度同じバックアップノードを使用しますが、プライマリノードは異なります。
6.1.4 Calendar Server バージョン 6.3 配備に応じた高可用性モデルの選択
次の表には、各高可用性モデルの長所と短所がまとめられています。この情報を使用して、どのモデルが配備に適しているかを判断してください。
表 6–1 各高可用性モデルの長所と短所
6.1.5 Calendar Server 6.3 配備での高可用性システムのダウンタイムの計算
次の表では、任意の日にシステム障害によってカレンダサービスが利用できなくなる確率を示しています。この計算では、平均で、システムクラッシュまたはサーバーハングにより 3 か月に 1 日各サーバーが停止し、12 か月に 1 日各ストレージデバイスが停止すると想定しています。また、両方のノードが同時に停止するという可能性の低いケースについては無視しています。
表 6–2 システムのダウンタイムの計算|
モデル |
サーバーのダウンタイムの確率 |
|
単一サーバー (高可用性なし) |
確率 (停止) = (4 日のシステム停止 + 1 日のストレージ停止)/365 = 1.37% |
|
非対称 |
確率 (停止) = (0 日のシステム停止 + 1 日のストレージ停止)/365 = 0.27% |
|
対称 |
確率 (停止) = (0 日のシステム停止 + 0 日のストレージ停止)/365 = (ほとんど 0) |
|
N + 1 非対称 |
確率 (停止) = (5 時間のシステム停止 + 1 日のストレージ停止)/(365xN) = 0.27%/N |
- © 2010, Oracle Corporation and/or its affiliates