Lab/Edu vSphere környezet NSX hálózati háttérrel – Ismertető
Ebben a sorozatban iránymutatást szeretnék adni arra, hogyan lehet egy meglévő vCenter-t és NSX-et kihasználó „full-nested” környezetet felépíteni. Megmutatom milyen komponensekre illetve beállításokra van szükség viszont nem térek ki pl az Active Directory és jumphost felépítésére, az NTP illetve DNS beállításaira. Viszont az utóbbi kettőről mindenképp gondoskodj: a jól működő névfeloldás és időszinkronizálás elengedhetetlen!
A végeredmény majd egy olyan környezet lesz amelyben:
- Tier-1 routerek-kel szeparálhatod a különböző célra épült Projekt-eket
- VLAN Trunk-re is lehetőség nyílik úgy, hogy a fizikai hálózaton nem kell módosítást végrehajtanod
- VyOS router-nek köszönhetően BGP peer-eket konfigurálhatsz és szimulálhatsz egy multi-site környezetet
Ezt követően, hogy mit hozol ki a megépített vSphere telepítésből már csak rajtad múlik; létrehozol vSAN Datastore cluster-eket, esetleg NSX adja majd a hálózatot netán Tanzu-t és vRA/O-t is elérhetővé tennéd? Szerintem ha kellő mennyiségű erőforással rendelkezel a nested ESXi host-ok futtatására – beleértve a háttértárat is -, akkor ezek mindegyikére lehetőséged lesz.
Tartalomjegyzék
Fontos!
Ahogy fentebb is említettem ez a leírás nem tér ki az AD, DNS, NTP, Jumphost telepítésére és beállítására, továbbá feltételezi, hogy NSX-ben már van egy konfigurált, általam csak Tenant-nak hívott Edge Cluster-ed a hozzá tartozó T0 és egy vagy több T1 router-ekkel valamint OSPF vagy BGP peering-el a fizikai hálózatod felé. Mivel a későbbiekben több komponensnek is szüksége lesz internet elérésre, ezért gondoskodj arról, hogy valamilyen úton-módon legyen kijutási pontod, akár egy proxy-n keresztül.
Általános design
A következő rajzon igyekeztem érthetően megmutatni, hogy mi lesz a végeredmény hálózat oldalról a meglévő NSX-ben.
Összefoglalva, hogy mi is látható a rajzon… Van egy T0 ami BGP-vel kapcsolódik a fizikai hálózathoz. A T0-hoz két T1 kapcsolódik, a G01 és a G02 végződésű. Ennek oka, hogy így szeretném szeparálni a különböző workload-okat, project-eket, értsd, a G01-hez kapcsolódó (bal) oldalon oktatási jellegű dolgokat szeretnék futtatni, míg a G02-höz kapcsolódó (jobb) oldalon akár egy másik kolléga kezdhet építkezésbe vagy egy konkrét gondhoz, upgrade-hez készíthetsz egy önálló környezetet. Értelemszerűen ez a két T1 továbbiakkal bővíthető amíg erőforrásügyileg bírják a fizikai szerverek.
A T1-ekhez tartozik egy-egy Segment, ők a 10.10.10.0/25 és 10.10.10.128/25 hálózatok. Mint láthatod T0 oldalon a BGP peering úgy lett beállítva, hogy csak és kizárólag ez a két hálózat kerül hirdetésre a fizikai oldal felé, semmi más. Ennek oka, hogy ez a két hálózat a „management”, azaz egy-egy jumphost-tal, azokra belépve tudod majd G01 és/vagy G02 oldalt elérni. Mivel egy T0 alá van kötve a két T1 ezért a két hálózat elérheti egymást, de ezt lehetőleg mellőzd vagy ZeroTrust megközelítéssel a distributed firewall segítségével tiltsd meg ezzel is elősegítve, hogy a különböző oldalak, projekt-ek ne zavarják egymást. Az említett két management hálózatról fogsz tudni elérni mindent, amit a későbbiekben felépítünk.
A T0-hoz direktben kapcsolódik a 172.16.10.0/28 Segment melynek ebben a design-ban az AD és NTP miatt van szerepe. Csak röviden megemlítve, az én design-omban itt található a rainpole.io root domain controller, míg a management hálózatokon van egy-egy child domain controller, a G01-ben az sa.rainpole.io míg a G02-ben az sb.rainpole.io. Lényegében ez a hálózat a megosztott erőforrások gyűjtőhelye, amit mindegyik T1-hez kapcsolt összes hálózat elérhet – értelemszerűen ZeroTrust segítségével ez szűkíthető.
Ezek lettek volna azok a Segment-ek, melyek valamelyik NSX gateway-hez kapcsolódnak, most pedig térjünk ki a maradék ötre (5) melyekről ugyanez nem mondható el. Ebből a 172.16.11.0/24 hálózatnak a szerepe a BGP peering. A két Edge Node (en01 és en05) egy-egy Service Interface-el kapcsolódik ehhez a Segment-hez, valamint majd a VyOS router-ek is két-két IP címet fognak innen kapni, az egyikkel majd a T0-val tartják a kapcsolatot, míg a másikkal egymással. Ennek oka, hogy Prefix List-tel szabályozni fogjuk, hogy melyik BGP partner mit fog megkapni és ezzel próbáljuk meg imitálni két külön adatközpontban lévő router kapcsolatát. És ha már VyOS… A megmaradt négy (4) Segment ennek a két VyOS router-nek egy-egy NIC-jéhez fog kapcsolódni és itt lesznek definiálva azok a VLAN-ok amelyeket a nested ESXi host-okon futó, nested vCenter-ben és nested NSX-ben fogunk majd használni.
VyOS design
A VyOS virtuális gépeknek négy NIC-jük lesz, egy a Management, egy a BGP kapcsolat miatt illetve kettő-kettő melyek bridge-el össze lesznek kötve. Miért? Mert így lehet a legegyszerűbben imitálni azt, hogy egy ESXi host két NIC-je hogyan csatlakozik a fizikai hálózathoz, hogy van két különálló switch-hez is kábelezve, hogy történik a load balance a kettő között és link failure esetén hogyan terelődik át a forgalom a megmaradtra. Tudom nem a legszebb megoldás, lehetne ezt szofisztikáltabban és egy valós enterprise környezetet jobban szimulálva is megcsinálni de az egyszerűséget szemelőt tartva született meg a döntés, hogy a Bridge a legalkalmasabb megoldás.
Mindegyik VyOS router-en tíz-tíz VLAN-t fogunk létrehozni. Mint láthatod ebből hatnak (6) szerepe is lesz míg a megmaradottakkal szabadon dolgozhatsz. Értelemszerűen, ha te nem szeretnél vSAN-t majd, akkor azt nem kell majd használnod, valamint ha nem akarsz NSX-et, akkor az Overlay Transport-ra sem lesz szükséged és használhatod másra.
