W dwóch pierwszych artykułach poruszyłem kwestię automatyzacji i naszkicowałem jej ramy, w drugim zrobiłem dygresję na temat wirtualizacji sieci, jako pierwszego podejścia do automatyzacji konfiguracji usług.
A teraz nadszedł czas, aby narysować schemat fizycznej sieci.

Jeśli nie jesteś obeznany z urządzeniami w sieciach centrów danych, zdecydowanie polecam zacząć od artykułu na ich temat.

Wszystkie wydania:

• 0. ADSK. Część Zerowa. Planowanie
• 1. ADSK. Część pierwsza (ta po zerowej). Wirtualizacja sieci
• 2. ADSK. Część Druga. Projektowanie sieci

Opisane w tej serii praktyki powinny być stosowane do sieci każdego typu, każdej skali oraz dowolnej różnorodności dostawców (nie). Jednak nie można opisać uniwersalnego przykładu zastosowania tych podejść. Dlatego zatrzymam się na nowoczesnej architekturze sieci DC: Fabryka Clos.
DCI zrealizujemy na MPLS L3VPN.

Na fizycznej sieci działa sieć Overlay z hosta (może to być VXLAN OpenStacka lub Tungsten Fabric, lub cokolwiek innego, co wymaga od sieci jedynie podstawowej łączności IP).

W tym przypadku będzie to stosunkowo prosty scenariusz do automatyzacji, ponieważ mamy wiele urządzeń konfigurujących się w ten sam sposób.

Wybierzemy sferyczne DC w próżni:

• Jedna wersja projektu wszędzie.
• Dwóch dostawców, tworzących dwie płaszczyzny sieci.
• Jedno DC przypomina drugie jak dwie krople wody.

Spis treści

• Topologia fizyczna
• Routing
• Plan IP
• Laboratoria
• Podsumowanie
• Przydatne linki

Niech nasz dostawca usług LAN_DC będzie na przykład hostował filmy szkoleniowe o przetrwaniu w uwięzionych windach.

W metropoliach cieszy się to ogromną popularnością, dlatego potrzebujemy wielu maszyn fizycznych.

Najpierw opiszę sieć mniej więcej tak, jak chciałbym ją widzieć. A potem uproszczę ją dla laboratorium.

Topologia fizyczna

Lokalizacje

LAN_DC będzie miał 6 DC:

• Rosja (RU):
  • Moskwa (msk)
  • Kazań (kzn)

• Hiszpania (SP):
  • Barcelona (bcn)
  • Malaga (mlg)

• Chiny (CN):
  • Shanghai (sha)
  • Xian (sia)

Wewnątrz DC (Intra-DC)

We wszystkich DC identyczne sieci wewnętrzne, oparte na topologii Clos.
Czym są sieci Clos i dlaczego właśnie one — w osobnym artykuł.

W każdym DC znajduje się 10 szaf z maszynami, będą one numerowane jako A, B, C I tak dalej.

W każdej szafie znajduje się 30 maszyn. Nie będziemy się nimi interesować.

W każdej szafie znajduje się także przełącznik, do którego podłączone są wszystkie maszyny — to jest Top of the Rack switch — ToR lub w terminologii fabryki Clos nazwiemy go Leaf.

Ogólny schemat fabryki.

Nazwiemy je XXX-leafY, gdzie XXX — trzy-literowe skrócenie DC, a Y — numer porządkowy. Na przykład, kzn-leaf11.

W artykułach pozwolę sobie na dosyć swobodne używanie terminów Leaf i ToR jako synonimów. Jednak należy pamiętać, że nie jest to zgodne z rzeczywistością.
ToR to przełącznik zainstalowany w szafie, do którego podłączone są maszyny.
Leaf to rola urządzenia w fizycznej sieci lub przełącznik pierwszego poziomu w terminologii topologii Clos.
Zatem Leaf != ToR.
Tak więc Leafem może być przełącznik EndofRaw, na przykład.
Jednak w ramach tego artykułu będziemy jednak traktować je jako synonimy.

Każdy przełącznik ToR z kolei łączy się z czterema wyższymi przełącznikami agregacyjnymi — Spine. Dla Spine'ów zarezerwowano po jednej szafie w DC. Nazwiemy je analogicznie: XXX-spineY.

W tej samej szafie znajdować się będzie sprzęt sieciowy zapewniający łączność między DC — 2 routery z MPLS na pokładzie. Ale w zasadzie — to te same ToR-y. Z punktu widzenia przełączników Spine nie ma żadnej różnicy, czy to zwykły ToR z podłączonymi maszynami, czy router do DCI — jedno i to samo przesyła.

Takie specjalne ToR-y nazywają się Edge-leaf. Będziemy je nazywać XXX-edgeY.

Wygląda to tak.

Na powyższej schemacie rzeczywiście umieściłem edge i leaf na tym samym poziomie. Klasyczne trzypoziomowe sieci nauczyły nas postrzegać uplink (stąd właśnie ten termin) jako łącza w górę. A tutaj „uplink” DCI idzie z powrotem w dół, co dla niektórych łamie zwykłą logikę. W przypadku dużych sieci, gdy centra danych dzielą się jeszcze na mniejsze jednostki — POD‘y (Point Of Delivery), wyodrębnia się oddzielne Edge-POD‘y dla DCI i wyjścia do zewnętrznych sieci.

Dla wygody percepcji w dalszym ciągu będę rysować Edge nad Spine, przy tym będziemy pamiętać, że na Spine nie ma żadnej inteligencji i różnicy w pracy z zwykłymi Leaf i Edge-leaf (choć mogą być pewne niuanse, ale w zasadzie tak jest).

Schemat fabryki z Edge-leafami.

Trójca Leaf, Spine i Edge tworzy sieć Underlay lub fabrykę.

Zadanie fabryki sieciowej (czytaj Underlay), jak już ustaliliśmy w poprzednim wydaniu, jest bardzo proste — zapewnić IP-łączność między maszynami zarówno w obrębie jednego DC, jak i między nimi.
Dlatego właśnie sieć nazywa się fabryką, podobnie jak fabryka przełączania wewnątrz modułowych skrzynków sieciowych, o czym można poczytać więcej w SDSM14.

A w rzeczywistości taka topologia nazywana jest fabryką, ponieważ fabric w tłumaczeniu oznacza tkaninę. I trudno się nie zgodzić:

Fabryka jest w pełni L3. Żadnych VLAN-ów, żadnego Broadcastu — to właśnie nasi wspaniali programiści w LAN_DC potrafią pisać aplikacje żyjące w paradygmacie L3, a maszyny wirtualne nie wymagają Live Migration z zachowaniem adresu IP.

I jeszcze raz: odpowiedź na pytanie dlaczego fabryka i dlaczego L3 — w osobnym. artykuł.

DCI — Data Center Interconnect (Inter-DC)

DCI będzie zorganizowane za pomocą Edge-Leaf, to znaczy, że są naszym punktem wyjścia w magistrali.
Dla uproszczenia przyjmijmy, że DC są połączone ze sobą bezpośrednimi łączami.
Wyłączamy z rozważania zewnętrzną łączność.

Zdaję sobie sprawę, że za każdym razem, gdy usuwam jakiś komponent, znacznie upraszczam sieć. I przy automatyzacji naszej abstrakcyjnej sieci wszystko pójdzie dobrze, a na rzeczywistej pojawią się problemy.
To prawda. A jednak celem tej serii jest przemyślenie i opracowanie podejść, a nie heroiczne rozwiązywanie wymyślonych problemów.

Na Edge-Leafach underlay umieszczane jest w VPN i przesyłane przez magistralę MPLS (to bezpośrednie łącze).

Taka oto schematyczna ilustracja na górnym poziomie powstaje.

Routing

Do routingu wewnątrz DC będziemy używać BGP.
Na magistrali MPLS OSPF+LDP.
Dla DCI, czyli organizacji łączności w underlay — BGP L3VPN przez MPLS.

Ogólny schemat routingu

W fabryce nie będzie żadnych OSPF ani ISIS (protocol routingu zakazany w Federacji Rosyjskiej).

A to oznacza, że nie będzie Auto-discovery i obliczania najkrótszych ścieżek — tylko ręczne (czyli w rzeczywistości automatyczne — w końcu mówimy o automatyzacji) konfigurowanie protokołu, sąsiedztwa i polityk.

Schemat routingu BGP wewnątrz DC

Dlaczego BGP?

Na ten temat istnieje cały RFC nosi nazwisko Facebook’a i Arista, opisujący, jak budować bardzo duże sieci centrów danych, używając BGP. Czyta się prawie jak literatura, gorąco polecam na leniwe wieczory.

A także cały rozdział w moim artykule jest temu poświęcony. Dokąd was kieruję na ten temat..

Ale jeśli krótko, to żadne IGP nie nadają się do dużych centrów danych, gdzie liczba urządzeń sieciowych idzie w tysiące.

Ponadto stosowanie BGP wszędzie pozwoli nie rozpraszać się na wsparcie dla różnych protokołów i synchronizację między nimi.

Mówiąc szczerze, w naszej fabryce, która raczej nie będzie szybko rosła, wystarczyłoby OSPF. To tak naprawdę problemy megaskalowalnych i kluczowych usług chmurowych. Ale załóżmy tylko przez chwilę, że to jest potrzebne, i użyjemy BGP, jak przykazał Piotr Lapuhoff.

Polityki routingu

Na przełącznikach Leaf importujemy do BGP prefiksy z interfejsów Underlay z sieci.
Będziemy mieć sesję BGP między każdą parą Leaf-Spine, w której te prefiksy Underlay będą ogłaszane w sieci.

W obrębie jednego centrum danych będziemy rozpowszechniać szczegóły, które zaimportowaliśmy do ToR. Na Leafach krawędziowych będziemy je agregować i ogłaszać w odległych DC oraz przekazywać do ToR. To znaczy, każdy ToR będzie dokładnie wiedział, jak dotrzeć do innego ToRa w tym samym DC i gdzie jest punkt wejścia, aby dostać się do ToRa w innym DC.

W DCI trasy będą przekazywane jako VPNv4. W tym celu interfejs Edge-Leaf w kierunku fabryki będzie umieszczony w VRF, nazwiemy go UNDERLAY, a sąsiedztwo ze Spine na Edge-Leaf będzie nawiązywane wewnątrz VRF, a między Edge-Leafami w rodzinie VPNv4.

Ponadto zabronimy reogłaszania tras otrzymanych od spine, z powrotem na nie.

Na Leaf i Spine nie będziemy importować Loopbacków. Będą nam potrzebne tylko do określenia Router ID.

Natomiast na Edge-Leafach importujemy go do Global BGP. Między adresami Loopback Edge-Leafy będą nawiązywać sesję BGP w IPv4 VPN-family między sobą.

Między urządzeniami EDGE będziemy mieli rozwiniętą magistralę na OSPF+LDP. Wszystko w jednej strefie. Ekstremalnie prosta konfiguracja.

Oto jak wygląda sytuacja z routingiem.

BGP ASN

Edge-Leaf ASN

Na Edge-Leafach będzie jeden ASN w każdym DC. To ważne, aby między Edge-Leafami istniał iBGP, i nie wpadliśmy na niuanse eBGP. Niech to będzie 65535. W rzeczywistości mógłby to być numer publicznej AS.

Spine ASN

Na Spine będziemy mieć jeden ASN na DC. Rozpoczniemy od pierwszego numeru w zakresie prywatnych AS — 64512, 64513 itd.

Dlaczego ASN na DC?

Rozbijmy to pytanie na dwa:

• Dlaczego identyczne ASN na wszystkich spine'ach jednego DC?
• Dlaczego różne w różnych DC?

Dlaczego identyczne ASN na wszystkich spine'ach jednego DC

Tak będzie wyglądać AS-Path Anterleyańskiego маршрута na Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Przy próbie ogłoszenia go z powrotem na Spine, ten go odrzuci, ponieważ jego AS (Spine_AS) już znajduje się na liście.

Jednak w obrębie DC całkowicie nam odpowiada, że trasy Underlay, które weszły na Edge, nie będą mogły wrócić w dół. Cała komunikacja między hostami wewnątrz DC powinna odbywać się na poziomie spine'ów.

Z kolei agregowane trasy z innych DC w każdym przypadku bez przeszkód dotrą do ToRów — w ich AS-Path znajdzie się tylko ASN 65535 — numer AS Edge-Leafów, ponieważ to na nich zostały stworzone.

Dlaczego różne w różnych DC

Teoretycznie może być konieczne przetransportowanie Loopbacków jakichś serwisowych maszyn wirtualnych między DC.

Na przykład, na hoście uruchomimy Route Reflector lub ten sam VNGW (Virtual Network Gateway), który za pomocą BGP połączy się z ToR-em i ogłosi swój loopback, który powinien być dostępny ze wszystkich DC.

Tak więc jak będzie wyglądał jego AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

I tutaj nie powinno być powtarzających się ASN.

To znaczy Spine_DC1 i Spine_DC2 muszą być różne, tak samo jak leafX_DC1 i leafY_DC2, do czego właśnie zmierzamy.

Jak pewnie wiesz, istnieją hacki, które pozwalają przyjmować trasy z powtarzającymi się ASN wbrew mechanizmowi zapobiegania pętlom (allowas-in na Cisco). I to ma nawet całkiem uzasadnione zastosowania. Ale to potencjalna luka w stabilności sieci. Osobiście dwa razy na nią wpadłem.

A jeśli możemy nie używać niebezpiecznych rzeczy, skorzystamy z tej możliwości.

Leaf ASN

Będziemy mieć indywidualny ASN na każdym przełączniku Leaf w całej sieci.
Robimy to w związku z uprzednio podanymi względami: AS-Path bez pętli, konfiguracja BGP bez wtyczek.

Aby trasy między Leafami mogły przechodzić bez przeszkód, AS-Path musi wyglądać tak:
[leafX_ASN, spine_ASN, leafY_ASN]
gdzie leafX_ASN i leafY_ASN powinny się różnić.

Jest to również wymagane w sytuacji ogłoszenia loopbacka VNF między DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Będziemy używać 4-bajtowego ASN i generować go na podstawie ASN Spine’a oraz numeru przełącznika Leaf, a mianowicie, w ten sposób: Spine_ASN.0000X.

Taka jest sytuacja z ASN.

Plan IP

Zasadniczo musimy przydzielić adresy dla następujących połączeń:

1. Adresy sieci Underlay między ToR a maszyną. Muszą być unikalne w całej sieci, aby każda maszyna mogła się połączyć z każdą inną. Doskonale nadaje się 10/8. Na każdą szafę po /26 z zapasem. Będziemy przydzielać po /19 na DC i /17 na region.
2. Adresy łączące między Leaf/Tor a Spine.

   Chcielibyśmy je przydzielać algorytmicznie, czyli obliczać na podstawie nazw urządzeń, które należy podłączyć.

   Niech to będzie… 169.254.0.0/16.
   A mianowicie 169.254.00X.Y/31, gdzie X — numer Spine, Y — sieć P2P /31.
   To pozwoli na uruchomienie do 128 szaf i do 10 Spine w DC. Adresy łącznikowe mogą (i będą) się powtarzać z DC do DC.

3. Punkt styku Spine — Edge-Leaf organizujemy na podsieciach 169.254.10X.Y/31, gdzie dokładnie tak samo X — numer Spine, Y — sieć P2P /31.
4. Adresy łącznikowe z Edge-Leaf w magistralę MPLS. Tutaj sytuacja jest nieco inna — miejsce połączenia wszystkich kawałków w jeden tort, dlatego nie możemy użyć tych samych adresów — musimy wybierać następną wolną podsieć. Dlatego weźmiemy za podstawę 192.168.0.0/16 i będziemy z niej wydobywać wolne.
5. Adresy Loopback. Przeznaczymy na nie cały zakres 172.16.0.0/12.
   • Leaf — po /25 w DC — te same 128 szaf. Przydzielimy po /23 na region.
   • Spine — po /28 w DC — do 16 Spine. Przydzielimy po /26 na region.
   • Edge-Leaf — po /29 w DC — do 8 urządzeń. Przydzielimy po /27 na region.

Jeśli w DC nie wystarczy nam przydzielonych zakresów (a nie wystarczy — aspirujemy do hyper-scalingu), po prostu przydzielamy następny blok.

Tak wygląda obraz IP adresacji.

Loopback’i:

Prefiks
Rola urządzenia
Region
DC

172.16.0.0/23
edge
 
 

172.16.0.0/27
pl
 

172.16.0.0/29
msk

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
bcn

172.16.0.40/29
mlg

172.16.0.64/27
cn
 

172.16.0.64/29
sha

172.16.0.72/29
sia

172.16.2.0/23
spine
 
 

172.16.2.0/26
pl
 

172.16.2.0/28
msk

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
bcn

172.16.2.80/28
mlg

172.16.2.128/26
cn
 

172.16.2.128/28
sha

172.16.2.144/28
sia

172.16.8.0/21
leaf
 
 

172.16.8.0/23
pl
 

172.16.8.0/25
msk

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
bcn

172.16.10.128/25
mlg

172.16.12.0/23
cn
 

172.16.12.0/25
sha

172.16.12.128/25
sia

Underlay:

Prefiks
Region
DC

10.0.0.0/17
pl
 

10.0.0.0/19
msk

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
bcn

10.0.160.0/19
mlg

10.1.0.0/17
cn
 

10.1.0.0/19
sha

10.1.32.0/19
sia

Laboratoria

Dwaj dostawcy. Jedna sieć. ADMM.

Juniper + Arista. Ubuntu. Stara dobra Eva.

Liczba zasobów na naszej wirtualce w Miranie jest ograniczona, dlatego na potrzeby praktyki będziemy używać tak uproszczonej sieci.

Dwa centra danych: Kazan i Barcelona.

• Po dwa spine w każdym: Juniper i Arista.
• Po jednym torze (Leaf) w każdym — Juniper i Arista, z jednym podłączonym hostem (weźmiemy lekki Cisco IOL do tego).
• Po jednej nodze Edge-Leaf (na razie tylko Juniper).
• Jeden przełącznik Cisco, aby rządzić wszystkimi.
• Oprócz sprzętu sieciowego uruchomiliśmy maszynę wirtualną jako kontroler. Pod zarządzaniem Ubuntu.
  Ma ona dostęp do wszystkich urządzeń, będą na niej działać systemy IPAM/DCIM, zbiór skryptów Pythona, Ansible i wszystko inne, co może być nam potrzebne.

Pełna konfiguracja wszystkich urządzeń sieciowych, które będziemy próbować odtworzyć za pomocą automatyzacji.

Podsumowanie

Czy to również jest przyjęta zasada? Zrobić krótkie podsumowanie pod każdym artykułem?

Tak więc wybraliśmy trójwarstwową sieć Clos w DC, ponieważ oczekujemy wiele ruchu East-West i chcemy ECMP.

Podzieliliśmy sieć na fizyczną (underlay) i wirtualną (overlay). Przy czym overlay zaczyna się od hosta — w ten sposób uprościliśmy wymagania dotyczące underlay.

Wybraliśmy BGP jako protokół routingu w sieciach anedralii ze względu na jego skalowalność i elastyczność polityk.

Będziemy mieć oddzielne węzły do organizacji DCI — Edge-leaf.
Na magistrali będzie OSPF+LDP.
DCI będzie realizowane na podstawie MPLS L3VPN.
Dla połączeń P2P adresy IP będziemy obliczać algorytmicznie na podstawie nazw urządzeń.
Loopbacki będziemy przypisywać zgodnie z rolą urządzeń i ich lokalizacją sekwencyjnie.
Prefiksy anedralii — tylko na przełączniki Leaf sekwencyjnie w oparciu o ich lokalizację.

Zakładając, że w tej chwili nie mamy jeszcze zainstalowanego sprzętu.
Dlatego nasze następne kroki będą polegały na wprowadzeniu ich do systemów (IPAM, inwentarz), zorganizowaniu dostępu, wygenerowaniu konfiguracji i wdrożeniu jej.

W następnym artykule przyjrzymy się Netbox — systemowi inwentaryzacji i zarządzania przestrzenią IP w DC.

Dziękuję

• Andriej Gazkow aka @glazgoo za korektę i poprawki.
• Aleksandr Klimenko aka @v00lk za korektę i poprawki.
• Artiom Czernobaj za KDPW.

Źródło: habr.com