高可用性とは、システム アーキテクチャまたはサービスに関して、IT 分野でよく使用される用語で、このアーキテクチャまたはこのサービスが適切な可用性率を備えているという事実を指します。
高可用性クラスター (コンピューティング クラスターとは対照的) は、ダウンタイムを可能な限り回避しながらサービスを提供することを目的としたコンピューターのクラスターです。
可用性を測定するには、基本的に「9」で構成されるパーセンテージを使用することがよくあります。
- 99% は、サービスが利用できない時間が年間 3.65 日未満であることを意味します
- 99.9%、年間 8.75時間未満
- 99.99%、年間 52分未満
- 99.999%、年間 5.2 分未満
- 99.9999%、年間 54.8 秒未満
- 99.99999%、年間 3.1 秒未満
- 等
高可用性を確保するテクノロジー
高可用性を確保するために、次のような多くの技術が使用されています。
- ハードウェアの冗長性とクラスタリング
- データセキュリティ: RAID、スナップショット、Oracle DataGuard、BCV、SRDF、
- サーバーを「ホット」に再構成する可能性（つまり、サーバーの実行中）
- デグレードモードまたはパニックモード
- バックアップ計画…
- バックアップの保護: アウトソーシング、サードパーティ サイトへの集中化
高可用性には、ほとんどの場合、安定化電源、床置き式エアコン、粒子フィルター付き、メンテナンス サービス、セキュリティ サービス、悪意のある行為や盗難に対するセキュリティなど、適切な施設が必要です。また、火災や水害にも注意してください。電源ケーブルや通信ケーブルは複数本にして埋設する必要があります。パリの建物でよく見られる、建物の地下駐車場に突き出てはいけません。ホスティング プロバイダーを選択するとき (高可用性施設を借りる場合)、これらの基準が最初に考慮されます。アーキテクチャの各レベル、各コンポーネント、コンポーネント間の各接続を確立する必要があります。
- 故障を検出するにはどうすればよいですか?例: Alteon ボックスによって実装される TCP ヘルスチェック寿命テスト、定期的に呼び出されるテスト プログラム (「ハートビート」)、コンポーネント上の「診断」タイプのインターフェイスなど。
- コンポーネントはどのように保護、冗長化、バックアップされているかなど。例: スタンバイ サーバー、システム クラスター、WebSphere クラスタリング、RAID ストレージ、バックアップ、デュアル SAN 接続、縮退モード、再インストールの準備ができている未使用の空きハードウェア (予備)。
- 緊急/劣化モードでトグルをどのようにアクティブにしますか。分析後に手動で?自動的に ？
- 緊急システムが安定した既知の状態で確実に再起動されるようにする方法。例: データベースのコピーから開始してログ アーカイブを再適用する、既知の状態からバッチを再開する、複数のデータ リポジトリを更新するトランザクションの 2 フェーズ コミットなど。
- アプリケーションがフォールバック メカニズムで再起動される方法。例: アプリケーションの再起動、中断されたバッチの再起動、縮退モードのアクティブ化、バックアップ サーバーによる障害が発生したサーバーの IP アドレスの再開など。
- 現在のトランザクションまたはセッションを再開する方法。例: アプリケーションサーバー上のセッション永続性、失敗する前に正常に実行されたがクライアントが応答を受信しなかったトランザクションに対してクライアントへの応答を保証するメカニズムなど。
- 通常の状態に戻す方法。例:
他のアプリケーションへの依存性
同期モードのミドルウェア (http、Tuxedo、Corba、EJB などの Web サービス) を使用して他のアプリケーションを要求するアプリケーションの場合、アプリケーションの可用性率は、アプリケーションが依存するアプリケーションの可用性と強く関係します。したがって、依存するアプリケーションの感度は、アプリケーション自体の感度と同等かそれ以上でなければなりません。それ以外の場合は考慮する必要があります
このため、可能であれば可用性を高めるために、非同期ミドルウェアの使用を優先します。
負荷分散と感度
感度は多くの場合、負荷分散メカニズムを備えた冗長要素によって管理されます。 (たとえば、Alteon ロードバランシングを備えた WebSphere クラスター)。このシステムが信頼性の点で実際の利益を提供するには、要素の 1 つに障害が発生した場合でも、残りの要素がサービスを保証するのに十分な電力を備えていることを検証する必要があります。つまり、負荷分散を行う 2 台のアクティブ サーバーの場合、1 台のサーバーの電力で負荷全体をカバーできなければなりません。サーバーが 3 台の場合、1 台のサーバーの電力で負荷の 50% をカバーできる必要があります (2 台のサーバーで同時にインシデントが発生する可能性は無視できると仮定します)。良好な信頼性を確保するために、多数のサーバーを相互にサポートする必要はありません。たとえば、99% の信頼性の高い要素を 1 回冗長すると、99.99% の信頼性が得られます (両方の要素が同時に故障する確率 = 1/100×1/100 = 1/10,000)
差動冗長性
要素の冗長性は、通常、複数の同一コンポーネントによる冗長化を選択することによって実現されます。これは、コンポーネントの 1 つの障害がランダムであり、他のコンポーネントの 1 つの障害とは無関係であることを効果的に前提としています。これは、たとえばハードウェア障害の場合です。これはすべての障害に当てはまるわけではありません。たとえば、オペレーティング システムの欠陥やソフトウェアコンポーネントの異常は、条件が良好であれば、すべてのコンポーネントで同時に発生する可能性があります。このため、アプリケーションが非常に機密性の高い場合は、性質は異なるが同じ機能を保証するコンポーネントを備えた冗長要素を検討します。これにより次のような問題が発生する可能性があります
- 異なる性質、異なる OS、異なるインフラストラクチャ ソフトウェア製品を備えたサーバーを選択します。
- 同じコンポーネントを 2 回開発します。そのたびに、コンポーネントに適用されるインターフェイス規約が尊重されます。
投票システムによる冗長性
このモードでは、異なるコンポーネントが同じ入力を処理するため、(原則として) 同じ出力が生成されます。
すべてのコンポーネントによって生成された結果が収集され、アルゴリズムが実装されて最終結果が生成されます。アルゴリズムは単純 (多数決) または複雑 (平均、加重平均、中央値など) にすることができ、その目的は、コンポーネントの 1 つの誤動作に起因する誤った結果を排除すること、および/またはシステムの信頼性を高めることです。いくつかのわずかに異なる結果を組み合わせることによって。このプロセスでは次のことが行われることに注意してください。
- 負荷分散は許可されません
- 投票アルゴリズムを管理するコンポーネントの信頼性の問題が発生します。
このプロセスは通常、次のような場合に使用されます。
- センサーが冗長化されているセンサー(例: 温度センサー) に基づいたシステム
- 同じ機能を保証するシステムまたは複数の異なるコンポーネントが使用され (差分冗長性を参照)、コンポーネントによって生成された結果を組み合わせることでより良い最終結果が得られます (例: より良い認識率を得るために複数のアルゴリズムを使用するパターン認識システム)。
「影の作戦」
冗長コンポーネントが故障し、それを修復した後、それをアクティブなサービスに再導入して、その効果的な機能をチェックしたい場合がありますが、その結果は使用されません。この場合、入力は信頼できることがわかっている 1 つ (または複数) のコンポーネントによって処理されます。これらは、システムの残りの部分で使用される結果を生成します。同じ入力は、「シャドウ」モードであると言われる再導入されたコンポーネントによっても処理されます。コンポーネントが正しく動作しているかどうかは、生成された結果を信頼できるコンポーネントの結果と比較することで検証できます。このプロセスは、「シャドウ」モードのコンポーネントを最終投票から除外するだけで十分であるため、投票ベースのシステムでよく使用されます。