|
| |
| Sun Java System Messaging Server 6 2004Q2 配備計画ガイド | |
第 10 章
サービス可用性に向けた計画この章では、配備に適切なサービス可用性のレベル決定方法について説明します。サービス可用性のレベルは、採用したハードウェアとソフトウェアインフラストラクチャ、および実際の保守の方法に関係しています。この章では、いくつかの選択肢とそのメリットおよびコストについて説明します。
この章には、以下の節があります。
Automatic System Reconfiguration (ASR) の概要単に高可用性 (HA) ソリューションを評価するだけでなく、ASR を可能にするハードウェアの配備についても検討する必要があります。
ASR は停止時間に関連するハードウェア障害を最小限にするためのプロセスです。サーバーに ASR 機能がある場合は、ハードウェアの個別のコンポーネントに障害が発生しても、停止時間を最小限にとどめることが可能になります。ASR により、サーバーの自動再起動と、障害の発生したコンポーネントが交換されるまでそれを停止しておくことが可能になります。欠点は、障害の発生したコンポーネントがサービスから排除される結果、システムのパフォーマンスが低下することです。たとえば、CPU に障害が発生すると、マシンは残りの CPU を使用して再起動されます。システムの I/O ボードまたはチップに障害が発生した場合は、システムの I/O ボードが減少するか、代わりの I/O パスが使用されます。
さまざまな Sun SPARC システムが、さまざまなレベルの ASR をサポートしています。高いレベルの ASR まではサポートしていないシステムもあります。当然ながら、高い ASR 機能を持つサーバーはその分コストも高くつきます。ソフトウェアに高可用性がない場合、コストには制約がないものとすれば、データ格納用にはハードウェアに高い冗長性と ASR 機能を持たせたマシンを選択します。
高可用性モデルの理解さまざまなタイプの高可用性モデルを Messaging Server として使用できます。一般的によく使用されるモデルに、以下の 3 つがあります。
- 非対称型 (ホットスタンバイ)
以下の節で、これらのモデルについてそれぞれ詳しく説明します。
注
異なる高可用性製品が異なるモデルをサポートしている場合もあれば、サポートしていない場合もあります。対応する製品の高可用性に関するマニュアルを参照して、どのモデルがサポートされているかを確認してください。
非対称型
基本的な非対称型または「ホットスタンバイ」型の高可用性モデルは、クラスタ化された 2 つのホストマシンまたは「ノード」で構成されます。1 つの論理 IP アドレスおよび関連するホスト名が両方のノードに指定されます。
このモデルでは、常に 1 つのノードだけがアクティブとなります。バックアップノードまたはスタンバイノードは、大半の時間はアイドル状態のままとなります。両ノード間で単独の共有ディスクアレイが構成され、アクティブまたは「プライマリ」なノードの支配下となります。メッセージストアパーティションおよびメッセージ転送エージェント (MTA) キューは、この共有ボリュームに置かれます。以下の図は非対称型モデルの例です。
図 10-1 非対称型高可用性モデル
前の図には、物理-A と物理-B の 2 つのノードがあります。フェイルオーバーの前は、物理-A がアクティブなノードです。フェイルオーバーが行われると、物理-B がアクティブなノードとなり、共有ボリュームは物理-B の支配下に切り替わります。すべてのサービスが物理-A で停止し、物理-B で開始されます。
このモデルのメリットは、バックアップノードがプライマリノードの予備としてだけ使用されることです。また、フェイルオーバー時に、バックアップノードでリソースの競合が起こることもありません。しかし、このモデルではバックアップノードがほとんどの時間でアイドル状態にあり、そのリソースがほとんど利用されないことになります。
対称型
基本的な対称型または「デュアルサービス」型の高可用性モデルは、それぞれ固有の 論理 IP アドレスを持つ 2 台のホストマシンで構成されます。それぞれの論理ノードは 1 つの物理ノードに関連付けられており、それぞれの物理ノードが、2 つのストレージボリュームを持つ 1 つのディスクアレイを制御します。1 つのボリュームがローカルメッセージ格納パーティションと MTA キューとして使用され、もう 1 つのボリュームは他方のメッセージ格納パーティションと MTA キューのミラーイメージとなります。
以下の図は、対称型高可用性モデルの例です。両方のノードが共にアクティブで、それぞれのノードが他方のバックアップとして機能します。正常な状態では、それぞれのノードが Messaging Server の 1 つのインスタンスだけを実行します。
図 10-2 対称型高可用性モデル
フェイルオーバーが起こったときには、障害の発生したノードのサービスが停止され、バックアップノードで再開されます。この時点で、バックアップノードは両方のノードの Messaging Server を実行し、2 つの個別ボリュームを管理しています。
このモデルのメリットは、両方のノードが同時にアクティブとなり、マシンリソースが完全に利用されることです。ただし、障害が発生している間は、バックアップノードで両方のノードの Messaging Server のサービスを実行するため、リソースの競合が多くなります。したがって、障害の発生したノードをできるだけ素早く修復し、サービスをデュアルサービスの状態に復元する必要があります。
このモデルでは、バックアップストレージアレイも提供されます。ディスクアレイに障害が発生した場合は、バックアップノードのサービスが冗長イメージを取り出します。
対称型モデルを構成するには、共有ディスクに共有バイナリをインストールする必要があります。ただし、共有バイナリをインストールすることにより、ローリングアップグレード、すなわち、Messaging Server のパッチリリース中にシステムの更新を行う機能が実行できなくなる場合があります (この機能は将来のリリースで対応を検討中)。
N+1 (N プラス 1)
N + 1 または "N プラス 1" モデルは、マルチノードの非対称型構成で運用します。N 個の論理ホスト名と N 個の共有ディスクアレイが必要です。1 つのバックアップノードが、他のすべてのノードに対するホットスタンバイとして確保されます。バックアップノードは、N 個のノードから同時に Messaging Server を実行できます。
図 10-3 は、基本的な N + 1 高可用性モデルの例です。
図 10-3 N + 1 高可用性モデル
1 つまたは複数のノードでフェイルオーバーが起こったときは、バックアップノードが障害の発生したノードの責任を引き受けます。
N + 1 モデルのメリットは、サーバーの負荷が複数のノードに分散され、すべてのノードの障害に対して 1 つのバックアップノードだけで対処できることです。したがってマシンのアイドル比率は、単独の非対称型モデルの 1 対 1 に対して、N 対 1 となります。
N + 1 モデルを構成するには、バイナリをローカルディスク (対称型モデルの共有ディスクのことではない) にだけインストールする必要があります。すべての対称型モデル、1 + 1 または N + 1 非対称型モデルあるいは対照型モデルの対称型高可用性ソリューションでは、現在の Messaging Server のインストールとセットアップのプロセスにより、バイナリは強制的に共有ディスクに置かれます。
高可用性モデルの選択以下の表で、それぞれの高可用性モデルのメリットとデメリットをまとめています。この情報を参考にして、配備にふさわしいモデルを決定してください。
システム停止時間の計算
以下の表で、システム障害によりメッセージサービスが利用できなくなる確率について説明します。ここでの計算は、システムクラッシュまたはサーバーのハングアップによるサーバーの停止が平均して 3 か月間に 1 日、ストレージデバイスの停止が 12 か月間に 1 日の割合で発生することを想定しています。両方のノードが同時に停止する可能性はきわめて小さいため、計算では無視しています。
製品の参照情報Messaging Server がサポートする高可用性モデルの詳細については、以下の製品マニュアルを参照してください。
リモートサイトフェイルオーバーの理解リモートサイトフェイルオーバーは、プライマリサイトに致命的な障害が発生した場合に、そのプライマリサイトに WAN で接続されているサイトでサービスを開始する機能です。リモートサイトフェイルオーバーにはいくつかの形式があり、それぞれにコストが異なります。
リモートサイトフェイルオーバーでは、すべてのケースでサーバーとストレージを追加して、リモートサイトにインストールおよび設定された、サービスのユーザー負荷のすべてまたは一部を処理する能力を持つようにする必要があります。すべてまたは一部というのは、顧客によっては優先するユーザーとそうでないユーザーがいることを意味します。ISP でも企業でも、そのような状況が起こります。ISP には、この機能のために割増料金を支払うユーザーがいます。企業では、全従業員に電子メールの機能を提供している部門内で、ユーザーによってはそのサポートが高くついている場合があるかもしれません。たとえば、カスタマサポートに直接関わるユーザーのメールに対してリモートサイトフェイルオーバーを選択した場合でも、製造ラインで勤務する従業員には、リモートサイトフェイルオーバーを用意しないというケースが考えられます。リモートハードウェアは、このようにリモートサイトフェイルオーバーメールサーバーにアクセスを許可されたユーザーの負荷を処理できます。
ユーザーベースの使用率だけを制限すると、必要な冗長サーバーとストレージハードウェアの数を減らすことができますが、フェイルバックの設定と管理も複雑になります。そのようなポリシーはまた、長期的には予期しない別の影響をユーザーに与えます。たとえば、ドメインメールルーターが 48 時間にわたって消失した場合、インターネット上の他の MTA ルーターがそのドメイン宛てのメールを保持します。ある時点で、サーバーがオンラインに復帰したときに (うまくいけば DoS による障害を受けることもなく)、そのメールが配信されます。さらに、すべてのユーザーをフェイルオーバーリモートサイトに設定していない場合は、MTA が起動して設定されていないユーザーに対して永続的なエラー (バウンス) が返されます。最後に、すべてのユーザーを受け入れるようにメールを設定している場合は、すべてのユーザーをフェイルバックするか、フェイルオーバーがアクティブな間使用できないアカウント宛てのメールを保持し、フェイルバックが起こったらそれを本来の配信の流れに戻すように MTA ルーターを設定する必要があります。
考えられるリモートサイトフェイルオーバーのソリューションには、以下のようなものがあります。
- 単純でコストのかからないシナリオ : リモートサイトの接続に広帯域幅の大規模ネットワークを使用しません。十分な規模のハードウェアを必ずしも使用する必要はありません。実際のところ、ハードウェアは当面の間は他の目的に使用できます。プライマリサイトからのバックアップがリモートサイトに対して定期的に提供されますが、必ずしも復元の必要はありません。予想される問題点としては、古いデータをオンラインに戻す際に重要なデータが失われたり、かなりの遅れが生じることです。プライマリサイトで障害が発生したときには、手動でネットワークを変更してサービスを開始し、続いて imrestore プロセスを開始します。サービスが起動されると、ファイルシステムの復元が開始されます。
- より複雑で、コストのかかるソリューション : Veritas および Sun の市販ソフトウェアソリューションでは、ローカル (プライマリ) ボリュームで発生するすべての書き込みがリモートサイトにも書き込まれます。通常の製品では、リモートサイトはプライマリサイトと共にロックステップかそれに近い状態になります。プライマリサイトで障害が発生した場合は、セカンダリサイトがネットワーク設定をリセットし、データをほとんど失うことなくサービスを提供できます。このシナリオでは、テープから復元する意味はありません。プライマリサイトの障害の前に切り替えられなかったデータは、少なくともフェイルバックが起きるか、MTA キューデータの場合には手動による介入が行われるまで、失われることになります。Veritas Site HA ソフトウェアは、プライマリサイトの障害を検出し、ネットワークをリセットしてサービスを起動する用途でよく使われますが、これはより高いレベルのデータ保管には必要ありません。サーバーがデータをコピーするのに負荷と待ち時間が大きく増加するため、このソリューションにはプライマリサイトで大量のハードウェアを必要とします。
- 最も実現性の高いソリューション : このソリューションでは、データのコピーがメッセージストアサーバーで行われることを除いて、ソフトウェアによるリアルタイムデータコピーソリューションと本質的には同じものです。日立データシステムズ (HDS) のアレイがこの機能を持っています。日立のアレイには、格納サーバーにほとんど、あるいはまったく影響を与えずに、アレイ間でこのデータコピーを実行する機能があります。HDS のアレイはサイズが大きく、このソリューションを導入するための基本コストも、Sun StorEdgeTM T3 や 3000 のアレイよりも高くつきます。さらに、HDS をフルに利用したとしても、M バイトあたりのコストも高くなります。大容量のストレージが必要な場合は、サーバーハードウェアを節約するために HDS がコピー処理を行うことを許可すれば、ストレージの追加コストを、少なくともある程度までは調整できます。
ハードウェアやソフトウェアをはじめ、管理コスト、電力費、光熱費、ネットワークコストまで、これらのソリューションでは、さまざまなコストが発生します。これらのコストはすべてそのまま計算に入れて、数字をはじき出します。そうしなければ、めったに起こらない処理を実行するときの思いがけない費用や、停止時間による直接のコスト、データ損失によるコストなど、いくつかのコストを算出するのが困難になります。このような種類のコストを正確に算定するのは不可能です。顧客によっては、停止時間とデータの損失は代償が高くつくか、まったく受け入れられません。その他の顧客にとっては不愉快以上のものではないでしょう。
リモートサイトフェイルオーバーを行う場合には、リモートディレクトリが少なくとも最新のもので、メッセージデータの復元が可能な状態にあることも必要です。リモートサイトにリストアメソッドを使用する場合は、ディレクトリが完全に復元されてからメッセージを復元する必要があります。また、ユーザーをシステムから削除した場合、ディレクトリ内でそのユーザーに無効のタグがつけられるだけなのはやむをえません。ユーザーのデータがあるメッセージバックアップテープが使用される限り、そのユーザーをディレクトリから削除してはなりません。
リモートサイトフェイルオーバーについての質問
以下の質問を参考にして、リモートサイトフェイルオーバーの計画を立ててください。
組織によっては、プライマリサイトで障害が発生したときに、手動処理のスクリプトセットで十分対応可能な場合もあります。短時間 (数分間) のうちにリモートサイトがアクティブになる必要がある組織もあります。そのような組織では、Veritas リモートサイトフェイルオーバーソフトウェアかそれに相当する機能を持ったその他のソフトウェアが必要です。
