Home > Security and SD-WAN > Deployment Guides > MX Warm Spare - High Availability Pair > MX Warm Spare - 高可用性ペア

MX Warm Spare - 高可用性ペア

MX Warm Spareの概要

このページでは、ワンアーム コンセントレーター モードまたはNATモードのいずれかで2つのMXセキュリティ アプライアンス間でVRRPプロトコルを使用して、高可用性(HA)ペアをセットアップする方法や設定されたHAペアで予測される動作について説明します。高可用性は、ハードウェア障害が発生したときにダウンタイムを最小化するために使用できます。

1つのHAペアには1つのライセンスのみが必要です。Warm Spareユニットには個別のライセンスが必要ありません。Warm Spareのフェールオーバーのアラートは、Alerts and Administration(アラートと管理)ページで設定できます。

注:セカンダリMXはプライマリMXと同じモデルである必要があります。Warm Spare機能は別々のMXモデル(MX80とMX100など)ではサポートされません。

 

image1.jpg

 

スワップ ボタンは2つのMX間でプライマリとスペアの役割を交換するために使用され、HAフェールオーバーをテストするためのものではありません。フェールオーバー テストを行うには、プライマリMXへのアップリンクの完全な切断が必要です。

ユース ケース

ほとんどすべての顧客環境では、ネットワークのダウンタイムはビジネスに直接的な影響を及ぼすため、何としても避ける必要があります。Warm Spare機能を使用すると、ネットワークのエッジが単一障害点となることが回避され、デバイス障害が発生したときにすばやい自動回復が可能になり、エンドユーザ サービスへの悪影響が軽減されます。

利点

  • ハードウェア障害が発生したときのネットワークのダウンタイムが大幅に削減されるか、使用されるアーキテクチャによっては完全に除去される。

  • ハードウェア障害からの復旧を支援するためのネットワーク管理者チームによる手動介入が必要ない。

用語

このドキュメントでは、以下の用語とその意味を理解することが重要です。

 

プライマリ:ネットワークの「メイン」MXとして設定されたMX。両方のMXがオンラインの場合、トラフィックはこちらのMXを通過します。これは静的な指定です。つまり、ネットワークの現在の状態にかかわらず、プライマリは常にプライマリとなります。

スペア: ネットワークの「セカンダリ」MXとして設定されたMX。両方のMXがオンラインの場合、こちらのMXが非アクティブのWarm Spareとなります。これは静的な指定です。つまり、ネットワークの現在の状態にかかわらず、セカンダリは常にセカンダリとなります。

 

アクティブ(マスター): ネットワークのエッジ ファイアウォール/セキュリティ アプライアンスとして現在機能しているMX。これは動的な指定です。

パッシブ: トラフィックが通過していない非アクティブなWarm Spareとして現在機能しているMX。これは動的な指定です。

 

デュアル マスター: デュアル マスターは、プライマリとスペアの両方がアクティブ状態にあるシナリオのことを言います。これは両方のMXがオンライン状態でクラウドと通信しているが、セカンダリがハートビート パケット(次のセクションのVRRPハートビートを参照)をプライマリから受信していない場合に発生します。これは動的DNS、VPN、および一般的なトラフィック処理でいくつかの問題の原因となりうるため、何としても避ける必要があります。このドキュメントの物理アーキテクチャのセクションでは、デュアル マスター シナリオが起こるリスクを最小限に抑えるためにMX Warm Spareペアを展開する方法について説明します。

基礎となる概念および技術

VRRPハートビート

MX Warm Spareペアの障害検出にはVRRPハートビート パケットを使用します。これらのハートビート パケットは、プライマリがオンラインで正しく機能していることを示すために、設定されたすべてのVLANでプライマリMXからセカンダリMXに送信されます。セカンダリはこれらのハートビート パケットを受信している限り、スペア状態で機能します。セカンダリがこれらのハートビート パケットを受信しなくなると、プライマリがオフラインであると推定し、マスター状態に移行します。MXがNATモードの場合、VRRPハートビートはWAN経由で送信されず、WANインターフェースが相互に通信できることが保証されません。代わりに、「接続監視」と呼ばれるメカニズムを使用して、デバイスのWAN状態を判別します。

MXのVRRPメカニズムに関する詳しい情報については、NAT HAフェールオーバーの動作のドキュメンテーションを参照してください。

接続監視

接続監視は、すべてのMXセキュリティ アプライアンスに組み込まれているアップリンク モニタリング エンジンです。エンジンのしくみはこの記事に記載されています。接続監視により、プライマリMXのすべてのアップリンクに障害が発生したとマークされると、そのMXはVRRPハートビート パケットの送信を停止し、Warm Spareフェールオーバーが開始されます。プライマリの少なくとも1つのアップリンクが動作状態に戻ると、プライマリはハートビート パケットの送信を再開し、セカンダリはアクティブの役割をプライマリに譲ります。

DHCP同期

IPアドレスがプライマリによってDHCP経由で割り当てられた後、同じアドレスがフェールオーバー後にセカンダリによって別のクライアントに割り当てられるといったシナリオを避けるために、DHCPリース テーブルはUDPポート3483を使用してプライマリとセカンダリの間で定期的に同期されます。

ダッシュボード設定

既存のダッシュボード ネットワークのWarm Spareフェールオーバーを設定するために、Security & SD-WAN(セキュリティ & SD-WAN) > Monitor(監視) > Appliance status(機器のステータス)に移動し、ページの左上付近のデバイス名の下にあるConfigure warm spare(Warm Spareの設定)を選択します。表示されるウィンドウで、Enabled(有効)を選択します。セカンダリMXのシリアル番号を入力して目的のアップリンクIP設定を選択し、Update(更新)を選択してWarm Spareを有効化します。

 

image3.png

 

Use MX uplink IPs(MXアップリンクIPの使用): このオプションを使用すると、現在アクティブなMXはインターネットにトラフィックを送信するとき、その1つまたは複数の別個のアップリンクIPを使用します。このオプションでは、インターネット向けのMXに追加のパブリックIPが不要ですが、アウトバウンド フローのソースIDが変更されるため、中断の多いフェールオーバーが発生することになります。

Use virtual uplink IPs(仮想アップリンクIPの使用): このオプションを使用すると、両方のMXはインターネットにトラフィックを送信するとき、共有されている仮想IP(VIP)を使用します。このオプションではアップリンクごとに追加のパブリックIPが必要になりますが、ネットワークがインターネットとの通信に使用するIPアドレスは不変であるため、シームレスなフェールオーバーが可能です。各アップリンクのVIPは、そのアップリンク用のMX自体のIPと同じサブネットに存在する必要があり、VIPは両方のMXアップリンクIPと異なっている必要があります。

Warm Spareフェールオーバーを使用して新しいネットワークを設定するには、通常のようにネットワークを作成し、プライマリMXを追加します。次に、上記のプロセスを使用して、セカンダリMXを追加します。

選択したオプションに関係なく、両方のMXデバイスには、ダッシュボード接続のための独自のアップリンクIPアドレスが必要です。

ダッシュボード設定は、セカンダリMXをネットワークに物理的に接続する前に常に行う必要があります。

Organization(オーガナイゼーション) > Inventory(インベントリ) ページで、同じモデルのMXが既に含まれているネットワークにMXが追加されると、そのMXは自動的にWarm Spareモードでそのネットワークに追加されます。

Warm Spare設定用のMXモード オプション

MXデバイスは、次の2つのうちいずれかのMXアドレッシング オプションを使用して、Warm Spareの高可用性ペアで設定できます。

  • VPNコンセントレーター/パス スルー モード

  • NAT モード

ダッシュボード内でモードがVVPN コンセントレーター/パス スルー モードとして反映されている場合、MXはこのモードのワンアーム コンセントレーター トポロジのみをサポートします。これに関する追加情報は、「「ワンアーム」VPN コンセントレーター ペアでのMXの接続」セクションを参照してください。

各モードでは、プライマリがセカンダリにフェールオーバーできる、2つのMXが同じネットワーク上に存在することになります。ただし、モードごとに必要な設定は若干異なります。ここでは、異なる設定方法および考慮事項について説明します。MXのアドレッシング モードや展開に最適なモードを選択する方法についての詳しい情報が必要な場合は、MXのアドレッシングとVLANの記事を参照してください。

VPN コンセントレーターWarm Spare 

コンセントレーターWarm Spareを使用することで、Meraki AutoVPNヘッドエンド アプライアンスに高可用性が提供されます。

ネットワーク設定 

各コンセントレーターは、Merakiクラウド コントローラと管理トラフィックを交換できるよう、固有のIPアドレスを持っています。ただし、コンセントレーターは非管理通信に使用される仮想IPアドレスも共有しています。

「ワンアーム」VPN コンセントレーター ペアでのMXの接続 

MXをワンアームVPNコンセントレーターとして導入する前に、Addressing and VLANs(アドレッシングとVLAN)ページでMXをパススルー モードまたはVPNコンセントレーター モードに設定します。ワンアームVPNコンセントレーター モードでは、ペアのユニットは、それぞれのインターネット ポート経由でのみネットワークに接続されます。これらがLANポート経由で直接接続されていないことを確認してください。これらは同じIPサブネット内に存在し、相互に通信でき、Cisco Merakiダッシュボードとも通信できる必要があります。VPNトラフィックのみがMXに経由され、進入パケットも退出パケットも同じインターフェース経由で送信されます。

仮想IP 

仮想IPアドレス(VIP)は、プライマリとWarm SpareのVPNコンセントレーターで共有されています。VPNトラフィックは、個々のコンセントレーターの物理IPアドレスではなくVIPに送信されます。仮想IPは、Warm Spareを設定するときに、Security & SD-WAN(セキュリティ & SD-WAN) > Monitor(監視) > Appliance status(機器のステータス)に移動して設定します。これは両方のアプライアンスのIPアドレスと同じサブネットに存在する必要があり、一意である必要があります。特に、プライマリまたはWarm SpareのIPアドレスと同じにすることはできません。

障害検出 

2つのコンセントレーターは、VRRPプロトコルを介してネットワーク上で正常性情報を共有します。障害検出は、インターネット/Merakiダッシュボードへの接続に依存していません。

プライマリ ユニットに障害が発生した場合、Warm Spareは元のプライマリが再びオンラインに戻るまで、プライマリの役割を引き受けます。プライマリVPNコンセントレーターがオンラインに戻り、スペアがVRRPハートビートを再び受信し始めると、Warm Spareコンセントレーターはアクティブの役割をプライマリ コンセントレーターに譲ります。

障害検出、Warm Spareコンセントレーターへのフェールオーバー、およびVPNパケットの処理の再開までの合計時間は通常は30秒未満です。

NAT Warm Spare 

NAT Warm Spareは、MXセキュリティ アプライアンスがNATゲートウェイとして使用されているときに、インターネット接続およびアプライアンス サービスに冗長性を提供するために使用されます。

WAN仮想IP 

仮想IPアドレス(VIP)は、プライマリとWarm Spareアプライアンスで共有されています。インバウンドおよびアウトバウンドのトラフィックはこのアドレスを使用して、フェールオーバー中に同じIPアドレスを保持し、中断を削減します。仮想IPは、Security & SD-WAN(セキュリティ & SD-WAN) > Monitor(監視) > Appliance status(機器のステータス)ページの左上のSPARE(スペア)セクションで設定します。2つのアップリンクが設定されている場合、VIPをリンクごとに設定できます。各VIPは、(VIPが設定されているアップリンク用の)両方のアプライアンスのIPアドレスと同じサブネットに存在する必要があり、一意である必要があります。特に、プライマリまたはWarm SpareのIPアドレスと同じにすることはできません。

 

image2.png

 

LAN IPアドレスは、設定済みのいずれかのVLANのアプライアンスIPに基づいて設定されます。LANでは仮想IPは不要です。

障害検出 

NAT モードのWarm Spareには2つの障害検出方法があります。

WANフェールオーバー: WANモニタリングは、アップリンク フェールオーバーに使用されるものと同じインターネット接続テストを使用して実行されます。これらの検査に関する詳細なデータは、Cisco Meraki Knowledge Baseを参照してください。プライマリ アプライアンスは、これらのテストに基づく有効なインターネット接続を持たない場合、VRRPハートビートの送信を停止し、結果としてフェールオーバーが発生します。元のプライマリ アプライアンスのアップリンク接続が復元し、Warm SpareがVRRPハートビートを再び受信し始めると、ウォーム スペアはアクティブの役割をプライマリ アプライアンスに譲ります。

LANフェールオーバー: 2つのアプライアンスは、VRRPプロトコルを介してネットワーク上で正常性情報を共有します。これらのVRRPハートビートはレイヤー2で発生し、設定済みのすべてのVLANで実行されます。アドバタイズメントがどのVLANのスペアにも到達しない場合、フェールオーバーをトリガーします。Warm SpareがVRRPハートビートを再び受信し始めると、ウォーム スペアはアクティブの役割をプライマリ アプライアンスに譲ります。

DHCP同期 

NATモードの高可用性ペアのMXは、LANのUDPポート3483経由でDHCP状態情報を交換します。これにより、DHCP IPアドレスがフェールオーバーよりも前にクライアントに既に割り当てられている場合に、フェールオーバー後に別のクライアントに渡されることを防ぎます。

要件およびベストプラクティス 

NAT HAを設定するときは、両方のMXがLAN上で信頼できる接続を確立し、プライマリMXのVRRPハートビートがスペアによって確実に認識できるようにすることが不可欠です。この接続性の信頼性を確保するには、次のことが必要です。

  • 2つのMXをLANのダウンストリーム スイッチ(理想的には複数のスイッチ)経由で互いに接続することで、VRRPハートビートを渡せるようにする必要があります。

    • それらの間の追加のホップは1回までとする必要があり、それらはすべてのVLANで通信できる必要があります。

    • 正しく設定されたHAトポロジではネットワークにループが生じるため、ダウンストリーム スイッチ インフラストラクチャでSTPを有効にするようにしてください。

  • NAT HAを初めて設定する場合、デバイスを物理的に配備する前に、スペアをダッシュボードに追加して設定し、スペアがその設定をただちに取得して適切に動作するようにする必要があります。

さらに、以下の考慮事項にも留意する必要があります。

  • 仮想IPが使用されている場合、2つのMXの各アップリンクはWAN側の同じブロードキャスト ドメインを共有する必要があります。

セルラー フェールオーバーの動作 

Merakiでは現在、高可用性(HA)ペアによるセルラー フェールオーバーをサポートしていません。これは、HAアップリンク フェールオーバーで必要なセルラー アップリンクの接続モニタリングを(MX 10.X以上で)実行しないためです。現時点では、HAペアでセルラー アップリンクが使用された場合、以下のことが順に発生します。

  1. プライマリMX WAN 1+2の障害により、セカンダリMXにフェールオーバーする

  2. セカンダリMX WAN 1+2の障害により、プライマリMXセルラーにフェールオーバーする

  3. プライマリMXセルラーの障害により、セカンダリMXセルラーにフェールオーバーする

上記のようにセルラー フェールオーバーを使用できますが、これはMerakiで正式にサポートされていません。

推奨されるトポロジ

NAT Warm Spare展開では2つの物理アーキテクチャが利用できます。

完全な冗長構成(複数スイッチ)

このアーキテクチャでは、プライマリMXとセカンダリMXが直接接続されず、VRRPハートビートはダウンストリーム スイッチ間で搬送されます。このトポロジには単一障害点がないため、これはほとんどの展開で推奨されるアーキテクチャです。

 

image5.png

完全な冗長構成(スイッチ スタック)

このアーキテクチャでは、プライマリMXおよびセカンダリMXはダウンストリーム スイッチ スタック経由で接続されています。各スイッチには、各MXへのアップリンクが少なくとも1つ存在します。これにより、トポロジの単一障害点がなくなります。

 

image4.png

 

2つ以上の物理WANアップリンクを使用した高可用性

アクティブなプライマリMXでは同時に2つのアクティブ アップリンクのみがサポートされていますが、セカンダリMXの第3のフェールオーバーのために追加のアップリンクを使用する必要があります。セカンダリMXで1つまたは2つの追加アップリンクを使用でき、プライマリMXのすべてのアップリンクに障害が発生したか、プライマリMXにハードウェア障害が発生した場合にアクティブになります。セカンダリMXに接続されたこれらの追加アップリンクは、プライマリMXのアップリンクとは異なるIPサブネットに属することができます。

NAT Warm Spareのトラブルシューティング

NAT HA設定に問題がある場合、ネットワークに影響を及ぼす様々な症状が現れることがあり、根本原因がNAT HAであることが明白でないこともあります。このセクションでは、HAの問題が通常はどのように現れるかに加えて、推奨されるトラブルシューティング手順について説明します。

デュアル マスターの問題

NAT HAで最もよくある問題の徴候は、デュアル マスターのシナリオで、このシナリオでは、プライマリMXとスペアMXがダッシュボードでどちらもアクティブ(マスター)であると報告されます。これはダッシュボードのSecurity & SD-WAN(セキュリティ & SD-WAN) > Monitor(監視) > Appliance status(機器のステータス)に移動し、アプライアンスの現在の状態を比較することで確認できます。

この問題は、プライマリMXがオンラインでハートビートを送信しているが、ハートビートがスペアによって認識されず、プライマリが停止しているとスペアが認識する場合に発生します。プライマリとスペアの両方がマスター状態の場合、DHCP、ルーティング、VPNなどに影響するネットワークの様々な問題の原因となります。

推奨されるトラブルシューティング手順

NAT HAに関するネットワークの問題が発生している場合、根本原因を特定するために以下のトラブルシューティング手順を実行する必要があります。

  1. ダッシュボード(Security & SD-WAN(セキュリティ & SD-WAN) > Monitor(監視) > Appliance status(機器のステータス))で両方のアプライアンスを確認し、上記のデュアル マスター シナリオがないか調べます。

    1. 両方のアプライアンスが一貫して「アクティブ」状態を報告している場合、それらのLAN接続を確認し、相互に通信できるようにします。

    2. プライマリがオンラインでアクティブのときに、スペアMXが断続的にアクティブ状態を報告している場合、両方のMXがすべてのVLANで相互に通信できることを確認します。さらに、2つのデバイスを接続するケーブルが不良なものでないか、あるいは通信の信頼性を損なう物理的な問題がないか確認します。

    3. いずれにせよ、各MXのLAN側でパケット キャプチャを行い、VRRPハートビートがどこで失われているかを明らかにします。

  2. HAペアがアップリンク側で仮想IPを使用するように設定されている場合、WAN接続の各ペア(たとえば各MXのWAN 1)が同じブロードキャスト ドメインを共有することを確認し、これらが両方ともアップストリーム デバイスによって認識できることを確認します。デュアル アップリンク/ISPを使用したトポロジの例については、以下の図を参照してください。

Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 9686

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community