マルチクラウド
未来の設計:VCF 9のネットワーク設計とレガシーL2の終焉
VMware Cloud Foundation (VCF) 9はもはや選択肢ではなく、指令です。Broadcom後の状況において、個別のvSphereまたはvSANライセンスを「自由に選択する」時代は終わり、データセンターを単一のプログラマブルなエンティティとして扱うことをネットワークエンジニアに強制するモノリシックなフルスタックの義務に取って代わられました。もしあなたがまだ手作業でVLANを設定したり、レガシーL2拡張を使って物理ファブリックを設計しようとしているなら、あなたは時代の流れに遅れているだけでなく、VCF 9の必須であるNSXおよびvSAN ESA統合の重みに耐えきれない障害点を設計していることになります。
Broadcom後の現実:VCF 9が戦略的基盤
VCF 9への移行は、SDDC (Software-Defined Data Center)へのアプローチ方法における根本的な変化を意味します。以前は、NSXは高度な環境向けの「オーバーレイオプション」として扱われることがよくありました。VCF 9では、NSXがエンジンであり、トランスミッションであり、ダッシュボードです。Broadcomはライセンスを合理化し、vSphere単体とVCFのコスト差が移行を強制するように設計されています。ネットワークエンジニアにとって、これは物理アンダーレイが不可視で、堅牢で、純粋なL3でなければならないことを意味します。
私たちは、ネットワークがハードウェアインターフェースではなく、VCF Servicesによって定義される設計哲学を見ています。レガシーvSAN (Original Storage Architecture - OSA)が廃止され、Express Storage Architecture (ESA)に移行したことで、ネットワーク要件は大幅に増加しました。もしあなたが最低でも25GbEを、VCF 9クラスターの標準である100GbEを配線していないなら、NVMeベースのESAがそのIOPSの可能性を達成するために必要なスループットを飢えさせています。
NSX-Tは死んだ、NSX Project AntreaとVPCに栄光あれ
VCF 9では、ネットワーキング構成要素が進化しました。NSX Virtual Private Cloud (VPC)モデルへの大きな推進が見られます。これは単なるマーケティング用語ではなく、マルチテナンシーの処理方法における構造的な変化です。エンジニアが視覚化に苦労していた複雑なTier-0/Tier-1のネストではなく、VCF 9はすべてのテナントまたはアプリケーション境界をVPCとして扱い、T1ルーターをセルフサービス型の消費モデルに抽象化しています。
設計の観点からは、Edge Clusterの再考が必要です。以前のバージョンでは、小さなEdge VMで済ませることができたかもしれません。VCF 9では、特に高性能なvSAN ESAトラフィックとマルチAZフェイルオーバーをサポートする場合、DPDK (Data Plane Development Kit)の要件に対応するために、Edge Nodeを「Large」または「X-Large」にサイジングする必要があります。標準的な4ノードの管理クラスターの場合、ノースサウス間のボトルネックを防ぐために、最低2つの100GbE対応Edge Nodeを推奨します。
VCF 9アンダーレイ:L3ファブリックか崩壊か
初期のPXEブートやOOB管理以外の目的で、ESXiホストへのMLAG/VPC (Virtual Port Channels) をまだ実行している場合、あなたは返済できない複雑性の負債を作り出しています。VCF 9はL3のみのリーフ-スパインアーキテクチャで thrived します。私たちは、NSX Federatedモデルを使用したBGP-to-the-Hostモデル、または少なくともTier-0 GatewayとTop-of-Rack (ToR) スイッチ間のEBGPを提唱します。
Dell VxRailまたはHPE Synergyノードを使用した典型的なVCF 9デプロイメントを考えてみましょう。物理構成は次のようになるはずです。
! Sample Leaf Switch BGP Configuration (Arista EOS style)
router bgp 65001
router-id 10.0.0.1
maximum-paths 64
neighbor VCF_EDGE_PEERS peer-group
neighbor VCF_EDGE_PEERS remote-as 65002
neighbor VCF_EDGE_PEERS bfd
neighbor 10.1.1.2 peer-group VCF_EDGE_PEERS
neighbor 10.1.1.3 peer-group VCF_EDGE_PEERS
redistribute connected
! Ensure MTU 9000 is set everywhere for vSAN ESA and Geneve Overlays
MTU 9000 (ジャンボフレーム)がエンドツーエンドで設定されていないと、NSXのGeneveカプセル化オーバーヘッドがフラグメント化され、30-40%のパフォーマンス低下につながります。VCF 9では、これは単なる「推奨」ではなく、vSAN ESAのヘルスチェックには必須です。
vSAN ESA:ネットワークはバックプレーン
VCF 9がvSAN ESAに依存することで、スループットの計算が変わります。従来のディスクグループモデルとは異なり、ESAはすべてのディスクがパフォーマンスディスクとなる単一階層アーキテクチャを使用します。これにより、リシンクイベント中にEast-Westトラフィックが大量に発生します。私たちはもはや10Gbpsのピークを設計しているわけではありません。ノード障害時に40-60Gbpsの持続的な負荷を設計しています。
これをサポートするために、VCF 9のネットワーク設計ではNetwork Partitioningを優先する必要があります。ホスト上で集約されたN-VDS (NSX Virtual Distributed Switch)を使用しているとしても、vSANシステムトラフィックの帯域幅を保証するためにNIOC (Network I/O Control)を使用する必要があります。vSANトラフィックをvMotionやオーバーレイトラフィックよりも適切に優先しないと、ネットワークが輻輳したときにSCSIタイムアウトや「All Paths Down」 (APD)シナリオが発生します。
Multi-AZ設計とリージョナルフェデレーション
VCF 9の主要な柱の一つは、簡素化されたMulti-Availability Zone (Multi-AZ)アーキテクチャです。Broadcomはストレッチクラスターのデプロイメントを合理化しましたが、基礎となるネットワーク要件は依然として厳格です。VCF 9ストレッチクラスターには以下が必要です。
- 管理プレーンとワークロードプレーンで5ms未満のラウンドトリップタイム (RTT)。
- vSAN ESAストレッチトラフィックで1ms未満のRTT (これは厳密な制限です)。
- Witnessトラフィックとレプリケーションのために、サイト間で最低10Gbpsの専用帯域幅。
VCF 9では、物理層でのL2ストレッチVLANから脱却します。代わりに、NSX Federationを使用してサイト間でセグメントをストレッチします。これにより、VMがセカンダリAZに移動した場合でも、トラフィックがプライマリサイトに「ヘアピン」バックしないように、ローカルイングレス/エグレス最適化 (BGPローカルプリファレンスを使用)が可能になります。もしあなたがNSX Federationアーキテクチャに関する詳細な解説を読んでいないなら、VCF 9のロールアウトにコミットする前に、Global Managerがサイト障害をどのように処理するかを再確認する必要があります。
セキュリティ:IDベース分散ファイアウォール (IDFW)
VCF 9におけるセキュリティは、マイクロセグメンテーションだけでなく、分散ファイアウォール (DFW)と最新のIDプロバイダーとの統合に関するものです。VCF 9準拠フレームワークでは、すべての管理トラフィックを、コミッショニングの段階からNSX DFWルールを使用して分離することが義務付けられています。管理VM間のEast-Westトラフィックに物理ファイアウォールを使用することはもはやありません。高密度VCF 9環境では、物理的なPalo AltoやFortiGateアプライアンスにトラフィックをヘアピンさせるオーバーヘッドは受け入れられません。
代わりに、NSX Distributed IDS/IPSを活用してください。VCF 9では、これらのシグネチャはBroadcom Cloud経由で自動的に更新されるため、単一のVLANタグやファイアウォールルールを変更することなく、ネットワークが横方向の移動脅威にリアルタイムで対応できます。これは、過去10年間プロジェクトが約束してきた「ゼロトラスト」アーキテクチャが、VCF 9の自動化エンジンを通じてついに実現されたものです。
無知の代償:ライセンスとハードウェアのアライメント
数字について話しましょう。VCF 9のライセンスは高価です。従来のvSphere Enterprise Plusのコアあたり (16コア最小) の2~3倍の費用がかかることがよくあります。このソフトウェアを老朽化した10GbEネットワーキングにデプロイすると、実質的に「愚か者税」を支払うことになります。高性能なソフトウェアに対して、500ドルのTop-of-Rackスイッチによってスロットルされている料金を払っているのです。
VCF 9への投資に対するROIを実現するには、ハードウェアが一致している必要があります。これは、Intel Ice LakeまたはSapphire Rapids CPU、ノードあたり少なくとも1TBのRAM、Mellanox ConnectX-6以上のNICを意味します。これらのNICは、NSXのパフォーマンスに不可欠なUptane/Hardware Offloadsをサポートしています。ハードウェアオフロードがないと、ホストCPUはそのサイクルの20-30%をGeneveカプセル化パケットの処理に費やし、VM統合率から奪うことになります。
結論
VCF 9のネットワーク設計は、物理層の徹底的な簡素化により、仮想層での極端な複雑性と俊敏性を可能にするものです。手動でのトランキングやスパニングツリーの調整の時代は終わりました。あなたの仕事は、NSXとvSAN ESAが本来の目的を果たす、つまり高性能で自己修復型のセキュアなクラウドプラットフォームを提供する、堅牢なL3の「ダークパイプ」を提供することです。
TechLeagueでは、これらの重要な移行を組織が乗り越える支援を専門としています。NSX VPCへの移行で苦労している場合でも、vSAN ESAのためにファブリックを再設計する必要がある場合でも、Broadcomのドキュメントでは語られていない深いレベルのエンジニアリング専門知識を提供します。カスタマイズされたコンサルティングおよびトレーニングパッケージをご覧いただき、VCF 9への道のりがパフォーマンスのボトルネックで終わらないようご確認ください。
よくある質問
VCF 9に推奨される最小物理NIC速度は何ですか?+
管理用には10GbEが技術的にサポートされていますが、VCF 9のvSAN ESAには不十分です。最低25GbEが必要であり、高密度NVMeクラスターには100GbEが強く推奨されます。
VCF 9ではジャンボフレームは必須ですか?+
VCF 9ではGeneveカプセル化の使用が義務付けられています。したがって、オーバーレイには最低1600のMTUが必要ですが、vSANとvMotionのパフォーマンスがフラグメンテーションによって低下しないように、9000 (ジャンボフレーム)が標準です。
NSX VPCはVCF 9ネットワーキングをどのように変えますか?+
VCF 9は、従来のTier-0/Tier-1階層からNSX VPCモデルに移行し、よりAWSのような消費エクスペリエンスを提供し、マルチテナンシーを簡素化します。
vSAN ESAが従来のvSANよりも多くのネットワーク帯域幅を必要とするのはなぜですか?+
vSAN ESAはディスクグループ (キャッシュ/容量) の概念を排除し、すべてのNVMeドライブがパフォーマンスに貢献するストレージプールを使用します。これにより、リシンク中にネットワークファブリックへのバースト負荷が大幅に増加します。
VCF 9 Multi-AZのレイテンシー要件は何ですか?+
VCF 9では、ストレッチクラスター構成において、サイト間の管理トラフィックで最大5msのRTT、vSANデータトラフィックで1msのRTTが必要です。
新しいBroadcomライセンスはネットワーク設計にどのように影響しますか?+
VCF 9は、フルスタック (vSphere、vSAN、NSX、Aria) を含むコアごとのサブスクリプションとして主に販売されます。これにより、NSXがデフォルトで含まれるため、「vSphereのみ」のネットワーク設計は時代遅れになります。