リモートサイトフェイルオーバーは、プライマリサイトに致命的な障害が発生した場合に、そのプライマリサイトに WAN で接続されているサイトでサービスを開始する機能です。リモートサイトフェイルオーバーにはいくつかの形式があり、それぞれにコストが異なります。
リモートサイトフェイルオーバーでは、すべてのケースでサーバーとストレージを追加して、リモートサイトにインストールおよび設定された、サービスのユーザー負荷のすべてまたは一部を処理する能力を持つようにする必要があります。すべてまたは一部というのは、顧客によっては優先するユーザーとそうでないユーザーがいることを意味します。ISP でも企業でも、そのような状況が起こります。ISP には、この機能のために割増料金を支払うユーザーがいます。企業では、全従業員に電子メールの機能を提供している部門内で、ユーザーによってはそのサポートが高くついている場合があるかもしれません。たとえば、カスタマサポートに直接関わるユーザーのメールに対してリモートサイトフェイルオーバーを選択した場合でも、製造ラインで勤務する従業員には、リモートサイトフェイルオーバーを用意しないというケースが考えられます。リモートハードウェアは、このようにリモートサイトフェイルオーバーメールサーバーにアクセスを許可されたユーザーの負荷を処理できます。
ユーザーベースの使用率だけを制限すると、必要な冗長サーバーとストレージハードウェアの数を減らすことができますが、フェイルバックの設定と管理も複雑になります。そのようなポリシーはまた、長期的には予期しない別の影響をユーザーに与えます。たとえば、ドメインメールルーターが 48 時間にわたって利用不能になった場合、インターネット上の他の MTA ルーターがそのドメイン宛てのメールを保持します。ある時点でサーバーがオンラインに戻った際に、メールが配送されます。さらに、すべてのユーザーをフェイルオーバーリモートサイトに設定していない場合は、MTA が起動して設定されていないユーザーに対して永続的なエラー (バウンス) が返されます。最後に、すべてのユーザーを受け入れるようにメールを設定している場合は、すべてのユーザーをフェイルバックするか、フェイルオーバーがアクティブな間使用できないアカウント宛てのメールを保持し、フェイルバックが起こったらそれを本来の配信の流れに戻すように MTA ルーターを設定する必要があります。
考えられるリモートサイトフェイルオーバーのソリューションには、次のようなものがあります。
単純でコストのかからないシナリオ: リモートサイトの接続に広帯域幅の大規模ネットワークを使用しません。十分な規模のハードウェアを必ずしも使用する必要はありません。実際のところ、ハードウェアは当面の間はほかの目的に使用できます。プライマリサイトからのバックアップがリモートサイトに対して定期的に提供されますが、必ずしも復元の必要はありません。予想される問題点としては、古いデータをオンラインに戻す際に重要なデータが失われたり、かなりの遅れが生じることです。プライマリサイトで障害が発生したときには、手動でネットワークを変更してサービスを開始します。サービスを開始したら、続いて imsrestore プロセスを開始します。最後にファイルシステムの復元が開始されると、続いてサービスが開始されます。
より複雑で、よりコストのかかるソリューション: Veritas および Sun の市販ソフトウェアソリューションでは、ローカル (プライマリ) ボリュームで発生するすべての書き込みがリモートサイトにも書き込まれます。通常の製品では、リモートサイトはプライマリサイトとともにロックステップかそれに近い状態になります。プライマリサイトで障害が発生した場合は、セカンダリサイトがネットワーク設定をリセットし、データをほとんど失うことなくサービスを提供できます。このシナリオでは、テープから復元する意味はありません。プライマリサイトの障害の前に切り替えられなかったデータは、少なくともフェイルバックが起きるか、MTA キューデータの場合には手動による介入が行われるまで、失われることになります。Veritas Site HA ソフトウェアは、プライマリサイトの障害を検出し、ネットワークをリセットしてサービスを起動する用途でよく使われますが、これはより高いレベルのデータ保管には必要ありません。サーバーがデータをコピーするための負荷と待ち時間が大きく増加するため、このソリューションでは、プライマリサイトで必要なハードウェアの台数が大幅に増加します。
最も実現性の高いソリューション: このソリューションは、データのコピーがメッセージストアサーバーで行われることを除いて、ソフトウェアによるリアルタイムデータコピーソリューションと本質的には同じものです。Message Store サーバーが、リモートのレプリケーションをサポートするストレージアレイに接続されている場合、リモートサイトに対するデータコピーはストレージアレイのコントローラそれ自体によって処理されます。リモートのレプリケーション機能を提供するストレージアレイは大容量になりがちなため、このソリューションを導入するための基本コストは、ローエンドストレージ製品を使用する場合よりも高くつきます。
ハードウェアやソフトウェアをはじめ、管理コスト、電力費、光熱費、ネットワークコストまで、これらのソリューションでは、さまざまなコストが発生します。これらのコストはすべてそのまま計算に入れて、数字をはじき出します。そうしなければ、いくつかのコストを算出するのが困難になります。そのようなコストには、めったに実施しない一連の手順を実施するときのミスによるコスト、停止時間による直接のコスト、データ損失によるコストなどがあります。このような種類のコストを正確に算定するのは不可能です。顧客によっては、停止時間とデータの損失は代償が高くつくか、まったく受け入れられません。別の顧客にとっては、それは単なる不愉快にすぎないかもしれません。
リモートサイトフェイルオーバーを行う場合には、リモートディレクトリが少なくとも最新のもので、メッセージデータの復元が可能な状態にあることも必要です。リモートサイトにリストアメソッドを使用する場合は、ディレクトリが完全に復元されてからメッセージを復元する必要があります。また、ユーザーをシステムから削除した場合、ディレクトリ内でそのユーザーに無効のタグがつけられるだけなのはやむをえません。ユーザーのデータがあるメッセージバックアップテープが使用されるかぎり、それらのユーザーをディレクトリから削除してはなりません。
次の質問を参考にして、リモートサイトフェイルオーバーの計画を立ててください。
サイトで必要とする応答性のレベルはどの程度か
組織によっては、プライマリサイトで障害が発生したときに、手動処理のスクリプトセットで十分対応可能な場合もあります。短時間 (数分間) のうちにリモートサイトがアクティブになる必要がある組織もあります。そのような組織では、Veritas リモートサイトフェイルオーバーソフトウェアかそれに相当する機能を持ったその他のソフトウェアが必要です。
ローカル HA 用の Sun Cluster とリモートサイトフェイルオーバー用の Veritas ソフトウェアを併用しないでください。Sun Cluster は現時点ではリモートサイトフェイルオーバーをサポートしていません。
また、プライマリサイトからバックアップサイトへの自動フェイルオーバーをソフトウェアに許可しないでください。その場合、セカンダリサイトからプライマリサイトの障害が誤って検出される可能性がかなり高くなります。このようなケースでは、ソフトウェアにプライマリサイトを監視させ、障害を検出したときに警告を出させるように設定します。次に、バックアップサイトへの自動フェイルオーバープロセスを開始する前に、障害が実際に発生していることを確認します。
どれぐらいのデータを保存し、どの程度の速さで利用可能にする必要があるか
これは単純な質問のようですが、細分化されて回答の幅は広くなります。シナリオには、簡単なものからほとんど完全なものまであり、ハードウェア、ネットワークデータインフラストラクチャー、保守のコストの面でも大きな違いがあります。