W poprzedniej wersji Opisałem ramy automatyzacji sieci. Z komentarzy wynika, że dla niektórych osób nawet to pierwsze podejście do problemu już rozwiązało niektóre kwestie. I bardzo mnie to cieszy, ponieważ naszym celem w cyklu nie jest owijanie Ansible skryptami w Pythonie, lecz zbudowanie systemu.

Ten sam framework ustala porządek, w jakim będziemy się zajmować tym zagadnieniem.
A wirtualizacja sieci, której poświęcony jest ten odcinek, nie wpisuje się szczególnie w tematykę ADSM, gdzie omawiamy automatyzację.

Ale spójrzmy na to z innej perspektywy.

Już od dawna wiele usług korzysta z jednej sieci. W przypadku operatora telekomunikacyjnego są to 2G, 3G, LTE, szerokopasmowy internet i B2B, na przykład. W przypadku DC: łączność dla różnych klientów, internet, pamięć blokowa, pamięć obiektowa.

A wszystkie usługi wymagają izolacji od siebie. Tak powstały sieci overlay.

I wszystkie usługi nie chcą czekać, aż człowiek skonfiguruje je ręcznie. Tak powstały orkiestratory i SDN.

Pierwsze podejście do systematycznej automatyzacji sieci, a raczej jej części, zostało dawno temu podjęte i wdrożone w wielu miejscach: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Dziś się nad tym zastanowimy.

Spis treści

• Przyczyny
• Terminologia
• Underlay - fizyczna sieć
• Overlay - wirtualna sieć
  • Overlay z ToR’a
  • Overlay z hosta
  • Na przykładzie Tungsten Fabric
    • Komunikacja wewnątrz jednej fizycznej maszyny
    • Komunikacja między VM, znajdującymi się na różnych fizycznych maszynach
    • Wyjście na zewnątrz

• FAQ
• Podsumowanie
• Przydatne linki

Przyczyny

I skoro już o tym mowa, warto wspomnieć o przesłankach do wirtualizacji sieci. W rzeczywistości ten proces nie rozpoczął się wczoraj.

Pewnie wielokrotnie słyszałeś, że sieć zawsze była najbardziej inertną częścią każdej systemu. I to prawda w każdym tego słowa znaczeniu. Sieć to podstawa, na której opiera się wszystko, a wprowadzanie zmian na niej jest dość trudne — usługi nie znoszą, kiedy sieć przestaje działać. Często wyłączenie jednego węzła może spowodować awarię wielu aplikacji i wpływać na wielu klientów. Częściowo dlatego zespół sieciowy może opierać się wszelkim zmianom — bo teraz to jakoś działa (możliwe, że nawet nie wiemy jak), a tutaj trzeba skonfigurować coś nowego, i nie wiadomo, jak to wpłynie na sieć.

Aby nie czekać, aż dostawcy skonfigurują VLAN i nie rejestrować usług na każdym węźle sieci, ludzie wymyślili użycie overlayów — nakładanych sieci, których jest wiele, takich jak GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE itd.

Ich atrakcyjność polega na dwóch prostych aspektach:

• Konfigurujemy tylko węzły końcowe — nie musimy ingerować w węzły tranzytowe. To znacznie przyspiesza proces, a czasem wręcz pozwala wyeliminować dział sieci z procesu wprowadzania nowych usług.
• Obciążenie jest ukryte głęboko w nagłówkach — węzły tranzytowe nie muszą nic wiedzieć o nim, o adresacji na hostach, trasach nakładanej sieci. To oznacza, że musisz przechowywać mniej informacji w tabelach, co pozwala na prostsze/tańsze urządzenia.

W tej nie do końca pełnej publikacji nie planuję omawiać wszystkich możliwych technologii, a raczej opisać ramy działania sieci overlay w Data Center.

Cała seria będzie opisywać centrum danych, składające się z rzędów jednorodnych szaf, w których zainstalowane jest to samo serwerowe wyposażenie.

Na tym sprzęcie uruchamiane są maszyny wirtualne/kontenery/serverless, realizujące usługi.

Terminologia

W cyklu serwerem będę nazywał program, który realizuje serwerową stronę komunikacji klient-serwer.

Fizyczne maszyny w szafach będziemy nazywać serwerami. nie Fizyczna maszyna

to komputer x86 zainstalowany w szafie. Najczęściej używanego terminu . Będziemy nazywać ją „ hostmaszynalubHypervisor host.

to aplikacja uruchomiona na fizycznej maszynie, emulująca fizyczne zasoby, na których uruchamiane są Maszyny Wirtualne. Czasami w literaturze i w sieci słowo „hypervisor” jest używane jako synonim „hosta”. to system operacyjny uruchomiony na fizycznej maszynie nad hypervisorem. Dla nas w ramach tego cyklu nie jest aż tak ważne, czy jest to rzeczywiście maszyna wirtualna, czy po prostu kontener. Będziemy nazywać to „

Wirtualna maszyna VM.Tenant«

to szerokie pojęcie, które w tym artykule zdefiniuję jako oddzielną usługę lub oddzielnego klienta. Multitenancy

lub multi-tenant — korzystanie z tej samej aplikacji przez różnych klientów/usług. Przy tym izolacja klientów osiągana jest dzięki architekturze aplikacji, a nie osobno uruchamianym instancjom. ToR — przełącznik na górze szafy.

ToR — przełącznik na szczycie stosu — przełącznik zainstalowany w racku, do którego są podłączone wszystkie fizyczne maszyny.

Oprócz topologii ToR, różni dostawcy praktykują End of Row (EoR) lub Middle of Row (chociaż to ostatnie to rzadkość, a skrótu MoR nigdy nie spotkałem).

Sieć podstawowa lub podłożna sieć — fizyczna infrastruktura sieciowa: przełączniki, routery, kable.

Sieć nałożona lub owerlej — wirtualna sieć tuneli działająca nałożona na fizyczną.

L3-fabryka lub fabryka IP — niesamowite wynalazek ludzkości, który pozwala na niepowtarzanie STP i nieuczenie się TRILL podczas rozmów. Koncepcja, w której cała sieć aż do poziomu dostępu jest wyłącznie L3, bez VLAN i ogromnych rozległych domen broadcastowych. O tym, skąd wzięło się słowo „fabryka”, porozmawiamy w następnej części.

SDN — Software Defined Network. Rzadko wymaga przedstawienia. Podejście do zarządzania siecią, w którym zmiany w sieci są wprowadzane nie przez człowieka, lecz przez oprogramowanie. Zazwyczaj oznacza to przeniesienie Control Plane poza końcowe urządzenia sieciowe do kontrolera.

NFV — Network Function Virtualization — wirtualizacja urządzeń sieciowych, która zakłada, że część funkcji sieci można uruchamiać jako wirtualne maszyny lub kontenery, aby przyspieszyć wdrażanie nowych usług, organizację Service Chaining oraz prostszą poziomą skalowalność.

VNF — Virtual Network Function. Konkretne wirtualne urządzenie: router, przełącznik, firewall, NAT, IPS/IDS itd.

Obecnie celowo upraszczam opis do konkretnej realizacji, aby nie wprowadzać czytelnika w zakłopotanie. Dla bardziej wnikliwego czytania odsyłam do sekcji Linki. Ponadto, Roma Gorgi, krytykujący ten artykuł za niedokładności, obiecał napisać osobny numer o technologiach wirtualizacji serwerów i sieci, bardziej szczegółowy i zwracający uwagę na detale.

Większość sieci dzisiaj można wyraźnie podzielić na dwie części:

Sieć podstawowa — fizyczna sieć o stabilnej konfiguracji.
Sieć nałożona — abstrakcja nad siecią podstawową dla izolacji najemców.

To prawda, zarówno w przypadku DC (który omówimy w tym artykule), jak i dla ISP (którego nie będziemy omawiać, ponieważ już było w SDSM). W przypadku sieci korporacyjnych sytuacja jest oczywiście nieco inna.

Obrazek z fokusem na sieć:

Sieć podstawowa

Underlay to fizyczna sieć: przełączniki sprzętowe i kable. Urządzenia w underlayu wiedzą, jak dotrzeć do fizycznych maszyn.

Opiera się na standardowych protokołach i technologiach. Nie bez powodu, ponieważ urządzenia sprzętowe wciąż działają na zastrzeżonym oprogramowaniu, które nie umożliwia programowania chipów ani wdrażania własnych protokołów, więc potrzebna jest kompatybilność z innymi dostawcami i standaryzacja.

Zarazem ktoś taki jak Google może sobie pozwolić na opracowanie własnych przełączników oraz rezygnację z powszechnie przyjętych protokołów. Ale LAN_DC to nie Google.

Underlay zmienia się stosunkowo rzadko, ponieważ jego zadaniem jest podstawowa łączność IP między fizycznymi maszynami. Underlay nic nie wie o uruchomionych usługach, klientach, tenantach — jego zadaniem jest tylko dostarczanie pakietu z jednej maszyny na drugą.
Underlay może być na przykład taki:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

Sieć underlay konfiguruje się w klasyczny sposób: CLI/GU/NETCONF.

Ręcznie, skryptami, zastrzeżonymi narzędziami.

Bardziej szczegółowo underlay będzie omawiane w następnym artykule cyklu.

Sieć nałożona

Overlay to wirtualna sieć tuneli rozciągnięta na warstwie Underlay, umożliwiająca maszynom wirtualnym jednego klienta komunikowanie się ze sobą, zapewniając izolację od innych klientów.

Dane klienta są enkapsulowane w nagłówkach tunelujących do przesyłania przez wspólną sieć.

W ten sposób maszyny wirtualne jednego klienta (jednej usługi) mogą komunikować się ze sobą przez Overlay, nawet nie zdając sobie sprawy, jaką drogę pokonuje pakiet.

Overlay może być na przykład taki, jak już wspomniałem wcześniej:

• Tunel GRE
• VXLAN
• EVPN
• L3VPN
• GENEVE

Sieć overlay jest zazwyczaj konfigurowana i utrzymywana przez centralny kontroler. Z niego konfiguracja, Control Plane i Data Plane są przesyłane do urządzeń zajmujących się routowaniem i enkapsulacją ruchu klienta. Trochę poniżej rozważmy to na przykładach.

Tak, to czyste SDN.

Istnieją dwa zasadniczo różniące się podejścia do organizacji sieci Overlay:

1. Overlay z ToR’a
2. Overlay z hosta

Overlay z ToR’a

Overlay może zaczynać się na przełączniku dostępu (ToR) stojącym w szafie, jak to ma miejsce na przykład w przypadku fabryki VXLAN.

To sprawdzony na sieciach ISP mechanizm, który wspierają wszyscy dostawcy sprzętu sieciowego.

Jednak w tym przypadku przełącznik ToR musi być w stanie oddzielać różne usługi, a administrator sieci powinien w pewnym stopniu współpracować z administratorami maszyn wirtualnych i wprowadzać zmiany (nawet automatycznie) w konfiguracji urządzeń.

Tutaj odsyłam czytelnika do artykułu o VxLAN na Habra naszym starym przyjacielu @bormoglotx.
W tej prezentacji ENOG szczegółowo opisano podejścia do budowy sieci DC z EVPN VXLAN-fabryką.

A dla pełniejszego wniknięcia w rzeczywistość, można przeczytać książkę Cisco A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Zauważam, że VXLAN to tylko metoda enkapsulacji, a zakończenie tuneli może odbywać się nie na ToR, ale na hoście, jak ma to miejsce w przypadku OpenStacka, na przykład.

Jednak fabryka VXLAN, w której overlay zaczyna się na ToR, jest jednym z ustalonych projektów sieci overlay.

Overlay z hosta

Innym podejściem jest rozpoczęcie i zakończenie tuneli na końcowych hostach.
W takim przypadku sieć (Underlay) pozostaje maksymalnie prosta i statyczna.
A host sam wykonuje wszystkie niezbędne enkapsulacje.

W tym celu konieczne będzie uruchomienie specjalnej aplikacji na hostach, ale warto.

Po pierwsze, uruchomienie klienta na maszynie z systemem Linux jest prostsze lub, powiedzmy, - w ogóle możliwe - podczas gdy na przełączniku prawdopodobnie nadal trzeba będzie korzystać z własnościowych rozwiązań SDN, co zabija ideę wielowalutowości.

Po drugie, przełącznik ToR w tym przypadku można pozostawić maksymalnie prostym, zarówno pod względem płaszczyzny kontroli, jak i płaszczyzny danych. Rzeczywiście - z kontrolerem SDN nie musi wtedy współpracować, a przechowywanie sieci/ARP-ów wszystkich podłączonych klientów także - wystarczy znać adres IP fizycznej maszyny, co znacznie ułatwia tabele przełączania/routingowe.

W serii ADSM wybieram podejście overlay z hosta - dalej będziemy mówić tylko o nim i nie wrócimy już do fabryki VXLAN.

Najłatwiej to zobaczyć na przykładach. Jako obiekt badawczy weźmiemy platformę SDN OpenSource OpenContrail, obecnie znaną jako Tungsten Fabric.

Na końcu artykułu przedstawię kilka refleksji na temat analogii z OpenFlow i OpenvSwitch.

Na przykładzie Tungsten Fabric

Na każdej fizycznej maszynie jest vRouter — wirtualny router, który zna podłączone do niego sieci i jakie klienty do nich należą — w zasadzie — router PE. Dla każdego klienta utrzymuje izolowaną tabelę routingu (czytaj VRF). I właściwie vRouter wykonuje tunelowanie Overlay.

Nieco więcej o vRouterze — na końcu artykułu.

Każda VM zlokalizowana na hypervisorze łączy się z vRouterem tej maszyny przez interfejs TAP.

TAP — Terminal Access Point — wirtualny interfejs w jądrze Linux, który umożliwia nawiązywanie interakcji sieciowych.

Jeśli za vRouterem znajduje się kilka sieci, dla każdej z nich tworzony jest wirtualny interfejs, któremu przypisywany jest adres IP — będzie on adresem bramy domyślnej.
Wszystkie sieci jednego klienta umieszczane są w jednym VRF (jednej tabeli), różne — w różnych.
Zaznaczam tu, że nie wszystko jest takie proste, i odsyłam ciekawskich czytelników na koniec artykułu..

Aby vRoutery mogły się ze sobą komunikować, a więc również VM znajdujące się za nimi, wymieniają się informacjami routingu przez kontroler SDN.

Aby wydostać się na zewnątrz, istnieje punkt wyjścia z matrycy — brama wirtualnej sieci VNGW — Virtual Network GateWay (termin mój).

Teraz przyjrzymy się przykładom komunikacji — i wszystko stanie się jasne.

Komunikacja wewnątrz jednej fizycznej maszyny

VM0 chce wysłać pakiet do VM2. Przyjmijmy na razie, że to VM jednego klienta.

Data Plane

1. VM-0 ma domyślną trasę do swojego interfejsu eth0. Pakiet jest tam wysyłany.
   Ten interfejs eth0 jest tak naprawdę wirtualnie połączony z wirtualnym routerem vRouter za pomocą interfejsu TAP tap0.
2. vRouter analizuje, na jaki interfejs dotarł pakiet, to znaczy do którego klienta (VRF) on należy, porównuje adres odbiorcy z tabelą routingu tego klienta.
3. Zauważając, że odbiorca znajduje się na tej samej maszynie za innym portem, vRouter po prostu wysyła pakiet do niego bez żadnych dodatkowych nagłówków — w tym przypadku vRouter ma już zapis ARP.

Pakiet w tym przypadku nie trafia do fizycznej sieci — został zrouterowany wewnątrz vRoutera.

Control Plane

Hypervisor przy uruchamianiu wirtualnej maszyny informuje ją o:

• Jej własnym adresie IP.
• Trasie domyślną — przez adres IP vRoutera w tej sieci.

vRouterowi przez specjalne API hypervisor informuje:

• Że musi stworzyć wirtualny interfejs.
• Jaki (VM) należy stworzyć Virtual Network.
• Do którego VRF ma być przypisany (VN).
• Statyczny zapis ARP dla tej VM — który interfejs odpowiada jej adresowi IP i do którego adresu MAC jest on przypisany.

Raz jeszcze, rzeczywista procedura interakcji została uproszczona dla łatwiejszego zrozumienia koncepcji.

W ten sposób wszystkie VM jednego klienta na tej maszynie vRouter widzi jako bezpośrednio podłączone sieci i może między nimi samodzielnie routować.

Natomiast VM0 i VM1 należą do różnych klientów, a zatem znajdują się w różnych tabelach vRoutera.

To, czy będą mogły się komunikować bezpośrednio, zależy od ustawień vRoutera oraz projektu sieci.
Na przykład, jeśli VM obu klientów używają adresów publicznych, lub NAT zachodzi na samym vRouterze, można ustanowić bezpośrednią trasę na vRouterze.

W przeciwnym razie może wystąpić zbieżność przestrzeni adresowej — konieczne będzie przechodzenie przez serwer NAT, aby uzyskać publiczny adres — przypomina to wyjście do zewnętrznych sieci, o których mowa poniżej.

Komunikacja między VM, znajdującymi się na różnych fizycznych maszynach

Data Plane

1. Początek jest dokładnie taki sam: VM-0 wysyła pakiet do adresata VM-7 (172.17.3.2) według swojego domyślnego ustawienia.
2. vRouter go odbiera i tym razem widzi, że adresat znajduje się na innej maszynie i jest dostępny przez tunel Tunnel0.
3. Najpierw nakłada etykietę MPLS, identyfikującą zdalny interfejs, aby na odwrotnej stronie vRouter mógł ustalić, gdzie ten pakiet umieścić, i to bez dodatkowych luków.

   

4. Z Tunnel0 źródło to 10.0.0.2, odbiorca: 10.0.1.2.
   vRouter dodaje nagłówki GRE (lub UDP) i nowy adres IP do oryginalnego pakietu.
5. W tabeli routingu vRoutera znajduje się trasa domyślna przez adres ToR1 10.0.0.1. Tam właśnie wysyła.

   
   

6. ToR1 jako uczestnik sieci Underlay wie (na przykład, przez OSPF), jak dotrzeć do 10.0.1.2, i wysyła pakiet odpowiednią trasą. Zwróć uwagę, że tutaj wchodzi w grę ECMP. Na ilustracji są dwa next hopy, i różne strumienie będą w nich umieszczane na podstawie hasha. W przypadku rzeczywistej fabryki byłoby tu raczej 4 next hopów.

   Przy tym nie musi wiedzieć, co znajduje się pod zewnętrznym nagłówkiem IP. To znaczy, że faktycznie pod IP może być kanapka z IPv6 nad MPLS nad Ethernet nad MPLS nad GRE nad GRE nad GRE.

7. Odpowiednio, po stronie odbierającej vRouter usuwa GRE i na podstawie etykiety MPLS rozumie, na który interfejs należy przekazać ten pakiet, rozdziela go i wysyła w pierwotnej formie do odbiorcy.

Control Plane

Podczas uruchamiania maszyny dzieje się to samo, co opisano powyżej.

A dodatkowo jeszcze to:

• Dla każdego klienta vRouter przydziela etykietę MPLS. Jest to etykieta serwisowa L3VPN, według której klienci będą rozdzielani w obrębie jednej fizycznej maszyny.
  

  W rzeczywistości etykieta MPLS jest zawsze przydzielana przez vRouter, ponieważ nie wiadomo z góry, że maszyna będzie wchodzić w interakcje tylko z innymi maszynami za tym samym vRouterem, a to prawdopodobnie nawet nie jest prawdą.

• vRouter ustanawia połączenie z kontrolerem SDN za pomocą protokołu BGP (lub podobnego – w przypadku TF jest to XMPP 0_o).
• Poprzez tę sesję vRouter informuje kontrolera SDN o trasach do podłączonych sieci:
  • Adres sieci
  • Metoda enkapsulacji (MPLSoGRE, MPLSoUDP, VXLAN)
  • Etykieta MPLS klienta
  • Swój adres IP jako nexthop

• Kontroler SDN otrzymuje takie trasy od wszystkich podłączonych vRouterów, i odzwierciedla je innym. To znaczy, że pełni rolę Route Reflectora.

To samo dzieje się w drugą stronę.

Overlay może zmieniać się nawet co minutę. Tak to mniej więcej wygląda w publicznych chmurach, gdy klienci regularnie uruchamiają i wyłączają swoje maszyny wirtualne.

Centralny kontroler przejmuje wszystkie trudności związane z utrzymywaniem konfiguracji oraz kontrolą tabeli przełączania/routingu na vRouterze.

Mówiąc w skrócie, kontroler łączy się ze wszystkimi vRouterami za pomocą BGP (lub podobnego protokołu) i po prostu przekazuje informacje o trasie. BGP, na przykład, już ma Address-Family do przesyłania metody enkapsulacji. MPLS-in-GRE lub MPLS-in-UDP.

Przy tym nie zmienia się w żaden sposób konfiguracja sieci Underlay, którą, nawiasem mówiąc, automatyzować jest znacznie trudniej, a złamać przypadkowym ruchem łatwiej.

Wyjście na zewnątrz

Gdzieś symulacja powinna się skończyć, i z wirtualnego świata trzeba przejść do rzeczywistego. Potrzebny jest brama taksowa.

Stosuje się dwa podejścia:

1. Instalowany jest sprzętowy router.
2. Uruchamiany jest jakiś appliance, realizujący funkcje routera (tak, tak, po SDN zderzyliśmy się i z VNF). Nazwijmy go wirtualną bramą.

Zaletą drugiego podejścia jest tania pozioma skalowalność – brak mocy – uruchomiliśmy jeszcze jedną wirtualkę z bramą. Na dowolnej fizycznej maszynie, bez konieczności szukania wolnych szafek, jednostek, zasilania, kupowania samego sprzętu, transportu, instalacji, okablowania, konfigurowania, a potem jeszcze wymiany uszkodzonych komponentów.

Wadą wirtualnego bramy jest to, że jednostka fizycznego routera jest znacznie potężniejsza niż wielordzeniowa maszyna wirtualna, a jego oprogramowanie dostosowane do jego własnej podstawy sprzętowej działa znacznie stabilniej (nie). Trudno ignorować również fakt, że kompleks sprzętowo-programowy po prostu działa, wymagając jedynie konfiguracji, podczas gdy uruchamianie i utrzymanie wirtualnej bramy to zadanie dla silnych inżynierów.

Jedną nogą brama spogląda na wirtualną sieć Overlay, jak zwykła maszyna wirtualna, i może współdziałać z innymi VM. Przy tym może kończyć sieci wszystkich klientów i, odpowiednio, prowadzić routowanie między nimi.

Drugą nogą brama patrzy w sieć główną i wie, jak przedostać się do Internetu.

Data Plane

Proces wygląda następująco:

1. VM-0, mając domyślnie vRouter, wysyła pakiet z adresatem w świecie zewnętrznym (185.147.83.177) na interfejs eth0.
2. vRouter odbiera ten pakiet i robi lookup adresu docelowego w tabeli routingu — znajduje trasę domyślną przez bramę VNGW1 przez Tunnel 1.
   Widzi również, że to jest tunel GRE z SIP 10.0.0.2 i DIP 10.0.255.2, a także trzeba najpierw przypiąć etykietę MPLS tego klienta, którą oczekuje VNGW1.
3. vRouter pakuje pierwotny pakiet w nagłówki MPLS, GRE i nowy IP i wysyła do adresu ToR1 10.0.0.1 zgodnie z domyślną trasą.
4. Sieć podkładowa dostarcza pakiet do bramy VNGW1.
5. Bramka VNGW1 usuwa nagłówki tunelujące GRE i MPLS, widzi adres docelowy, konsultuje swoją tabelę routingu i rozumie, że ma on trafić do Internetu — zatem przez Full View lub Default. W razie potrzeby przeprowadza translację NAT.
6. Od VNGW do bordera może być zwykła sieć IP, co jest mało prawdopodobne.
   Może to być klasyczna sieć MPLS (IGP+LDP/Rsvp TE), może być odwrotna fabryka z BGP LU lub tunel GRE od VNGW do bordera przez sieć IP.
   Bez względu na wszystko, VNGW1 dokonuje niezbędnych enkapsulacji i wysyła pierwotny pakiet w kierunku bordera.

Ruch w przeciwną stronę przechodzi te same kroki w odwrotnej kolejności.

1. Border dostarcza pakiet do VNGW1
2. Ten go rozbiera, patrzy na adres odbiorcy i widzi, że jest on dostępny przez tunel Tunnel1 (MPLSoGRE lub MPLSoUDP).
3. W związku z tym przyczepia etykietę MPLS, nagłówek GRE/UDP i nowy IP i wysyła do swojego ToR3 10.0.255.1.
   Adres docelowy tunelu to adres IP vRoutera, za którym znajduje się docelowa VM — 10.0.0.2.
4. Sieć podpodstawowa dostarcza pakiet do odpowiedniego vRoutera.
5. Docelowy vRouter odłącza GRE/UDP, określa interfejs na podstawie oznaczenia MPLS i wysyła surowy pakiet IP do swojego interfejsu TAP, związanego z eth0 VM.

Control Plane

VNGW1 ustanawia sąsiedztwo BGP z kontrolerem SDN, od którego uzyskuje wszystkie informacje routingu dotyczące klientów: za jakim adresem IP (vRouterem) znajduje się jaki klient oraz jakim oznaczeniem MPLS jest identyfikowany.

Podobnie informuje kontroler SDN o domyślnej trasie z oznaczeniem tego klienta, wskazując siebie jako nexthopa. Następnie ta domyślna trasa dociera do vRouterów.

Na VNGW zazwyczaj odbywa się agregacja tras lub translacja NAT.

W drugą stronę w sesji z borderami lub Route Reflectorami przesyła dokładnie tę agregowaną trasę. Od nich otrzymuje trasę domyślną, Full-View lub coś innego.

Jeśli chodzi o enkapsulację i wymianę ruchu, VNGW nie różni się od vRoutera.
Jeśli rozszerzyć zakres, do VNGW i vRouterów można dodać inne urządzenia sieciowe, takie jak zapory, farmy oczyszczania lub wzbogacania ruchu, IPS i tak dalej.

Dzięki sekwencyjnemu tworzeniu VRF i odpowiedniemu ogłaszaniu tras można sprawić, aby ruch krążył tak, jak chcesz, co nazywa się Service Chaining.

Czyli również tutaj kontroler SDN pełni rolę Route-Reflectora między VNGW, vRouterami i innymi urządzeniami sieciowymi.

Jednak kontroler faktycznie przekazuje również informacje o ACL i PBR (Routing na podstawie polityki), zmuszając poszczególne strumienie ruchu do przemieszczania się nie tak, jak nakazuje trasa.

FAQ

Dlaczego ciągle robisz uwagę o GRE/UDP?

Cóż, w zasadzie to jest specyficzne dla Tungsten Fabric — można w ogóle tego nie brać pod uwagę.

Ale jeśli chodzi o TF, będąc jeszcze OpenContrail, obsługiwał obie enkapsulacje: MPLS w GRE i MPLS w UDP.

UDP jest dobre, ponieważ w porcie źródłowym w jego nagłówku bardzo łatwo zakodować funkcję haszującą z początkowych IP+Proto+Port, co umożliwia równoważenie.

W przypadku GRE, niestety, są tylko zewnętrzne nagłówki IP i GRE, które są identyczne dla całego enkapsulowanego ruchu, więc mowa o równoważeniu nie ma miejsca — niewielu może zajrzeć tak głęboko w pakiet.

Do pewnego czasu routery, jeśli w ogóle potrafiły obsługiwać dynamiczne tunele, to tylko w MPLSoGRE, a dopiero niedawno nauczyły się obsługiwać MPLSoUDP. Dlatego też zawsze trzeba dodać wzmiankę o możliwości dwóch różnych enkapsulacji.

Dla uczciwości warto zauważyć, że TF z powodzeniem obsługuje także L2 połączenia za pomocą VXLAN.

Obiecałeś przeprowadzić paralele z OpenFlow.
Rzeczywiście, same się nasuwają. vSwitch w tym samym OpenStacku działa w bardzo podobny sposób, używając VXLAN, który zresztą również korzysta z nagłówka UDP.

W Data Plane działają w zasadzie podobnie, znacznie różni się natomiast Control Plane. Tungsten Fabric używa XMPP do przesyłania informacji o trasach do vRouter, podczas gdy w OpenStacku działa OpenFlow.

Można powiedzieć trochę więcej o vRouter?
Dzieli się on na dwie części: vRouter Agent i vRouter Forwarder.

Pierwszy działa w User Space systemu operacyjnego gospodarza i komunikuje się z kontrolerem SDN, wymieniając informacje o trasach, VRF i ACL.

Drugi realizuje Data Plane — zazwyczaj w Kernel Space, ale może być również uruchamiany na SmartNICach — kartach sieciowych z CPU i oddzielnym programowalnym chipem przełączającym, co pozwala zredukować obciążenie CPU maszyny gospodarza i uczynić sieć szybszą oraz bardziej przewidywalną.

Istnieje także scenariusz, w którym vRouter to aplikacja DPDK w User Space.

vRouter Agent przesyła ustawienia do vRouter Forwarder.

Czym jest Virtual Network?
Wspomniałem na początku artykułu o VRF, że każdy najemca jest przypisany do swojego VRF. I jeśli dla powierzchownego zrozumienia działania sieci opartej na overlayach to wystarczy, to już przy następnej iteracji należy zrobić pewne doprecyzowania.

Zazwyczaj w mechanizmach wirtualizacji byt Virtual Network (można to uznać za nazwę własną) wprowadza się oddzielnie od klientów/najemców/maszyn wirtualnych — jest to całkowicie samodzielny byt. A ten Virtual Network można już podłączyć przez interfejsy do jednego najemcy, drugiego, dwóch, czy gdziekolwiek indziej. Tak na przykład realizuje się Service Chaining, gdy ruch musi przejść przez określone węzły w odpowiedniej kolejności, po prostu tworząc i przypinając Virtual Network w odpowiedniej kolejności.

Dlatego nie ma bezpośredniego odpowiednika między Virtual Network a najemcą.

Podsumowanie

To dość powierzchowne opisanie działania wirtualnej sieci z nakładką z hosta i kontrolerem SDN. Bez względu na platformę wirtualizacji, którą dzisiaj wybierzesz, będzie ona działać w podobny sposób, niezależnie czy to VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric czy Juniper Contrail. Różnice będą dotyczyć rodzajów enkapsulacji i nagłówków, protokołów dostarczania informacji do końcowych urządzeń sieciowych, ale zasada programowalnej sieci nakładkowej działającej na stosunkowo prostej i statycznej sieci podstawowej pozostanie ta sama.
Można powiedzieć, że w dziedzinie tworzenia prywatnych chmur, SDN oparty na sieci nakładkowej wygrał. Nie oznacza to jednak, że OpenFlow nie ma miejsca we współczesnym świecie — jest używany w OpenStack i tym samym VMWare NSX, jak mi wiadomo, stosuje go Google do konfiguracji sieci podstawowej.

Nieco niżej zamieściłem linki do bardziej szczegółowych materiałów, jeśli chcesz zgłębić temat.

A co z naszą siecią podstawową?

A w zasadzie nic. Przez cały czas pozostawała taka sama. To, co musi robić w przypadku nakładki z hosta, to aktualizować trasy i ARP-y w miarę pojawiania się i znikania vRouter/VNGW oraz przesyłać pakiety między nimi.

Sformułujmy listę wymagań dla sieci podstawowej.

1. Musieć obsługiwać jakiś protokół routingu, w naszej sytuacji — BGP.
2. Mieć dużą przepustowość, najlepiej bez auto-przekierowywania, aby pakiety nie ginęły z powodu przeciążenia.
3. Obsługiwać ECMP — nieodłączny element fabryki.
4. Musieć zapewnić QoS, w tym skomplikowane rzeczy, takie jak ECN.
5. Obsługiwać NETCONF — przygotowanie na przyszłość.

Swojej pracy samej sieci podstawowej poświęciłem tutaj bardzo mało czasu. To dlatego, że w dalszej części serii skupimy się именно на ней, а о накладном мы будем говорить только вскользь.

Oczywiste jest, że mocno ograniczam nas wszystkich, używając jako przykładu sieć centrum danych zbudowaną na fabryce Cloza z czystą IP-routerną i nakładką z hosta.

Jednak jestem pewien, że każdą sieć o określonym designie można opisać w formalnych terminach i zautomatyzować. Po prostu dążę tutaj do zrozumienia podejść do automatyzacji, a nie do zdezorientowania wszystkich, rozwiązując zadanie w ogólnym ujęciu.

W ramach ADS-M planujemy z Romanem Gorge'em opublikować oddzielny numer poświęcony wirtualizacji moc obliczeniowych i jej interakcji z wirtualizacją sieci. Proszę pozostańcie w kontakcie.

Przydatne linki

• Architektura Tungsten Fabric.
• about:cloud. 6 godzin o Yandex.Cloud, gdzie m.in. omawiana jest wirtualna sieć na TF.
• Czym jest Open vSwitch?
• Wprowadzenie do VxLAN.
• RFC 7348. Wirtualna Ekstensywna Sieć Lokalna (VXLAN): Ramy dla nakładania wirtualizowanych sieci warstwy 2 na sieci warstwy 3.
  
• Podejście Scaleway do VXLAN EVPN Fabric. Tutaj omawiana jest cała sieć DC, w tym Underlay, Overlay, podejścia do multi-homing i zarządzania.

Dziękuję

• Roman Gorga — były prowadzący podcastu linkmeup, obecnie ekspert w dziedzinie platform chmurowych. Dziękuję za komentarze i poprawki. Czekamy również na jego wkrótce zapowiedziany głębszy artykuł o wirtualizacji.
• Aleksandr Shalimov — mój kolega i ekspert w dziedzinie rozwoju wirtualnych sieci. Dziękuję za komentarze i poprawki.
• Walentyn Sinytsyn — mój kolega i ekspert w dziedzinie Tungsten Fabric. Dziękuję za komentarze i poprawki.
• Artem Czerńobaj — ilustrator linkmeup. Dziękuję za KDPV.
• Aleksandrowi Limonowowi. Za mem «automato».

Źródło: habr.com