A két technológia és a két gyártó szereti úgy felfesteni a saját termékét, hogy az övé az a tökéletes és mindent sokkal jobban tud mint a másik. Ez nagyon nincs így, mindkettőnek van előnye és hátránya, de ami szerintem fontosabb, hogy azon tehetős ügyfelek, akik megtehetik önmagában azt hogy mindkettőt megvásárolják és be is vezessék, azoknak nagyon nem mindegy a közös működés mélysége és formája.
Bizony, van közös működési mód, de itt van a legnagyobb félreértés és konfliktus a fejekben.
Előtte tisztázzuk mi az az ACI és az NSX. Mindkettő hálózat-virtualizációs és automatizációs megoldás. Én úgy szoktam mondtani, hogy az ACI olyan a fizikai világban mint az NSX a virtuálisban. Előbbi sosem lesz akkora király a VMware háza táján mint az NSX, míg ez utóbbi teljesen esélytelen hogy valaha fizikai switch-eken konfiguráljon bármit – bár hozzáteszem, hogy az NSX-V idejében még volt hardware VTEP pl Arista switch-ekkel, ahol bár egy köztes rétegen keresztül, de az NSX konfigurált fel portot.
Az ACI lényegében a Nexus 9000 modellek használata ACI módban, ezáltal a menedzsmentje ezeknek a switch-eknek az ACI agyába, az APIC (Cisco Application Policy Infrastructure Controller) entitásba költözik.
Részletesen foglalkozik az ACI-val, Makláry Tamás kollégám, érdemes menteni a könyvelzőid közé:
https://www.telecommer.hu/2019/12/halozat-virtualizacio-gyakorlatban-aci.html
Az NSX-V/T pedig igazából bármilyen hálózaton ami képes layer 3 kapcsolatot biztosítani, hozza amit kell és nem csak overlay-t ad, hanem a load-balancer-től kezdve a VPN-en át a mikroszegmentációig mindent.
Mindkettőnél a legfontosabb az automatizáció/komponálhatóság.
Itt mindenki tegyen fel magának egy kérdést, ezt: Milyen gyakran változik a fizikai hálózat és vele együtt a fizikai szerverek?
Ha a válasz itt az, hogy alig, minden második évben bekerül két switch és például amúgy is a dolgok 90%-a virtualizált, akkor az ACI a bevezetés után használva sem lesz. Létrehozzák benne a megfelelő konfigurációt, dokumentálják, pecsét és kész.
Ha a kérdést úgy teszem fel, hogy a virtualizációban milyen gyakran változnak a dolgok, használnak-e konténereket, akkor más a kimenetel. Ekkor az NSX-T kikerülhetetlen. Hogy miért? Mert akármit mond a Cisco, senki más nem tud úgy varázsolni VMware rétegben – és már több más OS-en is – mint a VMware. Lehet trükközni, de a vége mindig azonos, nem támogatott megoldás.
Mikor kell mindkettő egyszerre? Fogalmam sincs, nem értem egyelőre. Általában emögött azt sejtem, hogy a hálózati entitás és a szerver csapat kötelet húznak és a termékek vitáját a gordiuszi csomóval hasonlítom. Ezt átvágja tulajdonképpen a menedzsment azzal, hogy mindkettőnek ad valamit. Ez eddig rendben is van, mert fel lehet osztani a pályát. Erre van is a Cisco-nak egy jó kis dokumentációja (link) és két javaslata:
Csak a képeket nézve, alig van különbség. A dokumentum egyénként megragadt az NSX-V-nél, de gyanítom hogy NSX-T esetében is azonos a dokumentum.
Az első eset amit a Cisco lájkol, azaz az ACI adja az overlay-t és kvázi az underlay-t is, az NSX pedig intézi a saját szintjén a mikroszegmentációt, az elosztott routing-ot, load-balancert. Amúgy nagyon vicces, de az opció 1 esetén a képről hiányzik az Edge, ahol pl a load balancing és az E-W tűzfal amúgy megvalósítható….lol. Ez a megoldást a VMware nem nagyon szereti és totálisan megértem, mivel a licenszeket égetjük el vele és a két fő funkciójából egyet teljesen elveszt. A Cisco és ezáltal a Cisco-s hálózati emberek pedig imádják, mert lényegében a VM-ekig látnak – a vDS-ig csak – minden új szegmens, minden ki beállítás a kezükben van.
A második eset, amit a VMware inkább elfogad, a Cisco hallani sem akar róla és a Cisco-s üzemeltetés pedig rendeli is a lédig Xanax-ot. Az ACI létrehozza az NSX számára a szükséges VLAN-okat, amelyekben az NSX létrehozza a saját overlay hálózatát. Igen az Eredet című filmre hajaz, overlay az overlay-ben. A hálózatos kollégák utálják, mert nulla ráhatásuk és rálátásuk van azokra a szegmensekre, amelyeket a VM-ek használnak, hibakeresésnél kis sarkítással az overlay-ben egy Geneve overlay-t látnak. Viszont az NSX mindent elvégezhet amit tud, saját maga hozza létre a szegmenseket, mikroszegmentál és így tovább.
Mielőtt haladnék tovább, beszéljük még az Opció 1 esetről. Itt a Cisco-nak van egy komponense, a VMM, ami képes automatizálni a VMware rétegben a Distributed vSwitch-et – meg persze sok egyebet, mint Microsoft System Center VMM, or Red Hat Virtualization-t. Erről a lehetőségről hadd idézzem a VMware álláspontját, változtatás nélkül:
VMware vSphere Distributed Switch™ cannot be controlled by the Cisco ACI plug-in nor Cisco ACI Virtual Networking (otherwise known as Virtual Machine Management, VMM). ACI VMM was developed independently and is outside the partner support model VMware has in place. All support and subsequent risk of use for ACI VMM will be handled solely by Cisco. See the Cisco documentation about out-of-synchronization issues that can arise from use of VMM. VMware supports the use of vSphere APIs for VDS management and operation, but not the unintended extensions imposed by VMM and required for the success of ACI internal network management operations.
For interoperability with NSX Data Center, the vSphere VDS and VMware NSX-T™ Data Center N-VDS must be provisioned and managed independently from ACI. This is inclusive of Cisco Virtual Networking involving virtual machines, containers, and service virtual machines such as the ACI virtual edge (AVE).
Ha valaki mégis ilyet implementál, akkor pedig nézzük meg azt, hogy kit lehet hívni ha baj van:
VMware supports vSphere and all features available through the public API.
Any API level integration implemented outside of a certified partner program is a customer’s responsibility and is not supported by VMware.
Cisco ACI VMM/AVE leverages the vSphere APIs but was developed outside of any formal partner program and therefore is not supported by VMware.For Support Requests which directly relate to the ACI VMM/AVE component and how it interacts with vSphere, VMware will request that the Cisco VMM/AVE component be removed for troubleshooting purposes as per support policy
https://kb.vmware.com/s/article/57780
If the issue is reproducible without the Cisco VMM/AVE component, VMware will support and investigate as normal.
If the issue is not reproducible when the ACI VMM/AVE component is removed, VMware will not investigate further.
Szóval ha ACI állítgatja a vDS-t, akkor a VMware nem nyújt támogatást. Ezt szerintem ne kockáztassa meg senki sem, mivel ha hiba van, akkor a Cisco-t lehet hívni maximum a VMware-es hibával.
De mi az amit nem tud az NSX és tud az ACI? Említettem, hogy a Cisco tudja a legjobban a saját switch-einek automatizált beállítását és ezek nagy méretben és magas számban történő alkalmazását. Mikroszegmentálni viszont egyáltalán nem képes. Azonos szegmensben lévő két virtuális gép, amely ráadául azonos hoszton van szűrhetetlen az ACI által. Főleg azért mert ez nem stateful firewall az ACI szintjén, hanem egy jól megírt elosztott ACL. NSX-ben pedig tűzfal van, stateful és méghozzá van egy elosztott a vmnic-ek szintjén, és még „egy” az E-W határán legalább.
Szóval ebben a tűzfal témában a nem összemérhető a két termék. A hálózat automatizációja és központosított menedzsmenjében igen, viszont itt mindenkinek van előnye, mivel a sajátját csak az tudja támogatottan és legjobban nyomogatni.
Verdikt
Nem vagyok egyik mellett és ellen sem, viszont mielőtt egyiket/másikat vagy netán mindkettőt választjuk, kérdezzünk meg pár szakértőt arról, hogy arra az igényre ami van, mi a legjobb. Ez a szakertő pedig ne a VMware vagy a Cisco alkalmazásában álljon.