次の方法で共有

ExpressRoute プライベート ピアリングを使用したディザスター リカバリーの設計

  • [アーティクル]

ExpressRoute は、Microsoft リソースへのキャリア グレード プライベート ネットワーク接続を提供する高可用性のために設計されています。 つまり、Microsoft ネットワーク内の ExpressRoute パスには単一障害点はありません。 ExpressRoute 回線の可用性を最大限に高めるための設計に関する考慮事項については、「ExpressRoute を使用した高可用性のための設計」、および Well-Architectured フレームワークに関する記事を参照してください

しかし、マーフィーのよく知られている格言 -- 何事であれ失敗する可能性のあるものは、いずれ失敗する -- を考慮し、この記事では、単一の ExpressRoute 回線を使用して対処できるエラーに留まらず、ソリューションに注目しましょう。 geo 冗長 ExpressRoute 回線を使用した、ディザスター リカバリー用の堅牢なバックエンド ネットワーク接続を構築するためのネットワーク アーキテクチャに関する考慮事項を確認していきます。

Note

この記事で説明する概念は、Virtual WAN で、またはその外部で ExpressRoute 回線を作成する場合にも同様に適用されます。

冗長接続ソリューションの必要性

ExpressRoute ピアリングのロケーションやリージョンのサービス全体がデグレードする可能性やインスタンスがあります。 このようなリージョン全体のサービスの停止の根本原因には、自然災害が含まれます。 したがって、ビジネス継続性とミッション クリティカルなアプリケーションのためには、ディザスター リカバリーの計画を行うことが重要です。

Note

自然災害時にビジネス継続性を維持するためなど、時間的制約のある状況でディザスター リカバリー設計を実装する必要がある場合は、以下の要因を考慮する必要があります。

  • このドキュメントでは、異なるピアリングの場所を通して構成されている複数の ExpressRoute 回線に堅牢なディザスター リカバリー設計を実装する方法についてのガイダンスを提供します。 このシナリオでは、ExpressRoute 回線を設定するのに十分な時間とリソースがあることを前提とします。
  • geo 冗長ではない単一の ExpressRoute 回線のディザスター リカバリー設計をすばやく構成する必要がある場合は、以下の代替手段を使用できます。
    • プライベート ピアリング トラフィックのバックアップとしてサイト間 VPN を使用します。
    • Microsoft ピアリング トラフィックのバックアップとしてインターネット接続を使用します。

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

オンプレミス ネットワークと Microsoft の間の ExpressRoute 接続に依存している場合、ExpressRoute を介したディザスター リカバリーを計画するには、次のことを考慮する必要があります。

複数の ExpressRoute 回線の使用に関する課題

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

ただし、geo 冗長並列パス間のトラフィックの負荷を分散する場合、ステートフル エンティティがあるかどうかに関係なく、ネットワーク パフォーマンスは一貫性のないものになります。 これらの geo 冗長並列パスは、[場所別のプロバイダー] ページにある同じ都市または異なる都市を通過させることができます。

同じメトロ内の ExpressRoute 回線での冗長性

多くの都市には、ExpressRoute の場所が 2 つあります。 たとえば、Amsterdam と Amsterdam2 などです。 冗長性を設計する場合、同じ都市内の両方の場所を使用して Azure への 2 つの並列パスを構築できます。 このタスクを同じプロバイダーと実行するか、回復性を向上させるために別のサービス プロバイダーと連携することを選択します。 この設計の別の利点としては、アプリケーションのフェールオーバーが発生したとき、オンプレミスのアプリケーションと Microsoft の間でのエンドツーエンドの待機時間が常にほぼ同じであるという点があります。 ただし、地震などの自然災害が発生した場合、両方のパスの接続が使用できなくなる可能性があります。

さまざまなメトロ内の ExpressRoute 回線での冗長性

冗長性のために異なる都市を使用する場合は、同じ地政学的リージョン内で 2 番目の場所を選択する必要があります。 地理的リージョンの外部のロケーションを選択するには、並列パスの両方の回線に対して Premium SKU を使用する必要があります。 この構成の利点は、自然災害によって両方のリンクが停止する可能性が低くなる点です。ただし、エンドツーエンドの待機時間が増えるというコストがあります。

注意

ExpressRoute 回線で BFD を有効にすると、Microsoft Enterprise Edge (MSEE) デバイスと顧客やパートナーの Edge ルーターの間のリンク障害検出を高速化しやすくなります。 ただし、一部の障害状態では、冗長サイトへの全体的なフェールオーバーと収束に最大 180 秒かかる場合があり、この期間中に待機時間やパフォーマンスの低下が増加する可能性があります。

この記事では、geo 冗長パスを構成するときに直面する可能性のある課題に対処する方法について説明します。

中小企業のオンプレミス ネットワークに関する考慮事項

次の図に示されているネットワークの例を考えてみましょう。 この例では、Contoso のオンプレミスの場所と Azure リージョンの Contoso の VNet 間に、geo 冗長 ExpressRoute 接続が確立されています。 図では、青色の実線が優先されるパス (ExpressRoute 1 経由) を示し、点線がスタンバイ パス (ExpressRoute 2 経由) を表しています。

中小規模のオンプレミス ネットワークに関する考慮事項の図。

既定では、すべての ExpressRoute パスでルートを同じようにアドバタイズする場合、Azure は、等コスト マルチパス (ECMP) ルーティングを使用して、すべての ExpressRoute パス間でオンプレミス バインド トラフィックの負荷を分散します。

しかし、geo 冗長 ExpressRoute 回線では、ネットワーク パスが異なる別のネットワークのパフォーマンスを考慮する必要があります (特にネットワーク待機時間について)。 通常の操作時により一貫したネットワークパフォーマンスを得るには、最小限の待機時間を提供する ExpressRoute 回線を優先する必要がある場合があります。

以下のいずれかの手法を使用して、別の回線より ExpressRoute 回線を優先するように Azure に影響を与えることができます。

  • 他の ExpressRoute 回線と比較し、優先される ExpressRoute 回線経由でより具体的なルートをアドバタイズする
  • 優先される ExpressRoute 回線に仮想ネットワークをリンクする接続に対して、より高い接続の重みを構成する
  • AS パスがより長い (AS パスを前に付加) 優先順位の低い ExpressRoute 回線経由でルートをアドバタイズする

より具体的なルート

次の図は、より具体的なルートのアドバタイズを使用して、ExpressRoute パスの選択に影響を与える様子を示したものです。 図の例では、Contoso のオンプレミスの /24 IP 範囲が、優先されるパス (ExpressRoute 1) 経由では 2 つの /25 アドレス範囲として、スタンバイ パス (ExpressRoute 2) 経由では /24 としてアドバタイズされています。

より具体的なルートを使用してパスの選択に影響を与える様子を示した図。

/24 と比べ、/25 はより具体的であるため、Azure では通常の状態で ExpressRoute 1 経由で 10.1.11.0/24 宛てのトラフィックを送信します。 ExpressRoute 1 の両方の接続がダウンした場合、VNet では ExpressRoute 2 経由のみの 10.1.11.0/24 ルートのアドバタイズが認識されるため、このエラー状態ではスタンバイ回線が使用されます。

接続の重み

次のスクリーンショットは、Azure portal 経由の ExpressRoute 接続の重みの構成を示しています。

Azure portal を使用して接続の重みを構成する画面のスクリーンショット。

次の図は、接続の重みを使用して ExpressRoute パスの選択に影響を与える様子を示したものです。 既定の接続の重みは 0 です。 以下の例では、ExpressRoute 1 の接続の重みが 100 として構成されています。 VNet が複数の ExpressRoute 回線経由でアドバタイズされたルート プレフィックスを受信した場合、その VNet は重みが最も高い接続を優先します。

接続の重みを使用してパスの選択に影響を与えるようすを示した図。

ExpressRoute 1 の両方の接続がダウンした場合、VNet では ExpressRoute 2 経由のみの 10.1.11.0/24 ルートのアドバタイズが認識されるため、このエラー状態ではスタンバイ回線が使用されます。

AS パスを前に付加

次の図は、AS パスを前に付加を使用して ExpressRoute パスの選択に影響を与える様子を示したものです。 図では、ExpressRoute 1 経由でのルートのアドバタイズが eBGP の既定の動作を示しています。 ExpressRoute 2 経由でのルートのアドバタイズでは、ルートの AS パスにさらにオンプレミス ネットワークの ASN が付加されます。 同じルートが複数の ExpressRoute 回線経由で受信されている場合、eBGP ルートの選択プロセスごとに、VNet では AS パスが最も短いルートが優先されます。

AS パスを前に付加を使用してパスの選択に影響を与えるようすを示した図。

ExpressRoute 1 の両方の接続がダウンした場合、VNet では ExpressRoute 2 経由のみの 10.1.11.0/24 ルートのアドバタイズが認識されます。 その結果、より長い AS パスの関連性が失われます。 そのため、スタンバイ回線がこのエラー状態で使用されます。

いずれかの手法を使用して、他のものより Azure ExpressRoute のものを優先するように Azure に影響を与える場合は、オンプレミス ネットワークでも、非対称フローを回避するために Azure でバインドされたトラフィックに対して同じ ExpressRoute パスを優先することを確認する必要もあります。 通常、他のものより ExpressRoute 回線を優先するようにオンプレミス ネットワークに影響を与える場合は、ローカルの基本設定値が使用されます。 ローカルの基本設定は内部の BGP (iBGP) メトリックです。 ローカルの基本設定値が最も高い BGP ルートが優先されます。

重要

スタンバイとして特定の ExpressRoute 回線を使用する場合は、それらを積極的に管理し、定期的にフェールオーバー操作をテストする必要があります。

大規模な分散エンタープライズ ネットワーク

大規模な分散エンタープライズ ネットワークがある場合は、複数の ExpressRoute 回線が存在する可能性があります。 このセクションでは、別のスタンバイ回線を必要とすることなく、アクティブ/アクティブ ExpressRoute 回線を使用してディザスター リカバリーを設計する方法について説明します。

以下の図に示されている例を考えてみましょう。 例では、Contoso に、2 つの異なるピアリングの場所にある ExpressRoute 回線経由で、2 つの異なる Azure リージョンにある 2 つの Contoso IaaS デプロイに接続されているオンプレミスの場所が 2 つあります。

大規模な分散オンプレミス ネットワークの考慮事項の図。

ディザスター リカバリーのアーキテクチャをどのように設計するかは、クロス リージョンからクロス ロケーション (region1/region2 から location2/location1) へのトラフィックがどのようにルーティングされるかに影響します。 異なる方法でクロス リージョンからクロス ロケーションのトラフィックをルーティングする、2 つの異なるディザスター アーキテクチャについて考えてみましょう。

シナリオ 1

最初のシナリオでは、Azure リージョンとオンプレミス ネットワーク間のすべてのトラフィックが定常状態でローカル ExpressRoute 回線経由で流れるように、ディザスター リカバリーを設計しましょう。 ローカル ExpressRoute 回線で障害が発生した場合、Azure とオンプレミス ネットワーク間のすべてのトラフィック フローでリモート ExpressRoute 回線が使用されます。

シナリオ 1 は次の図に示されています。 図の緑色の線は、VNet1 とオンプレミス ネットワーク間のトラフィック フローのパスを示しています。 青色の線は、VNet2 とオンプレミス ネットワーク間のトラフィック フローのパスを示しています。 実線は定常状態での必要なパスを示しており、破線は、定常状態のトラフィック フローを渡す対応する ExpressRoute 回線のエラー時のトラフィック パスを示しています。

1 つ目のシナリオのトラフィック フローの図。

オンプレミス ネットワークでバインドされたトラフィックのローカル ピアリング場所の ExpressRoute への接続を優先するように、VNet に影響を与える接続の重みを使用するシナリオを設計することができます。 ソリューションを完了するには、対称的な逆方向のトラフィック フローを確保する必要があります。 ExpressRoute 回線を優先するために、(オンプレミス側で ExpressRoute 回線が終了される) BGP ルーター間の iBGP セッションでローカルの基本設定を使用することができます。 ソリューションは次の図に示されています。

アクティブ/アクティブの ExpressRoute 回線ソリューション 1 の図。

シナリオ 2

シナリオ 2 は次の図に示されています。 図の緑色の線は、VNet1 とオンプレミス ネットワーク間のトラフィック フローのパスを示しています。 青色の線は、VNet2 とオンプレミス ネットワーク間のトラフィック フローのパスを示しています。 定常状態 (図の実線) では、VNet とオンプレミス ロケーションの間のすべてのトラフィックは、Microsoft バックボーンを通常通り使用して流れ、オンプレミス ロケーション間の相互接続を介して流れるのは、ExpressRoute の失敗状態 (図の破線) においてのみです。

2 つ目のシナリオのトラフィック フローの図。

ソリューションは次の図に示されています。 図に示されているように、より具体的なルート (オプション 1) または AS パスを前に付加 (オプション 2) を使用して VNet パスの選択に影響を与える、シナリオを設計することができます。 Azure でバインドされたトラフィックのオンプレミス ネットワーク ルートの選択に影響を与えるには、オンプレミスの場所間の相互接続を優先順位の低いものとして構成する必要があります。 相互接続リンクを望ましいものとしてどのように構成するかは、オンプレミス ネットワーク内で使用されるルーティング プロトコルによって異なります。 iBGP ではローカルの基本設定、IGP (OSPF または IS-IS) ではメトリックを使用できます。

アクティブ/アクティブの ExpressRoute 回線ソリューション 2 の図。

重要

1 つまたは複数の ExpressRoute 回線が複数の仮想ネットワークに接続されている場合、仮想ネットワーク間のトラフィックは ExpressRoute 経由でルーティングできます。 ただし、これは推奨されません。 仮想ネットワーク間の接続を有効にするには、仮想ネットワーク ピアリングを構成します。

次のステップ

この記事では、ExpressRoute 回線のプライベート ピアリング接続のディザスター リカバリーを設計する方法について説明しました。 次の記事では、アプリケーションおよびフロントエンドのアクセスの観点から、ディザスター リカバリーに対処します。