Cisco ACI Multi-Pod vs. Multi-Site: 2026年におけるアーキテクチャの選択

Cisco ACI Multi-PodとMulti-Siteの選択は、データシートの範囲をはるかに超える影響を持つ、決定的なアーキテクチャ上の判断となります。この決定は、しばしばレイテンシーやスケールという単純な問題として捉えられがちです。しかし実際には、2026年における適切な選択は、障害ドメイン、運用上の複雑さ、および総所有コスト（TCO）の冷静な評価にかかっています。Multi-Podは、単一障害ドメインという代償を伴う「魅力的なシンプルさ」を提供し、Multi-Siteは真のフォールト分離を提供しますが、より高いエンジニアリングスキルと大幅に大きな予算を要求します。誤った選択は、技術的負債だけでなく、キャリアを決定づけるような停止につながります。

コアアーキテクチャ要素: PodとSite

マルチファブリック拡張を比較する前に、ベースラインコンポーネントを正確に理解することが重要です。ACIポートフォリオ全体はスパイン・リーフのClosトポロジーに基づいて構築されていますが、これらのトポロジーの管理方法と相互接続方法によってアーキテクチャが決まります。

単一ACIファブリック: ベースライン障害ドメイン

標準的なACIファブリックは、最低3台のApplication Policy Infrastructure Controllers (APIC) クラスター、一連のスパインスイッチ（例：Nexus 9508とGen3 -FX3ラインカード）、および一連のリーフスイッチ（例：Nexus 93180YC-FX3）で構成されます。この全体的な構成は、単一の管理およびコントロールプレーンドメインを形成します。ACIの基本的な原則は、ファブリック内のすべてのエンドポイントが、ポリシーと到達可能性の観点から、単一のホップで相互に到達可能であるという点であり、これはVXLANオーバーレイによって実現されます。厳密には、この単一ファブリックは単一の障害ドメインです。APICソフトウェア（ACIバージョン6.0以上）の致命的なバグや、Council of Oracle Protocol (COOP) のコントロールプレーンのメルトダウンは、ファブリック全体に影響を与え、その影響は避けられません。

ACI Multi-Pod: 拡張された単一ファブリック

ACI Multi-Podは、標準的なACIファブリックを複数の物理的な場所、つまり「ポッド」に「拡張」したものと考えることができます。各ポッドは独自のスパイン・リーフトポロジーを持ちます。しかし、すべてのポッドは *単一* のAPICクラスターによって管理され、そのAPICクラスターはいずれかのポッドに存在します。ポッドはIPベースのInter-Pod Network (IPN) を介して接続されます。管理の観点からは、単一のファブリックです。テナント、EPG、ブリッジドメイン（BD）など、すべての設定オブジェクトはすべてのポッド間で同期されます。これは、単一の管理画面を持つことを意味しますが、同時に地理的に分散された単一の障害ドメインを持つことも意味します。APICクラスターの障害は、Multi-Podインフラストラクチャ全体を不安定にする可能性があります。

ACI Multi-Site: 独立したファブリックのフェデレーション

ACI Multi-Siteは、根本的に異なるパラダイムを提示します。各「サイト」は、独自の専用APICクラスターを持つ完全かつ独立したACIファブリックです。これらのサイトは完全に自律的であり、Site1での障害はSite2に運用上の影響を一切与えません。サイトは標準的なIP/MPLSまたはVXLAN EVPNネットワークを介して相互接続されます。その鍵となるのは、以前のMulti-Site Orchestrator (MSO) であったNexus Dashboard Orchestrator (NDO) です。NDO（バージョン4.2以上）は、別のNexus Dashboardクラスタ上で動作し、フェデレーションおよびポリシーオーケストレーションエンジンとして機能します。管理者はNDOでテンプレートとポリシーを定義し、NDOはそれに対応する設定を各サイトのローカルAPICクラスタにプッシュします。NDOはファブリックをリアルタイムで管理するのではなく、コントロールプレーンコンポーネントではなくオーケストレーション層です。

相互接続: IPN vs. ISN詳細

ポッドまたはサイトを接続するネットワークは、些細な実装詳細ではなく、特定の厳格な要件を持つアーキテクチャの中核コンポーネントです。

Multi-Pod IPN設計要件

IPNは、各ポッドのスパインスイッチを接続するレイヤー3ネットワークです。スパインはIPNデバイスとの間でOSPFアドジャセンシーを確立し、他のポッドのスパインとの間でBGP EVPNセッションを確立します。主な要件は以下の通りです。

• 高いMTU: IPNはVXLANカプセル化されたトラフィック（50バイトのオーバーヘッド）に対応するために、少なくとも9150バイトのMTUをサポートし、フラグメンテーションを防ぐ必要があります。これは譲れない要件です。IPNにCatalyst 9500-48UXMのようなデバイスを使用する場合は、エンドツーエンドのMTUの厳密な検証が必要です。
• マルチキャスト: PIM-Bidirは、ポッド間でフラッディングする必要のあるブロードキャスト、未知ユニキャスト、マルチキャスト（BUM）トラフィックを効率的に処理するために必須のルーティングプロトコルです。他のPIMモードでも機能しますが、Bidirが標準設計です。
• DHCPリレー: APICは、リモートポッドのスパインを含むノードにTEPアドレスを割り当てるためにDHCPを使用します。IPNは、APICで定義されたTEPプールサブネットを指すDHCPリレーエージェントで構成する必要があります。
• レイテンシー: 公式のサポートされるRound-Trip Time (RTT) は50msです。しかし、10msを超えるレイテンシーがあるIPN上でL2ブリッジドメインを拡張する設計は、重大な問題を引き起こす可能性があります。高レイテンシーはブロードキャストストームの影響を増幅させ、vMotionのようなアプリケーションのパフォーマンスを著しく低下させる可能性があります。ポッド間のL3ルーテッド接続のみの場合は、50msがより現実的です。

Multi-Site Inter-Site Network (ISN)

Multi-SiteのISNは、ACI固有の要件に関してはシンプルですが、より洗練された基盤となるネットワークを想定しています。ISNは通常、キャリア提供のMPLS L3VPN、またはますます増えているVXLAN BGP EVPNを実行する自社管理のダークファイバーネットワークです。データプレーン接続はスパイン間で行われ、BGP EVPNセッションを利用してサイト間でエンドポイント到達性情報を交換します。NDOはこれらのBGPセッションの確立をオーケストレーションしますが、基盤となるネットワークトランスポートはACIから独立しています。これは重要な区別です。Multi-Siteは、サイトが *どのように* 接続されているかを規定するのではなく、適切なMTUでルーテッドトラフィックを交換できることを規定するだけです。

障害ドメインとブラスト半径

これは最も重要な考慮事項です。障害ドメインが大きいほど管理は容易になりますが、リスクは増大します。Multi-PodとMulti-Siteは、このスペクトルの両極端に位置します。

Multi-Podでは、ACIのバグ、誤った設定プッシュ、またはAPICコントロールプレーンの障害は、グローバルなイベントとなります。APIC GUIまたはAPIを介して行われた変更は、すべてのポッドに同時に伝播されます。COOPのバグによってファブリック全体のエンドポイント学習の問題が発生するシナリオを想像してみてください。Multi-Pod設計では、この問題はすぐにすべてのデータセンターに広がります。ディザスタリカバリサイトはプライマリサイトと同じ障害の影響を受け、役に立たなくなります。これは、真の事業継続を目指すほとんどのエンタープライズグレードのデプロイメントにとって、容認できないリスクです。

対照的に、Multi-Siteは堅牢なフォールト分離を提供します。各サイトは自己完結型のACIファブリックです。Nexus Dashboard Orchestratorはアウトオブバンドのオーケストレーションプラットフォームです。NDOクラスターが障害を起こしても、サイト間のポリシーの *変更* はできなくなりますが、各サイトの既存のデータプレーンとコントロールプレーンは完全に機能し続けます。サイト間のデータトラフィックは影響を受けません。Site1で実行されているACIバージョンのバグは、Site2には伝播されません。これにより、段階的で制御されたアップグレード（例：Site2をACI 6.1にアップグレードし、検証後、数週間後にSite1をアップグレードする）が可能になります。これはMulti-Podにはない、重要な運用上のセーフティネットです。

サイジング例: サイト間帯域幅とNDOリソース

一般的な2サイトのシナリオをモデル化しましょう。80km離れた2つのデータセンターで、アクティブ/アクティブのアプリケーションクラスターとデータベースレプリケーションをサポートする必要があります。

• サイト数: 2
• リーフスイッチ総数: 300 (各サイト150)
• テナント数: 50
• EPG数: 3,000
• ピークサイト間レプリケーショントラフィック: 150 Gbps

Multi-Podサイジングアプローチ

Multi-Podの場合、主要な懸念事項はIPNです。150 Gbpsのラインレート、大パケットトラフィックを転送できるIPNデバイスが必要です。十分な100Gポート密度を持つJniper SRX5800のペア、またはCisco Catalyst 9606Rシャーシが必要となるでしょう。より大きな問題はL2 BUMトラフィックです。もし500のVLAN（BDとして）をポッド間で拡張し、それぞれが平均10 MbpsのBUMトラフィックを生成すると、それは5 Gbpsの定常的なマルチキャストトラフィックとなり、IPN帯域幅とIPNルーターのCPUを消費します。この計算は往々にして見落とされます。(拡張されたBDの数) * (BDあたりの平均BUMトラフィック) = IPNの定常負荷。この負荷は常に存在し、帯域幅計画に含める必要があります。

Multi-Siteサイジングアプローチ

Multi-Siteの場合、キャリアから200Gbps（150 Gbps + 33%のヘッドルーム）のL3VPN/EVPN Waveサービスをプロビジョニングします。焦点はNexus Dashboardクラスターのサイジングに移ります。Cisco NDO 4.2サイジングガイドに基づくと、2サイト、3000 EPG、50テナントを管理するには、各ノードが約16 vCPU、64GB RAM、1TBのディスクスペースを持つ仮想マシンである3ノードのNDOクラスターが必要です。これは無視できない仮想化フットプリントです。コストはデータパス帯域幅計算（単純なキャリア回線費用）ではなく、NDOと2番目のサイトの冗長APICクラスターのコンピューティングおよびソフトウェアライセンスにあります。

よくある落とし穴: DCIを介したL2の拡張

Multi-PodとMulti-Siteの両方が提供する最も危険な機能は、Layer 2ブリッジドメインを地理的に離れた場所に拡張する機能です。技術的には可能ですが、ほとんどの場合、アーキテクチャ上の誤りです。L2を拡張すると、単一のブロードキャストドメインが作成され、片方のサイトでのブロードキャストストームがDCI/IPNリンクにフラッディングし、もう一方のサイトに影響を与えます（運命共有）。トラブルシューティングを複雑にし、ハードコードされたIPアドレスを持つレガシーアプリケーションを最新化することを避けるための「つっかえ棒」として機能することがよくあります。Multi-SiteはVXLANでL2トラフィックをトンネルする方法においてよりエレガントですが、根本的な問題は残ります。2026年のベストプラクティスは、L2ドメインを単一サイトにローカルに保ち、すべてのトラフィックに対してサイト間のL3ルーテッド接続のみを使用することです。拡張しないでください。

ACI Multi-Siteを使用すべきでない場合

フォールト分離における技術的な優位性にもかかわらず、Multi-Siteは普遍的なソリューションではありません。Multi-Podがより現実的な選択肢となる特定のシナリオがあります。

第一にコストです。Multi-Siteの展開には、*各サイト* に完全なAPICクラスター（最低3ノード）、さらにNexus Dashboardクラスター（物理または仮想）、さらにNDOソフトウェアライセンス（例：N-D-ADV-S-GF）が必要です。これは、単一のAPICクラスターを使用するMulti-Pod設計と比較して、コントローラーとソフトウェアのコストを容易に2倍にする可能性があります。もし2つの「サイト」が同じ建物内の2つのフロアに過ぎない場合、Multi-Siteのコストは正当化できません。

第二にスケールとレイテンシーです。ダークファイバーと5ms未満のRTTを持つ2つの都市圏にまたがる小規模な展開（例：合計80リーフスイッチ未満）の場合、Multi-PodはNDOよりも運用が簡単な統合管理プレーンを提供します。単一障害ドメインのリスクは、物理的な近接性と低いレイテンシーがネットワーク起因の問題の可能性を制限する場合、運用上のシンプルさのために計算された許容可能なトレードオフとなり得ます。

最後に、チームのスキルセットを考慮してください。Multi-Podは、単一ファブリックACIの知識の直接的な拡張です。NDO、スキーマテンプレート、および基盤となるBGP EVPNサイト間ネットワークを管理する必要があるMulti-Siteは、複雑さが大幅に増大します。チームがその運用上の飛躍に対応できる準備ができていない場合、Multi-Siteを実装すると、フォールト分離によって解決されるよりも、誤設定によるリスクを多く招く可能性があります。

最終的に、意思決定はリスクの冷静な評価にかかっています。Multi-Podは単一の拡張された障害ドメイン内での運用簡素化を優先し、コストとシンプルさが最重要であり、リスクが許容範囲内と見なされる都市圏デプロイメントに適しています。Multi-Siteは、フォールト分離とスケーラビリティを何よりも優先し、事業継続が不可欠な大規模で地理的に分散したネットワークに必要な選択肢となります。技術的に可能であるというだけでなく、運用上の現実と予算に合致するアーキテクチャを選択してください。

TechLeagueでは、認定された専門家がお客様の特定の環境に合わせた両アーキテクチャのTCOと運用上の影響をモデル化するお手伝いをいたします。お問い合わせいただき、ご相談を開始してください。VXLAN EVPN設計とNexus Dashboardエコシステムに関する関連投稿もご覧ください。