Pentru articole similare distribuite de mine despre automatizarea rețelei, vă rugăm să consultați catalogul „NetDevOps de la zero”
În ultimii ani, odată cu dezvoltarea continuă a domeniului global cloud computing și creșterea continuă a afacerilor, tehnologia rețelei a continuat să se dezvolte și a apărut tehnologia SDN. De la ideea de bază inițială a separării redirecționării și controlului bazat pe Openflow, oamenii continuă să se extindă În extinderea SDN-ului, oamenii pot ajunge în prezent la un consens că Openflow nu mai este o condiție necesară (dar separarea redirecționării și controlului este încă o condiție de bază), iar programabilitatea rețelei a devenit încet unul dintre criteriile importante pentru măsurarea unei arhitecturi SDN.
Operațiunile programabile ale echipamentelor tradiționale de rețea se bazează în general pe protocoale CLI și SNMP. Fie scripturi sau software de management al rețelei, toate sunt dezvoltate pe această bază pentru a atinge gama largă de programabilitate a rețelei despre care vom vorbi astăzi. capabilități, realizând astfel automatizarea multor scenarii. Unele dispozitive acceptă configurarea unor interfețe web și înlocuirea configurației generale prin xml. Acestea sunt foarte rare și nu vor fi descrise în detaliu în acest articol.
CLI
CLI (Command-line Interface) realizează interacțiunea om-calculator prin linia de comandă. Este o abilitate necesară pentru lucrătorii din rețea. Oamenii deschid software-ul SSH sau Telnet pe dispozitiv în fiecare zi, apoi lipesc o configurație, o salvează și își fac efectul. Într-o zi, oamenii s-au săturat de acest tip de repetare și au folosit un program pentru a genera automat scripturi de configurare, a se conecta la dispozitiv în loturi și a emite configurații pentru a intra în vigoare, realizând automatizarea. Aceasta este o metodă programabilă în rețea. Să vorbim despre avantaje, care sunt foarte în concordanță cu gândirea oamenilor, ideile și sistemele tehnice existente. Dar, în cele din urmă, această abordare favorizează oamenii față de dispozitivele din rețea. Are următoarele dezavantaje:
-Există diferențe uriașe în seturile de comandă între producători. Nu numai producătorii, ci diferite versiuni de software ale aceluiași model pot avea diferențe foarte diferite.
-Dezvoltatorii trebuie să fie familiarizați cu setul de comenzi și cu modul de utilizare. Există riscuri de securitate la nivel de configurare. De exemplu, cu o mișcare a mâinii, portul pe care voiam să-l deschid s-a transformat în închiderea portului...
-Nu există cerințe obligatorii pentru protocoalele de transmisie (SSH și Telnet) și există riscuri de securitate a producției.
-Procesul de analizare și generare a configurațiilor este extrem de complicat. În multe cazuri, regulile obișnuite scrise nu pot fi decât infinit aproape de „adevăr”, dar nu de întregul „adevăr”.
-Nu există nicio tranzacție, iar o configurație poate intra în vigoare parțial și poate să nu aibă efect.
-Nu există un mecanism de inspecție automatizat și este complet dependent de oameni. De exemplu, vreau să testez dacă scriptul generat este corect. Există o cale, dar este foarte dificil și adesea dificil de implementat cu ușurință.
- Nicio idee despre modelarea datelor
CLI este întotdeauna o modalitate de interacțiune om-calculator. Poate oferi rețelei anumite capacități de programabilitate prin programe, dar la urma urmei, nu este o metodă care este în mod inerent programabilă în rețea. Sub valul actual de cloud computing și SDN, nu este potrivit pentru implementarea automată la scară largă în rețea, iar programabilitatea sa este limitată. Este dificil pentru cei din afară să înțeleagă dificultatea dezvoltării.
SNMP
SNMP (SNMP, Simple Network Management Protocol), acest protocol poate suporta sisteme de management al rețelei pentru a monitoriza dacă dispozitivele conectate la rețea au vreo situație care să atragă atenția managementului. Acesta constă dintr-un set de standarde de management al rețelei, inclusiv un protocol de nivel de aplicație, o schemă de bază de date și un set de obiecte de date.
Pentru o bucată de conținut din Wikipedia, evidențiem gestionarea rețelei, monitorizarea și obiectele de date. Este folosit pentru gestionarea rețelei, poate fi configurat și colectat și este folosit în principal pentru monitorizare. Are modelare de date pentru a structura unele module, caracteristici și date de stare ale echipamentelor de rețea. Este utilizat în principal pentru sistemele de management al rețelei (în cea mai mare parte monitorizare). Atunci să vorbim despre deficiențele sale:
- Lizibilitate slabă. Preferă „mașina” în om-mașină. Nu este lizibil atunci când este utilizat, iar datele de modelare nu sunt, de asemenea, lizibile. Utilizează un superset de ASN.1.
-Securitatea este limitată. Există trei versiuni: v1, v2c și v3, iar securitatea este îmbunătățită în succesiune. Cu toate acestea, cel mai comun este v2c, care are securitate limitată. Versiunea v3 este foarte sigură prin design, dar nu este universală. . .
-Nu există mecanism de backup, recuperare sau rollback. Avem, de asemenea, show run și alte metode pentru a face backup pentru linia de comandă, dar snmp. . .
- Foarte puține scrieri. Citiți mult, scrieți puțin, folosit în mare parte pentru monitorizare.
- Elementele de date care pot fi colectate sunt limitate, iar configurația întregului dispozitiv nu poate fi obținută. De multe ori descoperim că putem folosi cli pentru a-l colecta, dar nu putem folosi snmp pentru a-l colecta.
- Există un blocaj de performanță. Limita superioară a datelor colectate este de 64K, iar granularitatea colectării este prea mare. În rețelele mari și complexe, poate dura câteva minute sau mai mult. Acest lucru evidențiază, de asemenea, punctul important. Cerințele noastre pentru granularitate sunt, de asemenea, foarte stricte. De multe ori sperăm să colectăm traficul portuar la fiecare câteva secunde. În rețelele mari, cred că software-ul tradițional de gestionare a rețelei este... Pentru a extinde încă o propoziție, metoda actuală este telemetria (cum ar fi gRPC), care poate atinge nivelul de microsecunde, iar unele necesită o combinație de software și hardware. Nu este încă popular, dar în viitor Trebuie să fie o tendință. Cât despre când va veni asta în viitor...
-De la naștere, SNMP a fost foarte folosit în domeniul monitorizării rețelei pentru a obține date pentru monitorizare. Lipsa și complexitatea capacităților de configurare au dus la o utilizare redusă a acestuia în configurarea rețelei. Rețea doar pentru citire programabilă.
Protocolul Netconf și modelul YANG
În fața următoarei generații de rețele, ce fel de protocoale de gestionare a rețelei avem nevoie pentru a realiza mai bine programabilitatea rețelei și pentru a îmbunătăți nivelul de automatizare?
IETF a propus următoarele idei în RFC3535 în 2002 (de fapt sunt 33. Pe baza informațiilor online și a cunoștințelor autorului, am scris următoarele idei):
1. Există o interfață programabilă pentru configurarea rețelei
2. Aceeași configurație poate fi utilizată între producători și modele
3. Necesitatea de a unifica un limbaj de modelare cu o bună lizibilitate
4. Completați funcțiile de verificare și recuperare a erorilor
5. Tranzacțional
Dacă aveți o idee, doar implementați-o. În 2006, IETF a propus protocolul Netconf, care a rezolvat problemele ridicate de RFC3535. Netconf inițial a stipulat doar cadrul de bază și operațiunile protocolului și a definit soluții care au luat în considerare unele probleme ale RFC3535. Nu prevedea un limbaj de modelare unificat. Prin urmare, echipamentele unor producători timpurii au suportat doar unele operațiuni de bază ale Netconf și nu au folosit un strat inferior unificat. Limbajul de modelare a datelor.
RFC6020 a fost lansat în 2010, propunând limbajul de modelare a modelului YANG și o metodă de a-l combina cu NETCONF. O definiție este un limbaj de modelare a datelor care unifică logica resurselor de bază între producători, iar cealaltă definiție este un set de comenzi unificate pentru operațiunile fiecărui producător privind datele de configurare și datele de stare. Instanțele de date create de modelul YANG sunt împachetate în protocolul Netconf. Transmisie, cele două sunt combinate între ele pentru a construi un nou set de interfețe programabile de rețea universală pentru noua eră, bazate pe modelul YANG și conduse de protocolul Netconf.
După 2016, protocolul Netconf a fost strâns integrat cu modelul YANG și a devenit popular. Până acum, când ne uităm la unele aspecte ale software-ului arhitecturii SDN, am auzit mai mult sau mai puțin acești doi termeni.
YANG și Netconf, unul este static și celălalt este dinamic, la fel ca yin și yang. Cei doi au derivat lumea programabilă în rețea a erei următoare. (Când ne uităm la depozitul YANG de pe github, vom descoperi, de asemenea, că icoana lui este Tai Chi, iar legătura dintre numele său și „Yang” dezvăluie oarecum ideile de design ale designerului original).
În continuare, vom vorbi pe scurt despre modelul YANG și protocolul Netconf. Să vorbim mai întâi despre limbajul de modelare a datelor YANG pentru a vedea cum descrie geamănul digital al acestei lumi de rețea.
Model YANG
În documentul RFC6020, capitolul de deschidere afirmă clar, YANG, un limbaj de modelare a datelor pentru protocolul de configurare a rețelei. Este abrevierea lui Yet Another Next Generation (Yang) Data Modeling Language. Este un limbaj de modelare folosit pentru a descrie concepte de rețea.
Acceptă definirea listelor, dicționarelor și structurilor de date chiar mai complexe, acceptă constrângeri, enumerari, importuri de referințe, managementul versiunilor și spații de nume. Din cauza spațiului, vom oferi o scurtă explicație. Pentru informații detaliate, puteți consulta:
Poate descrie acest dispozitiv de rețea foarte simplu într-un limbaj structurat. De exemplu, pentru definirea unui port:
În calitate de personal profesionist de operare și întreținere, cu puține elemente de bază ale rețelei și puține elemente de bază de programare, puteți înțelege definiția unui port relativ clar. Este o structură de listă și poate exista mai multe. Unul dintre atributele sale este numele-interfață (de asemenea, o cheie). , unic, nerepetabil), precum și atributul viteză și atributul duplex, ambele fiind șiruri.
Multe atribute ale unui dispozitiv de rețea sunt descrise de modelul YANG, inclusiv starea configurației și starea de funcționare.
În acest fel, YANG Model descrie lumea online folosind un limbaj structurat. Dacă sunteți interesat, puteți citi articolul de mai sus pe blogul pe Internet, care are o descriere foarte aprofundată.
Poate fi convertit în date XML foarte bine și împachetat în protocolul Netconf pentru transmitere (o vom explica mai târziu):
Totodată, pentru a nivela diferențele dintre furnizori, Openconfig, condus de Google, a standardizat modelul de date. De pe site-ul oficial, vedem sloganul „Gestionare a rețelei bazată pe model, proiectat de utilizatori, neutru pentru furnizori”, care este proiectat de utilizatori și multiplatformă. Programare de rețea, comună de furnizor, bazată pe model (să o traducem mai întâi în acest fel). Pentru a spune simplu, înseamnă a face modelarea între diverși producători la fel, astfel încât atunci când configurați anumite date, nu trebuie să căutați unul câte unul prin modelul yang privat al fiecărui producător. Dar Internetul are întotdeauna protocoale private și diferiți producători vor crea mereu protocoale private noi și mai bune pentru „o experiență mai bună a utilizatorului” și „o strategie de afaceri mai bună” (acesta este cu adevărat păcatul original al producătorilor de rețele). Imaginea prezintă unele dintre implementările de model yang openconfig cele mai frecvent utilizate.
Judecând după imagine, cred că sunt destul de multe, iar configurațiile utilizate în mod obișnuit sunt relativ complete. Dar, în practică, depinde dacă producătorul acceptă și aceste modele yang. Unele dispozitive cu versiuni superioare ale unui anumit subiect sunt practic acceptate. Încă nu m-am uitat mai atent la cele domestice.
Rețelele nu pot fi exact aceleași. Pentru un inginer care este angajat în operarea și dezvoltarea rețelei de întreținere, este o binecuvântare să poată atinge același obiectiv!
openconfig poate fi găsit în https://github.com/openconfig/public/tree/master/release/models
Puteți găsi modele yang private pe diverse site-uri oficiale.
Protocolul Netconf
După ce am vorbit despre modelul yang, să vorbim despre protocolul Netconf. Modelul yang definește descrierea digitală a lumii rețelei, iar Netconf definește achiziția (get) și ajustarea (config) de date.
Netconf încapsulează datele lumii descrise de modelul yang pentru a realiza managementul lumii rețelei.
Datele Yang sunt încapsulate în xml și apoi gestionate prin protocolul Netconf. Este un protocol cu o idee grozavă stratificată, care descrie unele detalii ale protocolului într-o manieră ierarhică. Să ne uităm la poza de mai sus.
-Transmisie: Netconf este transmis prin protocolul SSH, este orientat spre conexiune și are garanții de securitate.
-Mesaj: Efectuați un apel de la distanță către dispozitivul de rețea prin RPC, managerul de rețea emite o solicitare rpc, iar dispozitivul de rețea reia rpc-reply.
-Operațiunea: Acesta este sufletul Netconf. Acceptă get (date de configurare și de rulare), get-config (obținerea de date de configurare și un dispozitiv poate avea mai multe date de configurare, unul care rulează, unul de pornire, mai mulți candidați), edit -config (configurați parametrii dispozitivului de rețea, acceptă adăugarea, ștergere și modificare), delete-config, copy-config (copiați configurația la destinație, destinația poate fi ftp, fișier sau configurație în execuție etc.), blocare\deblocare (blocare configurație pentru a preveni conflictele de configurare sau eșecurile cauzate de operații cu mai multe procese) și așa mai departe.
-Date: datele sunt date yang împachetate în xml. La fel ca portul descris mai sus, datele structurate sunt ușor de programat. Folosit pentru a descrie datele care urmează să fie configurate sau șterse sau obținute.
Acestea sunt cele patru straturi ale Netconf. Capătul de control și dispozitivul de rețea comunică prin Netconf, prin protocolul tradițional ssh, folosind subsistemul Netconf, iar portul implicit este 830. După cum se arată mai jos:
Această figură demonstrează interacțiunea folosind ssh brut, dar de fapt implementăm acest proces prin programare. Vă voi demonstra mai târziu metoda de implementare a programării.
Netconf configurează dispozitivele de rețea. Procesul de interacțiune este aproximativ după cum urmează:
Această imagine este atât de scăzută, de asemenea, puteți vedea că a fost desenată de mine... Înțelegerea mea despre Netconf este ca mai sus. Cred că există multe imagini pe Internet care nu sunt corecte și multe comportamente ale agentului server nu sunt corecte. Aceasta este ceea ce simt intuitiv când mă conectez la dispozitiv și, desigur, corespunde unu-la-unu cu documentația oficială.
Ne putem uita la câteva exemple Netconf:
Bună, construiește un link.
Am văzut mai multe cuvinte cheie, versiunea Netconf, modelul YANG acceptat, id-ul sesiunii. În același timp, salut indică în ce spațiu de nume operăm. În acest caz, este versiunea corespunzătoare a Netconf.
Obțineți configurația
Un parametru al get-cofig este sursa, care este locul în care sunt obținute datele de configurare (rulare, pornire sau altele). Un alt parametru este filtrul, adică ce date sunt obținute din modelul de date descris de ce model yang. Aceasta corespunde capacității trimise inițial de dispozitivul de rețea. Dacă reușește, datele de configurare corespunzătoare vor fi returnate.
Obțineți date de configurare sau de rulare
Similar cu get-config, dar ceea ce se obține este rularea configurației (înțelegerea personală) sau rularea datelor. Filtrul poate fi specificat.
Copiați configurația
Operația de copiere are doi parametri, sursă și destinație. Răspunsul de succes este cu eticheta ok.
Editați configurația
Când editați configurația, specificați elementul de date care trebuie editat, spațiul de nume al capacității și eticheta corespunzătoare. De exemplu, aceasta este pentru a configura dhcp, care este descris de modelul yang http://tail-f.com/ns/example/dhcp.
Închideți sesiunea cu grație
Acest tip de mesaj este transmis înainte și înapoi în ssh. Extragem doar o parte din mesaj pentru a facilita înțelegerea tuturor.
Apoi adăugați pur și simplu conținut pentru referință.
-Netconf se bazează pe sesiune și fiecare succes va avea un ID de sesiune.
-Fiecare cerere are un ID de mesaj, atâta timp cât acesta devine treptat mai mare
-Configurația datelor poate fi blocată, exclusivă și operată prin blocare.
-Netconf este tranzacțional, iar operațiunile sunt fie toate implementate, fie niciuna. În același timp, conform documentației site-ului oficial, această tranzacționalitate este pentru configurarea N dispozitive de rețea, adică polimorfismul de configurare unică poate susține tranzacționalitatea. Dar nu am facut-o inca...
-Netconf acceptă abonament. În ceea ce privește performanța dispozitivului, ordinul de mărime este de aproximativ 5 sesiuni. Mă pot abona la un anumit articol de date și dispozitivul mă va anunța când se schimbă.
-Capacitate, așa înțeleg eu. Dispozitivul de rețea trimite versiunea Netconf și YANG Model, iar terminalul de control trimite versiunea Netconf. Numai când versiunea Netconf se potrivește cu cele două putem continua. Acesta este sentimentul meu intuitiv. Orice sfat este binevenit.
- Operațiuni precum get edit vor specifica datele care trebuie modificate, care pot fi filtrate folosind filtru.
-copy-config acceptă copierea unui set complet de configurații de undeva în undeva. Undeva poate fi un fișier FTP, rulare, pornire și configurații candidate pe dispozitiv.
-Netconf acceptă și verificarea configurației, folosind operația de validare.
Acest articol încă speră să popularizeze știința și nu voi intra în detalii. Puteți citi protocoalele relevante ale RFC, care de fapt nu este foarte lung.
În practică, pe baza unor software-uri open source, cum ar fi ncclient al lui Python, putem configura cu ușurință dispozitivele de rețea în mod automat și putem realiza programabilitatea rețelei. Aceasta este misiunea Netconf și YANG Model.
Personalul rețelei citește definițiile modelului YANG bine formatate și utilizează limbaje de programare relevante pentru a efectua operațiuni programabile pe dispozitivele de rețea pe baza operațiunilor definite de Netconf. În acest fel, calea către programabilitatea rețelei este creată.
Să ne extindem și să ne imaginăm că modelul YANG a definit structura de date a dispozitivului de rețea. Îl putem opera prin Netconf. Poate fi operat și prin alte protocoale?
Raspunsul este da. De fapt, multe alte protocoale au fost derivate din Netconf, cum ar fi RESTConf. Așa cum se arată mai jos,
Modelul YANG (public și nativ) definește structura de date, deasupra căreia sunt noi protocoale de management al rețelei, Netconf, RESTCon, gRPC, etc. În acest fel, putem opera dispozitive de rețea prin RESTConf pe baza API-ului HTTP RESTful, putem opera și rețea dispozitive prin Netconf bazat pe SSH sau putem opera dispozitive de rețea prin gRPC bazat pe HTTP2.0. Toate sunt bazate pe YANG cu o structură de date bună. Modelați, scrieți datele corespunzătoare, încapsulați-le în xml sau json pentru a programa dispozitivele de rețea. Acesta este viitorul programabilității rețelei. Pentru a fi precis, este Model Driven Program, programabilitate de rețea bazată pe model. Inginerii de rețea se concentrează treptat pe parametrii dispozitivului în loc de setul de comenzi și configurează parametrii rețelei citind modelul de date corespunzător.
La final, scriu, de ce să deschid acest cont public. Am studiat informatica și tehnologia când eram la școală. După ce am intrat la locul de muncă, am fost angajat în lucrări de operare și întreținere a rețelei. Gândindu-mă la asta, motivul pentru care am fost împărțit în echipe poate fi pentru că eram absolvent la Institutul de Cercetare în Tehnologia Rețelei (manual amuzant). De la bun început, am fost implicat în operațiuni de rețea. În etapa ulterioară de operare și întreținere, au fost folosite instrumente pentru a simplifica munca și a îmbunătăți eficiența pe baza CLI. Ulterior, instrumentele au fost dezvoltate treptat în aplicații web structurate BS. Au fost expuși în mod constant noilor tehnologii și au continuat să îmbogățească noi funcții.
Din fericire, au ajuns din urmă cu dezvoltarea tehnologiei open source și SDN și, treptat, am făcut tranziția către NetDevOps și am folosit abilitățile mele de programare pentru a îmbunătăți capacitățile de operare și întreținere ale echipei. De asemenea, mi-a plăcut să scriu această linie de cod. Pe măsură ce scrierea progresează, se descoperă treptat că NetDevOps ar trebui să fie o abilitate pe care fiecare inginer de rețea ar trebui să o aibă în viitor (toată lumea adaugă combustibil la foc), astfel încât să poată realiza atât planificarea la nivel înalt, cât și implementarea rapidă. Privind înapoi la unele informații de pe Internet, să fiu sincer, există foarte puține în China, iar atmosfera internă nu este foarte puternică. Multe software-uri autohtone se bazează pe vechiul CLI și snmp, iar toată lumea încă folosește instrumente text și instrumente SSH pentru muncă. Așa că sper că eupot să-i învețe pe alții cum să pescuiască, să-mi împărtășesc experiența (gropile) și abilitățile cu mai mulți ingineri de operare și întreținere a rețeleiși fac tot posibilul. Xiao Chu a spus că puteți învăța ceva pentru a vă reduce volumul de muncă și, concentrându-vă pe viitorul îndepărtat, operarea și întreținerea rețelei interne pot evolua cu adevărat către automatizare.
Pe viitor, voi înregistra câteva videoclipuri și voi scrie câteva articole. Este foarte obositor să scrii un document. Sunteți binevenit să vă abonați, să colectați, să dați clic pe like și să vizionați.
anexă: operațiuni comune Netconf
Proiectare soluție DWDM OTN și cotație de cost, vă rugăm să vă conectați cu mine, Taylor Huang
