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