SDSM s-a terminat, dar dorința incontrolabilă de a scrie rămâne.

Timp de mulți ani, fratele nostru a suferit din cauza activităților de rutină, încrucișându-și degetele înainte de a se comite și lipsind de somn din cauza retrocedărilor nocturne.
Dar vremurile întunecate se apropie de sfârșit.

Cu acest articol voi începe o serie despre cum mă se vede automatizarea.
Pe parcurs, vom înțelege etapele de automatizare, stocarea variabilelor, formalizarea designului, RestAPI, NETCONF, YANG, YDK și vom face multă programare.
Mă înseamnă că a) nu este un adevăr obiectiv, b) nu este necondiționat cea mai bună abordare, c) părerea mea, chiar și în timpul mișcării de la primul la ultimul articol, se poate schimba - sincer să fiu, de la etapa de proiect la publicație, am rescris totul complet de două ori.

Conținut

1. goluri
   1. Rețeaua este ca un singur organism
   2. Testarea configurației
   3. Versiune
   4. Monitorizarea și autovindecarea serviciilor

2. Fonduri
   1. Sistemul de inventariere
   2. sistem de gestionare a spațiului IP
   3. Sistem de descriere a serviciilor de rețea
   4. Mecanismul de inițializare a dispozitivului
   5. Model de configurare independent de furnizor
   6. Interfață de driver specifică furnizorului
   7. Mecanism de livrare a configurației dispozitivului
   8. CI / CD
   9. Mecanism de rezervă și căutare a abaterilor
   10. Sistem de monitorizare

3. Concluzie

Voi încerca să conduc ADSM într-un format ușor diferit de SDSM. Vor continua să apară articole mari, detaliate, numerotate, iar între ele voi publica mici note din experiența de zi cu zi. Voi încerca să lupt cu perfecționismul aici și să nu-i ling pe fiecare dintre ei.

Ce amuzant este că a doua oară trebuie să treci pe aceeași cale.

La început a trebuit să scriu și eu articole despre rețele din cauza faptului că nu erau pe RuNet.

Acum nu am putut găsi un document cuprinzător care să sistematizeze abordările automatizării și să analizeze tehnologiile de mai sus folosind exemple practice simple.

S-ar putea să greșesc, așa că vă rugăm să furnizați link-uri către resurse utile. Totuși, asta nu-mi va schimba hotărârea de a scrie, pentru că scopul principal este să învăț ceva eu ​​însumi, iar să le fac viața mai ușoară altora este un bonus plăcut care mângâie gena împărtășirii experienței.

Vom încerca să luăm un centru de date LAN DC de dimensiuni medii și să elaborăm întreaga schemă de automatizare.
Voi face unele lucruri aproape pentru prima dată cu tine.

Nu voi fi original în ideile și instrumentele descrise aici. Dmitry Figol are un excelent canal cu fluxuri pe acest subiect.
Articolele se vor suprapune cu ele în multe aspecte.

LAN DC are 4 DC-uri, aproximativ 250 de comutatoare, o jumătate de duzină de routere și câteva firewall-uri.
Nu Facebook, dar suficient pentru a te face să te gândești profund la automatizare.
Există, totuși, o părere că dacă ai mai mult de 1 dispozitiv, automatizarea este deja necesară.
De fapt, este greu de imaginat că oricine poate trăi acum fără cel puțin un pachet de scripturi pentru genunchi.
Deși am auzit că există birouri unde adresele IP sunt păstrate în Excel, iar fiecare dintre miile de dispozitive din rețea este configurat manual și are propria sa configurație unică. Aceasta, desigur, poate fi trecută drept artă modernă, dar sentimentele inginerului vor fi cu siguranță jignite.

goluri

Acum ne vom stabili cele mai abstracte obiective:

• Rețeaua este ca un singur organism
• Testarea configurației
• Versiune starea rețelei
• Monitorizarea și autovindecarea serviciilor

Mai târziu în acest articol ne vom uita la ce mijloace vom folosi, iar în cele ce urmează, ne vom uita la obiectivele și mijloacele în detaliu.

Rețeaua este ca un singur organism

Sintagma definitorie a seriei, deși la prima vedere poate să nu pară atât de semnificativă: vom configura rețeaua, nu dispozitivele individuale.
În ultimii ani, am observat o schimbare în accentul către tratarea rețelei ca o singură entitate, de unde Software de rețea definit, Rețele bazate pe intenție и Rețele autonome.
La urma urmei, de ce au nevoie aplicațiile la nivel global din rețea: conectivitate între punctele A și B (bine, uneori +B-Z) și izolarea de alte aplicații și utilizatori.

Și așa este sarcina noastră în această serie construi un sistem, menținând configurația curentă intreaga retea, care este deja descompus în configurația reală pe fiecare dispozitiv în conformitate cu rolul și locația acestuia.
Sistem managementul rețelei presupune că pentru a face modificări îl contactăm, iar acesta, la rândul său, calculează starea dorită pentru fiecare dispozitiv și îl configurează.
În acest fel, minimizăm accesul manual la CLI la aproape zero - orice modificare a setărilor dispozitivului sau a designului rețelei trebuie să fie oficializată și documentată - și abia apoi implementată la elementele de rețea necesare.

Adică, de exemplu, dacă am hotărât ca de acum înainte comutatoarele de rack din Kazan să anunțe două rețele în loc de una, vom

1. Mai întâi documentăm schimbările în sisteme
2. Generarea configurației țintă a tuturor dispozitivelor din rețea
3. Lansăm programul de actualizare a configurației rețelei, care calculează ce trebuie eliminat pe fiecare nod, ce trebuie adăugat și aduce nodurile la starea dorită.

În același timp, facem modificări manual doar în primul pas.

Testarea configurației

Este cunoscutcă 80% dintre probleme apar în timpul modificărilor de configurație - dovada indirectă a acestui lucru este că în timpul sărbătorilor de Anul Nou totul este de obicei calm.
Am asistat personal la zeci de întreruperi la nivel global din cauza unei erori umane: comandă greșită, configurația a fost executată în ramura greșită, comunitatea a uitat, MPLS a fost demolat global pe router, cinci piese hardware au fost configurate, dar eroarea nu a fost observate în a șasea, au fost comise modificări vechi făcute de o altă persoană. Există o mulțime de scenarii.

Automatizarea ne va permite să facem mai puține greșeli, dar la scară mai mare. În acest fel, puteți bloca nu doar un dispozitiv, ci întreaga rețea deodată.

Din cele mai vechi timpuri, bunicii noștri au verificat corectitudinea modificărilor făcute cu un ochi atent, bile de oțel și funcționalitatea rețelei după ce au fost lansate.
Acei bunici a căror muncă a dus la perioade de nefuncționare și pierderi catastrofale au lăsat mai puțini descendenți și ar trebui să se stingă în timp, dar evoluția este un proces lent și, prin urmare, nu toată lumea încă testează mai întâi schimbările în laborator.
Cu toate acestea, în fruntea progresului se află cei care au automatizat procesul de testare a configurației și aplicarea ulterioară a acesteia în rețea. Cu alte cuvinte, am împrumutat procedura CI/CD (Integrare continuă, implementare continuă) de la dezvoltatori.
Într-una dintre părți ne vom uita la cum să implementăm acest lucru folosind un sistem de control al versiunilor, probabil Github.

Odată ce te obișnuiești cu ideea de rețea CI/CD, peste noapte metoda de verificare a unei configurații prin aplicarea acesteia într-o rețea de producție va părea ca o ignoranță medievală timpurie. Un fel de a lovi un focos cu un ciocan.

O continuare organică a ideilor despre sistem managementul rețelei și CI/CD devine o versiune completă a configurației.

Versiune

Vom presupune că, cu orice modificări, chiar și cele mai minore, chiar și pe un dispozitiv neobservat, întreaga rețea se mută de la o stare la alta.
Și nu executăm întotdeauna o comandă pe dispozitiv, schimbăm starea rețelei.
Deci, să numim aceste state versiuni?

Să presupunem că versiunea actuală este 1.0.0.
S-a schimbat adresa IP a interfeței Loopback de pe unul dintre ToR? Aceasta este o versiune minoră și va fi numerotată 1.0.1.
Am revizuit politicile de import de rute în BGP - puțin mai serios - deja 1.1.0
Am decis să scăpăm de IGP și să trecem numai la BGP - aceasta este deja o schimbare radicală de design - 2.0.0.

În același timp, diferite DC-uri pot avea versiuni diferite - rețeaua se dezvoltă, se instalează noi echipamente, se adaugă noi niveluri de coloane undeva, nu în altele etc.

despre versiunea semantică vom vorbi într-un articol separat.

Repet - orice modificare (cu excepția comenzilor de depanare) este o actualizare a versiunii. Administratorii trebuie să fie informați cu privire la orice abateri de la versiunea curentă.

Același lucru este valabil și pentru anularea modificărilor - aceasta nu este anularea ultimelor comenzi, aceasta nu este o rollback folosind sistemul de operare al dispozitivului - aceasta aduce întreaga rețea la o versiune nouă (veche).

Monitorizarea și autovindecarea serviciilor

Această sarcină evidentă a atins un nou nivel în rețelele moderne.
Adesea, marii furnizori de servicii adoptă abordarea conform căreia un serviciu eșuat trebuie remediat foarte repede și trebuie ridicat unul nou, în loc să-și dea seama ce s-a întâmplat.
„Foarte” înseamnă că trebuie să fii acoperit cu generozitate pe toate părțile cu monitorizare, care în câteva secunde va detecta cele mai mici abateri de la normă.
Și aici valorile obișnuite, precum încărcarea interfeței sau disponibilitatea nodurilor, nu mai sunt suficiente. Nici monitorizarea manuală a acestora de către ofițerul de serviciu nu este suficientă.
Pentru multe lucruri ar trebui să existe Auto vindecare — luminile de monitorizare s-au făcut roșii și ne-am dus și am aplicat singuri pătlagină acolo unde ne-a durut.

Și aici monitorizăm, de asemenea, nu numai dispozitivele individuale, ci și sănătatea întregii rețele, atât whitebox, care este relativ de înțeles, cât și blackbox, care este mai complicat.

De ce vom avea nevoie pentru a implementa planuri atât de ambițioase?

• Aveți o listă cu toate dispozitivele din rețea, locația acestora, roluri, modele, versiuni de software.
  kazan-leaf-1.lmu.net, Kazan, frunză, Juniper QFX 5120, R18.3.
• Aveți un sistem de descriere a serviciilor de rețea.
  IGP, BGP, L2/3VPN, Politică, ACL, NTP, SSH.
• Să poată inițializa dispozitivul.
  Nume gazdă, IP administrare, Rută administrare, utilizatori, chei RSA, LLDP, NETCONF
• Configurați dispozitivul și aduceți configurația la versiunea dorită (inclusiv cea veche).
• Testați configurația
• Verificați periodic starea tuturor dispozitivelor pentru abateri de la cele actuale și raportați cui ar trebui să fie.
  Peste noapte, cineva a adăugat în liniște o regulă la ACL.
• Monitorizați performanța.

Fonduri

Sună destul de complicat pentru a începe descompunerea proiectului în componente.

Și vor fi zece dintre ei:

1. Sistemul de inventariere
2. sistem de gestionare a spațiului IP
3. Sistem de descriere a serviciilor de rețea
4. Mecanismul de inițializare a dispozitivului
5. Model de configurare independent de furnizor
6. Interfață de driver specifică furnizorului
7. Mecanism de livrare a configurației dispozitivului
8. CI / CD
9. Mecanism de rezervă și căutare a abaterilor
10. Sistem de monitorizare

Acesta, apropo, este un exemplu al modului în care s-a schimbat viziunea asupra obiectivelor ciclului - au fost 4 componente în proiect.

În ilustrație am descris toate componentele și dispozitivul în sine.
Componentele care se intersectează interacționează între ele.
Cu cât blocul este mai mare, cu atât trebuie acordată mai multă atenție acestei componente.

Componenta 1: Sistemul de inventariere

Evident, vrem să știm ce echipament este amplasat unde, la ce este conectat.
Sistemul de inventariere este o parte integrantă a oricărei întreprinderi.
Cel mai adesea, o întreprindere are un sistem de inventar separat pentru dispozitivele de rețea, care rezolvă probleme mai specifice.
Ca parte a acestei serii de articole, o vom numi DCIM - Data Center Infrastructure Management. Deși termenul DCIM în sine, strict vorbind, include mult mai mult.

În scopurile noastre, vom stoca următoarele informații despre dispozitiv în el:

• Număr inventar
• Descrierea titlului
• Model (Huawei CE12800, Juniper QFX5120 etc.)
• Parametrii caracteristici (plăci, interfețe etc.)
• Rol (Router pentru frunze, coloană vertebrală, chenar etc.)
• Locație (regiune, oraș, centru de date, rack, unitate)
• Interconexiuni între dispozitive
• Topologie de rețea

Este perfect clar că noi înșine vrem să știm toate acestea.
Dar va ajuta acest lucru în scopuri de automatizare?
Desigur.
De exemplu, știm că într-un anumit centru de date pe comutatoarele Leaf, dacă este Huawei, ACL-uri pentru filtrarea anumitor trafic ar trebui aplicate pe VLAN, iar dacă este Juniper, atunci pe unitatea 0 a interfeței fizice.
Sau trebuie să lansați un nou server Syslog la toate granițele din regiune.

În el vom stoca dispozitive de rețea virtuală, de exemplu routere virtuale sau reflectoare rădăcină. Putem adauga servere DNS, NTP, Syslog si in general tot ce se refera intr-un fel sau altul la retea.

Componenta 2: Sistem de management al spațiului IP

Da, iar în prezent există echipe de oameni care țin evidența prefixelor și adreselor IP într-un fișier Excel. Dar abordarea modernă este încă o bază de date, cu un front-end pe nginx/apache, API și funcții extinse pentru înregistrarea adreselor IP și a rețelelor împărțite în VRF-uri.
IPAM - Managementul adresei IP.

În scopul nostru, vom stoca următoarele informații în el:

• VLAN
• VRF
• Rețele/Subrețele
• adrese IP
• Legarea adreselor la dispozitive, a rețelelor la locații și a numerelor VLAN

Din nou, este clar că vrem să ne asigurăm că atunci când alocam o nouă adresă IP pentru loopback-ul ToR, nu ne vom împiedica de faptul că aceasta a fost deja atribuită cuiva. Sau că am folosit același prefix de două ori la capete diferite ale rețelei.
Dar cum ajută acest lucru la automatizare?
E ușor.
Solicităm un prefix în sistem cu rolul Loopbacks, care conține adrese IP disponibile pentru alocare - dacă este găsit, alocam adresa, dacă nu, solicităm crearea unui nou prefix.
Sau la crearea unei configurații de dispozitiv, putem afla din același sistem în care VRF ar trebui să fie amplasată interfața.
Și la pornirea unui nou server, scriptul se conectează în sistem, află în ce comutator se află serverul, în ce port și ce subrețea este alocată interfeței - și va aloca adresa serverului de la acesta.

Aceasta sugerează dorința de a combina DCIM și IPAM într-un singur sistem pentru a nu duplica funcții și pentru a nu servi două entități similare.
Asta vom face.

Componenta 3. Sistem de descriere a serviciilor de rețea

Dacă primele două sisteme stochează variabile care trebuie încă utilizate cumva, atunci al treilea descrie pentru fiecare rol al dispozitivului cum ar trebui să fie configurat.
Merită să distingem două tipuri diferite de servicii de rețea:

• Infrastructură
• Client.

Primele sunt concepute pentru a oferi conectivitate de bază și control al dispozitivului. Acestea includ VTY, SNMP, NTP, Syslog, AAA, protocoale de rutare, CoPP etc.
Aceștia din urmă organizează serviciul pentru client: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP etc.
Desigur, există și cazuri limită - unde să includă MPLS LDP, BGP? Da, iar protocoalele de rutare pot fi folosite pentru clienți. Dar acest lucru nu este important.

Ambele tipuri de servicii sunt descompuse în primitive de configurare:

• interfețe fizice și logice (tag/anteg, mtu)
• Adrese IP și VRF-uri (IP, IPv6, VRF)
• ACL-uri și politici de procesare a traficului
• Protocoale (IGP, BGP, MPLS)
• Politici de rutare (liste de prefixe, comunități, filtre ASN).
• Servicii utilitare (SSH, NTP, LLDP, Syslog...)
• etc.

Cum vom face exact asta, nu am idee încă. O vom analiza într-un articol separat.

Dacă este puțin mai aproape de viață, atunci am putea descrie asta
Comutatorul Leaf trebuie să aibă sesiuni BGP cu toate comutatoarele Spine conectate, să importe rețelele conectate în proces și să accepte numai rețele de la un anumit prefix de la comutatoarele Spine. Limitați CoPP IPv6 ND la 10 pps etc.
La rândul lor, țepii țin sesiuni cu toate lead-urile conectate, acționând ca reflectori de rădăcină, și acceptă de la ei doar trasee de o anumită lungime și cu o anumită comunitate.

Componenta 4: Mecanismul de inițializare a dispozitivului

Sub acest titlu combin multe dintre acțiunile care trebuie să aibă loc pentru ca un dispozitiv să apară pe radar și să fie accesat de la distanță.

1. Introduceți dispozitivul în sistemul de inventariere.
2. Selectați o adresă IP de gestionare.
3. Configurați accesul de bază la acesta:
   Nume gazdă, adresa IP de gestionare, ruta către rețeaua de management, utilizatori, chei SSH, protocoale - telnet/SSH/NETCONF

Există trei abordări:

• Totul este complet manual. Dispozitivul este adus la stand, unde o persoană organică obișnuită îl va introduce în sisteme, se va conecta la consolă și îl va configura. Poate funcționa pe rețele statice mici.
• ZTP - Zero Touch Provisioning. Hardware-ul a sosit, s-a ridicat, a primit o adresă prin DHCP, a mers pe un server special și s-a configurat singur.
• Infrastructura serverelor de consolă, unde configurația inițială are loc prin portul de consolă în modul automat.

Vom vorbi despre toate trei într-un articol separat.

Componenta 5: Model de configurare independent de furnizor

Până acum, toate sistemele au fost patch-uri disparate care oferă variabile și o descriere declarativă a ceea ce am dori să vedem în rețea. Dar, mai devreme sau mai târziu, va trebui să te confrunți cu specificul.
În această etapă, pentru fiecare dispozitiv specific, primitivele, serviciile și variabilele sunt combinate într-un model de configurare care descrie de fapt configurația completă a unui dispozitiv specific, doar într-o manieră neutră pentru furnizor.
Ce face acest pas? De ce nu creați imediat o configurație de dispozitiv pe care să o puteți încărca pur și simplu?
De fapt, aceasta rezolvă trei probleme:

1. Nu vă adaptați la o interfață specifică pentru interacțiunea cu dispozitivul. Fie că este CLI, NETCONF, RESTCONF, SNMP - modelul va fi același.
2. Nu păstrați numărul de șabloane/scripturi în funcție de numărul de furnizori din rețea, iar dacă se modifică designul, schimbați același lucru în mai multe locuri.
3. Încărcați configurația de pe dispozitiv (backup), puneți-o exact în același model și comparați direct configurația țintă cu cea existentă pentru a calcula delta și pregătiți un patch de configurare care va schimba doar acele părți care sunt necesare sau pentru a identifica abaterile.

Ca rezultat al acestei etape, obținem o configurație independentă de furnizor.

Componenta 6. Interfață de driver specifică furnizorului

Nu ar trebui să vă flatați cu speranța că într-o zi va fi posibil să configurați un ciska exact în același mod ca un Juniper, pur și simplu trimițându-le exact aceleași apeluri. În ciuda popularității tot mai mari a casetelor albe și a apariției suportului pentru NETCONF, RESTCONF, OpenConfig, conținutul specific pe care îl oferă aceste protocoale diferă de la furnizor la furnizor, iar aceasta este una dintre diferențele lor competitive la care nu vor renunța atât de ușor.
Acesta este aproximativ același cu OpenContrail și OpenStack, care au RestAPI ca interfață NorthBound, se așteaptă la apeluri complet diferite.

Deci, în al cincilea pas, modelul independent de furnizor trebuie să ia forma în care va merge la hardware.
Și aici toate mijloacele sunt bune (nu): CLI, NETCONF, RESTCONF, SNMP pur și simplu.

Prin urmare, vom avea nevoie de un driver care va transfera rezultatul pasului anterior în formatul necesar unui anumit furnizor: un set de comenzi CLI, o structură XML.

Componenta 7. Mecanism de livrare a configurației dispozitivului

Am generat configurația, dar încă trebuie să fie livrată pe dispozitive - și, evident, nu manual.
În primul rând, ne confruntăm cu întrebarea ce transport vom folosi? Și astăzi alegerea nu mai este mică:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• API-ul REST
• OpenFlow (deși este un outlier deoarece este o modalitate de a furniza FIB, nu setări)

Să punctăm t-ul aici. CLI este moștenire. SNMP... tuse tuse.
RESTCONF este încă un animal necunoscut; API-ul REST nu este susținut de aproape nimeni. Prin urmare, ne vom concentra pe NETCONF în serie.

De fapt, după cum cititorul a înțeles deja, până în acest moment ne-am hotărât deja asupra interfeței - rezultatul pasului anterior este deja prezentat în formatul interfeței care a fost aleasă.

În al doilea rând, și cu ce instrumente vom face asta?
Există, de asemenea, o gamă largă aici:

• Script sau platformă auto-scris. Să ne înarmam cu ncclient și asyncIO și să facem totul singuri. Cât ne costă să construim un sistem de implementare de la zero?
• Ansible cu biblioteca sa bogată de module de rețea.
• Sarea cu munca sa slabă cu rețeaua și legătura cu Napalm.
• De fapt, Napalm, care cunoaște câțiva vânzători și gata, la revedere.
• Nornir este un alt animal pe care îl vom diseca în viitor.

Aici favoritul nu a fost încă ales - vom căuta.

Ce altceva este important aici? Consecințele aplicării configurației.
Cu succes sau nu. Mai există sau nu acces la hardware?
Se pare că commit-ul va ajuta aici cu confirmarea și validarea a ceea ce a fost descărcat pe dispozitiv.
Acest lucru, combinat cu implementarea corectă a NETCONF, restrânge semnificativ gama de dispozitive adecvate - nu mulți producători acceptă angajamente normale. Dar aceasta este doar una dintre premisele în RFP. În cele din urmă, nimeni nu este îngrijorat că niciun furnizor rus nu va respecta condiția de interfață 32*100GE. Sau este îngrijorat?

Componenta 8. CI/CD

În acest moment, avem deja configurația pregătită pentru toate dispozitivele din rețea.
Scriu „pentru tot” pentru că vorbim despre versiunea stării rețelei. Și chiar dacă trebuie să modificați setările unui singur comutator, modificările sunt calculate pentru întreaga rețea. Evident, ele pot fi zero pentru majoritatea nodurilor.

Dar, așa cum sa spus deja mai sus, nu suntem un fel de barbari care doresc să introducă totul direct în producție.
Configurația generată trebuie să treacă mai întâi prin Pipeline CI/CD.

CI/CD înseamnă Continuous Integration, Continuous Deployment. Aceasta este o abordare în care echipa nu numai că lansează o nouă lansare majoră la fiecare șase luni, înlocuind-o complet pe cea veche, dar introduce în mod regulat treptat (de implementare) noi funcționalități în porțiuni mici, fiecare dintre acestea fiind testată cuprinzător pentru compatibilitate, securitate și performanță (integrare).

Pentru a face acest lucru, avem un sistem de control al versiunilor care monitorizează modificările de configurare, un laborator care verifică dacă serviciul client este întrerupt, un sistem de monitorizare care verifică acest fapt, iar ultimul pas este implementarea modificărilor în rețeaua de producție.

Cu excepția comenzilor de depanare, absolut toate modificările din rețea trebuie să treacă prin conducta CI/CD - aceasta este garanția noastră pentru o viață liniștită și o carieră lungă și fericită.

Componenta 9. Backup și sistem de detectare a anomaliilor

Ei bine, nu este nevoie să vorbim din nou despre backup-uri.
Pur și simplu le vom pune în git în funcție de coroană sau de schimbarea configurației.

Dar a doua parte este mai interesantă - cineva ar trebui să fie cu ochii pe aceste copii de rezervă. Și în unele cazuri, acest cineva trebuie să meargă și să întoarcă totul așa cum a fost, iar în altele, să miau cuiva că ceva nu este în regulă.
De exemplu, dacă a apărut un utilizator nou care nu este înregistrat în variabile, trebuie să-l eliminați din hack. Și dacă este mai bine să nu atingeți o nouă regulă de firewall, poate cineva tocmai a activat depanarea sau poate noul serviciu, un bungler, nu a fost înregistrat conform reglementărilor, dar oamenii s-au alăturat deja.

Încă nu vom scăpa de o mică deltă la scara întregii rețele, în ciuda oricăror sisteme de automatizare și a mâinii de oțel a managementului. Pentru a depana problemele, oricum nimeni nu va adăuga configurație la sisteme. Mai mult, este posibil ca acestea să nu fie incluse în modelul de configurare.

De exemplu, o regulă de firewall pentru numărarea numărului de pachete pe IP specific pentru a localiza o problemă este o configurație temporară complet obișnuită.

Componenta 10. Sistem de monitorizare

La început nu aveam de gând să tratez tema monitorizării - este încă un subiect voluminos, controversat și complex. Dar, pe măsură ce lucrurile au progresat, s-a dovedit că aceasta era o parte integrantă a automatizării. Și este imposibil să o ocoliți, chiar și fără practică.

Gândirea în evoluție este o parte organică a procesului CI/CD. După lansarea configurației în rețea, trebuie să putem determina dacă totul este în regulă acum.
Și vorbim nu numai și nu atât de mult despre programările de utilizare a interfeței sau disponibilitatea nodurilor, ci despre lucruri mai subtile - prezența rutelor necesare, atribute pe ele, numărul de sesiuni BGP, vecini OSPF, performanță end-to-end. a serviciilor supraiacente.
Au încetat să se mai adună syslog-urile către serverul extern sau s-a defectat agentul SFlow sau au început să crească scăderile din cozi sau s-a stricat conectivitatea dintre o pereche de prefixe?

Vom reflecta asupra acestui lucru într-un articol separat.

Concluzie

Ca bază, am ales unul dintre modelele moderne de rețea de centre de date - L3 Clos Fabric cu BGP ca protocol de rutare.
De data aceasta vom construi rețeaua pe Juniper, pentru că acum interfața JunOs este un vanlove.

Să ne facem viața mai dificilă utilizând doar instrumente Open Source și o rețea cu mai mulți furnizori - așa că pe lângă Juniper, voi alege încă o persoană norocoasă pe parcurs.

Planul pentru viitoarele publicații este cam așa:
Mai întâi voi vorbi despre rețelele virtuale. În primul rând, pentru că vreau și, în al doilea rând, pentru că fără aceasta, proiectarea rețelei de infrastructură nu va fi foarte clară.
Apoi despre designul rețelei în sine: topologie, rutare, politici.
Să asamblam un stand de laborator.
Să ne gândim și poate să exersăm inițializarea dispozitivului în rețea.
Și apoi despre fiecare componentă în detaliu intim.

Și da, nu promit să închei cu grație acest ciclu cu o soluție gata făcută. 🙂

Link-uri utile

• Înainte de a pătrunde în serie, merită să citiți cartea Natasha Samoilenko Python pentru ingineri de rețea. Și poate trece cursul.
• Va fi util și de citit RFC despre proiectarea fabricilor de centre de date de la Facebook de Peter Lapukhov.
• Documentația de arhitectură vă va oferi o idee despre cum funcționează Overlay SDN. Țesătură de wolfram (fost Open Contrail).

Mulțumesc

Defileul Romanului. Pentru comentarii și editări.
Artyom Cernobay. Pentru KDPV.

Sursa: www.habr.com