vNetwork Distributed Switch
Múlt heti találkozonkon elhangzottakat szeretném most summázni:
- vDS működése
- miben egyedi a vDS
- Mire használjunk Private VLAN-okat
- milyen buktatók lehetnek
A vDS alapvetően két fronton működik: a
- vCenter oldali rész (Control plane) felelős a vDS konfigurációjáért, itt tudunk változtatni a vswitch-portcsoportok beállításain.
- a hálózati forgalom természetesen továbbra is az egyes ESX kiszolgálókon megy végbe (IO plane). A két felületet legegyszerűbb úgy tekinteni, mintha a vCenter oldali rész a sablon, amely alapján az egyes ESX-ek elkészítik a saját rejtett vswitch-eiket.
Redundancia
A hagyományos vSwith-ek esetén a redundanciát egyszerűen a vswitch-hez fűzött NIC-ek szintjén valósítottuk meg. Ha egy vSwitch-hez bekötöttünk kettő vagy ennél töb NIC-ek, akkor by-default redundáns hálózati konfigurációt hoztunk létre, minden további kattintgatás nélkül is akár.
vDS esetében egy kicsit máshogy működik ez. A vDS-hez nem tudunk direkt módon hálózati kártyákat fűzni, ezeket egy köztes elemhez kell ugyanis rendelnünk: az UPLINK-ekhez. Azaz a vDS-en először definiálnunk kell, hogy az adot vDS switch hány UPLINK porton működjön (az uplink lesz a fizikai világgal való összeköttetés felülete). Ezután pedig a kialakított UPLINK-ekhez fogjuk tudni bekötni a fizikai hálózati adaptereinket egy egyszerű szabály szerint: egy UPLINK-hez, egy ESX-ből csak egyetlen egy NIC-kel csatlakozhatunk.
Hol itt a redundancia akkor? A dolog rém egyszerű: a vDS esetén az uplink-ek számának növelésével fogjuk tudni létrehozni a szükséges szintű redundanciát. Fontos továbbá, hogy a redundancia beállításokat immár nem magán a switch-en adjuk meg, hanem az egyes portcsoportok szintjén. Ahogy a kép is mutatja a két portcsoportunk esetén (kék-piros) határoztuk meg a redundanciát a két uplink felé (eltérő referenciával).
vDS egyedi funkciók
Miben több a VDS, mint a hagyományos vSwitch rendszer (csak felsorolás szintjén)?
- GUI-n állítható Jumbo frame és CDP funkciók
- Port Binding szabályozás (kikapcsolt VM-ek ne foglaljanak portot)
- VLAN trunking (megadhatunk tetszőlegesen több VLAN-t is egy-egy portcsoporthoz – nem kell már a mágikus 4095-re hagyatkozni)
- Network VMotion – hálózati statisztikák követik a VM-ek vmotion után is
- Port szintű forgalom blokkolás
- befelé irányúló sávszélesség szabályozás
- Port szintű policy konfiguráció felülbírálat
Private VLAN
Maga a private vlan funkció egyszerre kényelmi tényező és hatékonyabb biztonsági izoláció. Mi is a baj a sima VLAN-okkal? Igazából semmi, de néhány esetben VLAN izoláció nagyon macerás lehet (pl. azonos subnetben van mindenünk, de mégis szeretnénk izolálni).
A Private VLAN gyakorlatilag egy, már meglévő VLAN-t képes zónákra bontani. Az eredeti vlan-unk továbbra is megvan PRIMARY Vlan néven (ez látszódik a fizikai hálózat felé is), azonban ez alá három opcionális SECONDARY vlan-t is elhelyezhetünk, mind egyedi forgalmi szabályozással.
A másodlagos zónáknak három fajtája van:
- isolated
- community
- promiscuous
Az egyes zónák funkciói gyakorlatilag abban merülnek ki, hogy milyen módon láthatnak egymásba, honnan-hová küldhetünk adatot.
- A promiscuous belát a másik kettőbe.
- A Community belát a Promiscuous-ba és ebben a zónán belüli host-ok egymást is látják.
- Az Islodated zóna belát a promiscuous-be, de a zónán belüli host-ok nem látják egymást.
Hol használjunk Private VLAN-okat?
- Backup hálózatok esetén érdemes megfontolni az izolált zónák használatát az esetleges virustámadások backup hálózaton belüli terjedése meggátolása végett (is)
- DMZ hálózatok VLAN-on belüli izolációjához a legegyszerűbb választás az Isolated zóna használata: a DMZ-s host-ok nem láthatják egymást, így elejét vehetjük egy több lépcsős támadásnak, amely egy kevésbé védett DMZ-s host-ről történhetne a többi szerver felé.
Buktatók – Tervezési szempontok
- Mi történik a vDS-sel ha a vCenter kiesett, átmenetileg nem érhető el?
- a VM-ek nem érintettek, hálózati forgalom továbbra is biztosított
- nem lehetséges vDS beállítás módosítás
- nem lehetséges meglévő vagy új VM-ek vDS portcsoportra állítása!
- Mi történik a vCenter visszaállíthatatlanul elveszett?
Itt alapvető “gond”, hogy a meglévő VM-eket, amelyek jelenleg is vDS portcsoporton ülnek nem engedik törölni a vDS switch-et az ESX szerverekről. Emiatt vagy kialakítunk egy átmeneti lokális standard vSwitch-et egyesével minden ESX-en és ide áttereljük a VM-eket, VAGY telepítünk egy új vCenter-t, itt kialakítunk egy új vDS-t és ráállítjuk az ESX kiszolgálókat, majd erre áttesszük a VM-eket.
- az ESX-ekhez direkt módon kell csatlakozni vSphere Client-tel
- törölni kell a vDS switch-et egyesével az ESX-ről
- vCenter VM számára is vDS portcsoport ad hálózatot
- nem támogatott megoldás!
- tervezzünk vele a hálózatok kapcsán
- Service Console-VMK management hálózat és a vDS
- ezen hálózati rétegeket is kialakíthatjuk a központi switch-en
- azonban jó ha van tartalék – hibás konfiguráció esetén management hálózat nélkül maradhatnak az ESX host-ok (pl. jumbo frame bekapcsolás ezt nem támogató switch-ek esetén)
- ezért: vagy ne vigyük fel a vDS-be ezeket a hálózatokat
- vagy hibrid megoldáskén legyen lokális változata is ezen funkcióknak
További információk:
Private VLAN-ok tekintetében egy holland vmware oktató rakott össze egy 40 perces videót: http://www.ntpro.nl/blog/archives/1465-Online-Training-Configure-Private-VLAN-IDs.html





Ismét egy remek cikk, köszönjük!
Egy kérdés: valamilyen úton-módon meg lehet valósítani vDS-el (vagy akár sima vs-el) IP securityt? Értem ez alatt azt, hogy adott vm adott interfacen (vDS porton) csak megadott forrás IP-vel tudjon forgalmazni, megelőzvén, hogy beállíthassa magának a szomszéd vagy netán a gw IP-jét. Vagy ehhez már a nexus modul kéne?
Köszönjük!
Ilyen fajta lehetőség egyelőre még nincs a rendszerben. Amivel lehet indulni az a vShield Zones, ami része egyébként a vSphere-nek. Ez egy tűzfal megoldás valójában és nem port szintű IP sec, amire kérdeztél. Azonban hasonló eredményeket el lehet vele érni.
Röviden: vShield-en meghatározott tűzfal szabályok védik-korlátozzák a VM-eket. Az okosság ebben kettős:
-VMotion-től független – az adott VM, akkor is korlátozva van ha másik ESX-re költözik
-Nincs külső FW hardver igény – minden a dobozon belül van megoldva.
Egy újabb kérdés, remélem olvassa valaki, kicsit régi a post, a legfrissebbhez írva meg offtopic lenne
Szóval sikeresen migráltam egy datacenterben mindent VDS-re (kivéve a management networkot, az szépen elvan a vswitch0-kon, ott amúgy is működik default). Minden szép és jó volt, egészen addig, amíg bele nem futottam abba, hogy a régi vm létrehozó/regisztráló perl scriptjeim nem működnek. Pontosabban működnek, de a frissen beregisztrált VM hálózat nélkül marad. Utánanéztem kicsit a dolognak, próbáltam a vmx-be dvs specifikus paramétereket tenni hisz teljesen máshogy kell ezt csinálni mint sima vswitch esetén pl:
ethernet0.dvs.switchId = “e7……”
ethernet0.dvs.portgroupId = “dvportgroup-…”
ethernet0.dvs.portId = “…”
..de nem igazán érdekli a vcentert a dolog. Létrejön a vm, de a virtuális NIC nem kerül be a kívánt vds kívánt portjára (próbáltam állítgatni a port groupot, static/dynamic/ephemeral opciókkal, de semmi eredmény). Igazából ha egy sample vm-et létrehozok a VC GUI-n, majd berakom egy dvs portgroupba, kidobom az inventoryból, majd visszateszem, akkor ugyanez történik, tehát nem lesz csatlakoztatva a switchre a nic. Ez alapján ugye csak arról lehet szó, hogy a vmx file feldolgozásán kívül csinál még egy plusz dolgot a vcenter, aminek hatására az új vm-et “bepatcheli” a dvs-re. No, gondoltam sebaj, akkor nem .vmx file módosítgatásra van itt szükség, hanem perl SDK doksi olvasgatásra. Viszont egyáltalán nem találtam olyen lehetőséget amivel vds portokat (vm portokat, ez fontos) lehetne managelni cli-ből:(( Hosszas keresgélés és rengeteg olvasgatás után arra jutottam, hogy ezt nem tudja jelenleg a perl cli/sdk. Vmkernel interfacet hozzá tud adni a vds-hez, és ennyi, sima vm-et nem.
Van esetleg valami ötletetek hogy hogy lehet megoldani a problémát?
Az kimaradt még, hogy a probléma úgy is szépen megmutatkozik, hogy a vm “edit settings” ablakában ilyenkor (regisztráció scriptből, vagy remove from inventory/add inventory) nincs semmilyen network. Ha itt kézzel választok egyet, akkor természetesen a vcenter megcsinálja a vmdvsport összepárosítást, és minden működik. Na, erre szeretnék én valamilyen cli-s megoldást
Szia Csaba, én itt leszek egy kicsit “off”, mert sajnos nem tudok a témához (még) értelmesen hozzászólni. Egy dolog érdekelne: milyen típusú kapcsolat tartást szeretnél megvalósulni látni a hazai közösségen belül (pl. levelező lista, fórum, wiki) ?
Egyértelműen levelezőlista
A szakmai fórumok nagy része levelezőlistákon zajlik tapasztalataim szerint (linux listák, kisebb-nagyobb open es closed source projectek, stb stb..)
Ha kell segítek is szívesen, több egyesületnek is üzemeltetek listaszervereket, köztök olyat is, aminek 10 ezres nagyságrendű taglétszáma van. Megtiszteltetés lenne, természetesen ingyen és bérmentve
csaba,
van igeret fejlesztoktol (2-3 honapja), hogy belehegesztik a dvs-t is a cli-be.