Wirtualizacja domyślnej bramy w Hyper-V, cz. 1  

Tłumaczenie na podstawie Hyper-V Network Virtualization Gateway Architectural Guide : Michał Ledwoch

Opublikowano: 2013-03-01

Wstęp

Sieci klienckie wymagają w większości komunikacji wirtualnej sieci z siecią niezwirtualizowaną. W celu zapewnienia komunikacji należy wykorzystać domyślną bramę wirtualną pomiędzy dwiema sieciami. Wirtualizacja bramy domyślnej może być wykorzystywana w wielu scenariuszach sieciowych. Może być zbudowana na systemie Windows Server 2012, w którym zaimplementowany został przełącznik Top of Rack (TOR) bądź jako samodzielne urządzenie w sieci. W niniejszym artykule zaprezentowana zostanie wirtualizacja bramy domyślnej w następujących scenariuszach:

• chmury prywatnej jako funkcja routingu,
• chmury hybrydowej jako funkcji VPN,
• Load Balancer – wykorzystywanie wirtualizacji bramy do równoważenia obciążenia.

Chmura prywatna jako funkcja routingu

Czasami zdarza się tak, że duże przedsiębiorstwa z różnych przyczyn nie mogą udostępnić swoich usług i danych w chmurze publicznej. Mimo to, chcą korzystać z technologii chmur oraz wirtualizacji sieci poprzez konsolidację swoich zasobów danych w chmurze prywatnej. Podczas wdrażania chmury prywatnej w korporacjach rzadko spotykany jest problem dotyczący adresacji IP, ponieważ sieci firm korporacyjnych posiadają duże przestrzenie adresowe (np.10.xx.xx.xx/8).

Rys. 1. Rozmieszczenie chmury prywatnej.

Na powyższym rysunku przedstawiono klienta, który w wirtualnych podsieciach wykorzystuje adresację 10.229.x, podczas gdy w sieci Coprnet, która nie jest zwirtualizowana, również wykorzystywana jest adresacja 10.229.1. W tym przypadku adresy PA podsieci wirtualnych znajdują się w centrum danych, które posiadają adresację 10.60.x. Wdrożenie centrum danych pozwala na wykorzystanie wirtualizacji sieci w celu zapewnienia elastyczności wirtualnych maszyn dzięki użyciu Live Migration w skonsolidowanym centrum danych. Takie rozwiązanie zwiększa wydajność centrum danych poprzez obniżenie kosztów operacyjnych (OPEX) oraz nakładów inwestycyjnych (CAPEX). Scenariusz prywatnej chmury, przedstawiony na Rys. 1., wymaga wykorzystania prywatnej wirtualnej bramy domyślnej lub włączenia funkcjonalności bramy w istniejącym urządzeniu sieciowym. Celem wykorzystania wirtualizacji bramy domyślnej jest zapewnienie routingu pomiędzy adresacją sieci fizycznej oraz sieci wirtualnych.

Chmury hybrydowa jako funkcja VPN

Do głównych zalet wirtualizatora sieci Hyper-V należy możliwość bezproblemowego rozszerzania lokalnych centrów danych do centrum danych w chmurze, wykorzystującego system Windows Serwer 2012. Takie rozszerzenie tworzy model hybrydowy chmury, zaprezentowany na Rys. 2.

Rys. 2. Rozmieszczenie chmury hybrydowej.

W powyższym scenariuszu wewnętrzny serwer WWW zostanie przeniesiony z sieci firmowej do centrum danych znajdujących się w chmurze dostawcy usług hostingowych. Wykorzystując technologię Bring Your Own, oferowaną przez usługodawcę usług hostingowych, firma nie musi zmieniać konfiguracji maszyny wirtualnej, pełniącej rolę serwera WWW, oraz innych punktów końcowych sieci, do których odwołuje się serwer WWW. Provider zapewnia bezpieczne łącze poprzez wykorzystanie urządzenia VPN Gateway. Aby nawiązać połączenie VPN z dostawcą usług hostingowych, administratorzy sieci firmowej muszą skonfigurować jedynie lokalny serwer VPN z odpowiednim adresem IP. Wirtualna maszyna działająca jako serwer WWW po przeniesieniu do chmury będzie nadal działała. Maszyna wirtualna, po przeniesieniu działająca jako serwer WWW, może współpracować z innymi serwerami znajdującymi się w sieci firmowej. W przykładzie na Rys. 2. serwery usług (Active Direcotry, DNS oraz SQL) pozostają nie zmienione. Używając sieciowego narzędzia diagnostycznego, jakim jest tracer, można zauważyć, że ruch sieciowy pomiędzy maszyną wirtualną, która pracuje w roli serwera WWW, a SQL prowadzony jest przez Internet, a nie lokalnie. Chmura hybrydowa, zaprezentowana na Rys. 2., wymaga urządzenia VPN, które wykorzystuje wirtualizację domyślnej bramy sieci. Urządzenie VPN wirtualizujące bramę domyślną musi współdziałać z centrum danych oprogramowania Orchestrator (np. System Center Virutal Machine Manager), aby uzyskać odpowiednie zasady wirtualizacji sieci.

Load Balancer – wykorzystywanie wirtualizacji bramy do równoważenia obciążenia

* *Równoważenie obciążenia zapewnia iluzję jednego adresu IP (wirtualny adres IP lub VIP) dla klientów żądających usługi. Usługa realizowana jest dla wielu różnych adresów IP (adres IP lub DIP). Tradycyjny load Balancer, mapujący ruch sieciowy z VIP do DIP, wykorzystuje Network Adress Translation (NAT). Load Balancer ponownie zapisuje docelowy adres IP (VIP), przychodzącego pakietu, z jednego z adresów IP (DIP), wykorzystującego usługę równoważenia obciążenia. W przypadku gdy równoważenie obciążenia działa jako dwukierunkowa translacja NAT, wówczas DIP wysyła pakiet powrotny do Load Balancera i to właśnie on przypisuje adres źródłowy (DIP) w VIP.  W tym przypadku klient wie o VIP, natomiast nie ma informacji o DIP. W kontekście wirtualizacji sieci równoważenie obciążenia emituje NVGRE w pakietach, aby dostarczyć pakiety do przeznaczonych wirtualnych maszyn. Poniższy rysunek prezentuje dwie firmy – Blue i Red, które posiadają swoje wirtualne maszyny w tym samym centrum danych, działając z wykorzystaniem systemu multi-tenant. Centrum danych zapewnia równoważenie obciążenia dla najemców. Firma Blue, posiada cztery maszyny wirtualne, oferujące usługę równoważenia obciążenia. Firma Red dysponuje dwiema maszynami wirtualnymi, oferującymi różne usługi, które chcą świadczyć usługi zrównoważenia obciążenia.

Rys. 3. Przykład Load Balancera wykorzystującego technologięMulti-tenant.

Rys. 3. przedstawia wirtualną topologię, gdzie publiczne routowalne adresy IP obciążane są symetrycznie do wielu wirtualnych maszyn. Na przykład, klienci z Internetu wysyłają pakiety do adresu IP (VIP) firmy Blue. Load balancer, na podstawie polityki wirtualizacji sieci, emituje NVGRE, aby dostarczyć pakiet do odpowiedniego hosta Hyper-V. Hosty hyper-V denkapsulują pakiet i następnie dostarczają go do odpowiedniej maszyny wirtualnej.

Rys. 4. Rozmieszczenie Load Balancera wykorzystującego technologię Multi-tenant.

Rys. 4. przedstawia możliwe rozmieszczenia wirtualnych maszyn, które zostały zaprezentowane na Rys. 3. W tym przypadku przestrzeń PA obciążenia wirtualnych maszyny posiada adres 192.168.6.x. Firma Blue posiada cztery wirtualne maszyny, które uruchomione są na trzech fizycznych hostach. Natomiast firma Red dysponuje dwiema wirtualnymi maszynami, działającymi na dwóch różnych komputerach. Obie firmy świadczą usługi hostingu WWW. Dostęp do tych usług realizowany jest poprzez stosowanie publicznego routowalnego VIP (VIP firmy niebieskiej oraz czerwonej). Load Balancer stosuje politykę wirtualizacji sieci, generując odpowiedni pakiet NVRGE. W przypadku kiedy połączenie jest inicjowane z ClientaIP, a VIP przesyłany do Blue, wykorzystywana jest usługa równoważenia obciążenia, a połączenie trafia do maszyny VM2, znajdującej się w sieci firmy Blue. Load Balancer podczas wysyłania pakietu do maszyny VM2, znajdującej się w sieci firmy Blue musi umieścić w pakiecie VSID z BlueVSID1, CA 10.1.6.21 oraz PA 192.168.6.4. Adresem PA Load Balancera jest 192.168.6.2, związku z tym Load Balancer generuje NVGRE w nagłówku pakietu.

W scenariuszu przedstawionym na Rys. 5. klienci dwóch firm – Red oraz Blue mają wielowarstwowe aplikacje, które wymagają wykorzystania równoważenia obciążenia. Z punktu widzenia maszyn wirtualnych komunikacja do następnych poziomów odbywa się poprzez VIP1. Na przykład, maszyny wirtualne kategorii B1 komunikują się z maszynami wirtualnymi z kategorii B2 poprzez Blue VIP1. Blue VIP1 posiada Blue adres IP CA, który ma również odpowiedni adres Pa do równoważenia obciążenia. Omawianą topologię zaprezentowano na Rys. 6.

Rys. 5. Wykorzystanie Load  Balancing pomiędzy dwoma poziomami.

Rys. 6. Load Balancing umieszczony w centrum danych.

Blue CA VIP oraz Red CA VIP używają do równoważenia obciążenia adresu PA 192.168.6.2. Load Balancer musi widzieć VSID w pakiecie NVGRE, a następnie ustalić, które mapowanie należy wykorzystać z VIP do DIP. Na przykład, niebieska maszyna wirtualna 11, wysyłając pakiet do niebieskiego CA VIP, powinna ustawić w nagłówku NVGRE adres źródłowy 192.168.6.7, adres docelowy 192.168.6.2. Pole GRE key należy ustawić na Blue VSID1. Natomiast w polu Inner destination IP trzeba wstawić adres Blue CA VIP oraz resztę pół z oryginalnego pakietu. Polityka Load Balancingu musi odpowiadać za oba adresy – VSID oraz VIP, ponieważ adresy VIP muszą być unikatowe.