ディザスターリカバリー計画

[アーティクル]
06/01/2023

Virtual WAN を使用すると、すべてのグローバルデプロイを集約、連結して、一元的に管理し、セキュリティで保護することができます。グローバルデプロイには、さまざまなブランチ、ポイントオブプレゼンス (PoP)、プライベートユーザー、オフィス、Azure 仮想ネットワーク、およびその他のマルチクラウドデプロイの任意の組み合わせを含めることができます。 SD-WAN、サイト間 VPN、ポイント対サイト VPN、ExpressRoute を使用して、さまざまなサイトを仮想ハブに接続できます。複数の仮想ハブがある場合、Virtual WAN の標準のデプロイですべてのハブがフルメッシュで接続されます。

この記事では、ディザスターリカバリー用に Virtual WAN でサポートされるさまざまな種類のサービスとしてのネットワーク接続オプションを設計する方法について説明します。

Virtual WAN のサービスとしてのネットワーク接続オプション

Virtual WAN では、次のバックエンド接続オプションがサポートされています。

リモートユーザーの接続
ブランチ、オフィス、SD-WAN、サイト間 VPN
プライベート接続 (ExpressRoute プライベートピアリング)

これらの接続オプションごとに、Virtual WAN は仮想ハブ内に個別のゲートウェイインスタンスのセットをデプロイします。

もともと、Virtual WAN は通信業者レベルの高可用性ネットワーク集約ソリューションを提供するように設計されています。高可用性を実現するために、異なる種類の複数のゲートウェイが 1 つの Virtual WAN ハブにデプロイされている場合、Virtual WAN は複数のインスタンスをインスタンス化します。 ExpressRoute の高可用性の詳細については、「ExpressRoute を使用した高可用性のための設計」を参照してください。

ポイント対サイト VPN ゲートウェイでは、デプロイされるインスタンスの最小数は 2 です。ポイント対サイト VPN ゲートウェイでは、ポイント対サイトゲートウェイの合計スループット容量を選択すると、複数のインスタンスが自動的にプロビジョニングされます。仮想ハブに接続するクライアントまたはユーザーの数に応じて合計容量を選択します。クライアント接続の観点から見ると、ポイント対サイト VPN ゲートウェイインスタンスは、ゲートウェイの完全修飾ドメイン名 (FQDN) の陰に隠れています。

サイト間 VPN ゲートウェイでは、ゲートウェイの 2 つのインスタンスが 1 つの仮想ハブ内にデプロイされます。各ゲートウェイインスタンスは、独自のパブリック IP アドレスとプライベート IP アドレスのセットをと共にデプロイされます。次の画面キャプチャは、サンプルのサイト間 VPN ゲートウェイ構成の 2 つのインスタンスに関連付けられた IP アドレスを示しています。言い換えると、この 2 つのインスタンスは、ブランチからサイト間 VPN 接続を確立するために、2 つの独立したトンネルエンドポイントを提供します。高可用性を最大化するには、「複数の ISP リンクにわたる Azure パスの選択」を参照してください。

サイト間 VPN ゲートウェイ構成の例を示すスクリーンショット。

ネットワークアーキテクチャの高可用性を最大にすることは、ビジネス継続性とディザスターリカバリー (BCDR) のための重要な第一歩です。この記事の残りの部分では、既に説明したように、高可用性という枠を超えて、BCDR のために Virtual WAN 接続ネットワークを設計する方法について説明します。

ディザスターリカバリー計画の必要性

障害はいつどこで発生してもおかしくはありません。障害は、クラウドプロバイダーのリージョンまたはネットワーク内で、サービスプロバイダーのネットワーク内で、あるいはオンプレミスのネットワーク内で発生する可能性があります。自然災害、人為的エラー、戦争、テロ行為、不適切な構成などの特定の要因を原因とするクラウドまたはネットワークサービスの地域的影響は、排除するのが困難です。ビジネスに不可欠なアプリケーションの継続性を確保するには、ディザスターリカバリーの設計が必要です。包括的なディザスターリカバリー設計では、エンドツーエンドの通信パスで失敗する可能性があるすべての依存関係を特定し、それぞれの依存関係に対して重複しない冗長性を作り出す必要があります。

ミッションクリティカルなアプリケーションを Azure リージョン、オンプレミス、あるいはそれ以外のどこで実行しているかに関係なく、フェールオーバーサイトとして別の Azure リージョンを使用することができます。次の記事では、アプリケーションおよびフロントエンドのアクセスの観点から、ディザスターリカバリーに対処します。

冗長接続を使用する場合の課題

複数の接続を使用して同じ一連のネットワークを相互接続する場合、ネットワーク間の並列パスを導入することになります。並列パスが正しく設計されていない場合、非対称ルーティングになる可能性があります。パスにステートフルエンティティ (NAT やファイアウォールなど) がある場合、非対称ルーティングによってトラフィックフローがブロックされる可能性があります。一般に、プライベート接続では、NAT やファイアウォールなどのステートフルエンティティを使用することはありません。そのため、プライベート接続を介した非対称ルーティングでは、トラフィックフローをブロックする必要はありません。

ただし、geo 冗長の並列パス間でトラフィックを負荷分散する場合は、並列接続の物理パスが異なるため、ネットワークパフォーマンスが一貫性のないものになります。そのため、安定した状態 (エラー以外の状態) でのネットワークトラフィックのパフォーマンスと、ディザスターリカバリー設計の一環としてのエラー状態の両方を考慮する必要があります。

ネットワークの冗長性を利用する

ほとんどの SD-WAN サービス (マネージドソリューションまたはそれ以外) では、複数のトランスポートの種類 (インターネットブロードバンド、MPLS、LTE など) を使用してネットワーク接続を提供します。トランスポートネットワークの障害から保護するには、複数のトランスポートネットワークを経由した接続を選びます。ホームユーザーのシナリオでは、ブロードバンドネットワーク接続のバックアップとしてモバイルネットワークの使用を検討できます。

異なるトランスポートの種類でのネットワーク接続ができない場合は、複数のサービスプロバイダーを介したネットワーク接続を選びます。複数のサービスプロバイダーを介して接続している場合は、そのサービスプロバイダーが、重複しない独立したアクセスのネットワークを維持していることを確認してください。

リモートユーザーの接続に関する考慮事項

リモートユーザーの接続は、エンドデバイスとネットワークの間でポイント対サイト VPN を使用して確立されます。ネットワーク障害が発生すると、エンドデバイスが削除され、VPN トンネルの再確立が試行されます。そのため、ポイント対サイト VPN では、障害発生後の復旧時間を最小限に抑えることを目標として、ディザスターリカバリーの設計を行う必要があります。次のネットワークの冗長性により、復旧時間を最小限に抑えることができます。接続の重要度に応じて、これらのオプションの一部またはすべてを選ぶことができます。

ネットワークの冗長性を利用する (前述)。
ポイント対サイト VPN の終端の冗長仮想ハブを管理する。ポイント対サイトゲートウェイを持つ複数の仮想ハブがある場合、VWAN は、すべてのポイント対サイトエンドポイントを一覧表示するグローバルプロファイルを提供します。このグローバルプロファイルを使用すると、エンドデバイスは、最適なネットワークパフォーマンスを提供する、最も近い利用可能な仮想ハブに接続できます。すべての Azure デプロイが 1 つのリージョン内にあり、接続するエンドデバイスがリージョンに近接している場合は、リージョン内に冗長仮想ハブを配置できます。デプロイとエンドデバイスが複数のリージョンに分散している場合は、選択したリージョンごとにポイント対サイトゲートウェイを持つ仮想ハブをデプロイできます。 Virtual WAN には、リモートユーザーの接続に最適なハブを自動的に選択する組み込みのトラフィックマネージャーがあります。

次の図は、1 つのリージョン内で個別のポイント対サイトゲートウェイを持つ冗長仮想ハブを管理する場合の概念を示しています。

マルチハブポイント対サイト集計の図。

上の図では、緑色の線がポイント対サイト VPN 接続を示しています。黄色の点線は、スタンバイのバックアップ接続を示しています。 VWAN ポイント対サイトグローバルプロファイルは、ネットワークのパフォーマンスに基づいて、プライマリとバックアップの接続を選択します。グローバルプロファイルの詳細については、ユーザー VPN クライアントのグローバルプロファイルのダウンロードに関するページを参照してください。

サイト間 VPN に関する考慮事項

ここでは、次の図に示すサイト間 VPN 接続の例を考えてみましょう。高可用性のアクティブ/アクティブトンネルを使用してサイト間 VPN 接続を確立する方法については、「チュートリアル: Azure Virtual WAN を使用してサイト間接続を作成する」を参照してください。

サイト間 VPN を使用した、仮想 WAN へのオンプレミスブランチの接続の図。

注意

このセクションで説明する概念を理解しやすくするために、サイト間 VPN ゲートウェイの高可用性機能について繰り返し説明しませんが、これを使用すると、構成する VPN リンクごとに 2 つの異なるエンドポイントに対して 2 つのトンネルを作成できます。ただし、このセクションで推奨されるアーキテクチャのいずれかをデプロイするときは、確立するリンクごとに 2 つのトンネルを構成することを忘れないでください。

マルチリンクトポロジ

ブランチサイトでの VPN Customer Premises Equipment (CPE) の障害から保護するために、ブランチサイトで並列の CPE デバイスから VPN ゲートウェイへの並列 VPN リンクを構成できます。さらに、ブランチオフィスへの最後のサービスプロバイダーのネットワーク障害から保護するために、別のサービスプロバイダーネットワーク上に異なる複数の VPN リンクを構成できます。次の図は、同じ VPN ゲートウェイで終わるブランチサイトの 2つの異なる CPE から送信される複数の VPN リンクを示しています。

ブランチサイトへの冗長なサイト間 VPN 接続の図。

仮想ハブ VPN ゲートウェイからブランチサイトへのリンクは最大 4 つまで構成できます。ブランチサイトへのリンクを構成するときに、サービスプロバイダーと、そのリンクに関連付けられているスループット速度を特定できます。ブランチサイトと仮想ハブの間に並列リンクを構成すると、既定で VPN ゲートウェイによって、並列リンク間でトラフィックが負荷分散されます。トラフィックの負荷分散は、フローごとに等コストマルチパス (ECMP) に従って行われます。

マルチハブマルチリンクのトポロジ

マルチリンクトポロジは、オンプレミスのブランチの場所での CPE デバイスの障害とサービスプロバイダーのネットワーク障害を防止するものです。また、仮想ハブ VPN ゲートウェイのダウンタイムを防止するために、マルチハブマルチリンクのトポロジが役立ちます。次の図は、リージョン内の Virtual WAN インスタンスで複数の仮想ハブが構成されているトポロジを示しています。

ブランチサイトへのマルチハブサイト間 VPN 接続の図。

上記のトポロジでは、ハブ間接続での Azure リージョン内の待機時間は重要ではないため、オンプレミスとアクティブ/アクティブ状態の 2 つの仮想ハブの間で、すべてのサイト間 VPN 接続を使用できます。そのためには、ハブ間でスポーク VNet を分散します。このトポロジでは、既定でオンプレミスとスポーク VNET 間のトラフィックは、安定した状態の間はスポーク VNET が接続されている仮想ハブを直接通過し、障害状態のときにのみバックアップとして別の仮想ハブを使用します。直接接続されたハブによってアドバタイズされた BGP ルートはバックアップハブと比べて AS パスが短くなるため、安定した状態の間は、トラフィックは直接接続されたハブを通過します。

マルチハブマルチリンクのトポロジは、ほとんどの障害シナリオに対してビジネス継続性を守り、実現します。ただし、重大な障害によって Azure リージョン全体がダウンした場合に備えて障害に対処するには、"マルチリージョンマルチリンクのトポロジ" が必要です。

マルチリージョンマルチリンクのトポロジ

マルチリージョンマルチリンクのトポロジでは、前に説明したマルチハブマルチリンクのトポロジによって提供される保護に加えて、リージョン全体の致命的な障害からも保護されます。次の図は、マルチリージョンマルチリンクのトポロジを示しています。異なるリージョン内の仮想ハブは、同じ Virtual WAN インスタンスで構成できます。

ブランチサイトへの複数リージョンのサイト間 VPN 接続の図。

トラフィックエンジニアリングの観点からは、リージョン内に冗長なハブがある場合と、バックアップハブを別のリージョンに配置する場合の大きな違いを考慮する必要があります。違いは、プライマリリージョンとセカンダリリージョンの間の物理的な距離に起因する待ち時間です。そのため、実際のブランチ/エンドユーザーに最も近いリージョンに安定した状態のサービスリソースをデプロイし、リモートリージョンはバックアップ専用に使用することをお勧めします。

オンプレミスのブランチの場所が複数の Azure リージョンに分散している場合、負荷を分散し、安定した状態でのネットワークエクスペリエンスを向上させるために、マルチリージョンマルチリンクのトポロジがより効果的です。次の図は、複数のリージョンに複数のブランチがある場合のマルチリージョンマルチリンクのトポロジを示しています。このようなシナリオでは、このトポロジはさらに効果的なビジネス継続性ディザスターリカバリー (BCDR) を提供します。

マルチブランチサイトへの複数リージョンのサイト間 VPN 接続の図。

ExpressRoute に関する考慮事項

ExpressRoute プライベートピアリングのディザスターリカバリーの考慮事項については、「ExpressRoute プライベートピアリングを使用したディザスターリカバリーの設計」で説明しています。その記事で説明しているように、その記事に記載した概念は、仮想ハブ内に作成された ExpressRoute ゲートウェイにも同様に適用されます。次の図に示すように、リージョン内で冗長な仮想ハブを使用することは、中小企業のオンプレミスネットワークに関する考慮事項として推奨される唯一のトポロジ拡張です。

マルチハブ Expresss Route 接続の図。

上の図では、ExpressRoute 2 は、リージョン内の 2 つ目の仮想ハブにある別の ExpressRoute ゲートウェイで終わります。

次のステップ

この記事では、Virtual WAN のディザスターリカバリーの設計について説明しました。次の記事では、アプリケーションおよびフロントエンドのアクセスの観点から、ディザスターリカバリーに対処します。