冗長化とは

今日の企業は、かつてないほどネットワークに依存しています。モバイルブロードバンド、マルチクラウド、ハイブリッドクラウド、仮想化、リモートワーク、BYOD（Bring Your Own Device）などのトレンドにより、信頼できる接続性さえあれば、従業員はほぼどこからでも生産性を発揮できます。そのため、ERP、コミュニケーション・コラボレーション・システム、仮想デスクトップ・インフラ（VDI）などのミッションクリティカルなアプリケーションの高可用性を確保することは、IT部門にとって大きなプレッシャーとなっています。

最も堅牢で信頼性の高いソフトウェアやシステムであっても、障害が発生する可能性はあります。中断やダウンタイムを回避するために、IT 部門は冗長性とフォールトトレランスを利用した高可用性アーキテクチャを導入し、継続的な運用と迅速な災害復旧を可能にする必要があります。これは、アプリケーションの高可用性から、環境内のデータセンター内およびデータセンター間のネットワークトラフィックを管理するロードバランサーやアプリケーション配信コントローラー（ADC）の高可用性まで、データセンターのあらゆる要素に当てはまります。

ロードバランサーやアプリケーション配信コントローラーにおける冗長化の重要性

高可用性は、サービスの中断を引き起こす可能性のあるインフラストラクチャ内の単一障害点を特定し排除することから始まります。たとえば、デバイスの 1 つに障害が発生した場合に冗長コンポーネントを展開するフォールトトレランスを提供します。ロードバランサーは、スタンドアロンデバイスとして、あるいは ADC の機能として、どのように提供されるかによらず、サーバーのヘルスチェック、潜在的な障害の検出、必要に応じてトラフィックのリダイレクトを行うことにより、中断されないサービスへのプロセスを容易にします。

サーバーの耐障害性を確保することは当然ながら重要ですが、高可用性アーキテクチャはロードバランサーのレイヤー自体も考慮に入れなければなりません。このレイヤーが効果的に機能を果たせなくなると、このレイヤー下のサーバーがオーバーフローを起こし、自身の稼働状態だけでなく、アプリケーションのパフォーマンスやアプリケーションの可用性も損なわれる可能性があります。このため、ロードバランサーやADCの冗長化は、データセンターの他のコンポーネントと同様に重要です。

高可用性サーバークラスタと同様に、高可用性を実現するためにロードバランサーやADCを導入する方法には、次のようなものがあります：

• アクティブスタンバイ - 最も一般的な構成であるアクティブスタンバイモデルには、プライマリノードに障害が発生した場合にのみオンラインになる、各ADCの完全な冗長インスタンスが含まれます。各アクティブADCは異なる構成にすることができますが、各アクティブ／スタンバイのペアは同じ構成を共有します。
• アクティブ-アクティブ - このモデルでは、同様に構成された複数のADCが日常的に使用されるように配置されます。1つのノードに障害が発生した場合、そのトラフィックは残りの1つまたは複数のノードによって引き継がれ、必要に応じて負荷が分散され、一貫したサービスが保証されます。このアプローチでは、1つのADCが利用できない場合でも、クラスタ全体で十分な容量が利用可能であることが前提となっています。
• N+1 - アクティブスタンバイよりも低コストで冗長性を確保できるN+1構成には、プライマリADCのいずれかに障害が発生した場合にオンライン化できる1つ以上の予備ADCが含まれています。

いずれの場合も、迅速なフェイルオーバーにより、アプリケーションのパフォーマンスやアプリケーションの可用性に影響が出ないよう、ロードバランサー機能の耐障害性と災害復旧を実現します。フェイルオーバーとトラフィック管理は、通常、Virtual Router Redundancy Protocol冗長化規格のバージョンによって管理されます。

ロードバランサーやADCの高可用性のための主な機能

ADCの高可用性を確保するだけでなく、ADCがトラフィックを管理するアプリケーションの高可用性を確保することも必要です。サーバーに障害が発生した場合、ADCはトラフィックをクラスタ内の別の利用可能なサーバーに迂回させることができます。この機能を実現する主な機能は次のとおりです。

• ロードバランシングの様々な方法 - サーバーの選択には、ラウンドロビン、最小接続数、加重ラウンドロビン、加重最小接続数、最速応答など、いくつかの方法が使用できます。ADCは、これらのオプションをすべて提供し、お客様の環境と優先順位に最も適した構成を可能にする必要があります。
• ヘルスモニタリング - ダウンタイムをほとんど、またはまったく発生させずに迅速なフェイルオーバーを実現するために、以下のような多くの指標に基づいて、サーバーの健全性を継続的に評価する必要があります：
  • 各サーバーの総受信バイト数と総送信バイト数の時系列データ
  • 各サーバーからのトラフィックレートの時系列(Mbps単位)表示
  • 範囲を超えるエラートラフィックの割合
  • 有効な SSL 接続の数
  • サービスごとのアプリケーション・サーバーの平均レイテンシー
  • クライアント側のレイテンシー SRTT、最大、最小、および時系列での平均値
  • 特定の SQL データベースクエリのレスポンスタイムの測定などのカスタムヘルスチェック