LSDM ka mbaruar, por dëshira e pakontrolluar për të shkruar mbetet.

Për shumë vite, vëllai ynë vuante nga kryerja e punëve rutinë, duke kryqëzuar gishtat përpara se të angazhohej dhe nuk kishte gjumë për shkak të kthimeve të natës.
Por kohët e errëta po marrin fund.

Me këtë artikull do të filloj një seri se si per mua shihet automatizimi.
Gjatë rrugës do të kuptojmë fazat e automatizimit, ruajtjen e variablave, formalizimin e dizajnit, RestAPI, NETCONF, YANG, YDK dhe do të bëjmë shumë programim.
Mua do të thotë që a) nuk është një e vërtetë objektive, b) nuk është pa kushte qasja më e mirë, c) mendimi im, edhe gjatë lëvizjes nga artikulli i parë në të fundit, mund të ndryshojë - të them të drejtën, nga faza e draftit në botim, rishkrova gjithçka plotësisht dy herë.

Përmbajtje

1. qëllimet
   1. Rrjeti është si një organizëm i vetëm
   2. Testimi i konfigurimit
   3. Versionimi
   4. Monitorimi dhe vetë-shërimi i shërbimeve

2. fondet
   1. Sistemi i inventarit
   2. Sistemi i menaxhimit të hapësirës IP
   3. Sistemi i përshkrimit të shërbimit të rrjetit
   4. Mekanizmi i inicializimit të pajisjes
   5. Modeli i konfigurimit shitës-agnostik
   6. Ndërfaqja e shoferit specifike për shitësin
   7. Mekanizmi për dërgimin e konfigurimit në pajisje
   8. CI / CD
   9. Mekanizmi për rezervimin dhe kërkimin e devijimeve
   10. Sistemi i monitorimit

3. Përfundim

Do të mundohem ta zhvilloj ADSM-në në një format pak më ndryshe nga LSDM. Artikuj të mëdhenj, të detajuar, të numëruar do të vazhdojnë të shfaqen dhe mes tyre do të publikoj shënime të vogla nga përvoja e përditshme. Do të përpiqem të luftoj perfeksionizmin këtu dhe të mos lëpij secilin prej tyre.

Sa qesharake është që herën e dytë duhet të kalosh në të njëjtën rrugë.

Në fillim m'u desh të shkruaja artikuj për rrjetet vetë për faktin se ato nuk ishin në RuNet.

Tani nuk mund të gjeja një dokument gjithëpërfshirës që do të sistemonte qasjet ndaj automatizimit dhe do të analizonte teknologjitë e mësipërme duke përdorur shembuj të thjeshtë praktikë.

Mund të kem gabim, ndaj ju lutemi jepni lidhje me burime të dobishme. Megjithatë, kjo nuk do të ndryshojë vendosmërinë time për të shkruar, sepse qëllimi kryesor është të mësoj diçka vetë, dhe lehtësimi i jetës për të tjerët është një bonus i këndshëm që përkëdhel gjenin e ndarjes së përvojës.

Ne do të përpiqemi të marrim një qendër të dhënash LAN DC të mesme dhe të përpunojmë të gjithë skemën e automatizimit.
Unë do të bëj disa gjëra pothuajse për herë të parë me ju.

Nuk do të jem origjinal në idetë dhe mjetet e përshkruara këtu. Dmitry Figol ka një të shkëlqyer kanal me transmetime për këtë temë.
Artikujt do të mbivendosen me ta në shumë aspekte.

LAN DC ka 4 DC, rreth 250 switch, gjysmë duzine ruterash dhe disa mure zjarri.
Jo Facebook, por mjaftueshëm për t'ju bërë të mendoni thellë për automatizimin.
Sidoqoftë, ekziston një mendim se nëse keni më shumë se 1 pajisje, tashmë nevojitet automatizimi.
Në fakt, është e vështirë të imagjinohet se dikush tani mund të jetojë pa të paktën një paketë shkrimesh për gjunjët.
Megjithëse kam dëgjuar se ka zyra ku adresat IP mbahen në Excel, dhe secila prej mijëra pajisjeve të rrjetit është konfiguruar manualisht dhe ka konfigurimin e vet unik. Kjo, natyrisht, mund të kalohet si art modern, por ndjenjat e inxhinierit patjetër do të ofendohen.

qëllimet

Tani do të vendosim qëllimet më abstrakte:

• Rrjeti është si një organizëm i vetëm
• Testimi i konfigurimit
• Versionimi i gjendjes së rrjetit
• Monitorimi dhe vetë-shërimi i shërbimeve

Më vonë në këtë artikull do të shohim se çfarë mjetesh do të përdorim dhe në vijim do t'i shikojmë qëllimet dhe mjetet në detaje.

Rrjeti është si një organizëm i vetëm

Fraza përcaktuese e serialit, megjithëse në pamje të parë mund të mos duket aq domethënëse: ne do të konfigurojmë rrjetin, jo pajisjet individuale.
Në vitet e fundit, ne kemi parë një ndryshim në theksin drejt trajtimit të rrjetit si një entitet i vetëm, prandaj Rrjetëzimi i programuar i softuerit, Rrjetet e drejtuara nga qëllimi и Rrjetet autonome.
Në fund të fundit, çfarë kanë nevojë aplikacionet globalisht nga rrjeti: lidhje midis pikave A dhe B (mirë, ndonjëherë +B-Z) dhe izolim nga aplikacionet dhe përdoruesit e tjerë.

Dhe kështu detyra jonë në këtë seri është ndërtoni një sistem, duke ruajtur konfigurimin aktual të gjithë rrjetin, e cila tashmë është zbërthyer në konfigurimin aktual në secilën pajisje në përputhje me rolin dhe vendndodhjen e saj.
Sistem menaxhimi i rrjetit nënkupton që për të bërë ndryshime ne e kontaktojmë atë, dhe ai, nga ana tjetër, llogarit gjendjen e dëshiruar për secilën pajisje dhe e konfiguron atë.
Në këtë mënyrë, ne minimizojmë qasjen manuale në CLI pothuajse në zero - çdo ndryshim në cilësimet e pajisjes ose dizajnin e rrjetit duhet të zyrtarizohet dhe dokumentohet - dhe vetëm atëherë të shpërndahet në elementët e nevojshëm të rrjetit.

Kjo do të thotë, për shembull, nëse vendosëm që tani e tutje çelsat e rafteve në Kazan duhet të shpallin dy rrjete në vend të një, ne

1. Së pari ne dokumentojmë ndryshimet në sisteme
2. Gjenerimi i konfigurimit të synuar të të gjitha pajisjeve të rrjetit
3. Ne nisim programin e përditësimit të konfigurimit të rrjetit, i cili llogarit se çfarë duhet të hiqet në secilën nyje, çfarë të shtohet dhe i sjell nyjet në gjendjen e dëshiruar.

Në të njëjtën kohë, ne bëjmë ndryshime me dorë vetëm në hapin e parë.

Testimi i konfigurimit

Dihetse 80% e problemeve ndodhin gjatë ndryshimeve të konfigurimit - dëshmi indirekte për këtë është se gjatë festave të Vitit të Ri çdo gjë është zakonisht e qetë.
Unë personalisht kam dëshmuar dhjetëra ndërprerje globale për shkak të gabimit njerëzor: komanda e gabuar, konfigurimi u ekzekutua në degën e gabuar, komuniteti u harrua, MPLS u shkatërrua globalisht në ruter, pesë pjesë harduerësh u konfiguruan, por gabimi nuk ishte vërehet në datën e gjashtë, janë kryer ndryshime të vjetra të bëra nga një person tjetër. Ka shumë skenarë.

Automatizimi do të na lejojë të bëjmë më pak gabime, por në një shkallë më të madhe. Në këtë mënyrë ju mund të ndërtoni jo vetëm një pajisje, por të gjithë rrjetin menjëherë.

Që nga kohra të lashta, gjyshërit tanë kontrolluan korrektësinë e ndryshimeve të bëra me një sy të mprehtë, topa çeliku dhe funksionalitetin e rrjetit pasi ato u hapën.
Ata gjyshër, puna e të cilëve çoi në ndërprerje dhe humbje katastrofike, lanë më pak pasardhës dhe duhet të vdesin me kalimin e kohës, por evolucioni është një proces i ngadaltë, dhe për këtë arsye jo të gjithë ende po testojnë ndryshimet në laborator fillimisht.
Megjithatë, në krye të progresit janë ata që kanë automatizuar procesin e testimit të konfigurimit dhe aplikimin e tij të mëtejshëm në rrjet. Me fjalë të tjera, unë huazova procedurën CI/CD (Integrim i vazhdueshëm, vendosje e vazhdueshme) nga zhvilluesit.
Në një nga pjesët do të shikojmë se si ta zbatojmë këtë duke përdorur një sistem kontrolli versioni, ndoshta Github.

Pasi të mësoheni me idenë e rrjetit CI/CD, gjatë natës metoda e kontrollit të një konfigurimi duke e aplikuar atë në një rrjet prodhimi do të duket si injorancë e hershme mesjetare. Një lloj si të godasësh një kokë lufte me një çekiç.

Një vazhdim organik i ideve rreth sistemi menaxhimi i rrjetit dhe CI/CD bëhet një version i plotë i konfigurimit.

Versionimi

Ne do të supozojmë se me çdo ndryshim, madje edhe ato më të voglat, qoftë edhe në një pajisje të padukshme, i gjithë rrjeti lëviz nga një gjendje në tjetrën.
Dhe ne gjithmonë nuk ekzekutojmë një komandë në pajisje, ne ndryshojmë gjendjen e rrjetit.
Pra, le t'i quajmë këto shtete versione?

Le të themi se versioni aktual është 1.0.0.
A ka ndryshuar adresa IP e ndërfaqes Loopback në një nga ToR-të? Ky është një version i vogël dhe do të numërohet 1.0.1.
Ne rishikuam politikat për importimin e rrugëve në BGP - pak më seriozisht - tashmë 1.1.0
Ne vendosëm të heqim qafe IGP dhe të kalojmë vetëm në BGP - ky është tashmë një ndryshim rrënjësor i dizajnit - 2.0.0.

Në të njëjtën kohë, DC të ndryshme mund të kenë versione të ndryshme - rrjeti po zhvillohet, pajisje të reja po instalohen, nivele të reja të shtyllave po shtohen diku, jo në të tjera, etj.

në versionimi semantik do të flasim në një artikull të veçantë.

E përsëris - çdo ndryshim (përveç komandave të korrigjimit) është një përditësim i versionit. Administratorët duhet të njoftohen për çdo devijim nga versioni aktual.

E njëjta gjë vlen edhe për rikthimin e ndryshimeve - kjo nuk është anulim i komandave të fundit, kjo nuk është një rikthim duke përdorur sistemin operativ të pajisjes - kjo po sjell të gjithë rrjetin në një version të ri (të vjetër).

Monitorimi dhe vetë-shërimi i shërbimeve

Kjo detyrë e vetëkuptueshme ka arritur një nivel të ri në rrjetet moderne.
Shpesh, ofruesit e mëdhenj të shërbimeve përdorin qasjen që një shërbim i dështuar duhet të rregullohet shumë shpejt dhe të ngrihet një i ri, në vend që të kuptojnë se çfarë ka ndodhur.
"Shumë" do të thotë që ju duhet të mbuloheni bujarisht nga të gjitha anët me monitorim, i cili brenda sekondave do të zbulojë devijimet më të vogla nga norma.
Dhe këtu metrikat e zakonshme, të tilla si ngarkimi i ndërfaqes ose disponueshmëria e nyjeve, nuk janë më të mjaftueshme. Nuk mjafton as monitorimi manual i tyre nga nëpunësi.
Për shumë gjëra duhet të ketë Vetë-shërimi — dritat e monitorimit u kthyen në të kuqe dhe shkuam e vendosëm vetë delli ku na dhembte.

Dhe këtu ne monitorojmë gjithashtu jo vetëm pajisjet individuale, por edhe shëndetin e të gjithë rrjetit, si whitebox, që është relativisht e kuptueshme, dhe blackbox, që është më e ndërlikuar.

Çfarë do të na duhet për të zbatuar plane të tilla ambicioze?

• Keni një listë të të gjitha pajisjeve në rrjet, vendndodhjen e tyre, rolet, modelet, versionet e softuerit.
  kazan-leaf-1.lmu.net, Kazan, gjethe, Juniper QFX 5120, R18.3.
• Keni një sistem për përshkrimin e shërbimeve të rrjetit.
  IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH.
• Të jetë në gjendje të inicializojë pajisjen.
  Emri i hostit, IP Mgmt, Rruga Mgmt, Përdoruesit, Çelësat RSA, LLDP, NETCONF
• Konfiguroni pajisjen dhe sillni konfigurimin në versionin e dëshiruar (përfshirë të vjetër).
• Konfigurimi i testit
• Kontrolloni periodikisht statusin e të gjitha pajisjeve për devijime nga ato aktuale dhe raportoni se kujt duhet të jetë.
  Brenda natës, dikush shtoi në heshtje një rregull në ACL.
• Monitoroni performancën.

fondet

Duket mjaft e ndërlikuar për të filluar zbërthimin e projektit në komponentë.

Dhe do të jenë dhjetë prej tyre:

1. Sistemi i inventarit
2. Sistemi i menaxhimit të hapësirës IP
3. Sistemi i përshkrimit të shërbimit të rrjetit
4. Mekanizmi i inicializimit të pajisjes
5. Modeli i konfigurimit shitës-agnostik
6. Ndërfaqja e shoferit specifike për shitësin
7. Mekanizmi për dërgimin e konfigurimit në pajisje
8. CI / CD
9. Mekanizmi për rezervimin dhe kërkimin e devijimeve
10. Sistemi i monitorimit

Ky, nga rruga, është një shembull se si ndryshoi këndvështrimi për qëllimet e ciklit - kishte 4 komponentë në draft.

Në ilustrim kam përshkruar të gjithë përbërësit dhe vetë pajisjen.
Komponentët e kryqëzuar ndërveprojnë me njëri-tjetrin.
Sa më i madh të jetë blloku, aq më shumë vëmendje duhet t'i kushtohet këtij komponenti.

Komponenti 1: Sistemi i inventarit

Natyrisht, ne duam të dimë se ku ndodhet pajisjet, me çfarë është e lidhur.
Sistemi i inventarit është një pjesë integrale e çdo ndërmarrje.
Më shpesh, një ndërmarrje ka një sistem të veçantë inventarizimi për pajisjet e rrjetit, i cili zgjidh probleme më specifike.
Si pjesë e kësaj serie artikujsh, ne do ta quajmë atë DCIM - Menaxhimi i Infrastrukturës së Qendrës së të Dhënave. Edhe pse vetë termi DCIM, në mënyrë rigoroze, përfshin shumë më tepër.

Për qëllimet tona, ne do të ruajmë informacionin e mëposhtëm në lidhje me pajisjen në të:

• Numri i inventarit
• Titulli/Përshkrimi
• Modeli (Huawei CE12800, Juniper QFX5120, etj.)
• Parametrat karakteristikë (bordet, ndërfaqet, etj.)
• Roli (Leaf, Spine, Border Router, etj.)
• Vendndodhja (rajoni, qyteti, qendra e të dhënave, rafti, njësia)
• Ndërlidhjet ndërmjet pajisjeve
• Topologjia e rrjetit

Është krejtësisht e qartë se ne vetë duam t'i dimë të gjitha këto.
Por a do të ndihmojë kjo për qëllime automatizimi?
Pa dyshim.
Për shembull, ne e dimë se në një qendër të caktuar të dhënash në çelësat Leaf, nëse është Huawei, ACL-të për të filtruar një trafik të caktuar duhet të aplikohen në VLAN, dhe nëse është Juniper, atëherë në njësinë 0 të ndërfaqes fizike.
Ose ju duhet të hapni një server të ri Syslog në të gjithë kufijtë në rajon.

Në të do të ruajmë pajisjet e rrjetit virtual, për shembull ruterat virtualë ose reflektorët rrënjë. Mund të shtojmë serverë DNS, NTP, Syslog dhe në përgjithësi gjithçka që në një mënyrë ose në një tjetër lidhet me rrjetin.

Komponenti 2: Sistemi i menaxhimit të hapësirës IP

Po, dhe në ditët e sotme ka ekipe njerëzish që mbajnë gjurmët e prefikseve dhe adresave IP në një skedar Excel. Por qasja moderne është ende një bazë të dhënash, me një front-end në nginx/apache, API dhe funksione të gjera për regjistrimin e adresave IP dhe rrjeteve të ndara në VRF.
IPAM - Menaxhimi i adresave IP.

Për qëllimet tona, ne do të ruajmë informacionin e mëposhtëm në të:

• VLAN-et
• Zgjerimi VRF
• Rrjetet/Nënrrjetet
• adresat IP
• Lidhja e adresave me pajisjet, rrjetet me vendndodhjet dhe numrat VLAN

Përsëri, është e qartë se ne duam të sigurohemi që kur të ndajmë një adresë të re IP për loopback ToR, ne nuk do të pengohemi për faktin se ajo i ishte caktuar tashmë dikujt. Ose që kemi përdorur të njëjtin prefiks dy herë në skaje të ndryshme të rrjetit.
Por si ndihmon kjo me automatizimin?
Lehtë.
Ne kërkojmë një prefiks në sistem me rolin Loopbacks, i cili përmban adresa IP të disponueshme për alokim - nëse gjendet, alokojmë adresën, nëse jo, kërkojmë krijimin e një prefiksi të ri.
Ose kur krijojmë një konfigurim pajisjeje, mund të zbulojmë nga i njëjti sistem në të cilin duhet të vendoset ndërfaqja VRF.
Dhe kur fillon një server të ri, skripti regjistrohet në sistem, zbulon se në cilin ndërprerës është serveri, cili port dhe cili nënrrjet i është caktuar ndërfaqes - dhe do të ndajë adresën e serverit prej tij.

Kjo sugjeron një dëshirë për të kombinuar DCIM dhe IPAM në një sistem në mënyrë që të mos dublikohen funksionet dhe të mos shërbehen dy entitete të ngjashme.
Kjo është ajo që ne do të bëjmë.

Komponenti 3. Sistemi për përshkrimin e shërbimeve të rrjetit

Nëse dy sistemet e para ruajnë variabla që ende duhet të përdoren disi, atëherë i treti përshkruan për secilën rol të pajisjes se si duhet të konfigurohet.
Vlen të dallohen dy lloje të ndryshme të shërbimeve të rrjetit:

• Infrastruktura
• Klienti.

Të parat janë krijuar për të siguruar lidhjen bazë dhe kontrollin e pajisjes. Këto përfshijnë VTY, SNMP, NTP, Syslog, AAA, protokollet e rrugëtimit, CoPP, etj.
Këta të fundit organizojnë shërbimin për klientin: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etj.
Sigurisht, ka edhe raste kufitare - ku të përfshihen MPLS LDP, BGP? Po, dhe protokollet e rrugëzimit mund të përdoren për klientët. Por kjo nuk është e rëndësishme.

Të dy llojet e shërbimeve zbërthehen në primitivë të konfigurimit:

• ndërfaqet fizike dhe logjike (tag/anteg, mtu)
• Adresat IP dhe VRF (IP, IPv6, VRF)
• ACL-të dhe politikat e përpunimit të trafikut
• Protokollet (IGP, BGP, MPLS)
• Politikat e rrugëtimit (listat e parashtesave, komunitetet, filtrat ASN).
• Shërbimet komunale (SSH, NTP, LLDP, Syslog...)
• etj.

Se si saktësisht do ta bëjmë këtë, nuk e kam ende idenë. Ne do ta shqyrtojmë atë në një artikull të veçantë.

Nëse pak më afër jetës, atëherë mund ta përshkruanim atë
Ndërprerësi Leaf duhet të ketë sesione BGP me të gjithë çelësat Spine të lidhur, të importojë rrjete të lidhura në proces dhe të pranojë vetëm rrjete nga një prefiks i caktuar nga ndërprerësit Spine. Kufizoni CoPP IPv6 ND në 10 pps, etj.
Nga ana tjetër, shtyllat zhvillojnë sesione me të gjitha prizat e lidhura, duke vepruar si reflektues rrënjë, dhe pranojnë prej tyre vetëm rrugë me një gjatësi të caktuar dhe me një komunitet të caktuar.

Komponenti 4: Mekanizmi i Inicializimit të Pajisjes

Nën këtë titull unë kombinoj shumë nga veprimet që duhet të ndodhin në mënyrë që një pajisje të shfaqet në radar dhe të aksesohet nga distanca.

1. Fusni pajisjen në sistemin e inventarit.
2. Zgjidhni një adresë IP të menaxhimit.
3. Vendosni aksesin bazë në të:
   Emri i hostit, adresa IP e menaxhimit, rruga drejt rrjetit të menaxhimit, përdoruesit, çelësat SSH, protokollet - telnet/SSH/NETCONF

Ka tre qasje:

• Gjithçka është plotësisht manuale. Pajisja sillet në stendë, ku një person i zakonshëm organik do ta futë atë në sisteme, do të lidhet me tastierën dhe do ta konfigurojë atë. Mund të punojë në rrjete të vogla statike.
• ZTP - Sigurimi me prekje zero. Pajisja mbërriti, u ngrit, mori një adresë nëpërmjet DHCP, shkoi në një server të veçantë dhe u konfigurua vetë.
• Infrastruktura e serverëve të konsolës, ku konfigurimi fillestar ndodh përmes portës së konsolës në modalitetin automatik.

Ne do të flasim për të tre në një artikull të veçantë.

Komponenti 5: Modeli i konfigurimit shitës-agnostik

Deri më tani, të gjitha sistemet kanë qenë arna të ndryshme që ofrojnë variabla dhe një përshkrim deklarativ të asaj që do të donim të shihnim në rrjet. Por herët a vonë, do t'ju duhet të merreni me specifikat.
Në këtë fazë, për çdo pajisje specifike, primitivët, shërbimet dhe variablat kombinohen në një model konfigurimi që në fakt përshkruan konfigurimin e plotë të një pajisjeje specifike, vetëm në një mënyrë neutrale nga shitësi.
Çfarë bën ky hap? Pse të mos krijoni menjëherë një konfigurim pajisjeje që thjesht mund ta ngarkoni?
Në fakt, kjo zgjidh tre probleme:

1. Mos u përshtatni me një ndërfaqe specifike për të bashkëvepruar me pajisjen. Qoftë CLI, NETCONF, RESTCONF, SNMP - modeli do të jetë i njëjtë.
2. Mos e mbani numrin e shablloneve/skripteve sipas numrit të shitësve në rrjet dhe nëse dizajni ndryshon, ndryshoni të njëjtën gjë në disa vende.
3. Ngarkoni konfigurimin nga pajisja (backup), vendoseni në të njëjtin model dhe krahasoni drejtpërdrejt konfigurimin e synuar me atë ekzistues për të llogaritur deltën dhe për të përgatitur një patch konfigurimi që do të ndryshojë vetëm ato pjesë që janë të nevojshme ose për të identifikuar devijimet.

Si rezultat i kësaj faze, marrim një konfigurim të pavarur nga shitësi.

Komponenti 6. Ndërfaqja e shoferit specifike për shitësin

Nuk duhet të kënaqeni me shpresën se një ditë do të jetë e mundur të konfiguroni një ciska në të njëjtën mënyrë si një Juniper, thjesht duke u dërguar atyre saktësisht të njëjtat thirrje. Pavarësisht nga popullariteti në rritje i whiteboxes dhe shfaqja e mbështetjes për NETCONF, RESTCONF, OpenConfig, përmbajtja specifike që këto protokolle ofrojnë ndryshon nga shitësi në shitës dhe ky është një nga dallimet e tyre konkurruese që ata nuk do të heqin dorë aq lehtë.
Kjo është afërsisht e njëjtë me OpenContrail dhe OpenStack, të cilat kanë RestAPI si ndërfaqen e tyre NorthBound, presin thirrje krejtësisht të ndryshme.

Pra, në hapin e pestë, modeli i pavarur nga shitësi duhet të marrë formën në të cilën do të shkojë te hardueri.
Dhe këtu të gjitha mjetet janë të mira (jo): CLI, NETCONF, RESTCONF, SNMP thjesht.

Prandaj, do të na duhet një drejtues që do të transferojë rezultatin e hapit të mëparshëm në formatin e kërkuar të një shitësi specifik: një grup komandash CLI, një strukturë XML.

Komponenti 7. Mekanizmi për dërgimin e konfigurimit në pajisje

Ne kemi krijuar konfigurimin, por ai ende duhet të dorëzohet në pajisje - dhe, padyshim, jo ​​me dorë.
Së pari, jemi përballë pyetjes se çfarë transporti do të përdorim? Dhe sot zgjedhja nuk është më e vogël:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (megjithëse është një i jashtëzakonshëm sepse është një mënyrë për të ofruar FIB, jo cilësime)

Le të shënojmë t-në këtu. CLI është trashëgimi. SNMP... kollë kollë.
RESTCONF është ende një kafshë e panjohur; API REST nuk mbështetet pothuajse nga askush. Prandaj, ne do të përqendrohemi në NETCONF në seri.

Në fakt, siç e ka kuptuar tashmë lexuesi, deri në këtë pikë ne kemi vendosur tashmë për ndërfaqen - rezultati i hapit të mëparshëm është paraqitur tashmë në formatin e ndërfaqes që u zgjodh.

Në radhë të dytë, dhe me çfarë mjetesh do ta bëjmë këtë?
Ekziston gjithashtu një zgjedhje e madhe këtu:

• Skenar ose platformë e shkruar vetë. Le të armatosemi me ncclient dhe asincIO dhe të bëjmë gjithçka vetë. Sa na kushton të ndërtojmë një sistem vendosjeje nga e para?
• Ansible me bibliotekën e saj të pasur të moduleve të rrjetit.
• Kripa me punën e saj të dobët me rrjetin dhe lidhjen me Napalm.
• Në fakt Napalm, i cili njeh disa shitës dhe kaq, lamtumirë.
• Nornir është një tjetër kafshë që ne do të zbërthejmë në të ardhmen.

Këtu i preferuari nuk është zgjedhur ende - ne do të kërkojmë.

Çfarë tjetër është e rëndësishme këtu? Pasojat e aplikimit të konfigurimit.
I suksesshëm apo jo. A ka ende akses në harduer apo jo?
Duket se commit do të ndihmojë këtu me konfirmimin dhe vërtetimin e asaj që është shkarkuar në pajisje.
Kjo, e kombinuar me zbatimin e saktë të NETCONF, ngushton ndjeshëm gamën e pajisjeve të përshtatshme - jo shumë prodhues mbështesin kryerjet normale. Por ky është vetëm një nga parakushtet në RFP. Në fund, askush nuk shqetësohet se asnjë shitës i vetëm rus nuk do të përmbushë kushtin e ndërfaqes 32*100GE. Apo është i shqetësuar?

Komponenti 8. CI/CD

Në këtë pikë, ne tashmë e kemi gati konfigurimin për të gjitha pajisjet e rrjetit.
Unë shkruaj "për gjithçka" sepse po flasim për versionimin e gjendjes së rrjetit. Dhe edhe nëse keni nevojë të ndryshoni cilësimet e vetëm një ndërprerës, ndryshimet llogariten për të gjithë rrjetin. Natyrisht, ato mund të jenë zero për shumicën e nyjeve.

Por, siç u tha më lart, ne nuk jemi një lloj barbarësh që duam të hedhim gjithçka direkt në prodhim.
Konfigurimi i krijuar duhet së pari të kalojë përmes CI/CD të tubacionit.

CI/CD do të thotë Integrim i vazhdueshëm, vendosje e vazhdueshme. Kjo është një qasje në të cilën ekipi jo vetëm që nxjerr një version të ri të madh çdo gjashtë muaj, duke zëvendësuar plotësisht atë të vjetër, por rregullisht zbaton në mënyrë shtesë funksionalitetin e ri (Deployment) në pjesë të vogla, secila prej të cilave është testuar plotësisht për përputhshmëri, siguri dhe performanca (Integrimi).

Për ta bërë këtë, ne kemi një sistem kontrolli versioni që monitoron ndryshimet e konfigurimit, një laborator që kontrollon nëse shërbimi i klientit është i prishur, një sistem monitorimi që kontrollon këtë fakt dhe hapi i fundit është nxjerrja e ndryshimeve në rrjetin e prodhimit.

Me përjashtim të komandave të korrigjimit, absolutisht të gjitha ndryshimet në rrjet duhet të kalojnë përmes tubacionit CI/CD - kjo është garancia jonë për një jetë të qetë dhe një karrierë të gjatë e të lumtur.

Komponenti 9. Sistemi rezervë dhe zbulimi i anomalive

Epo, nuk ka nevojë të flasim përsëri për kopje rezervë.
Thjesht do t'i vendosim në git sipas kurorës ose me faktin e një ndryshimi konfigurimi.

Por pjesa e dytë është më interesante - dikush duhet të mbajë një sy në këto kopje rezervë. Dhe në disa raste, ky dikush duhet të shkojë dhe të kthejë gjithçka ashtu siç ishte, dhe në të tjera, t'i mjaulli dikujt se diçka nuk shkon.
Për shembull, nëse është shfaqur një përdorues i ri i cili nuk është i regjistruar në variabla, ju duhet ta hiqni atë nga hakimi. Dhe nëse është më mirë të mos prekni një rregull të ri të murit të zjarrit, mbase dikush sapo ka aktivizuar korrigjimin, ose ndoshta shërbimi i ri, një bungler, nuk është regjistruar sipas rregulloreve, por njerëzit tashmë i janë bashkuar.

Ne ende nuk do t'i shpëtojmë një delta të vogël në shkallën e të gjithë rrjetit, pavarësisht çdo sistemi automatizimi dhe dorës së çeliktë të menaxhimit. Për të korrigjuar problemet, askush nuk do të shtojë konfigurim në sisteme gjithsesi. Për më tepër, ato mund të mos përfshihen as në modelin e konfigurimit.

Për shembull, një rregull i murit të zjarrit për numërimin e numrit të paketave për IP specifike për të lokalizuar një problem është një konfigurim i përkohshëm krejtësisht i zakonshëm.

Komponenti 10. Sistemi i monitorimit

Në fillim nuk do ta trajtoja temën e monitorimit - është ende një temë voluminoze, e diskutueshme dhe komplekse. Por ndërsa gjërat përparuan, doli se kjo ishte një pjesë integrale e automatizimit. Dhe është e pamundur ta anashkalosh atë, edhe pa praktikë.

Mendimi në zhvillim është një pjesë organike e procesit CI/CD. Pas shpërndarjes së konfigurimit në rrjet, duhet të jemi në gjendje të përcaktojmë nëse gjithçka është në rregull me të tani.
Dhe ne po flasim jo vetëm dhe jo aq shumë për oraret e përdorimit të ndërfaqes ose disponueshmërinë e nyjeve, por për gjëra më delikate - praninë e rrugëve të nevojshme, atributet në to, numrin e seancave BGP, fqinjët OSPF, performancën nga fundi në fund. të shërbimeve të mbivendosura.
A ndaluan së shtuari sistemet e serverit të jashtëm, apo u prish agjenti SFlow, apo u rritën pikat në radhë, apo u prish lidhja midis disa palë parashtesash?

Ne do të reflektojmë për këtë në një artikull të veçantë.

Përfundim

Si bazë, zgjodha një nga modelet moderne të rrjetit të qendrave të të dhënave - L3 Clos Fabric me BGP si protokoll rrugëtimi.
Këtë herë ne do të ndërtojmë rrjetin në Juniper, sepse tani ndërfaqja JunOs është një vanlove.

Le ta bëjmë jetën tonë më të vështirë duke përdorur vetëm mjete me burim të hapur dhe një rrjet me shumë shitës - kështu që përveç Juniper, unë do të zgjedh një person më me fat gjatë rrugës.

Plani për botimet e ardhshme është diçka si ky:
Fillimisht do të flas për rrjetet virtuale. Para së gjithash, sepse unë dua, dhe së dyti, sepse pa këtë, projektimi i rrjetit të infrastrukturës nuk do të jetë shumë i qartë.
Pastaj në lidhje me vetë dizajnin e rrjetit: topologjinë, rrugëzimin, politikat.
Le të montojmë një stendë laboratorike.
Le të mendojmë për këtë dhe ndoshta të praktikojmë inicializimin e pajisjes në rrjet.
Dhe pastaj për secilin komponent në detaje intime.

Dhe po, nuk premtoj ta mbyll me hijeshi këtë cikël me një zgjidhje të gatshme. 🙂

Lidhje të dobishme

• Para se të futemi në seri, ia vlen të lexoni librin e Natasha Samoilenko Python për Inxhinierët e Rrjetit. Dhe ndoshta të kalojë kurs.
• Do të jetë gjithashtu e dobishme të lexoni RFC rreth projektimit të fabrikave të qendrave të të dhënave nga Facebook nga Peter Lapukhov.
• Dokumentacioni i arkitekturës do t'ju japë një ide se si funksionon Overlay SDN. Pëlhurë tungsteni (dikur Open Contrail).

Faleminderit

Gryka Romake. Për komente dhe modifikime.
Artyom Chernobay. Për KDPV.

Burimi: www.habr.com