vMX構築を行う上での最小サブネットサイズ、及び、拡張方法

回答を英語から翻訳しているため、文法に不備があるかもしれませんが、何卒ご容赦ください。

こんにちは。@

Microsoft Q&Aにお問い合わせいただき、ありがとうございます。

新しいvMXインスタンスをデプロイしようとした際に、デプロイが失敗してしまうという事象が発生しているとのこと、承知いたしました。

1. デプロイの失敗は、サブネットのサイズが小さすぎる（/29）ことが原因でしょうか？

はい、その可能性が極めて高いと考えられます。

Azureでは技術的には/29（8個のアドレス）のサブネットも許可されていますが、実際には、どのサブネットにおいてもプラットフォーム利用のために5個のIPアドレスが予約されます。そのため、/29のサブネット内で実際に利用可能なIPアドレスは、わずか3個しか残りません。

Cisco Meraki vMXのデプロイには、以下のIPアドレス割り当てが必要となります。

プライマリNICへのIPアドレス割り当て

プロビジョニング、診断、ヘルスチェック、および再デプロイの実行中に必要となる追加のIPアドレス利用

このように利用可能なIPアドレスが極めて限られている場合、特に再デプロイや更新処理を行う際に、デプロイが失敗したり、システムが不安定になったりする恐れがあります。

2. サブネットのサイズを小さく設定した場合、どのような影響（パフォーマンスや拡張性への影響）がありますか？

これはスループットやパフォーマンスに関する問題ではなく、プラットフォーム側のIPアドレス枯渇や、リソースのライフサイクル管理に関する問題となります。

3. サブネットの最小サイズとして、/26または/27は許容範囲内でしょうか？

はい、許容範囲内です。アドレス空間に十分な余裕がある場合は一般的に/24が推奨されますが、以下のガイドラインが広く受け入れられています。

/26 → 長期的な安定性を確保するための推奨最小サイズ

/27 → アドレス空間に制約がある場合に許容可能なサイズ

/29 → vMXのようなネットワーク仮想アプライアンス（NVA）には推奨されません

もしHub VNetのアドレス空間を/24まで拡張することが難しい場合は、/26を選択するのが安全かつ安定した運用につながります。また、/27でも許容範囲内ではありますが、アドレス空間の余裕はかなり少なくなります。お客様の要件に合わせて、適切なアドレス空間を作成してください。

4. 既存のvMXサブネットのサイズを拡張する際、現在稼働中のデプロイ（リソース）に影響を与えずに変更することは可能でしょうか？

いいえ、不可能です。Azureでは、サブネット内にリソースが既に配置されている場合、そのサブネットのサイズを「インプレース（稼働中のまま）」で変更・拡張する機能はサポートされていません。サブネットのサイズを拡張するには、以下のいずれかの対応が必要です。

推奨されるアプローチ（推奨）

十分なサイズ（例：/26 または /27）を持つ新しいサブネットを作成する

新しいサブネットに新しい vMX をデプロイする

VPN およびルーティングのトラフィックを移行する

古い vMX を廃止する

vMX のデプロイ時に発生したエラーのスクリーンショット、またはエラーメッセージの全文をプライベートメッセージにてお送りいただければ、そのエラーがサブネットの問題に起因するものかどうかを特定するお手伝いが可能です。上記の情報が解決の助けとなったか、あるいは本件に関してさらにサポートが必要かについて、お知らせいただけますと幸いです。

この回答がお役に立ちましたら、「回答を承認」をクリックし、ぜひ「いいね」をお願いいたします。この回答に関して追加のご質問がございましたら、「コメント」をクリックしてください。

Hello 管理者:仲田　督司

建設中に展開がうまく機能しなかった理由はサブネットが狭いからでしょうか?

Azureでは/29(8アドレス)のサブネットを許可していますが、プラットフォーム用に5つのIPアドレスが予約されており、/29サブネットには3つのIPアドレスしか使えません。この限られたIPアドレス数が、展開失敗の原因となっており、/29サブネットではCisco vMXの展開やライフサイクル操作に十分なIPを提供できません。このような小さなサブネットでは展開や再展開の問題がよく発生します。安定した運用のためには、より大きなサブネットが必要で、最低でも/27および/26が推奨されます。

サブネットの範囲が狭い場合、パフォーマンスやスケーラビリティを含めどのような影響が予想されますか?

狭いサブネット範囲は直接的なパフォーマンスには影響しませんが、安定性やスケーラビリティには大きな影響を与えます。利用可能なIPアドレスが少ないため、Azureはデプロイ、再デプロイ、アップグレード、メンテナンス中に問題が発生することがあります。また、インターフェースの追加やロードバランサーの追加、ソリューションのスケーリングなど、将来の拡張も制限されます。実際には、小さなサブネットは運用上の不安定さや成長を制限することが多いですが、パフォーマンスに即時的な影響が出ない場合もあります。

ハブvNetアドレスの範囲は狭く広がりがないので、/24でハブvNetアドレスを作成することは不可能です。/26以上が安定して動作する最小のサブネットだと聞いたことがありますが、それは問題でしょうか?

いいえ、それは問題ありません。/24サブネットは推奨されますが、必須ではありません。AzureでのCisco vMX展開では、/26サブネットが最も小さく安定しており、/27も多くの本番環境で動作します。最も重要なのは、Azureプラットフォームのニーズや将来の運用に十分なIPアドレスを確保することです。vMXサブネットが/26、または少なくとも/27であれば、HubのvNetアドレス空間が限られていても安定して動作するはずです。将来的に新たなリソースを展開する予定があるなら、/26か/24を選べます。

現在のvMXで使っているサブネットを拡張したい場合、現在の使用に影響せずに拡張する方法はありますか?

いいえ、Azureは既に使用中のサブネットを拡張しても既存のリソースに影響を与えません。現在のvMXサブネットは動作中はリサイズできません。なぜなら、vMXを切り離すか再デプロイが必要になり、ダウンタイムが発生するからです。

中断を防ぐためには、より広いアドレス範囲を持つ新しいサブネットを作成し、そのサブネット内に新しいvMXを展開し、トラフィックを移行してから古いvMXを廃止するのが最善です。この方法は安定性を維持し、現在の環境への影響を回避します。

上記の回答があなたの助けになれば幸いです!ご質問があればお知らせください。

「回答を受け入れる」と「アップボート」を忘れずに、提供された情報が役立ちます。これはコミュニティの他のメンバーにとって有益です。