Az újabb és kevésbé újabb trendek szerint is adatközpontban tároljuk adatainkat és futtatjuk alkalmazásainkat. Ezek rendelkezésre állásánál kiemelten igaz, hogy egy adatközpont nem adatközpont. Ennek tükrében ez a bejegyzés az adatközpontok összekapcsolásáról szól.

Milyen célok vezérelhetnek minket adatközpontok összekapcsolásánál? Egyrészt alkalmazásaink transzparensen legyenek képesek egyik adatközpontból a másikba átmenni, másrészt tervezetten lehessen virtuális gépeket mozgatni az adatközpontok között (IP cím váltás nélkül) valamint clusterek széthúzása két adatközpont között is szerepelhetnek a céljaink között. Ezekből egyértelműen következik, hogy ISO OSI modell szerint Layer2 kommunikáció szükséges a két (vagy több) adatközpont között.

A Layer2 kommunikáció rögtön további igényeket, kérdéseket vet fel. Jó lenne, ha az adatközpontok egymástól izoláltan működnének, azaz egyik összeomlása ne húzza magával a másikat. A broadcast, unknown unicast és multicast (BUM) forgalom minimalizálása érdekében a klasszikus MAC cím tanulást át kell helyezni a vezérlési síkba. Az adatközpontok között redundáns, nyomvonal független és gyors konvergenciájú útvonalak biztosítsák a magasabb rendelkezésre állást. Az adatközpontok közötti forgalom (Kelet-Nyugat) optimalizálása is kihívások elé állítják a tervezőket.

Ezeknek a szempontoknak a figyelembevételével nézzük meg, hogy milyen eszközeink, lehetőségeink vannak az adatközpontok összekapcsolására.

Kézenfekvő megoldást nyújt, ha a klasszikus eszközünkkel, a Spanning-Tree Protocollal kötjük össze az adatközpontjainkat. Sajnos még ma is láthatunk ilyen megoldásokat. Mi a hátránya ennek a megoldásnak? Nem izolált a két adatközpont, a root-bridge vándorolhat a két központ között, ami nagyobb kieséseket, hálózati bizonytalanságot okozhat, a broadcast és az unknown unicast forgalom korlátozás nélkül terjedhet a két adatközpont között, ami szintén a teljesítmény rovására mehet.

Az adatközpontok összekapcsolásánál vegyük figyelembe, hogy milyen technológia felett kell megvalósítanunk az összeköttetést. Alapvetően három esetet különböztetünk meg:

• Ethernet alapú összeköttetés, tipikusan metro környezetben
• MPLS alapú összeköttetés, tipikusan szolgáltatói környezetben
• IP alapú összeköttetés, tipikusan vállalati környezetben

Metro környezetben a MultiChassis EtherChannel technológiát részesítjük előnyben, ebben az esetben külön kell figyelni arra, hogy a két STP domain elkülönüljön egymástól – BUM storm-controlt és BPDU filtereket be kell kapcsolni a két telephely között. Ezzel a megoldással még nem értük el a control-plane alapú MAC cím tanulást, de a két telephely már izoláltan működik egymáshoz képest. Másik hátránya ennek a megoldásnak, hogy nem skálázható hatékonyan több telephely esetén.

MPLS környezetben VPLS technológiát részesítjük előnyben. Maga a VPLS technológia nem biztosít megfelelő redundanciát a központok között, ezért két VPLS domaint kell használnunk a megfelelő rendelkezésre állás érdekében, viszont a másodlagos kapcsolatokat csak akkor lehet aktiválni, mikor az elsődlegesek nem működnek, különben Layer2 hurok alakulhat ki. A megfelelő szemaforokat ebben az esetben EEM (Embedded Event Manager) scriptekkel lehet biztosítani, így viszont már kellően bonyolult rendszert kapunk.

IP kapcsolat esetén több eszközzel is élhetünk adatközpontok összekapcsolásakor, egyrészt a vállalati környezetben elterjedt OTV (Overlay Transport Virtualization) biztosíthat megfelelő összeköttetést, másrészt a szolgáltatói adatközpontokban manapság elterjedőben levő VxLAN technológia.

OTV technológia esetén a fenti követelmények közül mindegyik teljesül, elkülönül egymástól a két adatközpont, control-plane alapú MAC cím tanulás is megoldott – jelen esetben az IS-IS biztosítja a MAC címek hirdetését, visszavonását az adatközpontok között. Unicast/multicast képes IP hálózatokon is képes funkcionálni, és különösebb nehézségek nélkül alakítható ki redundáns működés, amelyen a terhelés elosztás is hatékonyan működik. A technológia legfőbb korlátját a control-plane „okozza”, hiszen az IS-IS nincs arra felkészítve, hogy több tízezer vagy százezer mac címet kezeljen. Ez a korlát kis hazánkban valószínűleg nem fog sok helyen igazi problémát okozni.

A másik, mostanában igen dinamikusan elterjedőben levő technológia a VxLAN. A VxLANt önmagában nem adatközpontok összekapcsolására találták ki, hanem egyrészt a 4k VLAN korlát, másrészt a Spanning Tree Protocol megszűntetése volt a célja. A klasszikus dot1q enkapszulált keretet a VxLAN egy 50byte-s fejrésszel egészíti ki, amelyben IP/UDP fejrész mellett egy 8byte-s VxLAN fejrész is található. A VxLAN fejrészben a 24 bites VNI azonosító teszi lehetővé a 16M VLAN használatát egy adatközpontban. A VxLAN technológiának nincs szabványos vezérlési síkja, több lehetőség közül lehet választani. A VxLAN technológia hálózattal szemben támasztott követelménye mindössze az IP elérhetőség és a multicast megfelelő működése. Jelen bejegyzésnek nem célja a VxLAN technológia részletes taglalása, így csak röviden megjegyezzük, hogy több változatban is lehet használni adatközpontok összekötésére: „stretched fabric” módban a két adatközpontban ugyanaz a control-plane, ugyanaz az IGP is, ebben az esetben nem valósul meg control-plane szintű izoláció a két (vagy több) adatközpont között. Multi-pod esetben végponttól végpontig terjed a VNI, de az adatközpontokban saját IGP és iBGP van saját AS számmal, és az adatközpontok eBGP-vel kommunikálnak egymással, míg Multi-Fabric esetben az adatközpontok között már teljes az izoláció, az adatközpontok közötti Layer2 kapcsolatot OTV-vel valósítjuk meg.

Az itt felsorolt technológiák közül szinte mindegyiket láthatjuk manapság adatközpontok összekötése esetén, legtöbbször a rendelkezésre álló eszközpark, költségvetés valamint az adatközpontok közötti távolság határozza meg, hogy melyiket használjuk.