スイッチオーバー、フェイルオーバー、リカバリー：微妙だけれども重要な違い

※この記事は翻訳されたものです。本記事の原文はこちら

高可用性は専門的な分野であり、他の専門分野と同様、独自の語彙や専門用語があります。当社のお客様は一般にITに非常に詳しいと思いますが、HA環境を使用したことがない場合、一部の一般的なHA用語がお客様と私たちにかなりの混乱を引き起こす可能性があります。

そのような用語は一見単純ですが、HAの文脈では非常に具体的な意味を持ちます。この記事では、これらの用語のうち、スイッチオーバー、フェイルオーバー、リカバリーの3つについて説明します。

一見単純ですが、HAの文脈では非常に具体的な意味を持ち

スイッチオーバーとは

スイッチオーバーとは、高可用性 (HA) クラスタリングソリューションのユーザーインターフェースまたはCLIを介してユーザーが開始するアクションです。スイッチオーバーでは、ユーザーが手動でアクションを開始して、保護対象のアプリケーションのソースサーバーまたはプライマリーサーバーを変更します。

典型的なスイッチオーバーシナリオでは、実行中のすべてのアプリケーションと依存関係が順番に停止されます。親アプリケーションから始まり、すべての子/依存関係が停止された時点で完了します。アプリケーションとその依存関係が停止すると、新しく指定されたプライマリーサーバーまたはソースサーバーで順番に再起動されます。

たとえば、アルファ、ベータ、ガンマというリソースがあるとします。アルファはベータとガンマに、ベータはガンマに依存しています。スイッチオーバーでは、リソースアルファが最初に停止され、次にベータ、最後にガンマが停止されます。3つすべてが停止すると、スイッチオーバーが続行され、目的のサーバーでリソースが動作状態になります。起動プロセスはリソースガンマから始まり、次にベータ、最後にリソースアルファの起動操作が完了します。

従来、スイッチオーバー操作は、リソースを決められた手順に従った秩序ある方法で停止する必要があるため、より多くの時間を必要としていました。スイッチオーバーは、アップタイムを維持しながらソフトウェアのバージョンを更新する必要がある場合、プライマリーの本番ノードで（ローリングアップグレードで）メンテナンス作業を実行する場合、またはDRテストを実行する場合によく行われます。

重要なポイント：対応が必要な障害がない場合は、スイッチオーバーを行う

フェイルオーバーとは

フェイルオーバーとは、通常、サーバーのクラッシュや予期せぬ再起動や計画外の再起動に対応するためのアクションであり、ユーザーが開始するものではありません。ノードAとノードBの2つのノードからなるHAクラスターのシナリオを考えてみましょう。このシナリオでは、重要なアプリケーションであるアルファ、ベータ、ガンマがノードA上で起動し、動作しています。このシナリオでは、ノードAが予期せぬ/計画外の再起動、電源オフ、停止、パニックに陥ったときにフェイルオーバーが実行されます。

 HAソフトウェアは、（ソリューションで定義されているように）ノードAがクラスター内で機能しなくなり、操作不能になったことを検出すると、フェイルオーバーを開始して重要なアプリケーション、リソース、 サービス、依存関係を、利用可能なクラスターノード（この場合はノードB）上でアクセスできるようにし ます。フェイルオーバーのシナリオでは、ノードAでクラッシュ（またはその他のシミュレートされた即時障害）が発生したため、ノードAで停止するプロセスはなく、適切な検出とフェンシングアクションが行われると、ノードBが直ちにリソースを復元するプロセスを開始します。

スイッチオーバーの場合と同様に、プロセスはリソースガンマから始まり、次にベータ、最後にリソースアルファの起動動作が完了します。通常、フェイルオーバーの処理は、スイッチオーバーよりも短い時間で済みます。これは、フェイルオーバーの処理では、以前のプライマリー（In-Serviceまたはアクティブ）ノードでリソースを停止（または静止）させる必要がないためです。

重要なポイント：フェイルオーバーは、システム障害に対応するために発生する

リカバリーとは

リカバリーとは、フェイルオーバーと混同されがちですが、リカバリーは、プロセス、サーバー、コミュニケーションパス、ディスク、あるいはクラスターリソースに障害が発生し、高可用性ソフトウェアがその障害に対応するために動作するときに発生します。ほとんどのHAソフトウェアは、リカバリーを複数の方法で処理することができます。最も代表的な方法は以下の通りです。

1. ローカルでグレースフルリスタート、その後リモートでグレースフルリスタート
   1. 再起動は常にローカルで試行され、リカバリーに成功した場合はそれ以上の動作は発生しません。ローカルでの再起動が失敗した場合は、次の操作が行われます。
   2. ローカルでの再起動に失敗した場合、リソースは決められた手順に従ってリモートノードに移動されます。
2. ローカルでグレースフルリスタート、その後リモートで強制リスタート
   1. 再起動は常にローカルで試行され、リカバリーに成功した場合はそれ以上の動作は発生しません。ローカルでの再起動に失敗した場合は、次の操作が行われます。
   2. プライマリーノードをフェンシングすることにより、リソースがリモートノードに移動されます。
3. リモートでの強制再起動
   1. ローカルで再起動が試行されることはありません。
   2. 方法2-2で説明したように、リソースは常に次に利用可能なクラスタノードに強制的に移動されます。
4. サーバーの強制再起動、リモートでのフェイルオーバーなし
   1. 再起動は常にローカルで試行されます。
   2. ローカルでの再起動に失敗した場合、プライマリーノードを再起動し、サービスの回復を試みます。
   3. リソースがリモートシステムにフェイルオーバーすることはありません。
5. ポリシーに基づいてローカルで再起動してからリモートで再起動する
   1. リモートのリカバリーが発生するまでの再試行回数をポリシーで管理することができます。

リカバリーポリシーにはさまざまなバリエーションがあるため、スイッチオーバーの動作に似たリカバリーイベントはよく見られます（特に方法1および5でよく見られます）。これらのシナリオでは、リモートノードで起動する前に、アプリケーションとサービスは手順に従って停止されます。方法2および3では、フェイルオーバーと同様の動作が見られ、プライマリーサーバーがHAソフトウェアによって再起動またはフェンシングされます。

方法4は通常はほとんど使用されないオプションですが、スイッチオーバーとフェイルオーバーの両方を組み合わせたものです。方法4は、アプリケーションとサービスのグレースフルストップから始まり、その後アプリケーションとサービスが再起動されます（スイッチオーバーとほぼ同じです）。

ただし、アプリケーションとサービスのローカルでの再起動に失敗した場合、（フェイルオーバーと同じように）システムは再起動されますが、リモートのクラスターノードにフェイルオーバーすることはありません。まれではありますが、方法4は、バランスの取れていないクラスターが存在する場合、またはポリシーベースの手法で使用する場合によく使用されます。

重要なポイント：リカバリーイベントは、選択した方法によって異なる

最後に

ベンダーで使用されるHA用語では、共通の用語が異なる意味を持つことがあります。エンタープライズアプリケーションを使用してクラスターソリューションの導入と保守を行う際には、フェイルオーバー、スイッチオーバー、リカバリーに関するソリューションプロバイダーの用語を理解しておく必要があるのです。