Wirtualizacja i elastyczna infrastruktura sieciowa
- Paweł Szczepaniak,
-
- Matt Prigge,
- 19.12.2012, godz. 12:00
Obecne stadium rozwoju VXLAN jest dość wczesne, przez co protokół ten ma jeszcze pewne braki. Obecnie jedynymi stosami sieciowymi, które mogą aktywnie brać udział w tworzeniu sieci opartych na VXLAN są Cisco Nexus 1000V oraz Open Vswitch. Nie ma praktycznie żadnych fizycznych urządzeń sieciowych, które mogą pracować jako Virtual Tunnel Endpoint (VTEP). Jeśli będziemy chcieli wprowadzić routing L3, aby zapewnić komunikację między różnymi VXLAN-ami, trzeba zaprząc do tej pracy wirtualną maszynę.
Niestety, nie są dostępne również żadne wirtualne routery (wirtualne appliance), pozwalające natywnie na partycypację w VXLAN. Obecnie jedynym sposobem na umożliwienie wirtualnemu routerowi połączenia z różnymi VXLAN-ami jest podłączenie wirtualnych kart sieciowych NIC do appliance routera dla każdego z VXLAN-ów. To nie tylko kłopotliwe, ale może także mieć ograniczone zastosowanie z racji tego, że vSphere limituje obsługę wirtualnych kart sieciowych na wirtualną maszynę do 10. W skomplikowanym środowisku może to nie być wystarczające i trzeba będzie uruchamiać po kilka routerów appliance na osobnych wirtualnych maszynach.
Zobacz również:
Poza niewątpliwą korzyścią w postaci braku zmian w konfiguracji fizycznej sieci, obecnie wykorzystanie VXLAN w tym przypadku jest nieco problematyczne.
Rozwiązanie 3: VLAN-y i wirtualny router
Ostatnie podejście polegało w teście na stworzeniu zduplikowanego zestawu VLAN na fizycznych urządzeniach sieciowych i skonfigurowaniu wirtualnej sieci drugiego centrum danych do komunikacji z nimi. Zamiast tworzyć nowy VRF na przełącznikach rdzeniowych, do routingu VLAN wykorzystano router virtual appliance. W porównaniu z poprzednim rozwiązaniem różnica w tym przypadku jest taka, że router nie musi pracować jako punkt końcowy VXLAN.
Wykorzystanie protokołu VXLAN na platformie VMware
Kompromisowe, trzecie rozwiązanie nie jest wolne od wad, ale sam proces dojścia do niego wykazał ograniczenia nowej technologii, jaką jest VXLAN.
Pomimo pewnych problemów z wykorzystaniem VXLAN w ramach obecnej oferty produktowej, należy docenić jego potencjał. W implementacji Nexus 1000V Cisco wykorzystało połączenie API z vSwitchem, co pozwala zewnętrznym usługom na automatyczne tworzenie segmentów VXLAN. Obecnie taka możliwość jest wykorzystywana jedynie w połączeniu z VMware vShield Edge oraz vCloud Director do automatyzacji wdrażania instancji chmur publicznych i prywatnych. Pozostaje nam jedynie czekać, aż powstanie produkt, który wykorzysta tę możliwość do uruchomienia pełnego router virtual appliance i zintegrowania z Nexus 1000V czy innym programowym przełącznikiem. Wtedy rozwiązanie dynamicznego uruchamiania segmentów L2 i routingiem L3 będzie pełne.