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

  • [アーティクル]

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

Virtual WAN へのポイント対サイト接続を作成するには、「チュートリアル: Azure Virtual WAN を使用してユーザー VPN 接続を作成する」を参照してください。 Virtual WAN へのサイト間接続を作成するには、「チュートリアル: Azure Virtual WAN を使用してサイト間接続を作成する」を参照してください。 ExpressRoute 回線を Virtual WAN に関連付けるには、「チュートリアル: Azure Virtual WAN を使用して ExpressRoute の関連付けを作成する」を参照してください。