高可用性 (HA) とは

高可用性 (HA) とは、 IT システムにほぼ常時アクセスできるようにし、ダウンタイムをゼロまたは最小限に抑える機能です。2 つの概念を組み合わせて、IT システムがその運用パフォーマンスレベルを満たしているかどうかを判別します。その概念とは、特定のサービスまたはサーバーがほぼ 100% の時間、ダウンタイムなしでアクセス可能 (または使用可能) であること、そして、そのサービスまたはサーバーが定められた期間において合理的な予測どおりに機能することです。高可用性とは、アップタイムのサービスレベル契約 (SLA) や、サービスプロバイダーと顧客の間で設定される期待値を達成できるだけでなく、真に回復力があり、信頼性が高く、適切に機能するシステムであることを示すものです。

オンラインサービスとハイブリッドワークロードの導入に伴い、運用基準を維持しながら増加するシステム負荷を処理するインフラストラクチャに対する需要が高まっています。高可用性 (HA) システムと呼ばれることの多いこれらのインフラストラクチャが高可用性を実現するためには、単に「より適切に動作する」だけでなく、数値で定義される結果を達成する必要があります。

高可用性ソリューション (高可用性サービス) の目標の 1 つがファイブナインの可用性というもので、システムが 99.999% の時間、正常に実行されることを意味します。通常、医療、政府、金融サービスなどのミッションクリティカルなシステムだけが、コンプライアンスや競争上の理由から、このレベルの可用性を必要とします。しかし、多くの組織や業界では、顧客に絶えずデジタルアクセスを提供するため、あるいは、従業員が自宅で仕事ができるようにするために、99.9% または 99.99% のアップタイムを維持する高可用性システムが必要とされています。

高可用性インフラストラクチャでは、システムのダウンタイムの増加につながり組織のパフォーマンス目標の達成を妨げる可能性がある単一障害点の検出と排除が重要です。単一障害点は、それが機能を失うとシステム全体がオフラインになってしまう可能性があるインフラストラクチャ要素で、複雑なシステムでは複数の単一障害点が存在する場合があります。

また、先進的で複雑な IT インフラストラクチャで発生するさまざまな種類の障害についても考慮する必要があります。そうした障害には、ハードウェア障害、ソフトウェア障害 (オペレーティングシステムと実行中のアプリケーションの両方)、サービス障害 (アクセスできないネットワーク、レイテンシー、クラウドサービスまたはパフォーマンスの低下など)、停電などの外部障害が含まれます。

各組織が高可用性に向けて実行できる最初のステップは、コアサービス、ワークロード、規制またはコンプライアンス要件、パフォーマンス・ベンチマーク、重要なアプリケーション、運用上の優先事項に基づいて、組織にとって最も重要な成果を特定することです。

• 規制コンプライアンスまたはユーザーエクスペリエンスのアップタイム要件は何ですか？
• 環境はどの程度分散されていますか？主な障害点は何ですか？
• アプリケーションに必要なパフォーマンスはどのようなものですか？そのアプリケーションのパフォーマンスに対するリスクはどのようなものですか？(ユーザートラフィックの増加や書き込み負荷の増加など)
• どのようなストレージが使用されていますか？
• データ損失またはデータアクセスに関してどのような要件がありますか？
• 現在の IT リソースを前提として、停止した場合に達成可能な SLA は何ですか？現在計画されている保守スケジュールと、アップタイムへの影響はどのようなものですか？
• さまざまな障害復旧シナリオや事業運営の変更に関する計画はありますか？

高可用性環境では、高可用性アーキテクチャが目標を達成しているかどうかを判別するために IT チームが使用する一般的な指標もあります。使用中のアーキテクチャとの関連性が他よりも高い指標もありますが、それらすべてを評価して、基準となるパフォーマンスの期待値を設定することは価値があります。

• 平均障害間隔 (MTBF)：システム障害が一度発生してから次に発生するまでの環境の稼働時間。
• 平均ダウンタイム：トポロジー内でシステムが復旧する、または置き換えられるまでのシステムの停止時間 (ダウンタイムの分数)。
• 目標復旧時間 (RTO)：修復を完了してシステムをオンラインに戻すまでの合計時間。
• 目標復旧時点 (RPO)：データを復旧できる必要がある期間。この時点までのデータが失われます。たとえば、あるシステムがバックアップから別のシステムを取り込むようになっており、バックアップが 1 日ごとに作成される場合、復旧したシステムでは最大 24 時間分のデータが失われている可能性があります。しかし、複製または共有ストレージがある場合、データ損失は数分またはそれ以下になる可能性があります。

高可用性アーキテクチャには、監視や自動化など、継続性計画の各層の原則が組み込まれています。これにより、特定のローカル障害から全体的な停止まで、あらゆる種類の障害に対してシステム全体が回復力を持つことができます。計画的な保守時間枠やその他のサービスの中断があっても、システム全体の運用を維持できます。

障害復旧または継続計画には、潜在的な障害に対する次のようなアプローチが組み込まれます。

• 特定の障害を予測する：IT アーキテクトは、まず各領域についてシステムが冗長であること、障害発生時に利用できるバックアップシステムがあることを確認します。次のステップは、停止したシステムが自動的に検出され、サービスがバックアップシステムに切り替えられるように、フェイルオーバーおよび障害検出のプロセスを自動化することです。
• パフォーマンスをプロアクティブに管理する：フォールトトレランスは機能停止への対策となりますが、パフォーマンスの低下には必ずしも対処できません。ここで、負荷分散とスケーラビリティが有用なツールになります。この場合、IT アーキテクトは、システムのパフォーマンスを監視し、複数のシステムを使用してユーザーの要求と操作を管理します。ロードバランサーとトラフィック管理は、帯域幅とシステムパフォーマンス、ユーザーの種類、または要求の種類に基づいて、トラフィックをインテリジェントにリアルタイムでルーティングできます。
• 大惨事に対処する：クラウドプロバイダーの停止やデータセンターサイトでの自然災害など、広範囲にわたるインフラストラクチャ障害はまれですが、ハードウェア/ソフトウェア障害のみの場合よりも包括的なアプローチが必要です。インフラストラクチャをオンラインに戻すとともに、最新のデータを利用できるようにする必要があります。これは、レプリケーション (パフォーマンスリスクがある) で同期的に、またはデータバックアップ (データ損失のリスクがある) で非同期的に実行できます。

高可用性アーキテクチャはアクティブなフェイルオーバークラスタを実行するため、冗長性とフェイルオーバー、そして理想的にはゼロダウンタイムが組み込まれています。クラスタ内では、ノードは可用性だけでなく、アプリケーション、サービス、ネットワークの全体的なパフォーマンスも監視されます。共有ストレージがあり、すべてのクラスタノードが同じデータソースから動作しているため、ノードが停止してもデータが失われることはありません。負荷分散を使用してトラフィックを管理し、最高のパフォーマンスを実現できます。

これらの広範な特性以外に、高可用性クラスタは、IT インフラストラクチャ内の優先順位とアクティビティに応じて、より専門的なアクティビティ用に設計できます。たとえば、Red Hat Enterprise Linux High Availability Add-On には 4 つのデフォルト構成があります。

• 高可用性：アップタイムと可用性を重視
• 高パフォーマンス：高速での同時並行操作を実現 
• 負荷分散：費用対効果の高いスケーラビリティを実現
• ストレージ：回復力のあるデータ管理を実現

実際の環境では、高可用性システムには、これらの重要な要素の側面が組み込まれます。

高可用性はインフラストラクチャ全体に及び、サービスとアプリケーションが実行される異なる環境 (クラウド環境と物理環境の両方) とさまざまな場所でデータとストレージを管理します。そのため、共通のプラットフォームと標準のオペレーティング環境は非常に強力です。これにより、デプロイメント環境に関係なく一貫性が生まれます。

Red Hat Enterprise Linux には、アドオンパッケージを通じて搭載できる追加の機能とサービスがあります。Red Hat Enterprise Linux High Availability Add-On は、トポロジーのネットワーキング、クラスタリング、およびストレージの側面に対応します。

高可用性はデータ管理と密接に関連しているため、Microsoft SQL Server および SAP 向けの Red Hat Enterprise Linux デプロイメントにも、Red Hat Enterprise Linux High Availability Add-On が含まれています。