この記事では、Azure で高可用性を実現するために一連のネットワーク仮想アプライアンス (NVA) をデプロイするための最も一般的なオプションについて説明します。 NVA は通常、異なるセキュリティ レベルで分類されたネットワーク セグメント間のトラフィック フローを制御するために使用されます (たとえば、非武装地帯 (DMZ) 仮想ネットワークとパブリック インターネットの間など)。
異なるセキュリティ ゾーン間のトラフィックを検査するために NVA を使用する設計パターンは数多くあります。次にその例を示します。
- 仮想マシンからインターネットへのエグレス トラフィックを検査し、データ流出を防ぐ。
- インターネットから仮想マシンへのイングレス トラフィックを検査し、攻撃を防ぐ。
- Azure 内の仮想マシン間のトラフィックをフィルター処理して、侵害されたシステムの横移動を防ぐ。
- オンプレミスのシステムと Azure 仮想マシンが異なるセキュリティ レベルに属すると見なされる場合、それらの間のトラフィックをフィルター処理する。 (たとえば、Azure が DMZ をホストし、オンプレミスが内部アプリケーションをホストする場合など)。
NVA には、ネットワーク ファイアウォール、レイヤー 4 リバース プロキシ、IPsec VPN エンドポイント、Web アプリケーション ファイアウォール機能を使用した Web ベースのリバース プロキシ、Azure からアクセスできるインターネット ページを制限するインターネット プロキシ、レイヤー 7 ロード バランサーなど、さまざまな例があります。 これらのすべては、この記事で説明するパターンを使用して Azure の設計に挿入できます。 Azure Firewall や Azure Application Gateway など、Azure のファースト パーティ ネットワーク仮想アプライアンスでも、この記事で後ほど説明する設計を使用できます。 これらのオプションを理解することは、設計の観点からだけでなく、ネットワークの問題をトラブルシューティングする点でも重要です。
最初に答える必要がある疑問は、ネットワーク仮想アプライアンスに高可用性が必要なのはなぜかという点です。 その理由は、これらのデバイスがネットワーク セグメント間の通信を制御するものだからです。 それらのデバイスが使用できないと、ネットワーク トラフィックがフローできず、アプリケーションは動作を停止します。 スケジュールされていた停止やスケジュール外の停止により、NVA インスタンスがダウンすることがあります (Azure や他のクラウドの他の仮想マシンと同様)。 これらのインスタンスは、その NVA が、Azure でシングル インスタンス SLA を提供するように Premium マネージド ディスクで構成されている場合でもダウンします。 このため、高可用性アプリケーションには、接続性を確保できる少なくとも 2 つ目の NVA が必要になります。
前提条件: この記事は、Azure ネットワーク、Azure Load Balancers、および 仮想ネットワーク トラフィック ルーティング (UDR) に関する基本的な知識を前提としています。
ネットワーク仮想アプライアンスを Azure VNet にデプロイする最適なオプションを選択する場合、考慮すべき最も重要な側面は、NVA ベンダーによってその特定の設計が調査および検証されているかどうかです。 さらに、その NVA を Azure に統合するのに必要な NVA 構成をそのベンダーが提供している必要もあります。 NVA ベンダーが、サポートされている NVA の設計オプションとして異なる代替手段を提供している場合、次の要因が決定に影響を与える場合があります。
- 収束時間: 各設計で、失敗した NVA インスタンスからトラフィックを離すのにどれくらいの時間が必要になるか。
- トポロジのサポート: 各設計オプションでどのような NVA 構成がサポートされるか。 アクティブ/アクティブ、アクティブ/スタンバイ、n+1 冗長のスケールアウト NVA クラスターはサポートされるか。
- トラフィックの対称性: 特定の設計で、非対称ルーティングを回避するために、NVA がパケットに対してソース ネットワーク アドレス変換 (SNAT) を実行する必要があるか。 あるいは、トラフィックの対称性は他の方法によって適用されるか。
このドキュメントの以下のセクションでは、NVA をハブ アンド スポーク ネットワークに統合するために使用される最も一般的なアーキテクチャについて説明します。
Note
この記事では、ハブとスポークの設計について重点的に説明します。 Virtual WAN については説明されていません。これは、Virtual WAN の場合、NVA のデプロイ方法は、特定の NVA がその Virtual WAN ハブでサポートされているかどうかに応じてはるかに規範的だからです。 詳細については、「Virtual WAN ハブのネットワーク仮想アプライアンス」を参照してください。
HA アーキテクチャの概要
以下のアーキテクチャは、高可用性の NVA で必要なリソースと構成について説明しています。
| 解決策 | メリット | 考慮事項 |
|---|---|---|
| Azure Load Balancer | アクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA をサポート。 非常に良好な収束時間 | NVA は正常性プローブ用のポートを提供する必要あり (特にアクティブ/スタンバイ展開の場合)。 インターネットとの間のフローに、対称性のために SNAT が必要 |
| Azure Route Server | NVA は BGP をサポートする必要あり。 アクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA をサポート。 | トラフィックの対称性に SNAT が必要 |
| Gateway Load Balancer | トラフィックの対称性は SNAT なしで保証される。 NVA をテナント間で共有可。 非常に良好な収束時間。 アクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA をサポート。 | インターネットとの間のフローをサポート。東西フローはサポートなし。 |
| PIP/UDR の変更 | NVA で必要な特別な機能なし。 対称なトラフィックを保証 | アクティブ/パッシブ設計の場合のみ。 1 - 2 分の高い収束時間 |
Load Balancer 設計
この設計では、2 つの Azure Load Balancer を使用して、NVA のクラスターをネットワークの残りの部分に公開します。
- 内部の Load Balancer は、Azure とオンプレミスの内部トラフィックを NVA にリダイレクトするために使用されます。 この内部ロード バランサーは、各 TCP/UDP ポートが NVA インスタンスにリダイレクトされるように、HA ポート規則 を使用して構成されます。
- パブリックな Load Balancer は、NVA をインターネットに公開します。 HA ポートは受信トラフィック用のため、個々の TCP/UDP ポートごとに専用の負荷分散規則で開く必要があります。
次の図で、インターネットからスポーク VNet 内のアプリケーション サーバーに送信されるパケットが従うホップのシーケンスを説明します。
このアーキテクチャの Visio ファイルをダウンロードします。
NVA を経由してスポークからパブリック インターネットにトラフィックを送信するメカニズムは、0.0.0.0/0 に対するユーザー定義のルートで、次のホップが内部の Load Balancer の IP アドレスになっています。
Azure とパブリック インターネット間のトラフィックの場合、トラフィック フローの各方向は異なる Azure Load Balancer (パブリック ALB 経由のイングレス パケットと内部 ALB 経由のエグレス パケット) を通過します。 このため、トラフィックの対称性が必要な場合は、戻りトラフィックを引き付けて、トラフィックの非対象を回避するために、NVA インスタンスによって送信元ネットワーク アドレス変換 (SNAT) を実行する必要があります。
この設計は、Azure とオンプレミス ネットワーク間のトラフィックを検査する目的でも使用できます。
NVA を経由してスポーク間でトラフィックを送信するメカニズムはまったく同じなので、追加の図は提供しません。 上のサンプル図では、spoke1 は spoke2 の範囲を知らないので、0.0.0.0/0 UDR は spoke2 宛のトラフィックを NVA の内部 Azure Load Balancer に送信します。
オンプレミス ネットワークと Azure 間、または Azure 仮想マシン間のトラフィックの場合、トラフィックの対称性は内部 Azure Load Balancer によって保証されます。トラフィック フローの両方向が同じ Azure Load Balancer を通過する場合、同じ NVA インスタンスが選択されます。
個々の NVA の停止に際して、Azure Load Balancer は非常に良好な収束時間を示します。 正常性プローブ は 5 秒ごとに送信でき、バックエンド インスタンスがサービス停止状態であることを宣言するために 3 回プローブが失敗する必要があるので、Azure Load Balancer が異なる NVA インスタンスにトラフィックを収束するのに、通常は 10 から 15 秒かかります。
このセットアップでは、アクティブ/アクティブ構成とアクティブ/スタンバイ構成の両方がサポートされます。 ただし、アクティブ/スタンバイ構成の場合、NVA インスタンスは、そのインスタンスがアクティブなロールに存在しない限り、Load Balancer 正常性プローブに応答しない TCP/UDP ポートまたは HTTP エンドポイントを提供する必要があります。
L7 ロード バランサーの使用
この設計の特定のケースでは、Azure Public Load Balancer を、単独で NVA と見なせる Azure Application Gateway などのレイヤー 7 ロード バランサーで置き換えています。 この場合、NVA に必要なのはそれらの前の内部 Load Balancer だけです。これは、Application Gateway からのトラフィックは VNet 内から送信され、トラフィックの非対称性は問題とならないためです。
NVA は、使用しているレイヤー 7 ロード バランサーでサポートされていないプロトコルの受信トラフィックに加えて、すべてのエグレス トラフィックを受け取る必要があります。 Azure Firewall を NVA として使用し、Azure Application Gateway をレイヤー 7 Web リバース プロキシとして使用する場合のこの構成の詳細については、「仮想ネットワークの Azure Firewall と Application Gateway」を参照してください。
Azure Route Server
Azure Route Server は、NVA が Border Gateway Protocol (BGP) 経由で Azure SDN と対話できるようにするサービスです。 NVA は、Azure VNet 内にどの IP プレフィックスが存在するかを学習するだけでなく、Azure 内の仮想マシンの有効なルート テーブルにルートを挿入することもできます。
上の図では、各 NVA インスタンスは、BGP 経由で Azure Route Server とピアリングされています。 Azure Route Server は NVA によってアドバタイズされたルートをプログラムするため、スポーク サブネットにルート テーブルは必要ありません。 2 つ以上のルートが Azure 仮想マシンでプログラミングされている場合、等コスト マルチパス (ECMP) を使用して、各トラフィック フローに対して NVA インスタンスの 1 つが選択されます。 したがって、トラフィックの対称性が要件である場合、この設計では SNAT が必要です。
この挿入方法では、アクティブ/アクティブ (すべての NVA が Azure Route Server に同じルートをアドバタイズする) とアクティブ/スタンバイ (一方の NVA がもう一方よりも短い AS パスを持つルートをアドバタイズする) の両方をサポートします。 Azure Route Server では、最大 8 つの BGP 隣接がサポートされます。 そのため、アクティブな NVA のスケールアウト クラスターを使用する場合、この設計では最大 8 つの NVA インスタンスがサポートされます。
収束時間は、このセットアップでは非常に高速で、BGP 隣接性の keepalive タイマーと holdtime タイマーの影響を受ける可能性があります。 Azure Route Server には既定の keepalive タイマーと holdtime タイマーがあります (それぞれ 60 秒と 180 秒) が、NVA は BGP の隣接確立中に低いタイマーをネゴシエートできます。 これらのタイマーを低く設定しすぎると、BGP が不安定になる可能性があります。
この設計は、Azure VNet で構成されたプレフィックスを学習したり、ExpressRoute プライベート ピアリング経由で特定のルートをアドバタイズしたりする必要がある VPN 終端 NVA などの、Azure ルーティングと対話する必要がある NVA では最も一般的なオプションです。
Azure Gateway Load Balancer
Azure Gateway Load Balancer は、ユーザー定義のルートでトラフィックを誘導することなくデータ パスに NVA を挿入できる新しい方法です。 Azure Load Balancer またはパブリック IP アドレス経由でワークロードを公開する Virtual Machines では、受信トラフィックや送信トラフィックを、別の VNet に存在する NVA のクラスターに透過的にリダイレクトできます。 次の図で、ワークロードが Azure Load Balancer 経由でアプリケーションを公開する場合に、パブリック インターネットからの受信トラフィックに対してパケットが従うパスを説明します。
この NVA 挿入方法の主な利点の 1 つは、送信元ネットワークアドレス変換 (SNAT) でトラフィックの対称性を保証する必要がないことです。 この設計オプションのもう 1 つの利点は、同じ NVA を使用して異なる Vnet との間のトラフィックを検査できるため、NVA の観点からマルチテナント機能を実現できることです。 NVA VNet とワークロード VNet の間に VNet ピアリングは不要で、ワークロード VNet にユーザー定義ルートを指定する必要もないため、構成を大幅に簡素化できます。
Gateway Load Balancer を使用したサービス挿入は、Azure Public Load Balancer に到達する受信フロー (およびその応答トラフィック) や、Azure から送信される送信フローに使用できます。 Azure 仮想マシン間の東西トラフィックでは、NVA 挿入に Gateway Load Balancer を利用できません。
NVA クラスターでは、Azure Load Balancer の正常性チェック プローブを使用することにより、個々の NVA インスタンスの障害を検出して、非常に短時間での収束を実現できます (10 - 15 秒)。
PIP-UDR の変更
この設計の背後にある考え方は、必要となるセットアップを NVA 冗長性なしで行い、NVA がダウンタイムの影響を受ける場合にこれを変更するというものです。 次の図で、Azure パブリック IP アドレスがアクティブな NVA (NVA1) に関連付けられ、スポーク内のユーザー定義ルートがそのアクティブな NVA の IP アドレスを次のホップ (10.0.0.37) として持つ仕組みを説明します。
アクティブな NVA が使用できなくなると、スタンバイ NVA が Azure API を呼び出して、パブリック IP アドレスとスポークのユーザー定義ルートを自身に再マップします (または、プライベート IP アドレスも移動します)。 これらの API 呼び出しは有効になるのに数分かかる場合があるため、このドキュメントで説明されているすべてのオプションの中で、この設計の収束時間が最悪になります。
この設計のもう 1 つの制限は、アクティブ/スタンバイ構成のみがサポートされることです。このため、スケーラビリティの問題が生じる可能性があります。NVA でサポートされる帯域幅を増やす必要がある場合、この設計では両方のインスタンスをスケールアップするしかありません。
この設計の利点の 1 つは、どの特定の時点でもアクティブな NVA が 1 つしかないため、トラフィックの対称性を保証するためのソース ネットワーク アドレス変換 (SNAT) が必要ないことです。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Keith Mayer | プリンシパル クラウド ソリューション アーキテクト
- Telmo Sampaio | プリンシパル サービス エンジニアリング マネージャー
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- Azure Firewall を使用して、セキュリティで保護されたハイブリッド ネットワークを実装する方法を学習します。
- 境界ネットワーク - クラウド導入フレームワーク
- クラウド DMZ - クラウド導入フレームワーク