SDSM się skończyło, ale niekontrolowana chęć pisania pozostała.

Przez wiele lat nasz brat cierpiał z powodu rutynowej pracy, trzymania kciuków przed podjęciem pracy i braku snu z powodu nocnych rekonwalescencji.
Ale mroczne czasy dobiegają końca.

W tym artykule rozpocznę serię o tym, jak to zrobić mnie widać automatyzację.
Po drodze zrozumiemy etapy automatyzacji, przechowywania zmiennych, formalizowania projektu, RestAPI, NETCONF, YANG, YDK i wykonamy dużo programowania.
Dla mnie oznacza, że ​​a) nie jest to prawda obiektywna, b) nie jest to bezwarunkowo najlepsze podejście, c) moja opinia, nawet w trakcie przechodzenia od pierwszego do ostatniego artykułu, może się zmienić – szczerze mówiąc, od etapu projektu do publikacji, przepisałem wszystko całkowicie dwa razy.

Zawartość

1. Cele
   1. Sieć jest jak pojedynczy organizm
   2. Testowanie konfiguracji
   3. Wersjonowanie
   4. Monitorowanie i samonaprawa usług

2. Znaczy
   1. system inwentaryzacji
   2. System zarządzania przestrzenią IP
   3. System opisu usług sieciowych
   4. Mechanizm inicjalizacji urządzenia
   5. Model konfiguracji niezależny od dostawcy
   6. Interfejs sterownika specyficzny dla dostawcy
   7. Mechanizm dostarczania konfiguracji do urządzenia
   8. CI / CD
   9. Mechanizm tworzenia kopii zapasowych i wyszukiwania odchyleń
   10. System monitorujący

3. wniosek

Spróbuję przeprowadzić ADSM w formacie nieco innym niż SDSM. W dalszym ciągu będą pojawiać się duże, szczegółowe, numerowane artykuły, a pomiędzy nimi będę publikować drobne notatki z codziennych doświadczeń. Postaram się tutaj zwalczyć perfekcjonizm i nie lizać każdego z nich.

Jakie to zabawne, że za drugim razem trzeba przejść tę samą ścieżkę.

Na początku musiałem sam pisać artykuły o sieciach, ponieważ nie było ich w RuNet.

Teraz nie mogłem znaleźć kompleksowego dokumentu, który usystematyzowałby podejścia do automatyzacji i przeanalizował powyższe technologie na prostych praktycznych przykładach.

Mogę się mylić, dlatego proszę o podanie linków do przydatnych zasobów. Nie zmieni to jednak mojej determinacji do pisania, bo głównym celem jest nauczenie się czegoś samemu, a ułatwianie życia innym to przyjemny bonus, który pieści gen dzielenia się doświadczeniami.

Spróbujemy wziąć średniej wielkości centrum danych LAN DC i opracować cały schemat automatyzacji.
Niektóre rzeczy będę robić z Tobą niemal po raz pierwszy.

Nie będę oryginalny w opisywanych tutaj pomysłach i narzędziach. Dmitry Figol ma doskonałe kanał ze streamami na ten temat.
Artykuły będą się z nimi pokrywać pod wieloma względami.

LAN DC ma 4 DC, około 250 przełączników, pół tuzina routerów i kilka zapór sieciowych.
Nie Facebook, ale wystarczająco, aby głęboko zastanowić się nad automatyzacją.
Istnieje jednak opinia, że ​​jeśli masz więcej niż 1 urządzenie, automatyzacja jest już potrzebna.
Właściwie trudno sobie wyobrazić, że ktokolwiek może teraz żyć bez przynajmniej paczki skryptów na kolana.
Chociaż słyszałem, że są biura, w których adresy IP trzymane są w Excelu, a każde z tysięcy urządzeń sieciowych jest konfigurowane ręcznie i ma swoją unikalną konfigurację. Można to oczywiście uznać za sztukę współczesną, ale uczucia inżyniera z pewnością zostaną urażone.

Cele

Teraz wyznaczymy najbardziej abstrakcyjne cele:

• Sieć jest jak pojedynczy organizm
• Testowanie konfiguracji
• Wersjonowanie stanu sieci
• Monitorowanie i samonaprawa usług

W dalszej części tego artykułu przyjrzymy się, jakich środków użyjemy, a w dalszej części przyjrzymy się szczegółowo celom i środkom.

Sieć jest jak pojedynczy organizm

Zdanie definiujące serię, choć na pierwszy rzut oka może nie wydawać się tak znaczące: skonfigurujemy sieć, a nie poszczególne urządzenia.
W ostatnich latach zaobserwowaliśmy przesunięcie akcentu w stronę traktowania sieci jako pojedynczego podmiotu, stąd tzw Sieci definiowane programowo, Sieci kierowane intencjami и Sieci autonomiczne.
W końcu czego aplikacje potrzebują globalnie od sieci: łączności między punktami A i B (no cóż, czasami +B-Z) i izolacji od innych aplikacji i użytkowników.

I takie jest nasze zadanie w tej serii zbudować system, zachowując obecną konfigurację całą sieć, która jest już rozłożona na rzeczywistą konfigurację na każdym urządzeniu zgodnie z jego rolą i lokalizacją.
System zarządzanie siecią oznacza, że ​​aby wprowadzić zmiany, kontaktujemy się z nią, a ona z kolei oblicza pożądany stan dla każdego urządzenia i konfiguruje je.
W ten sposób minimalizujemy ręczny dostęp do CLI niemal do zera – wszelkie zmiany w ustawieniach urządzenia czy projekcie sieci muszą zostać sformalizowane i udokumentowane – a dopiero potem wdrożone na niezbędne elementy sieci.

To znaczy, gdybyśmy na przykład zdecydowali, że odtąd przełączniki stojakowe w Kazaniu powinny ogłaszać dwie sieci zamiast jednej, zrobilibyśmy to

1. Najpierw dokumentujemy zmiany w systemach
2. Generowanie docelowej konfiguracji wszystkich urządzeń sieciowych
3. Uruchamiamy program do aktualizacji konfiguracji sieci, który oblicza, co należy usunąć w każdym węźle, co dodać i doprowadza węzły do ​​pożądanego stanu.

Jednocześnie zmian dokonujemy ręcznie dopiero w pierwszym kroku.

Testowanie konfiguracji

Znanyże 80% problemów występuje podczas zmian konfiguracji - pośrednim dowodem na to jest to, że podczas świąt noworocznych wszystko jest zwykle spokojne.
Osobiście byłem świadkiem dziesiątek globalnych przestojów spowodowanych błędem ludzkim: niewłaściwe polecenie, konfiguracja została wykonana w niewłaściwej gałęzi, społeczność zapomniała, MPLS został globalnie zniszczony na routerze, skonfigurowano pięć elementów sprzętu, ale błąd nie został zauważyłem szóstego, stare zmiany dokonane przez inną osobę zostały popełnione. Jest mnóstwo scenariuszy.

Automatyzacja pozwoli nam popełniać mniej błędów, ale na większą skalę. W ten sposób możesz zamurować nie tylko jedno urządzenie, ale całą sieć na raz.

Od niepamiętnych czasów nasi dziadkowie bacznym okiem sprawdzali poprawność wprowadzanych zmian, kule ze stali i funkcjonalność sieci po ich wdrożeniu.
Ci dziadkowie, których praca doprowadziła do przestojów i katastrofalnych strat, pozostawili mniej potomstwa i z czasem powinni wymrzeć, ale ewolucja jest procesem powolnym i dlatego nie każdy nadal najpierw testuje zmiany w laboratorium.
Przodują jednak ci, którzy zautomatyzowali proces testowania konfiguracji i jej późniejszego zastosowania w sieci. Innymi słowy, pożyczyłem procedurę CI/CD (Ciągła integracja, ciągłe wdrażanie) od programistów.
W jednej z części przyjrzymy się, jak zaimplementować to za pomocą systemu kontroli wersji, prawdopodobnie Githuba.

Kiedy już oswoisz się z ideą sieciowego CI/CD, z dnia na dzień metoda sprawdzania konfiguracji poprzez zastosowanie jej do sieci produkcyjnej będzie wydawać się wczesnośredniowieczną ignorancją. To tak jakby uderzyć młotkiem w głowicę bojową.

Organiczna kontynuacja pomysłów na temat system zarządzanie siecią i CI/CD staje się pełną wersją konfiguracji.

Wersjonowanie

Założymy, że przy jakichkolwiek, nawet najmniejszych zmianach, nawet na jednym niezauważalnym urządzeniu, cała sieć przechodzi z jednego stanu do drugiego.
I zawsze nie wykonujemy polecenia na urządzeniu, zmieniamy stan sieci.
Nazwijmy więc te stany wersjami?

Załóżmy, że bieżąca wersja to 1.0.0.
Czy zmienił się adres IP interfejsu Loopback na jednym z ToRów? To jest wersja pomocnicza i będzie oznaczona numerem 1.0.1.
Zrewidowaliśmy politykę importowania tras do BGP - trochę poważniej - już 1.1.0
Postanowiliśmy pozbyć się protokołu IGP i przejść wyłącznie na BGP – to już radykalna zmiana konstrukcyjna – wersja 2.0.0.

Jednocześnie różne DC mogą mieć różne wersje - sieć się rozwija, instaluje się nowy sprzęt, gdzieś dodawane są nowe poziomy kolców, a nie w innych itp.

Про wersjonowanie semantyczne porozmawiamy w osobnym artykule.

Powtarzam - każda zmiana (z wyjątkiem poleceń debugowania) jest aktualizacją wersji. Administratorzy muszą zostać powiadomieni o wszelkich odstępstwach od aktualnej wersji.

To samo tyczy się cofania zmian - nie jest to anulowanie ostatnich poleceń, nie jest to cofanie przy użyciu systemu operacyjnego urządzenia - jest to przywracanie całej sieci do nowej (starej) wersji.

Monitorowanie i samonaprawa usług

To oczywiste zadanie osiągnęło nowy poziom w nowoczesnych sieciach.
Często duzi usługodawcy przyjmują podejście, że nieudaną usługę należy naprawić bardzo szybko i zgłosić nową, zamiast zastanawiać się, co się stało.
„Bardzo” oznacza, że ​​trzeba obficie objąć ze wszystkich stron monitoringiem, który w ciągu kilku sekund wykryje najmniejsze odchylenia od normy.
I tutaj zwykłe wskaźniki, takie jak obciążenie interfejsu czy dostępność węzła, już nie wystarczą. Ręczne ich monitorowanie przez dyżurnego również nie wystarczy.
Dla wielu rzeczy powinno być Samo leczenie — światła monitorujące zmieniły kolor na czerwony, poszliśmy i sami przyłożyliśmy babkę tam, gdzie bolało.

I tutaj monitorujemy także nie tylko poszczególne urządzenia, ale także stan całej sieci, zarówno białej skrzynki, która jest stosunkowo zrozumiała, jak i czarnej skrzynki, która jest bardziej skomplikowana.

Czego będziemy potrzebować do realizacji tak ambitnych planów?

• Miej listę wszystkich urządzeń w sieci, ich lokalizację, role, modele, wersje oprogramowania.
  kazan-leaf-1.lmu.net, Kazań, liść, Juniper QFX 5120, R18.3.
• Posiadaj system opisu usług sieciowych.
  IGP, BGP, L2/3VPN, Polityka, ACL, NTP, SSH.
• Możliwość inicjalizacji urządzenia.
  Nazwa hosta, zarządzanie IP, zarządzanie trasą, użytkownicy, klucze RSA, LLDP, NETCONF
• Skonfiguruj urządzenie i doprowadź konfigurację do żądanej (w tym starej) wersji.
• Konfiguracja testowa
• Okresowo sprawdzaj stan wszystkich urządzeń pod kątem odchyleń od aktualnego i zgłaszaj komu powinien się on udać.
  W ciągu nocy ktoś po cichu dodał regułę do listy ACL.
• Monitoruj wydajność.

Znaczy

Brzmi to wystarczająco skomplikowanie, aby rozpocząć rozkładanie projektu na komponenty.

A będzie ich dziesięć:

1. system inwentaryzacji
2. System zarządzania przestrzenią IP
3. System opisu usług sieciowych
4. Mechanizm inicjalizacji urządzenia
5. Model konfiguracji niezależny od dostawcy
6. Interfejs sterownika specyficzny dla dostawcy
7. Mechanizm dostarczania konfiguracji do urządzenia
8. CI / CD
9. Mechanizm tworzenia kopii zapasowych i wyszukiwania odchyleń
10. System monitorujący

To swoją drogą przykład tego, jak zmieniło się spojrzenie na cele cyklu – w projekcie znalazły się 4 elementy.

Na ilustracji przedstawiłem wszystkie elementy oraz samo urządzenie.
Przecinające się elementy oddziałują na siebie.
Im większy blok, tym więcej uwagi należy poświęcić temu elementowi.

Komponent 1: System inwentaryzacji

Oczywiście chcemy wiedzieć, jaki sprzęt, gdzie się znajduje, do czego jest podłączony.
System inwentaryzacji jest integralną częścią każdego przedsiębiorstwa.
Najczęściej przedsiębiorstwo posiada odrębny system inwentaryzacji urządzeń sieciowych, który rozwiązuje bardziej szczegółowe problemy.
W ramach tego cyklu artykułów będziemy go nazywać DCIM – Data Center Infrastructure Management. Chociaż sam termin DCIM, ściśle rzecz biorąc, obejmuje znacznie więcej.

Dla naszych celów będziemy przechowywać w nim następujące informacje o urządzeniu:

• Numer inwentarzowy
• Opis tytułu
• Model (Huawei CE12800, Juniper QFX5120 itp.)
• Parametry charakterystyczne (płyty, interfejsy itp.)
• Rola (Liść, kręgosłup, router graniczny itp.)
• Lokalizacja (region, miasto, centrum danych, szafa, jednostka)
• Połączenia między urządzeniami
• Topologia sieci

Jest zupełnie jasne, że sami chcemy to wszystko wiedzieć.
Ale czy to pomoże w celach automatyzacji?
Z pewnością.
Przykładowo wiemy, że w danym centrum danych na przełącznikach Leaf, jeśli jest to Huawei, należy zastosować listy ACL do filtrowania określonego ruchu po sieci VLAN, a jeśli jest to Juniper, to na jednostce 0 interfejsu fizycznego.
Możesz też wdrożyć nowy serwer Syslog na wszystkich granicach w regionie.

Będziemy w nim przechowywać wirtualne urządzenia sieciowe, na przykład wirtualne routery lub reflektory root. Możemy dodać serwery DNS, NTP, Syslog i ogólnie wszystko, co w taki czy inny sposób wiąże się z siecią.

Komponent 2: System zarządzania przestrzenią IP

Tak, a obecnie istnieją zespoły osób, które śledzą prefiksy i adresy IP w pliku Excel. Jednak nowoczesne podejście to wciąż baza danych, z front-endem na nginx/apache, API i rozbudowanymi funkcjami do rejestrowania adresów IP oraz sieciami podzielonymi na VRF.
IPAM – zarządzanie adresami IP.

Dla naszych celów będziemy w nim przechowywać następujące informacje:

• VLAN
• VRF
• Sieci/podsieci
• Adresy IP
• Wiązanie adresów z urządzeniami, sieci z lokalizacjami i numerami VLAN

Znowu jasne jest, że chcemy mieć pewność, że przydzielając nowy adres IP dla pętli zwrotnej ToR, nie potkniemy się o to, że był on już komuś przypisany. Albo że dwukrotnie użyliśmy tego samego prefiksu na różnych końcach sieci.
Ale w jaki sposób pomaga to w automatyzacji?
To łatwe.
Żądamy w systemie prefiksu z rolą Loopbacks, która zawiera adresy IP dostępne do przydzielenia - jeśli zostanie znaleziony, przydzielamy adres, jeśli nie, żądamy utworzenia nowego prefiksu.
Lub tworząc konfigurację urządzenia, możemy dowiedzieć się z tego samego systemu, w którym VRF powinien znajdować się interfejs.
A przy uruchamianiu nowego serwera skrypt loguje się do systemu, dowiaduje się, w którym przełączniku znajduje się serwer, jaki port i jaka podsieć jest przypisana do interfejsu - i przydzieli z niego adres serwera.

Sugeruje to chęć połączenia DCIM i IPAM w jeden system, aby nie powielać funkcji i nie służyć dwóm podobnym podmiotom.
To właśnie zrobimy.

Komponent 3. System opisu usług sieciowych

Jeśli pierwsze dwa systemy przechowują zmienne, które należy jeszcze w jakiś sposób wykorzystać, trzeci opisuje dla każdej roli urządzenia, jak powinna być skonfigurowana.
Warto rozróżnić dwa różne rodzaje usług sieciowych:

• Infrastruktura
• Klient.

Te pierwsze mają na celu zapewnienie podstawowej łączności i kontroli urządzeń. Należą do nich VTY, SNMP, NTP, Syslog, AAA, protokoły routingu, CoPP itp.
Ci ostatni organizują obsługę klienta: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP itp.
Oczywiście zdarzają się też przypadki graniczne – gdzie uwzględnić MPLS LDP, BGP? Tak, a dla klientów można używać protokołów routingu. Ale to nie jest ważne.

Obydwa typy usług są rozkładane na elementy podstawowe konfiguracji:

• interfejsy fizyczne i logiczne (tag/anteg, mtu)
• Adresy IP i VRF (IP, IPv6, VRF)
• Listy ACL i zasady przetwarzania ruchu
• Protokoły (IGP, BGP, MPLS)
• Zasady routingu (listy prefiksów, społeczności, filtry ASN).
• Usługi użyteczności publicznej (SSH, NTP, LLDP, Syslog...)
• Itp.

Jak dokładnie to zrobimy, jeszcze nie mam pojęcia. Przyjrzymy się temu w osobnym artykule.

Gdyby było trochę bliżej życia, moglibyśmy to opisać
Przełącznik Leaf musi mieć sesje BGP ze wszystkimi podłączonymi przełącznikami Spine, importować podłączone sieci do procesu i akceptować tylko sieci z określonym prefiksem z przełączników Spine. Ogranicz CoPP IPv6 ND do 10 pps itp.
Z kolei kolce odbywają sesje ze wszystkimi podłączonymi leadami, pełniąc rolę reflektorów korzeniowych i przyjmują od nich tylko trasy o określonej długości i z określoną społecznością.

Komponent 4: Mechanizm inicjalizacji urządzenia

W tym nagłówku łączę wiele działań, które muszą zostać wykonane, aby urządzenie pojawiło się na radarze i można było uzyskać do niego zdalny dostęp.

1. Wprowadź urządzenie do systemu inwentaryzacyjnego.
2. Wybierz adres IP zarządzania.
3. Skonfiguruj do niego podstawowy dostęp:
   Nazwa hosta, adres IP zarządzania, trasa do sieci zarządzania, użytkownicy, klucze SSH, protokoły - telnet/SSH/NETCONF

Istnieją trzy podejścia:

• Wszystko jest całkowicie ręczne. Urządzenie zostaje przywiezione na stanowisko, gdzie zwykła organiczna osoba wprowadzi je do systemów, połączy się z konsolą i skonfiguruje. Może pracować w małych sieciach statycznych.
• ZTP – obsługa bezdotykowa. Sprzęt przyjechał, wstał, otrzymał adres przez DHCP, trafił na specjalny serwer i sam się skonfigurował.
• Infrastruktura serwerów konsolowych, gdzie wstępna konfiguracja odbywa się poprzez port konsoli w trybie automatycznym.

O wszystkich trzech porozmawiamy w osobnym artykule.

Komponent 5: Model konfiguracji niezależny od dostawcy

Do tej pory wszystkie systemy były odrębnymi łatkami, które udostępniały zmienne i deklaratywny opis tego, co chcielibyśmy zobaczyć w sieci. Ale prędzej czy później będziesz musiał uporać się ze szczegółami.
Na tym etapie dla każdego konkretnego urządzenia elementy podstawowe, usługi i zmienne są łączone w model konfiguracji, który faktycznie opisuje pełną konfigurację konkretnego urządzenia, tylko w sposób neutralny dla dostawcy.
Co daje ten krok? Dlaczego nie utworzyć od razu konfiguracji urządzenia, którą można po prostu przesłać?
W rzeczywistości rozwiązuje to trzy problemy:

1. Nie dostosowuj się do konkretnego interfejsu interakcji z urządzeniem. Czy to CLI, NETCONF, RESTCONF, SNMP – model będzie ten sam.
2. Nie trzymaj liczby szablonów/skryptów w zależności od liczby dostawców w sieci, a jeśli projekt się zmieni, zmień to samo w kilku miejscach.
3. Załaduj konfigurację z urządzenia (kopia zapasowa), włóż ją do dokładnie tego samego modelu i bezpośrednio porównaj konfigurację docelową z istniejącą, aby obliczyć deltę i przygotować poprawkę konfiguracyjną, która zmieni tylko te części, które są niezbędne lub wykryje odchylenia.

W wyniku tego etapu uzyskujemy konfigurację niezależną od dostawcy.

Komponent 6. Interfejs sterownika specyficzny dla dostawcy

Nie pochlebiaj sobie nadzieją, że pewnego dnia będzie można skonfigurować ciską dokładnie tak samo jak Junipera, po prostu wysyłając do nich dokładnie te same wywołania. Pomimo rosnącej popularności białych skrzynek i pojawienia się obsługi NETCONF, RESTCONF, OpenConfig, specyficzna treść dostarczana przez te protokoły różni się w zależności od dostawcy i jest to jedna z ich różnic konkurencyjnych, której nie poddają się tak łatwo.
Jest to mniej więcej to samo, co OpenContrail i OpenStack, które mają RestAPI jako interfejs NorthBound, oczekują zupełnie innych wywołań.

Zatem w piątym kroku model niezależny od dostawcy musi przyjąć taką formę, w jakiej trafi na sprzęt.
I tutaj wszystkie środki są dobre (nie): po prostu CLI, NETCONF, RESTCONF, SNMP.

Dlatego będziemy potrzebować sterownika, który przeniesie wynik poprzedniego kroku do wymaganego formatu konkretnego dostawcy: zestawu poleceń CLI, struktury XML.

Komponent 7. Mechanizm dostarczania konfiguracji do urządzenia

Wygenerowaliśmy konfigurację, ale trzeba ją jeszcze dostarczyć do urządzeń - i oczywiście nie ręcznie.
Po pierwszestajemy przed pytaniem z jakiego środka transportu skorzystamy? A dzisiaj wybór nie jest już mały:

• CLI (telnet, ssh)
• SNMP
• NETKONF
• KONF.REST
• REST API
• OpenFlow (chociaż jest to wartość odstająca, ponieważ jest to sposób na dostarczenie FIB, a nie ustawień)

Postawmy kropkę nad t tutaj. CLI jest dziedzictwem. SNMP... kaszel, kaszel.
RESTCONF to wciąż nieznane zwierzę; API REST nie jest obsługiwane przez prawie nikogo. Dlatego w serii skupimy się na NETCONF.

W rzeczywistości, jak czytelnik już zrozumiał, w tym momencie zdecydowaliśmy się już na interfejs - wynik poprzedniego kroku jest już przedstawiony w formacie wybranego interfejsu.

Po drugiei za pomocą jakich narzędzi to zrobimy?
Tutaj również jest duży wybór:

• Samodzielnie napisany skrypt lub platforma. Uzbrójmy się w ncclient i asyncIO i zróbmy wszystko sami. Ile kosztuje nas zbudowanie systemu wdrożeniowego od podstaw?
• Ansible z bogatą biblioteką modułów sieciowych.
• Sól ze swoją skromną pracą z siecią i połączeniem z Napalmem.
• Właściwie Napalm, który zna kilku dostawców i tyle, do widzenia.
• Nornir to kolejne zwierzę, które omówimy w przyszłości.

Tutaj faworyt nie został jeszcze wybrany - będziemy szukać.

Co jeszcze jest tutaj ważne? Konsekwencje zastosowania konfiguracji.
Sukces czy nie. Czy nadal jest dostęp do sprzętu czy nie?
Wygląda na to, że zatwierdzenie pomoże tutaj w potwierdzeniu i zatwierdzeniu tego, co zostało pobrane na urządzenie.
To, w połączeniu z poprawną implementacją NETCONF, znacznie zawęża zakres odpowiednich urządzeń - niewielu producentów obsługuje normalne zatwierdzenia. Ale to tylko jeden z warunków wstępnych RFP. Ostatecznie nikt nie martwi się, że żaden rosyjski dostawca nie spełni warunku interfejsu 32*100GE. A może się martwi?

Komponent 8. CI/CD

W tym momencie mamy już gotową konfigurację dla wszystkich urządzeń sieciowych.
Piszę „za wszystko”, bo mówimy o wersjonowaniu stanu sieci. Nawet jeśli zajdzie potrzeba zmiany ustawień tylko jednego przełącznika, zmiany zostaną przeliczone dla całej sieci. Oczywiście dla większości węzłów mogą one wynosić zero.

Ale jak już powiedziano powyżej, nie jesteśmy jakimś barbarzyńcą, który chce wszystko od razu wprowadzić do produkcji.
Wygenerowana konfiguracja musi najpierw przejść przez Pipeline CI/CD.

CI/CD oznacza ciągłą integrację, ciągłe wdrażanie. Jest to podejście, w którym zespół nie tylko co sześć miesięcy wydaje nową główną wersję, całkowicie zastępując starą, ale regularnie, stopniowo wdraża (wdrożenie) nową funkcjonalność w małych porcjach, z których każda jest wszechstronnie testowana pod kątem kompatybilności, bezpieczeństwa i wydajność (integracja).

Aby to zrobić, mamy system kontroli wersji monitorujący zmiany konfiguracji, laboratorium sprawdzające, czy obsługa klienta jest uszkodzona, system monitorujący, który sprawdza ten fakt, a ostatnim krokiem jest wdrożenie zmian do sieci produkcyjnej.

Z wyjątkiem poleceń debugowania, absolutnie wszystkie zmiany w sieci muszą przejść przez rurociąg CI/CD - to nasza gwarancja spokojnego życia i długiej, szczęśliwej kariery.

Komponent 9. System tworzenia kopii zapasowych i wykrywania anomalii

Cóż, nie ma już potrzeby rozmawiać o kopiach zapasowych.
Po prostu umieścimy je w git zgodnie z koroną lub faktem zmiany konfiguracji.

Ale druga część jest bardziej interesująca - ktoś powinien mieć oko na te kopie zapasowe. I w niektórych przypadkach ten ktoś musi iść i wszystko odwrócić tak jak było, a w innych miauczeć komuś, że coś jest nie tak.
Na przykład, jeśli pojawił się nowy użytkownik, który nie jest zarejestrowany w zmiennych, musisz usunąć go z hacka. A jeśli lepiej nie ruszać nowej reguły firewalla, może ktoś po prostu włączył debugowanie, a może nowa usługa, partacz, nie została zarejestrowana zgodnie z przepisami, ale ludzie już do niej dołączyli.

Nadal nie uciekniemy od małej delty w skali całej sieci, pomimo wszelkich systemów automatyki i twardej ręki kierownictwa. Aby rozwiązać problemy, nikt i tak nie będzie dodawać konfiguracji do systemów. Co więcej, mogą nawet nie zostać uwzględnione w modelu konfiguracji.

Na przykład reguła zapory sieciowej zliczająca liczbę pakietów na konkretny adres IP w celu zlokalizowania problemu jest całkowicie zwyczajną konfiguracją tymczasową.

Komponent 10. System monitorowania

Na początku nie miałem zamiaru poruszać tematu monitoringu – to wciąż obszerny, kontrowersyjny i złożony temat. Jednak w miarę postępu sprawy okazało się, że jest to integralna część automatyzacji. I nie da się tego obejść, nawet bez praktyki.

Ewoluująca myśl jest organiczną częścią procesu CI/CD. Po wdrożeniu konfiguracji do sieci musimy móc określić, czy teraz wszystko jest z nią w porządku.
I mówimy nie tylko i nie tyle o harmonogramach użycia interfejsu czy dostępności węzłów, ale o bardziej subtelnych rzeczach - obecności niezbędnych tras, atrybutów na nich, liczbie sesji BGP, sąsiadach OSPF, wydajności typu End-to-End usług nadrzędnych.
Czy dzienniki syslog do zewnętrznego serwera przestały się sumować, czy agent SFlow się zepsuł, czy spadki w kolejkach zaczęły rosnąć, czy może zerwała się łączność między jakąś parą prefiksów?

Zastanowimy się nad tym w osobnym artykule.

wniosek

Jako podstawę wybrałem jeden z nowoczesnych projektów sieci data center – L3 Clos Fabric z protokołem routingu BGP.
Tym razem zbudujemy sieć na Juniperze, bo teraz interfejs JunOs jest vanlove.

Utrudnijmy sobie życie, korzystając wyłącznie z narzędzi Open Source i sieci wielu dostawców - więc oprócz Junipera wybiorę po drodze jeszcze jednego szczęśliwca.

Plan na najbliższe publikacje wygląda mniej więcej tak:
Najpierw opowiem o sieciach wirtualnych. Po pierwsze dlatego, że chcę, a po drugie dlatego, że bez tego projekt sieci infrastruktury nie będzie zbyt jasny.
Następnie o samym projekcie sieci: topologia, routing, zasady.
Złóżmy stanowisko laboratoryjne.
Pomyślmy o tym i może poćwiczmy inicjalizację urządzenia w sieci.
A potem o każdym elemencie w intymnych szczegółach.

I tak, nie obiecuję, że z gracją zakończymy ten cykl gotowym rozwiązaniem. 🙂

Przydatne linki

• Zanim zagłębimy się w serial, warto przeczytać książkę Natashy Samoilenko Python dla inżynierów sieciowych. A może przejść kurs.
• Przyda się również lektura RFC o projekcie fabryk centrów danych z Facebooka autorstwa Petera Lapukhova.
• Dokumentacja architektury da Ci wyobrażenie o tym, jak działa Overlay SDN. Tkanina wolframowa (dawniej Open Contrail).

Dziękuję

Wąwóz rzymski. Do komentarzy i edycji.
Artem Czernobaj. Dla KDPV.

Źródło: www.habr.com