高可用性ソフトウェア

高可用性ソフトウェアは、システムが稼働し、ほとんどの時間利用できるようにするためのソフトウェアです。高可用性とは、システムが機能している時間の割合が高いことです。正式には (1 - (ダウンタイム/合計時間))*100% と定義できます。最低限必要な可用性はタスクによって異なりますが、システムは通常 99.999% (ファイブナイン) の可用性を実現しようとします。この特性は、価格とパフォーマンスの面で大きなペナルティを伴いながらも、通常 100% の可用性を実現しようとするフォールト トレランスよりも劣ります。

高可用性ソフトウェアは、サブシステムに障害が発生したときのパフォーマンス、元の障害発生時のシステムの状態に近い状態でサービスを再開する能力、およびダウンタイムを排除または最小限に抑える方法でサービスに影響するその他のタスク (ソフトウェアのアップグレードや構成の変更など) を実行する能力によって評価されます。可用性に影響を与えるすべての障害 (ハードウェア、ソフトウェア、構成) は、可用性を最大化するために高可用性ソフトウェアによって対処する必要があります。

冗長性を追加することで高可用性を実現できます。適切に実行すれば、冗長性を追加することで可用性が飛躍的に向上し、システム全体の可用性を高めることができます。N 台の冗長ホストと並列ホストがあり、それぞれが X の可用性を持っている場合、次の式を使用できます: ^{[1] [2]}

並列および冗長コンポーネントの可用性 = 1 - (1 - X)^ N

たとえば、各ホストの可用性が 50% しかない場合、10 台のホストを並列に使用すると、99.9023% の可用性を実現できます。

冗長性は必ずしも可用性の向上につながるわけではないことに注意してください。実際、冗長性は複雑さを増し、可用性を低下させます。Marc Brookerによると、冗長性を活用するには、次の点を確認してください。^[3]

1. システム全体の可用性が正味で向上します
2. 冗長コンポーネントが独立して故障する
3. システムは正常な冗長コンポーネントを確実に検出できます
4. システムは、冗長コンポーネントを確実にスケールアウトおよびスケールインできます。

一般的な高可用性ソフトウェアは、次のような機能を提供します。

ハードウェアとソフトウェアの冗長性を有効にします。これらの機能には次のものが含まれます。

1. ハードウェアとソフトウェアのエンティティの発見、
2. これらのエンティティへのアクティブ/スタンバイロールの​​割り当て、
3. 故障したコンポーネントの検出、
4. 冗長コンポーネントにアクティブになるよう通知し、
5. システムを拡張する能力。

サービスは、そのサービスに課せられたすべての要求を処理できない場合は利用できません。システムの「スケールアウト」プロパティとは、増大する需要に対応するためにサブシステムの複数のコピーを作成し、できればシステムをシャットダウンせずに、受信した作業をこれらのコピーに効率的に分散する機能 (負荷分散 (コンピューティング) ) を指します。高可用性ソフトウェアは、サービスを中断することなくスケールアウトを可能にする必要があります。

アクティブ/スタンバイ通信を有効にする (特にチェックポイント) : アクティブサブシステムは、スタンバイサブシステムがアクティブが中断したところから引き継ぐ準備ができていることを確認するために、スタンバイサブシステムと通信する必要があります。高可用性ソフトウェアは、冗長メッセージやイベントキューなどの通信抽象化を提供して、アクティブサブシステムがこのタスクを行えるようにすることができます。さらに、「チェックポイント」と呼ばれる重要な概念は、高可用性ソフトウェアに固有のものです。チェックポイントシステムでは、アクティブサブシステムはすべての重要な状態を識別し、この状態の変更を定期的にスタンバイに更新します。この概念は、一般的に分散ハッシュテーブルとして抽象化されます。アクティブサブシステムはキー/値レコードをテーブルに書き込み、アクティブサブシステムとスタンバイサブシステムの両方がそこから読み取ります。「クラウド」分散ハッシュテーブル ( Chord (ピアツーピア)、Kademliaなど) とは異なり、チェックポイントは完全に複製されます。つまり、「チェックポイント」ハッシュテーブル内のすべてのレコードは、1 つのコピーが実行されている限り読み取り可能です。^[4] [アプリケーションチェックポイント] と呼ばれる別の手法は、プログラムの状態全体を定期的に保存します。^[5]

インサービスアップグレードを有効にする: インサービスソフトウェアアップグレードは、サービスを低下させることなくソフトウェアをアップグレードする機能です。これは通常、冗長システムで「ローリング」アップグレードと呼ばれるものを実行することによって実装されます。つまり、アクティブがサービスを提供している間にスタンバイをアップグレードし、フェイルオーバーしてから古いアクティブをアップグレードします。もう 1 つの重要な機能は、新しいバージョンに障害が発生した場合に、古いバージョンのソフトウェアと構成に迅速にフォールバックできることです。^{[6] [7]}

スタンバイのレイテンシを最小限に抑え、スタンバイの正確性を確保する: スタンバイのレイテンシは、スタンバイがアクティブになるように指示されてから実際にサービスを提供するまでの時間として定義されます。「ホット」スタンバイ システムは、アクティブ システムのチェックポイントに応じて内部状態をアクティブに更新するシステムであり、ダウンタイムは数ミリ秒です。「コールド」スタンバイ システムは、アクティブが失敗するまでオフラインで、通常は「ベースライン」状態から再起動します。たとえば、多くのクラウド ソリューションでは、基盤となる物理マシンが失敗すると、別の物理マシンで仮想マシンを再起動します。「コールド」フェイルオーバー スタンバイのレイテンシは、30 秒以上から数分の範囲です。最後に、「ウォーム」スタンバイは、実行中であるものの、アクティブになる前に何らかの内部処理を実行する必要があるすべてのシステムを含む非公式の用語です。たとえば、ウォーム スタンバイ システムは、優先度の低いジョブを処理している可能性があります。アクティブが失敗すると、これらのジョブを中止し、アクティブのチェックポイント状態を読み取ってからサービスを再開します。ウォーム スタンバイのレイテンシは、チェックポイントが作成されるデータの量によって異なりますが、通常は数秒のレイテンシがあります。

高可用性ソフトウェアは、障害の範囲を最小限に抑え、特定の障害モードを処理するように設計された複雑なシステム アーキテクチャをエンジニアが作成するのに役立ちます。「通常の」障害はソフトウェア アーキテクチャで処理できる障害として定義され、「壊滅的な」障害は処理できない障害として定義されます。したがって、壊滅的な障害はサービス停止を引き起こします。ただし、壊滅的な障害が修復されるとすぐに自動的にサービス状態に戻るため、ソフトウェアは可用性を大幅に向上させることができます。

最も単純な構成 (または「冗長モデル」) は、アクティブ 1 台、スタンバイ 1 台、または 1+1 です。もう 1 つの一般的な構成は N+1 (アクティブ N 台、スタンバイ 1 台) で、スタンバイ サブシステムの数が少なくなるため、システム全体のコストが削減されます。一部のシステムでは、オールアクティブ モデルが使用され、スタンバイ サブシステムが常に検証されるという利点があります。

アクティブ、ホットスタンバイ、コールドスタンバイ（またはアイドル）サブシステムで構成を定義することもできます。これは、従来の「アクティブ+スタンバイ」という命名法を「アクティブ+スタンバイ+アイドル」（例：5+1+1）に拡張したものです。通常、「コールドスタンバイ」または「アイドル」サブシステムは、優先度の低い作業のためにアクティブになります。これらのシステムは、地理的冗長性と呼ばれる戦略で冗長ペアから遠く離れた場所に配置されることがあります。^[8] このアーキテクチャは、冗長マシンを分離することで、物理的にローカルなイベント（火災、洪水、地震）によるサービスの損失を回避しようとします。

高可用性ソフトウェアでは、ソフトウェア障害とハードウェア障害を区別し、個々のソフトウェア プロセス、ソフトウェア スタック全体、またはシステム全体の時間遅延再起動を試行するための高度なポリシーを指定できます。

過去 20 年間で、通信ネットワークやその他の複雑なソフトウェア システムは、ビジネスやレクリエーション活動に不可欠な要素になりました。

「同時に（経済が低迷している中）、ほぼ 60% の企業、つまり 10 社中 6 社が 99.999 を求めています。これは、ミッション クリティカルな基幹業務アプリケーションで 4 ナインまたは 5 ナインの可用性とアップタイムを意味します。また、回答者の 9%、つまり 10 社中ほぼ 1 社が、5 ナイン以上のアップタイムが必要だと言っています。つまり、ダウンタイムがないということです。言い換えれば、本当に防弾、爆弾にも耐えられるアプリケーションとハードウェア システムが必要です。では、何を使うかご存知ですか? 1 つは、高可用性クラスタを使用するか、より高価で複雑なフォールト トレランス サーバーを使用するかです。」^[9]

通信:ネットワークの停止は通信事業者の収益に多大な損失をもたらす可能性があり、緊急サービスへの電話アクセスは重要な公共安全問題であるため、 高可用性ソフトウェアは通信機器の重要なコンポーネントです。

防衛/軍事：最近、高可用性ソフトウェアは、有人および無人の車両の可用性を安価に提供する方法として防衛プロジェクトに導入され始めている^[10]

宇宙：高可用性ソフトウェアは、宇宙環境での非放射線耐性機器の使用に提案されています。放射線耐性電子機器は、市販の機器に比べて大幅に高価で、性能も低くなります。しかし、1台または2台の放射線耐性コントローラで動作する高可用性ソフトウェアは、冗長化された高性能の非放射線耐性コンピュータを多数管理でき、障害発生時にはフェイルオーバーしてリセットすることができます。^[11]

一般的なクラウドサービスでは、Linux などの標準サーバー OS を実行するネットワーク接続されたコンピューターのセット (通常は仮想マシン) が提供されます。コンピューターは多くの場合、同じデータ センター内の他のインスタンスとは無料で通信でき (テナント ネットワーク)、外部のコンピューターとは有料で通信できます。クラウド インフラストラクチャでは、仮想マシン レベルでの簡単な障害検出と再起動が提供される場合があります。ただし、再起動には数分かかる場合があり、可用性が低下します。また、クラウド サービスでは仮想マシン内のソフトウェア障害を検出できません。クラウド仮想マシン内で実行される高可用性ソフトウェアは、ソフトウェア (および仮想マシン) 障害を数秒で検出し、チェックポイントを使用してスタンバイ仮想マシンがサービスを引き継ぐ準備ができていることを確認できます。

サービス可用性フォーラムは、アプリケーションを考慮した高可用性の標準を定義しています。^[12]

• コンピュータ クラスター
• 高い信頼性を誇るソフトウェア

• OpenClovis SAFplus 高可用性ソフトウェア
• Linux-HA ソフトウェアは 2008-07-05 にWayback Machineでアーカイブされています
• Linux 用 Keepalived
• Windows および Linux 向け Evidian SafeKit ソフトウェア