SDN VMware NSX alapokon - Bevezető

SDN VMware NSX alapokon - Bevezető

Nincs divatosabb – és őszintén szólva néha zavarba ejtőbb – felirat hímezve a napjainkban létrejövő adatközpontok tervezői és kivitelezői csapatainak zászlajára, mint az „SDDC”, azaz a Szoftveresen Definiált Adatközpont”. Mit jelent ez?

Első lépésként szoftveresen definiáljuk virtuális gépekként kiszolgálóinkat, majd – és ez bár első olvasásra hajmeresztőnek tűnhet – köszönjük, de nem kérünk a tradicionális adattár megoldásokból, hiszen az így SDS, azaz szoftveresen definiált adattár lesz. Innen nincs megállás, egyre inkább érdektelenné válunk a rack-be szerelt hálózati eszközök csodaképességeivel szemben is, hiszen ott van nekünk az SDN, azaz a szoftveresen definiált hálózatkialakítás. Foglalkozzunk egy kicsit ez utóbbival, tekintsük át nagyvonalakban, hogy mit nyújt a VMware SDN megoldása, az NSX!

Mind a gyakorlatban, mind pedig a tanfolyamok során gyakran tapasztalom, hogy a hálózati virtualizációval kapcsolatos alapfogalmakat nem árt tisztázni.

Virtuális hálózatokkal már az „alap” vSphere szolgáltatások között is találkozhatunk, hiszen ott a „sima” virtuális switch, a haladóbbaknak pedig sokkal fejlettebb tulajdonságcsomagot kínál a distributed virtual switch verzió. Mindkét megoldás tökéletes a maga helyén és szerepében a hypervisorok és a virtuális gépek hálózatba kapcsolására, de itt rögtön jön egy kis bökkenő: bár a velük kialakított hálózat virtuális, nem képesek másra, mint az adatközpont fizikai switch-eiben megvalósított valós vagy virtuális (VLAN) hálózatokhoz kapcsolódni, és a fent említett virtuális gépek és a VMkernel hálózati igényeit kielégíteni, úgy, hogy a hálózatot nem mi, hanem „a hálózatosok” konfigurálják. Mi a beállításainkkal azonban tulajdonképpen lekövetjük a fizikai hálózat adta lehetőségeket.

Mit jelent ez a gyakorlatban?

Ha VLAN kell, akkor szólunk a Network Adminnak, mire ő, nagy kegyelmében, készít nekünk néhányat. Persze nem azonnal! A Hálózatügyi Hivatal törvényben meghatározott válaszideje 8-15 nap ugyanis. Ugye ismerős?

Ha routing-ra van szükségünk, akkor szelíden könyörgünk, a NAT mielőbbi megvalósítása érdekében fenyegetőzünk, egy VPN kiszolgálóért a megvesztegetéstől sem riadunk vissza, egy load balancer beállításért pedig reflexből hívjuk fel ukrán ismerősünk titkos számát, hogy győzze meg (no persze szelíden!) a network team vezetőjét még ma este az irodaház parkolójában arról, hogy ezt bizony be kellene konfigurálni, méghozzá gyorsan.

Ezek alapján ezen írás jelen pillanatban két irányba is elindulhatna:

  1. Hogyan legyünk agresszív, félelmet keltő, tehát sikeres adatközpont üzemeltetők?
  2. Hogyan vehetjük saját kezünkbe az irányítást?

Bár személyesen hajlanék az első pontban részletezhető megoldásra, itt és most hadd javasoljam a 2. pont tárgyalását.

Mit akarunk elérni?

Tulajdonképpen azt, hogy a fent felvázolt problémáink eltűnjenek (és ha lehet, gyorsan és egy csapásra). Rendben, de hogyan?

Logikai Switching:

Az NSX használatával nem lesz gondunk a virtualizációban fellépő szeparált hálózatok iránti igényt kiszolgáló VLAN-okra, elég egy nagy sebességű Transport Network, ez lehet egy VLAN, vagy akár egy komplett transzparens fizikai switch. Ebben VXLAN (vagy az újabb NSX-T esetén GENEVE) technológiával gyakorlatilag tetszőleges számú hálózatot (Logikai Switch-et) alakíthatunk ki a hypervisoba integrált kernel modulokkal. Magunk között horizontális hálózatoknak is hívjuk ezeket, hiába, minden szubkultúrának megvan a maga szlengje ugyebár.

És így nem hívjuk fel a Network Admint egy-egy új VLAN miatt, ennek ő is örül, nekünk is könnyebb.

Elosztott Logikai Routing (DLR):

A virtuális gépek, gépcsoportok hálózati kommunikációs igényei útválasztást, routing beállításokat tesznek szükségessé. Köszönjük szépen, de nem a fizikai hálózatban, hanem a virtualizációban, ráadásul a hypervisor-okban elhelyezett kernel módú routerekkel oldjuk meg a horizontális hálózatok közti kapcsolatokat. Statikus vagy dinamikus bejegyzések (OSPF, BGP) kerüljenek a táblákba? Tessék választani igény szerint! Magunkban örvendezünk, hogy az így megvalósított routing a hasznos kommunikációt nem „járatja meg” vertikálisan, azaz az adatközpont igazi routerein keresztül. Ennek igazi előnye a sebesség és a teljesítmény.

A Network Admin összeráncolt szemöldökkel néz, majd legyint: áh, a véemveresek majd rájönnek, hogy nem is ez az Egy Igaz Út és egymás között nevetgélnek rajtunk.

Elosztott tűzfal és mikroszegmentáció:

A világ tele van gonoszokkal, sőt, rajtunk kívül mindenki - mindenki, kivétel nélkül - kiberbűnöző. Ezzel megalapoztuk a tűzfal szükségességét, amit több helyen is megvalósíthatnánk: a virtuális gépek operációs rendszereiben éppúgy, mint a fizikai hálózat igazi, nagy tűzfal eszközein. A baj csak az, hogy a virtualizáció felügyeleti lehetőségei ezekre nem terjednek ki. Akkor viszont mi lenne, ha a tűzfal szintén a hypervisor kernelben, közvetlenül a virtuális gépek hálózati kapcsolatain működne? Jó ötlet, legyen így! Nem lenne jobb, ha mindezt házirend alapon irányítanánk, amelyben feltételként számtalan opcióból választhatnánk azon információk közül, amik a virtualizációban eleve rendelkezésre állnak? Ha a feltételek függetlenek lehetnének a virtuális gépek helyétől, vagy esetleg pont azt figyelnék? Függhetnének a bejelentkezett felhasználótól is akár? L2-től L7-ig terjedő feltételeket állíthatnánk be? De, igen, ez a Distributed Firewall kernel modul, melynek felügyelete a mi kezünkben van.

A Network Admin mostantól sajnálja, de nem dohányzik, amikor cigit kérsz tőle. Pedig tudod, hogy van nála.

A Logikai hálózatok közvetlen kapcsolása a fizikai hálózattal (L2 Bridge):

Tegyük fel, hogy úgy hozza az élet, hogy nem egy pillanat alatt, hanem viszonylag hosszú idő áll rendelkezésedre fizikai gépeket virtuális gépekké konvertálni, vagy hagyományos VLAN alapú kapcsolatokkal rendelkező virtuális gépeket logikai hálózatokba illeszteni úgy, hogy a közvetlen elérhetőségeiket közben végig megtartják. Na, nost mi legyen? Semmi, nem nagy ügy, konfiguráljunk az NSX-ben L2 Bridge-et! A funkciót szintén kernel módú szoftverkomponens intézi, egy erre a feladatra kijelölt hypervisoron.

A Network Admin már nem köszön reggel a liftben.

Határponti szolgáltatások (EDGE Services):

Az eddigiek során a legfontosabb kernel módú szolgáltatásokat tekintettük át, most szót kell ejteni a hálózati környezet olyan közismert és gyakran használt megoldásairól is, melyek itt, az NSX-ben speciális célgépekben, ún. Edge Services Gateway Appliance-ekben működnek: Határponti tűzfal, DHCP kiszolgáló, VPN szolgáltatás, Load Balancing, NAT. Az Edge Services Gateway mindezen funkciókat redundanciával képes ellátni a feladathoz és annak erőforrás igényéhez méretezve. Igény szerint mi állítjuk elő és konfiguráljuk az igényeinknek megfelelően. Feladatát célszerűen az adatközpont és a külvilág, valamint az adatközponti elhatárolt környezet (Tenant) és az adatközponti közös hálózat kapcsolásakor látja el.

Önálló szabály-alapú tűzfal, amelyre a házirendek is kiterjeszthetők, két irányú NAT, L4-7 Load Balancing, Site-to-site VPN, SSL Client VPN van bene? Van. OSPF és BGP routing protokollok redisztribúciós lehetőséggel? Hát persze! Hányat tetszik kérni? Itt lesz fogyasztva? Tessék!

Szomorú, de a Network Admin már nem dolgozik itt. Tegnap láttuk, ahogy karjaiban egy papírdobozzal – benne a kávésbögréje, egy félig fonnyadt virág és egy megfakult fénykép régi idők elfeledett csocsóbajnokságáról – kiballag a parkolóba az öreg, kopott barna Toyotához, beteszi a dobozt és elhajt vele. Pont, mint az amerikai filmekben. A sorompót a biztonsági őr nyitotta ki neki, mert már nem volt mágneskártyája…

A szerző megjegyzése

Nagyon nagy tisztelettel kérek elnézést a fentiekben többször emlegetett Network Admintól, főleg, ha bárki magára ismerne benne. Legfőképpen azért, mert nem tudtam legyűrni a belső kényszert, a kisördögöt, és felhasználtam becses személyét az írásban, amiért szégyellem is magam. Nagyon. Meg is követem ugyanakkor, hiszen itt ővele pimasz módon nagy igazságtalanság történt. Úgy tettünk, mintha nem lenne szükség az ő ismereteire és sokéves tapasztalatára, pedig a valóság az, hogy nagyon is szükségünk van rá és a tudására az SDN megoldások bevezetése során. Attól, hogy a kezünkbe kerül egy olyan felügyeleti konzol, amiben ténylegesen szoftveres alapon definiálhatunk hálózati konfigurációt, azért ne gondoljuk, hogy a hálózati fogalmak, terminológiák és szabályok megtanulását és begyakorlását ezzel meg tudjuk úszni...

Így végezetül, hiszen nem lenne kerek a sztori heppiend nélkül:

Ma visszahívtuk a Network Admint. A vezetőség rózsaszirmokból hintett utat rendelt számára a főbejárattól egészen az új, napfényes irodájáig egy neves catering cégtől. Jogosultságot konfiguráltunk számára az NSX felügyeleti konzolhoz, amit percek alatt átlátott. Hálásan isszuk minden szavát a megvalósítás és az üzemeltetés problémáinak átbeszélésekor. Gyakran kérdezi, hogy kérünk-e cigit. Tanulunk tőle. Ő is tőlünk. Egy csapat vagyunk.

Ha érdekelnek a (technikai) részletek, találkozzunk az NSX tanfolyamokon!

Székács András
senior VMware oktató, Training360
VMware Certified Instructor (VCI), VMware Certified Advanced Professional (VCAP)

  1. VMware NSX: Install, Manage, Configure v6.4
  2. VMware vSphere: Optimize and Scale v6.7

Vissza a hírekhez