Powiązane artykuły udostępnione przeze mnie na temat automatyzacji sieci można znaleźć w katalogu „NetDevOps od podstaw”
W ostatnich latach, wraz z ciągłym rozwojem globalnej dziedziny przetwarzania w chmurze i ciągłym rozwojem biznesu, technologia sieciowa również nadal się rozwija i pojawiła się technologia SDN. Od pierwotnej, podstawowej idei oddzielenia przesyłania i kontroli w oparciu o Openflow, ludzie nadal się rozwijają. W przypadku rozszerzenia SDN ludzie mogą obecnie osiągnąć konsensus, że Openflow nie jest już warunkiem koniecznym (ale oddzielenie przekazywania i kontroli jest nadal jest podstawowym warunkiem), a programowalność sieci powoli staje się jednym z ważnych kryteriów pomiaru architektury SDN.
Programowalne operacje tradycyjnego sprzętu sieciowego są generalnie oparte na protokołach CLI i SNMP. Niezależnie od tego, czy są to skrypty, czy oprogramowanie do zarządzania siecią, wszystkie są opracowywane na tej podstawie w celu osiągnięcia szerokiego zakresu programowalności sieci, o którym będziemy dzisiaj mówić. możliwości, realizując w ten sposób automatyzację wielu scenariuszy. Niektóre urządzenia obsługują konfigurację niektórych interfejsów internetowych i zastąpienie ogólnej konfiguracji poprzez XML. Są to bardzo rzadkie przypadki i nie będą szczegółowo opisywane w tym artykule.
interfejs wiersza polecenia
CLI (interfejs wiersza poleceń) umożliwia interakcję człowiek-komputer za pośrednictwem wiersza poleceń. Jest to umiejętność niezbędna pracownikom sieci. Ludzie codziennie otwierają na urządzeniu oprogramowanie SSH lub Telnet, następnie wklejają konfigurację, zapisują ją i zaczynają obowiązywać. Któregoś dnia ludzie znudzili się tego rodzaju powtarzaniem i użyli programu do automatycznego generowania skryptów konfiguracyjnych, logowania się do urządzenia partiami i wydawania konfiguracji, aby zaczęły obowiązywać, realizując automatyzację. Jest to metoda programowalna sieciowo. Porozmawiajmy o zaletach, które są bardzo spójne z ludzkim myśleniem, pomysłami i istniejącymi systemami technicznymi. Ostatecznie jednak takie podejście faworyzuje ludzi zamiast urządzeń sieciowych. Ma następujące wady:
-Istnieją ogromne różnice w zestawach poleceń pomiędzy producentami. Nie tylko producenci, ale różne wersje oprogramowania tego samego modelu mogą znacznie się różnić.
-Programiści muszą znać zestaw poleceń i sposób jego używania. Istnieją zagrożenia bezpieczeństwa na poziomie konfiguracji. Przykładowo jednym ruchem ręki port, który chciałem otworzyć, zamienił się w zamknięcie portu…
-Nie ma obowiązkowych wymagań dotyczących protokołów transmisji (SSH i Telnet) i istnieją zagrożenia bezpieczeństwa produkcji.
-Proces analizowania i generowania konfiguracji jest niezwykle skomplikowany. W wielu przypadkach zapisane reguły mogą być nieskończenie bliskie tylko „prawdy”, ale nie całej „prawdy”.
-Nie ma transakcyjności, a konfiguracja może częściowo zadziałać, a część nie.
- Nie ma zautomatyzowanego mechanizmu kontroli i jest to całkowicie zależne od ludzi. Chcę na przykład sprawdzić, czy wygenerowany skrypt jest poprawny. Istnieje sposób, ale jest on bardzo trudny i często trudny do łatwego wdrożenia.
-Nie mam pojęcia o modelowaniu danych
CLI jest zawsze sposobem interakcji człowiek-komputer. Może zapewnić sieci pewne możliwości programowania za pomocą programów, ale w końcu nie jest to metoda, która z natury jest programowalna przez sieć. W obliczu obecnej fali przetwarzania w chmurze i SDN nie nadaje się on do zautomatyzowanego wdrażania na dużą skalę w sieci, a jego programowalność jest ograniczona. Osobom z zewnątrz trudno jest zrozumieć trudność rozwoju.
SNMP
SNMP (SNMP, Simple Network Management Protocol) protokół ten może obsługiwać systemy zarządzania siecią w celu monitorowania, czy urządzenia podłączone do sieci znajdują się w jakiejkolwiek sytuacji, która wymaga uwagi kierownictwa. Składa się z zestawu standardów zarządzania siecią, w tym protokołu warstwy aplikacji, schematu bazy danych i zestawu obiektów danych.
W przypadku treści w Wikipedii wyróżniamy zarządzanie siecią, monitorowanie i obiekty danych. Służy do zarządzania siecią, można go konfigurować i gromadzić, a służy głównie do monitorowania. Posiada modelowanie danych w celu ustrukturyzowania niektórych modułów, charakterystyk i danych o stanie sprzętu sieciowego. Stosowany jest głównie w systemach zarządzania siecią (głównie monitorowania). Następnie porozmawiajmy o jego wadach:
-Słaba czytelność. Woli „maszynę” w człowieku-maszynie. Nie jest czytelny, gdy jest używany, a dane modelowania również nie są czytelne. Wykorzystuje nadzbiór ASN.1.
- Bezpieczeństwo jest ograniczone. Istnieją trzy wersje: v1, v2c i v3, a bezpieczeństwo jest ulepszane sekwencyjnie. Jednak najczęstszym jest v2c, który ma ograniczone bezpieczeństwo. Wersja v3 jest z założenia bardzo bezpieczna, ale nie jest uniwersalna. . .
-Nie ma mechanizmu tworzenia kopii zapasowych, odzyskiwania ani wycofywania. Mamy także show run i inne metody tworzenia kopii zapasowych wiersza poleceń, ale snmp. . .
-Bardzo mało pisze. Dużo czytaj, mało pisz, używane głównie do monitorowania.
- Ilość danych, które można zebrać, jest ograniczona i nie można uzyskać konfiguracji całego urządzenia. Wiele razy okazuje się, że możemy użyć cli do zebrania danych, ale nie możemy użyć snmp do ich zebrania.
-Występuje wąskie gardło w wydajności. Górny limit zbieranych danych wynosi 64 KB, a szczegółowość zbierania jest zbyt duża. W dużych i złożonych sieciach może to zająć kilka minut lub dłużej. To również podkreśla ważną kwestię. Nasze wymagania dotyczące szczegółowości są również bardzo rygorystyczne. Wiele razy mamy nadzieję zbierać ruch portowy co kilka sekund. Myślę, że w dużych sieciach tradycyjne oprogramowanie do zarządzania siecią jest… Aby rozwinąć jeszcze jedno zdanie, obecną metodą jest telemetria (taka jak gRPC), która może osiągnąć poziom mikrosekund, a niektóre wymagają kombinacji oprogramowania i sprzętu. Jeszcze nie jest to popularne, ale w przyszłości musi być trendem. A co do tego, kiedy to nastąpi w przyszłości…
-Od chwili swoich narodzin protokół SNMP był szeroko stosowany w dziedzinie monitorowania sieci w celu uzyskania danych do monitorowania. Brak i złożoność możliwości konfiguracyjnych spowodowały, że są one rzadko wykorzystywane w konfiguracji sieci. Programowalna sieć tylko do odczytu.
Protokół Netconf i model YANG
Jakiego rodzaju protokoły zarządzania siecią potrzebujemy, aby lepiej realizować programowalność sieci i poprawiać poziom automatyzacji, w obliczu nowej generacji sieci?
IETF zaproponował następujące pomysły w RFC3535 w 2002 roku (właściwie jest ich 33. W oparciu o informacje dostępne w Internecie i wiedzę autora napisałem następujące pomysły):
1. Istnieje programowalny interfejs do konfiguracji sieci
2. Tę samą konfigurację można stosować u różnych producentów i modeli
3. Potrzeba ujednolicenia języka modelowania z dobrą czytelnością
4. Pełne funkcje sprawdzania błędów i odzyskiwania
5. Transakcyjne
Jeśli masz pomysł, po prostu go zrealizuj. W 2006 roku IETF zaproponował protokół Netconf, który rozwiązał problemy wynikające z RFC3535. Początkowy Netconf określał jedynie podstawowe ramy i operacje protokołu oraz zdefiniował rozwiązania, które uwzględniały niektóre problemy RFC3535. Nie przewidywał jednolitego języka modelowania. Dlatego sprzęt niektórych wczesnych producentów obsługiwał tylko niektóre podstawowe operacje Netconf i nie korzystał z ujednoliconej dolnej warstwy. Język modelowania danych.
RFC6020 został wydany w 2010 roku, proponując język modelowania YANG Model i metodę łączenia go z NETCONF. Jedna definicja to język modelowania danych, który ujednolica podstawową logikę zasobów między producentami, a druga definicja to ujednolicony zestaw poleceń dla operacji każdego producenta na danych konfiguracyjnych i danych o stanie. Instancje danych utworzone przez model YANG są opakowane w protokół Netconf. Transmisja, oba są ze sobą łączone w celu zbudowania nowego zestawu uniwersalnych programowalnych interfejsów sieciowych na nową erę w oparciu o model YANG i napędzanych protokołem Netconf.
Po 2016 roku protokół Netconf został ściśle zintegrowany z modelem YANG i stał się popularny. Jak dotąd, gdy przyjrzymy się niektórym aspektom oprogramowania architektury SDN, słyszeliśmy mniej więcej te dwa terminy.
YANG i Netconf, jeden jest statyczny, a drugi dynamiczny, podobnie jak yin i yang. Obaj stworzyli programowalny sieciowo świat następnej ery. (Kiedy spojrzymy na magazyn YANG na githubie, odkryjemy również, że jego ikoną jest Tai Chi, a związek pomiędzy jego nazwą a „Yang” w pewnym stopniu ujawnia pomysły projektowe oryginalnego projektanta).
Następnie krótko porozmawiamy o modelu YANG i protokole Netconf. Porozmawiajmy najpierw o języku modelowania danych YANG, aby zobaczyć, jak opisuje on cyfrowego bliźniaka tego sieciowego świata.
Model YANG
W dokumencie RFC6020 rozdział otwierający wyraźnie stwierdza, YANG, język modelowania danych dla protokołu konfiguracji sieci. Jest to skrót od Yet Another Next Generation (Yang) Data Modeling Language. Jest to język modelowania używany do opisu koncepcji sieci.
Obsługuje definiowanie list, słowników i jeszcze bardziej złożonych struktur danych, obsługuje ograniczenia, wyliczenia, import referencji, zarządzanie wersjami i przestrzenie nazw. Ze względu na miejsce podajemy krótkie wyjaśnienie. Aby uzyskać szczegółowe informacje, możesz zapoznać się z:
Potrafi bardzo prosto opisać to urządzenie sieciowe w ustrukturyzowanym języku. Na przykład dla definicji portu:
Jako profesjonalny personel zajmujący się obsługą i konserwacją, dysponujący odrobiną podstaw sieci i odrobiną podstaw programowania, możesz stosunkowo łatwo zrozumieć definicję portu. Jest to struktura listowa i może być ich wiele. Jednym z jego atrybutów jest nazwa-interfejsu (również klucz). , unikalny, niepowtarzalny), a także atrybut szybkości i atrybut dupleksu, które są ciągami znaków.
Model YANG opisuje wiele atrybutów urządzenia sieciowego, w tym stan konfiguracji i stan działania.
W ten sposób Model YANG opisuje świat online za pomocą ustrukturyzowanego języka. Jeśli jesteś zainteresowany, możesz przeczytać powyższy wpis na blogu internetowym, który zawiera bardzo szczegółowy opis.
Można go bardzo dobrze przekonwertować na dane XML i zapakować w protokół Netconf w celu transmisji (wyjaśnimy to później):
Jednocześnie, aby zniwelować różnice pomiędzy dostawcami, Openconfig pod przewodnictwem Google ujednolicił model danych. Na oficjalnej stronie internetowej widzimy hasło „Neutralne dla dostawców, oparte na modelach zarządzanie siecią zaprojektowane przez użytkowników”, zaprojektowane przez użytkowników i wieloplatformowe. Programowanie sieciowe typowe dla dostawców, oparte na modelach (najpierw przetłumaczmy to w ten sposób). Mówiąc najprościej, chodzi o to, aby modelowanie pomiędzy różnymi producentami było takie samo, tak aby konfigurując pewne dane, nie trzeba było przeglądać po kolei prywatnego modelu Yang każdego producenta. Ale Internet zawsze ma prywatne protokoły, a różni producenci zawsze będą tworzyć nowe, lepsze protokoły prywatne w celu „lepszego doświadczenia użytkownika” i „lepszej strategii biznesowej” (jest to w rzeczywistości grzech pierworodny producentów sieci). Zdjęcie pokazuje niektóre z częściej używanych implementacji modelu yang openconfig.
Sądząc po obrazku, myślę, że jest ich całkiem sporo, a powszechnie stosowane konfiguracje są w miarę kompletne. Ale w praktyce zależy to od tego, czy producent wspiera także te modele Yang. Zasadniczo obsługiwane są niektóre urządzenia wyższej wersji danego tematu. Krajowym jeszcze się nie przyjrzałem.
Sieci nie mogą być dokładnie takie same. Dla inżyniera zajmującego się obsługą i konserwacją sieci osiągnięcie tego samego celu jest błogosławieństwem!
openconfig można znaleźć w https://github.com/openconfig/public/tree/master/release/models
Prywatne modele Yang można znaleźć na różnych oficjalnych stronach internetowych.
Protokół Netconfa
Po rozmowie o modelu Yang, porozmawiajmy o protokole Netconf. Model Yang definiuje cyfrowy opis świata sieci, a Netconf definiuje pozyskiwanie (get) i dostosowywanie (config) danych.
Netconf hermetyzuje dane świata opisanego przez model Yang, aby zrealizować zarządzanie światem sieciowym.
Dane Yang są hermetyzowane w formacie XML, a następnie zarządzane poprzez protokół Netconf. Jest to protokół ze świetnym, warstwowym pomysłem, opisującym niektóre szczegóły protokołu w sposób hierarchiczny. Spójrzmy na zdjęcie powyżej.
-Transmisja: Netconf jest przesyłany poprzez protokół SSH, jest zorientowany na połączenie i ma gwarancje bezpieczeństwa.
-Wiadomość: Wykonaj zdalne połączenie z urządzeniem sieciowym poprzez RPC, menedżer sieci wysyła żądanie RPC, a urządzenie sieciowe wznawia odpowiadanie na RPC.
-Operacja: To jest dusza Netconfa. Obsługuje get (dane konfiguracyjne i uruchomieniowe), get-config (pobieranie danych konfiguracyjnych, a urządzenie może mieć wiele danych konfiguracyjnych, jedno działające, jedno uruchamiane, wielu kandydatów), edit -config (konfiguruje parametry urządzenia sieciowego, obsługuje dodawanie, usuwanie i modyfikacja), Delete-config, copy-config (skopiuj konfigurację do miejsca docelowego, miejscem docelowym może być FTP, plik lub działająca konfiguracja itp.), lock\unlock (zablokuj konfigurację, aby zapobiec konfliktom konfiguracji lub awariom spowodowanym przez operacje wieloprocesowe) i tak dalej.
-Dane: dane to dane Yang zapakowane w XML. Podobnie jak port, który opisaliśmy powyżej, dane strukturalne są łatwe do zaprogramowania. Używany do opisu danych, które mają zostać skonfigurowane, usunięte lub uzyskane.
Są to cztery warstwy Netconfa. Strona sterująca i urządzenie sieciowe komunikują się poprzez Netconf, tradycyjnym protokołem ssh, wykorzystując podsystem Netconf, a domyślnym portem jest 830. Jak pokazano poniżej:
Ten rysunek pokazuje interakcję przy użyciu surowego ssh, ale tak naprawdę realizujemy ten proces poprzez programowanie. Później zademonstruję Ci sposób implementacji programowania.
Netconf konfiguruje urządzenia sieciowe. Proces interakcji wygląda mniej więcej następująco:
Ten obrazek jest tak niski, że widać też, że go narysowałem… Moje rozumienie Netconfa jest takie jak powyżej. Myślę, że w Internecie jest wiele nieprawidłowych zdjęć i wiele zachowań agenta serwera jest nieprawidłowych. To właśnie czuję intuicyjnie logując się na urządzenie i oczywiście pokrywa się to jeden do jednego z oficjalną dokumentacją.
Możemy spojrzeć na kilka przykładów Netconf:
Witam, zbuduj link.
Widzieliśmy kilka słów kluczowych, wersję Netconf, obsługiwany model YANG, identyfikator sesji. Jednocześnie hello wskazuje, w jakiej przestrzeni nazw działamy. W tym przypadku jest to odpowiednia wersja Netconfa.
Pobierz konfigurację
Jednym z parametrów get-cofig jest źródło, z którego pobierane są dane konfiguracyjne (uruchamianie, uruchamianie lub inne). Kolejnym parametrem jest filtr, czyli to, jakie dane zostaną uzyskane z modelu danych opisanego przez który model Yang. Odpowiada to możliwościom pierwotnie przesłanym przez urządzenie sieciowe. Jeśli operacja się powiedzie, zostaną zwrócone odpowiednie dane konfiguracyjne.
Uzyskaj dane konfiguracyjne lub uruchomieniowe
Podobnie do get-config, ale uzyskiwane jest uruchomienie konfiguracji (osobiste zrozumienie) lub uruchomienie danych. Można określić filtr.
Skopiuj konfigurację
Operacja kopiowania ma dwa parametry: źródło i miejsce docelowe. Pomyślna odpowiedź jest oznaczona tagiem OK.
Edytuj konfigurację
Podczas edycji konfiguracji określ element danych do edycji, przestrzeń nazw możliwości i odpowiednią etykietę. Na przykład ma to na celu skonfigurowanie dhcp, który jest opisany przez model Yang http://tail-f.com/ns/example/dhcp.
Zakończ sesję z wdziękiem
Jest to tego rodzaju wiadomość przesyłana tam i z powrotem za pomocą protokołu SSH. Po prostu wyodrębniamy część wiadomości, aby ułatwić wszystkim zrozumienie.
Następnie po prostu dodaj trochę treści w celach informacyjnych.
-Netconf opiera się na sesji i każdy sukces będzie miał identyfikator sesji.
-Każde żądanie ma identyfikator wiadomości, o ile stopniowo się zwiększa
-Konfiguracja danych może być zablokowana, wyłączna i obsługiwana poprzez blokadę.
-Netconf jest transakcyjny i albo wszystkie operacje są zaimplementowane, albo żadne. Jednocześnie, zgodnie z oficjalną dokumentacją strony internetowej, ta transakcyjność dotyczy konfiguracji N urządzeń sieciowych, czyli jednorazowy polimorfizm konfiguracji może wspierać transakcyjność. Ale jeszcze tego nie zrobiłem…
-Netconf obsługuje subskrypcję. Jeśli chodzi o wydajność urządzenia, rząd wielkości wynosi około 5 sesji. Mogę subskrybować określony element danych, a urządzenie powiadomi mnie, gdy ulegnie on zmianie.
-Możliwość, tak to rozumiem. Urządzenie sieciowe wysyła wersję Netconf i YANG Model, a terminal sterujący wysyła wersję Netconf. Dopiero gdy wersja Netconf będzie zgodna z obiema wersjami, będziemy mogli kontynuować. To jest moje intuicyjne odczucie. Wszelkie porady są mile widziane.
-Operacje takie jak get edit określą dane do zmiany, które można filtrować za pomocą filtra.
-copy-config obsługuje kopiowanie pełnego zestawu konfiguracji skądś dokądś. Miejscem tym może być plik FTP, konfiguracja działająca, uruchamiana i kandydująca na urządzeniu.
-Netconf obsługuje także weryfikację konfiguracji za pomocą operacji sprawdzania poprawności.
Artykuł ten wciąż ma nadzieję na popularyzację nauki i nie będę wdawał się w szczegóły. Możesz przeczytać odpowiednie protokoły RFC, które w rzeczywistości nie są zbyt długie.
W praktyce w oparciu o oprogramowanie typu open source, np. ncclient Pythona, możemy łatwo automatycznie konfigurować urządzenia sieciowe i osiągać programowalność sieci. Taka jest misja Netconf i YANG Model.
Personel sieci czyta dobrze sformatowane definicje modelu YANG i używa odpowiednich języków programowania do wykonywania programowalnych operacji na urządzeniach sieciowych w oparciu o operacje zdefiniowane przez Netconf. W ten sposób wytyczana jest ścieżka do programowalności sieci.
Rozwińmy i wyobraźmy sobie, że Model YANG zdefiniował strukturę danych urządzenia sieciowego. Możemy go obsługiwać poprzez Netconf. Czy można go obsługiwać także poprzez inne protokoły?
Odpowiedź brzmi tak. W rzeczywistości wiele innych protokołów wywodzi się z Netconf, takich jak RESTConf. Jak pokazano niżej,
Model YANG (publiczny i natywny) definiuje strukturę danych, nad którą znajdują się nowe protokoły zarządzania siecią, Netconf, RESTCon, gRPC itp. W ten sposób możemy obsługiwać urządzenia sieciowe poprzez RESTConf w oparciu o HTTP RESTful API, możemy także obsługiwać sieć urządzenia poprzez Netconf w oparciu o SSH lub możemy obsługiwać urządzenia sieciowe poprzez gRPC w oparciu o HTTP2.0. Wszystkie opierają się na YANG z dobrą strukturą danych. Modeluj, zapisz odpowiednie dane, zamknij je w formacie XML lub json, aby zaprogramować urządzenia sieciowe. To jest przyszłość programowalności sieci. Mówiąc ściślej, jest to program sterowany modelem, programowanie sieci oparte na modelu. Inżynierowie sieci stopniowo skupiają się na parametrach urządzenia zamiast na zestawie poleceń i konfigurują parametry sieci, czytając odpowiedni model danych.
Na koniec napiszę, dlaczego warto otworzyć to konto publiczne. W szkole uczyłem się informatyki i technologii. Po wejściu na stanowisko pracy zajmowałem się obsługą i konserwacją sieci. Myśląc o tym, powodem, dla którego zostałem podzielony na zespoły, może być to, że byłem doktorantem w Instytucie Badań Technologii Sieciowych (podręcznik zabawny). Od samego początku zajmowałem się operacjami sieciowymi. Na późniejszym etapie eksploatacji i konserwacji zastosowano narzędzia ułatwiające pracę i poprawiające efektywność w oparciu o CLI. Później narzędzia te stopniowo przekształcano w aplikacje internetowe o strukturze BS. Były stale narażone na nowe technologie i stale wzbogacały się o nowe funkcje.
Na szczęście nadążyli za rozwojem technologii open source i SDN, a ja stopniowo przeniosłem się do pracy w NetDevOps i wykorzystałem swoje umiejętności programistyczne do poprawy możliwości obsługi i utrzymania zespołu. Pisanie tej linii kodu również sprawiało mi przyjemność. W miarę pisania stopniowo odkrywa się, że NetDevOps powinien być umiejętnością, którą każdy inżynier sieciowy powinien posiadać w przyszłości (każdy dolewa oliwy do ognia), aby mógł osiągnąć zarówno planowanie na wysokim poziomie, jak i szybkie wdrożenie. Patrząc wstecz na niektóre informacje w Internecie, szczerze mówiąc, w Chinach jest ich bardzo niewiele, a atmosfera w kraju nie jest zbyt silna. Wiele krajowego oprogramowania opiera się na starym CLI i snmp, a wszyscy nadal używają do pracy narzędzi tekstowych i narzędzi SSH. Mam więc nadzieję, że jamogę uczyć innych, jak łowić ryby, dzielić się moim doświadczeniem (doły) i umiejętnościami z większą liczbą inżynierów zajmujących się obsługą i konserwacją siecii zrobię co w mojej mocy. Xiao Chu powiedział, że możesz się czegoś nauczyć, aby zmniejszyć obciążenie pracą, a skupiając się na odległej przyszłości, obsługa i konserwacja sieci domowej mogą naprawdę ewoluować w kierunku automatyzacji.
W przyszłości nagram kilka filmów i napiszę kilka artykułów. Pisanie dokumentu wydaje się naprawdę trudne. Zapraszamy do subskrybowania, zbierania, klikania Lubię to i oglądania.
dodatek: Typowe operacje Netconf
Projekt rozwiązania DWDM OTN i wycena kosztów, proszę o kontakt ze mną, Taylorem Huangiem
