ディザスタ・リカバリ

コンピューティングやネットワークなどの関連技術において、フェイルオーバーとは、バックアップ復旧設備にオペレーションを切り替えるプロセスのことである。フェイルオーバーにおけるバックアップ・サイトは一般に、スタンバイまたは冗長化されたコンピュータ・ネットワーク、ハードウェア・コンポーネント、システム、またはサーバーであり、多くの場合、二次災害復旧（DR）ロケーションにある。通常、フェイルオーバーでは、フェイルオーバー・ツールまたはフェイルオーバー・サービスを使用して、一時的に運用を停止し、リモート・ロケーションから運用を再開します。

フェイルバック操作では、予定されたメンテナンス期間または災害の後に、本番稼動を元の場所に戻します。スタンバイ状態から完全に機能する状態に戻すことです。

通常、システム設計者は、CA、HA、または高水準の信頼性が要求されるシステム、サーバー、またはネットワークにおいて、フェイルオーバー機能を提供する。また、フェイルオーバーの実践は、仮想化ソフトウェアの使用により、サービスの中断がほとんどない物理的なハードウェアへの依存度が低くなっています。

フェイルオーバー・テストでは、サーバー障害時にシステムの能力を検証し、復旧に向けて十分なリソースを割り当てる。言い換えれば、フェイルオーバー試験は、サーバーのフェイルオーバー能力を評価します。

このテストでは、何らかの異常終了や障害が発生した場合に、必要な余分なリソースを処理し、バックアップシステムに業務を移行する能力がシステムにあるかどうかを判断します。例えば、フェイルオーバーとリカバリーのテストでは、クリティカルな障害時にしばしば破られるパフォーマンスのしきい値を達成した時点で、システムが追加のCPUや複数のサーバーを管理し、電力を供給する能力を判断します。これは、フェイルオーバーテスト、回復力、およびセキュリティの間の重要な関係を浮き彫りにしています。

アプリケーション・サーバーは、単にアプリケーションを実行するサーバーである。つまり、アプリケーションサーバーのフェイルオーバーは、この種のサーバーを保護するためのフェイルオーバー戦略です。

最低限、これらのアプリケーション・サーバは固有のドメイン名を持つべきであり、理想的には異なるサーバ上で実行されるべきです。フェイルオーバークラスターのベストプラクティスには通常、アプリケーションサーバーのロードバランシングが含まれます。

フェイルオーバークラスターは、フォールトトレランス（FT）、継続的可用性（CA）、または高可用性（HA）を一緒に提供するコンピュータサーバーのセットです。フェイルオーバークラスターのネットワーク構成では、仮想マシン（VM）、物理ハードウェアのみ、またはその両方を使用できます。

フェイルオーバークラスター内のサーバーの1台がダウンすると、フェイルオーバープロセスが起動します。障害が発生したコンポーネントのワークロードをクラスター内の別のノードに即座に送信することで、ダウンタイムを防ぐことができます。

アプリケーションやサービスに対してHAまたはCAのいずれかを提供することが、フェイルオーバークラスターの主な目的である。フォールトトレラント（FT）クラスタとしても知られるCAクラスタは、メインシステムやプライマリシステムに障害が発生した場合のダウンタイムを排除し、エンドユーザが中断やタイムアウトなしにアプリケーションやサービスを使い続けることを可能にします。

対照的に、HAクラスタではサービスが短時間中断する可能性があるにもかかわらず、ダウンタイムは最小限に抑えられ、自動的に復旧し、データの損失はありません。HAクラスタの復旧プロセスは、ほとんどのフェールオーバークラスタソリューションの一部として含まれているフェールオーバークラスタマネージャツールを使用して構成できます。

広義には、クラスタとは2つ以上のノードまたはサーバを指し、通常は物理的にケーブルで接続され、ソフトウェアで接続されます。並列処理または並行処理、負荷分散、クラウド・ストレージ・ソリューションなどの追加のクラスタリング技術が、一部のフェイルオーバー実装に含まれています。

インターネットフェイルオーバーは、基本的に冗長またはセカンダリのインターネット接続であり、障害発生時のフェイルオーバーリンクとして使用される。これは、サーバーにおけるフェイルオーバー機能のもう1つの部分と考えることができます。

アクティブ-アクティブとアクティブ-パッシブまたはアクティブ-スタンバイは、高可用性（HA）のための最も一般的な構成である。それぞれの実装手法は異なる方法でフェイルオーバーを実現しますが、どちらも信頼性を向上させます。

通常、同じ種類のサービスをアクティブに同時に実行する少なくとも2つのノードがアクティブ-アクティブ高可用性クラスタを構成します。アクティブ-アクティブ・クラスタは、すべてのノードにワークロードをより均等に分散し、単一のノードが過負荷になるのを防ぎ、負荷分散を実現します。また、より多くのノードが利用可能な状態に保たれるため、スループットと応答時間が向上します。HAクラスタがシームレスに動作し、冗長性を実現するためには、ノードの個々の構成と設定を同一にする必要があります。

対照的に、アクティブ-パッシブクラスタでは、少なくとも2つのノードが必要ですが、そのすべてがアクティブであるとは限りません。最初のノードがアクティブな2ノード・システムでは、2番目のノードはフェイルオーバー・サーバとしてパッシブまたはスタンバイのままになります。このスタンバイ運用モードでは、アクティブなプライマリ・サーバーが機能しなくなった場合でも、バックアップとして機能するように待機しておくことができます。ただし、障害が発生しない限り、クライアントはアクティブなサーバーにのみ接続します。

アクティブ-アクティブ・クラスタと同様に、アクティブ-スタンバイ・クラスタの両サーバはまったく同じ設定で構成する必要があります。こうすることで、フェイルオーバー・ルーターやサーバーが引き継がなければならない場合でも、クライアントはサービスの変化を認識することができません。

アクティブ-スタンバイ・クラスタでは、スタンバイ・ノードが常に稼働しているにもかかわらず、実際の利用率がゼロに近づくことは明らかです。

アクティブ-アクティブ・クラスタでは、各ノードが単独で全負荷を処理できるにもかかわらず、両ノードの利用率は半分ずつに近づきます。ただしこれは、アクティブ-アクティブ構成ノードの1台が負荷の半分以上を一貫して処理する場合、ノードの障害によってパフォーマンスが低下する可能性があることも意味します。

アクティブ-アクティブHA構成では、両方のパスがアクティブであるため、障害発生時の停止時間は実質的にゼロです。アクティブ-パッシブ構成では、システムが一方のノードから他方のノードに切り替わらなけ ればならず、時間がかかるため、停止時間が長くなる可能性があります。

サーバーのフェイルオーバー自動化には、パルスまたはハートビート状態が含まれる。つまり、ハートビート・ケーブルは、プライマリ・サーバーが常にアクティブな状態で、ネットワーク内の2つのサーバーまたは複数のサーバーを接続する。ハートビートが続いているか、パルスを感知している限り、セカンダリー・サーバーはただ休んでいるだけである。

しかし、セカンダリー・サーバーがプライマリー・フェイルオーバー・サーバーからのパルスの変化を感知すると、インスタンスを起動し、プライマリー・サーバーのオペレーションを引き継ぐ。また、技術者やデータセンターにメッセージを送り、プライマリー・サーバーをオンラインに戻すよう要求する。手動承認構成の自動化と呼ばれるシステムでは、技術者やデータセンターに単に警告を発し、サーバーへの変更を手動で行うよう要求するものもある。

仮想化では、ホスト・ソフトウェアを実行する仮想マシンまたは擬似マシンを使用して、コンピュータ環境をシミュレートします。このようにして、フェイルオーバー・プロセスは、コンピューター・サーバー・システムの物理的なハードウェア・コンポーネントから独立することができる。

フェイルオーバーとは、信頼性の高いバックアップシステムに自動的かつシームレスに切り替える機能のことである。コンポーネントまたはプライマリ・システムに障害が発生した場合、スタンバイ運用モードまたは冗長性のいずれかでフェイルオーバーを実現し、ユーザーへの悪影響を軽減または排除する必要。

以前アクティブだったバージョンの異常な故障や終了時に冗長性を実現するには、スタンバイデータベース、システム、サーバー、その他のハードウェアコンポーネント、またはネットワークが、常に自動的に動作に切り替わる準備が整っていなければなりません。言い換えれば、フェイルオーバーはディザスタリカバリ（DR）にとって非常に重要であるため、スタンバイコンピュータサーバシステムを含むすべてのバックアップ技術は、それ自体が障害を免れるものでなければならない。

分散システムに障害が発生した場合、コンポーネントやサービス間に多くの依存関係が存在する可能性があるため、どのように復旧させるか判断が難しい場合があります。ここでは、分散システムで依存関係を管理し、復旧の順序を設定するための主な考慮事項を紹介します：

重要な依存関係を特定する： 重要な依存関係の特定：まず、システム内のさまざまなサービスやコンポーネント間の依存関係をマッピングすることから始めます。システムの機能にとって最も重要な依存関係を特定し、これらの依存関係に障害が発生した場合の影響を判断します。

依存関係の優先順位付け： 重要な依存関係を特定したら、システム機能への影響と、他のサービスやコンポーネントが依存する度合いに基づいて、依存関係の優先順位を決定します。

復旧手順を確立する： 各サービスやコンポーネントの復旧手順を定義し、復旧に必要な手順と依存関係を明記します。

復旧プロセスを自動化する： 手動による介入を最小限に抑え、システムの復旧に必要な時間を短縮するため、可能な限り復旧プロセスの自動化を検討します。

復旧計画のテストと検証 ：定期的にテストと検証を行い、効果的で最新の状態に保つようにします。復旧のための模擬演習を実施し、潜在的な問題を特定し、計画を改善します。

分散型システムにおけるリカバリーの課題

よく設計された分散システムでは、あるコンポーネントの故障がシステム全体の故障を意味することはないはずです。むしろ、故障はそのコンポーネント自体に分離されるべきです。このような種類の障害を適切に検出し、対応するようにシステムを設計することは可能である。いずれにせよ、災害復旧テスト計画は、現実的な条件が訓練されるように、これらのニュアンスを考慮する必要があります。ここでは、復旧可能な分散型システムを設計する際に対処しなければならない課題をいくつか紹介します：

ネットワーク障害とデータレプリケーション
ネットワークトポロジーは、通常の運用中に変化することがあります。ネットワーク・パーティション、ネットワークの混雑、ポリシー、ルール、セキュリティ・グループ、その他多くの要因によって、システム内のコンポーネント間で断続的または恒久的な切断が発生することがあります。

フェイルオーバー時のプライマリーネットワークとリカバリーネットワークをどのように設計し、運用しているか？また、本番システムと並行してどのようにテストを行うかを理解することも重要です。リカバリーシステムは、オンデマンドでリカバリーできることが分かっていればそれでいいのです。

分散トランザクション管理
分散システムで実行されるトランザクションは、複数のシステムにまたがる可能性があり、それらのシステム間で調整する必要があることを意味します。この調整は、複数のマシンプロセスにまたがるトランザクションを調整することになるため、些細なことではありません。

さらに、トランザクションは、それらの他のマシン上の他のトランザクションや、データベースやファイルシステムなどの外部リソースと調整する必要がある場合があります。

サービス依存性の解決
サービス間でビジネスロジックの実行やサービスコールを連携させるためには、サービス同士を見つけることができる必要があります。ほとんどのマイクロサービス実装では、サービスディスカバリーが必要ですが、モノリシックなアーキテクチャでも応用が可能です。

データの一貫性と回復
多くの場合、ディザスタリカバリは、データの損失や破損を最小限に抑えながら、できるだけ早くサービスを回復することを目的としています。したがって、アプリケーションは、状態を失ったりデータを破損したりすることなく、障害から回復できるように設計されていなければなりません。

バックアップとディザスタリカバリの計画
バックアップは復旧計画に欠かせないもので、データのバックアップコピーがない場合は、ゼロから作り直すことも可能です。

災害復旧テスト + 復旧メカニズムの検証
リカバリープランは複雑なメカニズムに依存しており、本番環境に導入する前にテストが必要です。

ソフトウェアの新バージョンが常にリリースされ、リカバリに影響を与える可能性のある新機能が追加されるため、テストは定期的に行う必要があります。