How To Calculate High Availability Uptime Percentage?
可用性とは、特定のシステムが特定の期間（通常は 1 年間）にどれだけ完全に稼働していたかを示すもので、パーセントで表されます。 アップタイムが必ずしもアベイラビリティと同じ意味である必要はないことに注意してください。 システムは稼働していても、ユーザーには利用できないことがあります。 その理由は、ネットワークや負荷分散の問題かもしれません。
アップタイムは通常、可用性の5つの9を使った等級付けを使って表現されます。 等級が「9分の1」であれば、保証される可用性は90%であることを意味します。 今日、ほとんどの組織や企業は、少なくとも「スリーナイン」、つまり 99.9% の可用性を持つことを要求しています。
企業にはさまざまな可用性のニーズがあります。 年間を通じて24時間稼働する必要がある企業は、「ファイブナイン」、つまり99.999%のアップタイムを目指します。 0.1% はそれほど大きな違いではないように思われるかもしれません。 しかし、これを時間や分に換算すると、大きな数字になるのです。
各グレードの年間最大ダウンタイムを確認するには、ナインの表を参照してください:
| 可用性レベル | 年間最大ダウンタイム | 1日のダウンタイム |
| ワンナイン： 90% | 36.5日 | 2.4 時間 |
| トゥーナイン。 99% | 3.65 日 | 14 分 |
| Three Nines: 99.9% | 8.76 時間 | 86 秒 |
| Four Nines: 99.99% | 52.6 分 | 8.6 秒 |
| Five Nines: 99.999% | 5.25 分 | 0.86 秒 |
| Six Nines: 99.9999% | 31.5 秒 | 8.6 ミリ秒 |
表が示すように、99% と 99.9% ではかなりの差があります。
時間や分ではなく、1 年の日数で測定することに注意してください。 可用性の尺度が高くなるほど、サービスのコストも高くなります。
ダウンタイムをどのように計算するのですか。 システムの一部、またはシステム全体の正常な機能に影響を与える可能性のあるすべてのコンポーネントについて、ダウンタイムを測定することが不可欠である。 定期的なシステムメンテナンスは、アベイラビリティ測定の一部でなければなりません。 このような計画的なダウンタイムは、ビジネスの停止にもつながりますので、IT 環境を構築する際には、その点にも注意を払う必要があります。
お分かりのように、100%の可用性レベルは表には現れませんが、簡単に言えば、完全にフェイルセーフなシステムは存在しないということです。 さらに、バックアップ コンポーネントへの切り替えには、ミリ秒、分、または時間など、ある程度の時間がかかります。
How to Achieve High Availability
高可用性ソリューションを実装しようとしている企業は、システムが高可用性と認められるために必要な複数のコンポーネントと要件を理解する必要があります。 ビジネスの継続性と操作性を確保するためには、重要なアプリケーションとサービスを 24 時間稼動させる必要があります。 高可用性を実現するためのベストプラクティスには、一定の条件を満たすことが必要です。 ここでは、99.999%の信頼性と稼働率を達成するための 4 つのステップを紹介します。
Eliminate Single Points of Failure High Availability vs. Redundancy
高稼働システムの重要な要素は、あらゆるレベルの冗長性を実現することによって単一障害点をなくすことです。 自然災害やハードウェア、電源の故障に関係なく、IT インフラストラクチャには、故障したシステムを置き換えるためのバックアップ コンポーネントが必要です。 その中で最も一般的なものは、
- N+1モデルには、システムを稼働させるために必要な量の機器（「N」と呼ばれる）が含まれています。 これは、障害が発生した場合に備えて、各コンポーネントに独立したバックアップコンポーネントを1つずつ搭載して運用するものです。 例としては、アプリケーションサーバーに追加の電源を使用することですが、これは他のITコンポーネントでもかまいません。 このモデルは通常、アクティブ／パッシブです。 バックアップのコンポーネントはスタンバイ状態にあり、障害が発生したときに引き継ぐために待機しています。 N+1冗長化もアクティブ／アクティブにすることができます。 この場合、プライマリコンポーネントが正常に機能しているときでも、バックアップコンポーネントが動作しています。 N+1モデルは、完全な冗長システムではないことに注意してください。 違いは、2つの同じコンポーネントの障害に耐えられるかどうかである。 2N モデルは、システムを実行するために必要な個々のコンポーネントの量が 2 倍になっています。 このモデルの利点は、単一のコンポーネントに障害が発生したのか、システム全体に障害が発生したのかを考慮する必要がないことです。 運用を完全にバックアップ・コンポーネントに移行することができます。
- 2N+1モデルは、2Nと同じレベルの可用性と冗長性を提供し、もう1つのコンポーネントを追加して保護を強化します。
究極の冗長性は、地理的冗長によって実現します。
これが自然災害やその他の完全停止のイベントに対する唯一の機構となります。 この場合、サーバーは異なる地域の複数の場所に分散されます。
サイトは別々の都市、国、あるいは大陸に配置する必要があります。 そうすれば、それらは完全に独立している。 もし、ある場所で壊滅的な障害が発生した場合、別の場所がピックアップしてビジネスを継続することができるでしょう。
この種の冗長性は非常にコストがかかる傾向があります。 最も賢明な判断は、世界中にデータ センターを持つプロバイダーのホスティング ソリューションを利用することです。
停電に次いで、ネットワーク障害はビジネス ダウンタイムの最も一般的な原因の 1 つです。 ネットワーク サービスのアップタイムを 100% にするためには、代替のネットワーク パスを用意する必要があります。
Data Backup and Recovery
Data Safety は、すべてのビジネスにとって最大の関心事の 1 つです。 高可用性システムには、健全なデータ保護と災害復旧計画が必要です。
絶対に必要なのは、適切なバックアップを取ることです。 もう 1 つの重要なことは、データがすばやく失われたり、破損したり、あるいは完全にストレージが故障した場合に回復できることです。 ビジネスで低い RTO と RPO が要求され、データを失う余裕がない場合、検討すべき最良の選択肢は、データ レプリケーションを使用することです。 ビジネスの規模、要件、および予算に応じて、多くのバックアップ プランから選択できます。
データのバックアップとレプリケーションは、IT の高可用性と密接に関連しています。 どちらも慎重に計画する必要があります。 冗長インフラでフル・バックアップを作成することは、データの回復力を確保するために不可欠であり、見落としてはならないことです」
。
