Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



04.01.2022

Dane klientów HPE przejęte w...

HPE poinformowało, że dane klientów zostały przejęte w wyniku naruszenia dotyczącego jego...
04.01.2022

Bezpieczny dostęp

Citrix rozszerza swoje rozwiązania z zakresu bezpiecznego dostępu.
04.01.2022

Ochrona pracy zdalnej

Fortinet przedstawił spójną koncepcję zabezpieczania środowiska IT w firmach, które...
04.01.2022

Rozwiązania dla Linuxa

Red Hat poinformował o udostępnieniu rozwiązania Red Hat Enterprise Linux 8.5.
04.01.2022

Usługi chmurowe

Strefa lokalna AWS w Polsce
04.01.2022

Nowy laptop należący do serii...

ASUS VivoBook Pro 16X to nowy laptop należący do popularnej serii VivoBook. Przeznaczony...
04.01.2022

Do fizycznej wirtualizacji...

QNAP zaprezentował urządzenie nowej generacji do wirtualizacji sieci – QuCPE-7012 –...
04.01.2022

Dla przemysłu

Transcend prezentuje bezpieczne dyski SSD zgodne ze standardem Opal SSC 2.0. Oba dyski...
04.01.2022

SI w monitoringu

Firma i-PRO, mająca swoje korzenie w Panasonic, wprowadziła do swojej serii S kamery typu...

Wirtualizacja sieci z Vmware NSX

Data publikacji: 26-06-2018 Autor: Michał Kaźmierczyk
RYS. 1. SCHEMAT PROPAGACJI...

Znamy już podstawowe założenia i idee sieci definiowanych programowo oraz podstawowe komponenty i zasadę działania jednego z flagowych produktów w tej dziedzinie technologii, czyli VMware NSX. W kolejnym artykule przedstawiamy zasady działania produktu w zakresie L2, procesie jego wdrożenia oraz pozostałych funkcjach, niezwiązanych z obsługą sieci L2.

W pierwszej części cyklu („IT Professional” 3/2018, s. 69) staraliśmy się wykazać, że zmieniające się oczekiwania biznesu, zwłaszcza dotyczące szybkości implementacji nowych systemów informatycznych i wprowadzania zmian w tych już istniejących, wymuszają wprowadzanie technologii opartych na automatyzacji. Dodatkowo niezwykle szybki wzrost chmury obliczeniowej, w której mamy do czynienia z niespotykaną wcześ­niej skalą przetwarzania, sprawia, że tradycyjne podejście do infrastruktury IT staje się powoli reliktem przeszłości. 

 
Jednym z rozwiązań pozwalających poradzić sobie z powstałymi problemami i sprostać oczekiwaniom, jest oparcie całej infrastruktury – od storage’u, poprzez CPU, RAM i urządzenia wejścia/wyjścia, aż po sieci – na oprogramowaniu, tworzącym ze znajdującego się „pod spodem” hardware’u jednolitą, w pełni konfigurowalną i zarządzaną za pomocą jednego interfejsu programowego platformę. Takie rozdzielenie sprzętu od pracujących na nim systemów operacyjnych czy aplikacji nazywane jest obecnie centrum danych definiowanym programowo, a jednym z jego komponentów są sieci definiowane programowo. 
 
> VMware NSX
 
W poprzedniej części opisaliśmy podstawowe założenia i komponenty systemu SDN ze stajni VMware będącego jednym z najpowszechniejszych produktów tego typu na rynku. Dowiedzieliśmy się, że do jego wdrożenia potrzebna jest wirtualizacja VMware (w momencie pisania tej części artykułu istnieją już produkcyjne rozwiązania NSX-T implementujące wirtualizację sieci niezależnie od środowiska) oraz następujące komponenty: NSX Manager, klaster NSX kontrolerów, hypervisory przygotowane do NSX, logiczne switche (LS) do obsługi ruchu L2 zastępujące tradycyjne VLAN-y.
 
Szczegółowo opisany został również przepływ pakietów pomiędzy dwoma wirtualnymi maszynami komunikującymi się w obrębie jednej podsieci IP wewnątrz LS-a. Z opisu można było dowiedzieć się, że za większość wewnętrznej komunikacji pomiędzy znanymi obiektami odpowiada klaster kontrolerów. 
 
Nie przedstawiliśmy jednak, co dzieje się w sytuacji, gdy kontroler nie potrafi odpowiedzieć lub też, gdy wirtualne maszyny przesyłają ruch niebędący ruchem unicast, tzw. multidestination.
 
> Metody replikacji ruchu BUM
 
Na początku zastanówmy się, z jakim ruchem mamy do czynienia. Potocznie określa się tego typu ruch jako BUM. To akronim pochodzący od pierwszych liter nazw trzech rodzajów ruchu:
 
  • Broadcast – to oczywiście ruch rozgłoszeniowy typu jeden do wszystkich – np. zapytania ARP czy NetBios;
  • Multicast – to ruch typu jeden do wielu odbiorców chcących ten ruch otrzymać, np. telewizja IP, rozgłoszenia w ramach OSPF itp.;
  • Unknown unicast – to natomiast szczególny przypadek, w którym na urządzeniu bądź oprogramowaniu sieciowym pojawia się ruch typu unicast, ale urządzenie nie wie, co z nim zrobić, czyli brak mu odpowiedniego wpisu w tablicy CAM. 
 
W części pierwszej wspominaliśmy, że hosty ESXi (VTEP-y) przesyłają do kontrolerów trzy typy raportów: VTEP, MAC i IP, oraz, że jeśli dwie maszyny chcą się ze sobą skomunikować, VTEP-y otrzymują od kontrolerów informację, na który VTEP docelowy przesłać enkapsulowany pakiet L2. 
 
Co dzieje się jednak, gdy VTEP otrzyma od wirtualnej maszyny ruch typu BUM i musi go rozesłać do wszystkich innych maszyn wirtualnych w obrębie źródłowego LS-a? Otóż NSX-y stosują w tym celu jedną z metod replikacji ruchu BUM. Jest ich trzy: unicast, multicast oraz hybrid.
 
> Metoda unicast  
 
Zaczniemy od metody unicast, gdyż w jej przypadku obsługa L2 2 NSX działa dokładnie tak, jak opisywaliśmy do tej pory. VTEP-y rozsyłają do kontrolerów VTEP raport, czyli informację o tym, który VTEP partycypuje w którym LS-ie. Następnie kontrolery rozsyłają tę informację na wszystkie inne partycypujące VTEP-y, tak że np. dla LS-a 5001 wszystkie VTEP-y, które mają uruchomioną w nim maszynę wirtualną, wiedzą o wszystkich innych tego typu VTEP-ach.
 
Załóżmy, że mamy cztery hypervisory – dwie pary, w których VTEP-y znajdują się w dwóch różnych podsieciach IP. W momencie gdy na VTEP-ie pojawia się pochodzący od wirtualnej maszyny ruch typu BUM (poza ARP, gdyż podlega ono supresji, jak opisano w części pierwszej), VTEP, bazując na otrzymanych od kontrolera VTEP raportach (tablicy wszystkich VTEP-ów partycypujących w danym LS-ie), rozsyła enkapsulowany w VXLAN ruch BUM unicastem do wszystkich VTEP-ów, które biorą udział w LS-ie źródłowym. Rozesłanie unicastem odbywa się jednak z pewnym zastrzeżeniem. W ramach swojej podsieci IP (podsieci VTEP-ów) ruch rozsyłany jest do każdego VTEP-a, natomiast do każdej innej podsieci strumień unicastowy płynie do jednego wybranego VTEP-a z flagą w protokole VXLAN replicate locally ustawioną na 1, tak aby VTEP ten, zwany w tym momencie UTEP-em, rozesłał ruch unicastem do każdego innego VTEP (partycypującego w danym LS-ie) w ramach swojej podsieci.
 
[...]
 
Autor jest architektem i wdrożeniowcem infrastruktury oraz sieci dla serwerowni i centrów danych. Specjalizuje się w zagadnieniach routingu i switchingu. Jest również certyfikowanym trenerem VMware, prowadzi szkolenia z zakresu wirtualizacji przetwarzania i sieci.  

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"