Cloud infrastruktúra skálázhatósága – VXLAN dióhéjban

Az augusztus végi VMworld konferencián a VMware és a Cisco bejelentette, hogy az Arista, Broadcom, Citrix, és Red Hat szakembereivel közösen (IETF munkacsoport keretein belül) egy új fejlesztésen dolgoznak, mely fejlesztés eredménye megoldást jelenthet a “cloud” infrastruktúra egyes skálázhatósági problémáira.

Mi az a “cloud” infrastruktúra?

A “cloud” infrastruktúra – egyszerűen definiálva – nem más, mint szolgáltatásként igénybe vehető infrastruktúra, nevezetesen Infrastructure as a Service (továbbiakban IaaS).(Cloud computing definíciója bővebben)

Mint minden szolgáltatásnak az IaaS-nek is két szereplője van, a szolgáltató (cloud provider) és a felhasználó(k) (tenant, multi-tenant). A szolgáltató birtokolja, üzemelteti és fejleszti az infrastruktúrát és jól felfogott érdeke, hogy ezen infrastruktúrán minél több felhasználó igényét ki tudja szolgálni, oly módon, hogy az infrastruktúrát alkotó valamennyi eszköz, erőforrás közös felhasználású legyen.
A felhasználó beruházásmentes, mindkét irányban dinamikusan skálázható infrastruktúrát szeretne, melyben adatait és alkalmazásait más felhasználó adataitól és alkalmazásaitól teljesen szeparált módon, biztonságban tudhatja.

A közös  infrastruktúrán megvalósítandó logikai szeparációra technológiai szinten most is rendelkezésre állnak megoldások, azonban egyesek skálázhatósági szempontból szűk keresztmetszetet jelenthetnek.
Nézzük pl. a Layer 2-es szinten való szeparációért felelős IEEE 802.1Q VLAN (Virtual Local Area Network) gyenge pontját.
A  VLAN azonosítók tárolása 12 bit-en történik, ami ugye 4096 különböző lehetőséget jelent. Ezek egy része a szolgáltatói architektúrában szükséges szegmentáció kialakítását (pl. Front-End, Back-End, Management stb.), más része a cloud infrastruktúra eléréséhez szükséges külső kapcsolatok biztosítását, a maradék pedig a felhasználók szegmentációs igényeit szolgálja. Ha felhasználónként csak 10 VLAN-nal számolunk, mely nem egy elrugaszkodott érték (pl. 3 rétegű alkalmazás architektúra, DMZ-k stb.), 400 felhasználó már súrolni fogja a logikai szegmentáció technológiai korlátját.       

Mi is az a VXLAN (Virtual eXtensilbe LAN)?

L2-es szegmentációt biztosító technológia, mely:

  • az azonosítók 24 bit-en való tárolása következtében a VLAN-hoz képest lényegesen nagyobb skálázhatóságot biztosít (akár 16 777 216 különböző azonosító)
  • az alkalmazott “MAC-in-UDP” enkapszuláció segítségével lehetővé teszi a L2-es tartományok kiterjesztését IP hálózaton keresztül
  • alkalmazható akár virtuális gép (VM) migrációra két virtuális adatközpont kötött hagyományos L2-es kapcsolat hiányában (bár erre a célra megfelelőbb megoldást biztosít az OTV (Overlay Transport Virtualization) vagy a LISP)
  • a L2-es “unknown unicast”, “broadcast” és “multicast” forgalmat IP “multicast” segítségével juttatja el a távoli virtualizációs rendszeren (hypervisor) lévő virtuális gépekhez

Meglátások:

A VXLAN hozzáadott értéke a “cloud” infrastruktúrák L2-es szegmentálhatósági skálázhatóságában nem vitatható, ugyanakkor a felhasználhatósága jelenleg még igencsak limitált körülmények között, kizárólag a virtuális infrastruktúra kereten belül valósítható meg, hiszen ahhoz, hogy egy VXLAN szegmensen lévő virtuális gép kommunikálni tudjon a “külvilággal” (fizikai infrastruktúra), úgynevezett VTEP (VXLAN Tunnel End Point) “gateway” támogatást biztosító komponensre van szükség, mely jelenleg csak a VMware vShield Edge és a Cisco Nexus 1000V termékekben érhető el. Amennyiben két VXLAN szegmens között valamilyen L3-as funkciót (pl. router, tűzfal stb.)  szeretnénk megvalósítani, jelenleg az adott L3-as funkcionalitásnak megfelelő virtuális gépen futó megoldást kell választanunk, mely nem biztos, hogy pl. performancia szempontból megfelel az elvárásainknak. Az igazi “nagyüzemi” felhasználáshoz feltétlenül szükség lesz a VXLAN-t támogató fizikai hálózati eszközök (adatközponti switchek, routerek, tűzfalak, terhelés elosztók stb.) megjelenésére.

Ellentétben az OTV-vel és LISP-pel, a VXLAN nem alkalmaz “control plane” megoldást, ezért a MAC címek tanulása a VLAN-nál megszokott módon, “unknown unicast flooding” segítségével valósul meg, mely kikerülve a helyi VXLAN szegmensből IP “multicast” segítségével jut el a távoli VXLAN szegmensekhez. Ez a fajta L2 “broadcast”- és “multicast”-tot IP “multicast”-tá alakító üzemmód hordoz némi kockázatot, hiszen egy esetleges helyi “broadcast” vihar IP “multicast” viharrá alakul át, így terjedve át a távoli virtualizációs rendszerbe, adatközpontba.  

Bárt az alkalmazott “MAC-in-UDP” enkapszuláció és a “muticast” képes IP hálózat lehetővé teszi a VM mobilitás biztosítását, akár az elsődleges és a DR adatközpontok között is, a fenti kockázat miatt, valamint a két adatközpont közötti szuboptimális routing (oda-vissza) elkerülése miatt  nem ajánlatos alkalmazása erre a célra.

Bővebben:

Cimkék: , ,

Hozzászólás írása

Hiba az űrlap kitöltése során!

* A csillaggal jelölt mezők kitöltése kötelező

*
*
*
*