A korábban tárgyalt Small DC Design alapon kiépített POC vagy éles környezet használata után előbb-utóbb – remélem előbb 😉 – felmerülhet az igény, hogy a mikroszegmentáció mellett mást szolgáltatást is igénybe akarunk venni.
Lehet ez az igény:
- overlay és
optimalizált útválasztás: kiterjeszteni a VM-ek által használt szegmenseket több telephelyre/telephelyen belül máshová – de az nem akarjuk megtenni alacsonyabb szinten. - load balancer/VPN
Tárgyalom először a másodikat, mert az a legkönnyebben megvalósítható. Nem kell hozzá más, mint egy Edge Services Gateway és kész.
Load balancer
- One arm mode – ha egy interfésze van az ESG-nek:
Nagyon egyszerű bevezetni, ezen az egyetlen interfészen lesz a virtuális IP (VIP). Ezen az interfészen történik a szerverek elérése is.
A kommunikáció útvonala:
- A kliensek a lekéréseket a VIP-re küldik.
- Kétszer is NAT-olódik itt a forgalom. Egyszer egy DNAT történik, azaz az eredeti cél IP, ami a VIP volt, kicserélésre kerül a szerver pool egyik tagjának IP-jére – természetesen arra, ami a terhelés és egyéb szabályok mentén kiválasztásra kerülő. A másik egy SNAT, azaz a klienstől érkező forgalom forrása cserélődik ki a VIP címére.
- A pool szerver válaszol a VIP IP-jére ami az NSX ESG LB-ben meg van határozva.
- A load balancer újra végrehajtja a dupla NAT-ot és forrás IP-ként felhasználja a VIP címét, mikor választ küld a klienseknek.
Mivel egy interfész van, így sajnos annak a lábnak azonos szegmensben kell lennie, mint amiben a szerverek az LB Poolban. Itt már érezhető a legkomolyabb limitációja ennek a verziónak, mégpedig hogy minden egyes szegmensen, ahol load balancer funkcionalitás kell, oda minden esetben egy egy ESG-t le kell tenni (ha egy szegmensen több LB VIP kell, akkor azért elég egy ESG, nem kell kettő).
Transparent mode
A kommunikáció útvonala:
- A kliens a VIP-re küldi a lekérést
- A load balancer csak egy DNAT-ot végez el, amiben kicseréli a cél IP-t, azaz a VIP-t kicseréli egy szerver IP-jére az adott pool-ban.
- A cél szerver válaszol a kérésre, amiben a destination IP az eredeti kliens IP.
- Az LB megkapja a csomagot és csinál egy SNAT-ot, így válaszol a kliensnek.
Overlay
Erről már írtam korábban, nagyon kevés olyan eset van, hogy az ügyfél zöldmezős. Azaz, elég kevéssé lehetséges hogy az ügyfél csak ezért venne NSX-et, mivel ha ez kell/kellett neki, akkor azt már megoldotta másképp.
Ehhez már szükség van NSX Controller-ekre, természetesen háromra. Kellenek VTEP interfészek is minden ESXi hosztra, a szükséges kernel szintű komponensek is.
Ez a kiindulási állapot:
Minden port group, amit a virtuális gépek használnak, VLAN-ok hordozzák, az átjáró minden esetben a VMware környezeten kívül található egy switch-en/router-en/tűzfalon.
Ezt megváltoztatni brownfield ügyfél – értsd nem startup, nem új környezet – működő rendszerében picit több lépésből áll. Ehhez optimális esetben azokat a VLAN-okat, amikben VM-jeink vannak, bevisszük VXLAN-ba. Szerencsés esetben nincs fizikai gép ezekben a szegmensekben, ha mégis, akkor kell egy DLR – vagy több – ami megvalósítja VXLAN<->VLAN bridge-et. Erről írtam már itt.
A végállapot pedig valahogy így néz ki, ahol már van egy DLR, a routing ezáltal tényleg optimális, minden hoszton ott van. A VXLAN/VLAN határa egy ESG.
Arról órákat lehet beszélgetni, hogy szükség van-e arra, hogy az Edge ESG-k izolálva legyenek-e egy külön klaszterben. Szerintem annak van értelme, ha a Compute és Edge klaszter van egyben és a Management külön.
Ennél csak egy módon lehet mégjobban szegregálni a funckiókat és feloldani, kizárni minden függőséget. Én azt gondolom, hogy igen nagy ügyfelek esetében van létjogosultsága, mivel ők megengedhetik maguknak azt a pár fizikai gépet – legalább kettőt – amik erre dedikálhatók. Akkor is jobb ez a választás, ha valami olyan magas szintű biztonságot kell nyújtani, hogy adott zónák – DMZ és belső – nem érinthetik ugyanazon szerver még különböző interfészeit sem, tehát ha magas biztonsági szabályok érvényesek és alapvetően nem bíznak a sérthetetlen kódban.
Ez utóbbi jelentősen megnöveli a szükséges hosztok számát, mert minden klaszterben szükség van redundanciára. A Management-ben azért mert itt fut a compute klaszter vCenter Server-e, az NSX Manager, a három Controller – a monitoring és kinek mi kell még. Az Edge klaszterben futnak a DLR Control VM-ek – HA-ban a passzív is, ECMP-ben pedig értelemszerűen mind. Itt érdemes picit gondolkodni. Ha az adott ESG-t ECMP-vel akarok hajtani, négy ESG VM-mel, akkor nem rossz ötlet legalább négy hosztot használni, mert egyébként semmi értelme. Az is javaslat, hogy a DLR Control VM-eket, a velük kapcsolatban lévő ESG-kkel ne futtassuk azonos hoszton, szóval itt azért exponenciálisan nő a hosztok minimális száma.
