My Home NW Lab

逸般の誤家庭のネットワーク

Azure環境でのMeraki vMX (Virtual MX)の冗長化の概要

概要

Public Cloud向けの仮想アプライアンスであるMeraki vMX (Virtual MX)の冗長化は、物理アプライアンスのMXとは冗長化設計が異なってきます。背景はPublic Cloud特有の技術要素があるためです。
本記事では主にAzure環境での冗長化に焦点を当てます。また、本記事の内容は2022年02月頃の情報を元にしています。

vMXはWarm-Spareに非対応

物理 (Physical)アプライアンスのMXと異なり、AzureやAWS環境の仮想 (Virtual)アプライアンスのvMXはWarm-Spareに対応していません。
そして、Warm-Spareの対応有無によってライセンスの観点でも違いが出てきます。

  • 物理 (Physical)アプライアンスのMXは、Warm-Spareの場合は2台1セットとして1ライセンスのカウントになります。
  • しかし、仮想 (Virtual)アプライアンスのvMX (Virtual MX)ではWarm-Spareが組めないため、台数分のライセンスが必要になります。

f:id:myhomenwlab:20220209200008j:plain
vMXはWarm-Spareに非対応

なお、管理・運用上の観点では、vMXはWarm-Spare非対応によりvMX 2台分で1セットに扱いに出来ないため、 vMXで冗長構成を組むにしてもMerakiの管理単位としてのNetwrokを分ける必要が出てきます。

f:id:myhomenwlab:20220209201550j:plain
Merakiの管理単位としてのNetworkがvMX単位に独立

通信の向きによる通信フローの違い

Azure環境のvMXは筐体観点ではActive-Activeで動作するようになります。 ですが、通信フローの観点では、SpokeからHubへの通信経路はHubに対する優先度で一意に決まります。

f:id:myhomenwlab:20220209203943j:plain
SpokeからHubへの通信経路

そして、Azure環境内のHubからSpokeへの通信経路は、Route TableのNext hop IP Addressで指定されているvMXへルーティングされます。
ルーティングの向き先を操作すれば、非対称な通信フローにもできるため、想定外の通信フローにならないように注意してください。

f:id:myhomenwlab:20220209204000j:plain
HubからSpokeへの通信経路

このように通信の向きによって、通信フローに関わる設定が異なる点を把握しておく必要があります。

障害の検知と切り替えの仕組みが別途必要 (ha-nva-fo に関しての情報)

AzureではRoute TableをSubnetに紐付けてルーティングの管理を行っております。
そして、宛先サブネットへのNext hop IP Addressは1つとなりますが、vMXはWarm-SpareによるFisrt Hopの冗長化を提供できないため、 正常に稼働しているvMXより何れかのIPアドレスを決め打ちして指定しておく必要があります。

そうなると、正常に稼働していたvMXに障害が発生した場合に、Route TableのNext hop IP Addressを切り替える必要があります。

vMXの切り替えの仕組みは、Merakiからは公式には提供されていません。 そのため、要件を満たせるように自動的な切り替えの仕組みを用意する必要があります。

f:id:myhomenwlab:20220209200519j:plain
障害の検知と切り替え - 正常時
f:id:myhomenwlab:20220209200717j:plain
障害の検知と切り替え - 障害時

なお、Merakiの公式ドキュメントには、Azure Functionsを活用する ha-nva-fo のPowershellスクリプトが参考情報として記載されていました。

documentation.meraki.com

f:id:myhomenwlab:20220209202555j:plain
Deploying Highly Available vMX in Azureのドキュメント

For implementing Azure functions to support High Availability vMXs, please reference:

https://github.com/Azure/ha-nva-fo

ただし、ha-nva-fo はNVA (Network Virtual Appliance)全般を対象とした汎用的なスクリプトであるため、 MerakiのvMX特有の考慮事項や、きめ細かな顧客要件には適宜対応する必要があります。
よって、Meraki vMXの実案件では、アプリケーション開発系のエンジニアをアサインする検討が必要になります。

なお、Azure Functionsを用いる場合は、Azure Functions自体の障害も検討する必要がある点に留意してください。

ha-nva-fo のMeraki vMX向けのパッチ (Branch)

ha-nva-fo をMeraki vMX向けに使用するにあたりハマった点があったため、 ha-nva-fo をForkしてMeraki vMX向けのパッチ (Branch)を作りました。

GitHub - myhomenwlab/ha-nva-fo at patch-meraki-vmx

本記事の執筆時点では、個人の検証環境レベルで行える簡単な冗長化の切り替えの確認しか行ってません。そして、筆者が品質を担保するものでもございません。

強調したい点は、実案件でMeraki vMXを冗長構成で導入する際に「冗長化の切り替えスクリプト」を自作すると、 責任分解点的にMerakiやAzureのサポート窓口に問い合わせできなくなるため、自分たちの手で品質を担保する必要があります。

具体的には「営業チームでMeraki vMX案件を取ってきたから、後は技術チームで宜しくね!」からの「アプリケーション開発系のノウハウが足りずにプロジェクトが炎上しました。」だと目も当てられません。
本記事を書き記しているのは、それを周知するためであると言っても過言ではありません。

補足情報: Hub間の通信ループ (追記: 2022年04月03日)

本記事の内容は、Merakiの用語でDC-DC Failoverと呼ばれる冗長構成となります。 そしてDC-DC Failover構成では、Hub間で通信がループするのが想定動作であるため、提案や導入時は下記の記事も確認してください。

myhomenwlab.hatenablog.com