Z pewnych względów jednak wirtualne maszyny zostały pogrupowane na wiele segmentów warstwy drugiej, z których każdy zawierał sieć VLAN i był reprezentowany przez oddzielną grupę wirtualnych portów w vSphere (w tym przypadku wykorzystywano przełączniki wirtualne Cisco Nexus 1000V). SRM traktuje odrębnie prawdziwe site recovery od testowego, pozwalając administratorowi na przeprowadzenie testu bez przerywania trwającej replikacji SAN i pozwala także na wybranie osobnych wirtualnych sieci do wykorzystania. Dzięki tej funkcjonalności można było stworzyć zestaw "cień" wirtualnych sieci, w których wirtualne maszyny mogły wystartować podczas testu, podczas gdy rzeczywiste wirtualne maszyny kontynuowały pracę w oryginalnych sieciach.

Niestety, udostępnianie takiego zduplikowanego zestawu wirtualnych sieci przy jednoczesnym umożliwieniu wszystkim odzyskanym maszynom komunikacji ze sobą bez zmian w wyłączanej sieci - okazało się niełatwym zadaniem. Omówmy trzy możliwe rozwiązania tego problemu.

Zobacz również:

• 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT

Rozwiązanie 1: VLAN i VRF

W pierwszym bierzemy pod uwagę budowę "cienia" zestawu VLAN-ów, które zduplikują istniejące produkcyjne VLAN-y. Konfiguracja grup portów wirtualnych opartych na tych VLAN-ach pozwoli wirtualnym maszynom działającym na innych elementach drugiego klastra wirtualizacyjnego na połączenia ze sobą niezależnie, czy zostały uruchomione na tym samym hoście. Minus jest taki, że wydzielony zestaw VLAN-ów i przypisanych konfiguracji w wirtualnym środowisku będzie musiał być dodatkowo zarządzany - oznacza to dodatkową pracę administracyjnę, choć nie aż tak pracochłonną.

Dodatkowo, proste tworzenie osobnego zestawu VLAN-ów (L2) nie pozwoli wirtualnym maszynom w jednym VLAN na połączenie z maszynami w innym. Do tego potrzebny jest routing (L3). Na szczęście przełączniki rdzeniowe w teście obsługiwały tworzenie VRF (Virtual Routing and Forwarding). Poprzez konfigurację nowego VRF możemy podzielić podzbiór rdzeniowych interfejsów L3 VLAN na "partycjonowany" router z jego własną tablicą routingu. Pozwoli to identycznie adresowanym interfejsom na istnienie zarówno w środowisku testowym, jak i produkcyjnym bez wzajemnej widoczności i konfliktów.

Takie rozwiązanie niewątpliwie będzie działać, ale wymaga wprowadzenia sporych komplikacji do sieci: definicji VLAN-ów w drugim centrum danych oraz w rdzeniu sieci, gdzie także potrzebna będzie dodatkowa konfiguracja routingu. Wydaje się, że musi być prostsze rozwiązanie.

Rozwiązanie 2: VXLAN-y i wirtualny router

VXLAN powstał, aby uporać się z wieloma problemami ze skalowalnością i provisioningiem, które mogą nas spotkać w dużych infrastrukturach wirtualizacyjnych, np. w sytuacji, gdy wymagane jest stały provisioning nowych VLAN-ów zarówno w warstwie fizycznej, jak i wirtualnej do obsługi izolowanych sieci klientów. Protokół jest także receptą na wyczerpywanie się dostępnych identyfikatorów VLAN (12 bitów - 4096).

VXLAN rozwiązuje te problemy poprzez tunelowanie ruchu L2 między hostami wirtualizacyjnymi w pakietach warstwy L3 - oznacza to tworzenie zestawu kompletnie odizolowanych segmentów sieci, które są widoczne tylko w środowisku zwirtualizowanym, wymagającym niewiele lub wcale czasu na konfigurację. Dodatkowo VXLAN pozwala na wykorzystanie ponad 16 mln kombinacji (24 bity) identyfikatorów VNI (Virtual Network ID) - oznacza to miliony zamiast tysięcy możliwych segmentów sieci.

O ile tak duża liczba sieci może nie mieć obecnie dużego praktycznego znaczenia, o tyle wykorzystanie VXLAN zamiast VLAN powinno praktycznie wyeliminować konieczność zmian w konfiguracji fizycznych urządzeń sieciowych i powinno być łatwe w rozszerzeniu - to spełnia nasze wymagania.