SDSM baigėsi, bet nenumaldomas noras rašyti išlieka.

Daugelį metų mūsų brolis kentėjo nuo įprastų darbų, sukryžiavo pirštus prieš įsipareigodamas ir trūko miego dėl naktinių atsitraukimų.
Tačiau tamsūs laikai eina į pabaigą.

Šiuo straipsniu pradėsiu seriją apie tai, kaip mane matosi automatika.
Pakeliui suprasime automatizavimo etapus, kintamųjų saugojimą, dizaino formalizavimą, RestAPI, NETCONF, YANG, YDK ir atliksime daug programavimo.
Man reiškia, kad a) tai nėra objektyvi tiesa, b) tai nėra besąlygiškai geriausias požiūris, c) mano nuomonė, net ir pereinant nuo pirmo iki paskutinio straipsnio, gali pasikeisti – tiesą sakant, nuo juodraščio iki publikaciją, viską visiškai perrašiau du kartus.

Turinys

1. Tikslai
   1. Tinklas yra tarsi vienas organizmas
   2. Konfigūracijos testavimas
   3. Versijų kūrimas
   4. Paslaugų stebėjimas ir savigyda

2. Fondai
   1. Inventorizacijos sistema
   2. IP erdvės valdymo sistema
   3. Tinklo paslaugų aprašymo sistema
   4. Įrenginio inicijavimo mechanizmas
   5. Pardavėjo-agnostinės konfigūracijos modelis
   6. Pardavėjo specifinė tvarkyklės sąsaja
   7. Konfigūracijos pateikimo į įrenginį mechanizmas
   8. CI / CD
   9. Atsarginio kopijavimo ir nukrypimų paieškos mechanizmas
   10. Stebėjimo sistema

3. išvada

Bandysiu atlikti ADSM formatu, kuris šiek tiek skiriasi nuo SDSM. Ir toliau pasirodys dideli, išsamūs, sunumeruoti straipsniai, o tarp jų publikuosiu nedideles pastabas iš kasdienės patirties. Bandysiu čia kovoti su perfekcionizmu ir nelaižyti kiekvieno iš jų.

Kaip juokinga, kad antrą kartą tenka eiti tuo pačiu keliu.

Iš pradžių man pačiam teko rašyti straipsnius apie tinklus, nes jų nebuvo „RuNet“.

Dabar negalėjau rasti išsamaus dokumento, kuriame būtų susisteminti automatizavimo metodai ir analizuojamos aukščiau pateiktos technologijos naudojant paprastus praktinius pavyzdžius.

Galiu klysti, todėl pateikite nuorodas į naudingus išteklius. Tačiau tai nepakeis mano ryžto rašyti, nes pagrindinis tikslas – pačiam ko nors išmokti, o palengvinti gyvenimą kitiems – maloni premija, glostanti patirties dalijimosi geną.

Bandysime paimti vidutinio dydžio LAN DC duomenų centrą ir parengti visą automatizavimo schemą.
Kai kuriuos dalykus su tavimi darysiu beveik pirmą kartą.

Čia aprašytose idėjose ir priemonėse nebūsiu originalus. Dmitrijus Figolis turi puikų kanalas su srautais šia tema.
Straipsniai daugeliu aspektų sutaps su jais.

LAN DC turi 4 DC, apie 250 jungiklių, pusšimtį maršrutizatorių ir porą ugniasienių.
Ne Facebook, bet pakankamai, kad galėtumėte giliai susimąstyti apie automatizavimą.
Tačiau yra nuomonė, kad jei turite daugiau nei 1 įrenginį, automatizavimas jau reikalingas.
Tiesą sakant, sunku įsivaizduoti, kad dabar kas nors gali gyventi be bent jau kelių scenarijų paketo.
Nors girdėjau, kad yra biurų, kur IP adresai saugomi Excel programoje, o kiekvienas iš tūkstančių tinklo įrenginių yra konfigūruojamas rankiniu būdu ir turi savo unikalią konfigūraciją. Tai, žinoma, gali būti perduota kaip modernus menas, tačiau inžinieriaus jausmai tikrai bus įžeisti.

Tikslai

Dabar iškelsime pačius abstraktiausius tikslus:

• Tinklas yra tarsi vienas organizmas
• Konfigūracijos testavimas
• Tinklo būsenos versijų kūrimas
• Paslaugų stebėjimas ir savigyda

Vėliau šiame straipsnyje apžvelgsime, kokias priemones naudosime, o toliau – išsamiai apžvelgsime tikslus ir priemones.

Tinklas yra tarsi vienas organizmas

Apibrėžianti serialo frazė, nors iš pirmo žvilgsnio gali pasirodyti ne tokia reikšminga: konfigūruosime tinklą, o ne atskirus įrenginius.
Pastaraisiais metais pastebėjome, kad tinklas buvo traktuojamas kaip vienas subjektas, todėl Programinės įrangos apibrėžta tinklų kūrimas, Tikslais pagrįsti tinklai и Autonominiai tinklai.
Galų gale, ko reikia programoms globaliai iš tinklo: ryšio tarp taškų A ir B (na, kartais + B-Z) ir izoliacijos nuo kitų programų ir vartotojų.

Taigi mūsų užduotis šioje serijoje yra sukurti sistemą, išlaikant esamą konfigūraciją visą tinklą, kuri jau yra išskaidyta į faktinę kiekvieno įrenginio konfigūraciją pagal jo vaidmenį ir vietą.
Sistema tinklo valdymas reiškia, kad norėdami atlikti pakeitimus susisiekiame su juo, o jis savo ruožtu apskaičiuoja norimą kiekvieno įrenginio būseną ir ją sukonfigūruoja.
Tokiu būdu beveik iki nulio sumažiname rankinę prieigą prie CLI – bet kokie įrenginio nustatymų ar tinklo dizaino pakeitimai turi būti formalizuoti ir dokumentuoti – ir tik tada iškeliami į reikiamus tinklo elementus.

Pavyzdžiui, jei nuspręstume, kad nuo šiol stovo jungikliai Kazanėje turėtų skelbti du tinklus, o ne vieną, mes

1. Pirmiausia dokumentuojame sistemų pokyčius
2. Visų tinklo įrenginių tikslinės konfigūracijos generavimas
3. Paleidžiame tinklo konfigūracijos atnaujinimo programą, kuri suskaičiuoja, ką kiekviename mazge reikia pašalinti, ką pridėti, ir perkelia mazgus į norimą būseną.

Tuo pačiu metu pakeitimus atliekame rankiniu būdu tik pirmame žingsnyje.

Konfigūracijos testavimas

Žinomaskad 80% problemų atsiranda keičiant konfigūraciją – netiesioginis to įrodymas yra tai, kad per Naujųjų metų šventes dažniausiai viskas būna ramu.
Aš asmeniškai mačiau dešimtis pasaulinių prastovų dėl žmogiškosios klaidos: neteisinga komanda, konfigūracija buvo įvykdyta netinkamoje šakoje, bendruomenė pamiršo, MPLS buvo nugriautas visame maršrutizatoriuje, sukonfigūruotos penkios aparatinės įrangos dalys, bet klaida nebuvo šeštą pastebėjo, buvo atlikti seni kito asmens pakeitimai. Yra daugybė scenarijų.

Automatizavimas leis mums padaryti mažiau klaidų, bet didesniu mastu. Tokiu būdu galite blokuoti ne tik vieną įrenginį, bet ir visą tinklą vienu metu.

Nuo neatmenamų laikų mūsų seneliai įdėmiai tikrino atliktų pakeitimų teisingumą, plieno rutulius ir tinklo funkcionalumą po to, kai jie buvo išvynioti.
Tie seneliai, kurių darbas lėmė prastovą ir katastrofiškus nuostolius, paliko mažiau palikuonių ir laikui bėgant turėtų išmirti, tačiau evoliucija yra lėtas procesas, todėl ne visi pirmieji vis dar išbando pokyčius laboratorijoje.
Tačiau pažangos priešakyje yra tie, kurie automatizavo konfigūracijos testavimo procesą ir tolesnį jos pritaikymą tinkle. Kitaip tariant, aš pasiskolinau CI/CD procedūrą (Nuolatinis integravimas, nuolatinis diegimas) iš kūrėjų.
Vienoje iš dalių apžvelgsime, kaip tai įgyvendinti naudojant versijų valdymo sistemą, tikriausiai Github.

Kai priprasite prie tinklo CI/CD idėjos, per naktį konfigūracijos tikrinimo metodas, pritaikius jį gamybos tinklui, atrodys kaip ankstyvųjų viduramžių nežinojimas. Panašu į kovinę galvutę plaktuku.

Ekologiškas idėjų apie sistema tinklo valdymas ir CI/CD tampa visa konfigūracijos versija.

Versijų kūrimas

Darysime prielaidą, kad esant bet kokiems pakeitimams, kad ir kokie maži, net ir viename nepastebimame įrenginyje visas tinklas persikelia iš vienos būsenos į kitą.
Ir visada įrenginyje nevykdome komandos, keičiame tinklo būseną.
Taigi pavadinkime šias valstijas versijomis?

Tarkime, kad dabartinė versija yra 1.0.0.
Ar pasikeitė Loopback sąsajos IP adresas viename iš ToR? Tai nedidelė versija ir bus sunumeruota 1.0.1.
Mes peržiūrėjome maršrutų importavimo į BGP politiką – šiek tiek rimčiau – jau 1.1.0
Nusprendėme atsikratyti IGP ir pereiti tik prie BGP – tai jau radikalus dizaino pakeitimas – 2.0.0.

Tuo pačiu metu skirtingi DC gali turėti skirtingas versijas - tinklas vystosi, diegiama nauja įranga, kažkur pridedami nauji spinos lygiai, o ne kituose ir pan.

apie semantinės versijos kalbėsime atskirame straipsnyje.

Kartoju – bet koks pakeitimas (išskyrus derinimo komandas) yra versijos atnaujinimas. Administratoriai turi būti įspėti apie bet kokius nukrypimus nuo dabartinės versijos.

Tas pats pasakytina ir apie pakeitimų grąžinimą - tai nėra paskutinių komandų atšaukimas, tai nėra atšaukimas naudojant įrenginio operacinę sistemą - tai viso tinklo perkėlimas į naują (seną) versiją.

Paslaugų stebėjimas ir savigyda

Ši savaime suprantama užduotis šiuolaikiniuose tinkluose pasiekė naują lygį.
Dažnai stambūs paslaugų teikėjai laikosi požiūrio, kad sugedusią paslaugą reikia labai greitai sutvarkyti ir kelti naują, o ne išsiaiškinti, kas atsitiko.
„Labai“ reiškia, kad iš visų pusių turite būti dosniai padengtas stebėjimu, kuris per kelias sekundes aptiks menkiausius nukrypimus nuo normos.
Ir čia jau nebepakanka įprastų metrikų, tokių kaip sąsajos įkėlimas ar mazgų prieinamumas. Neužtenka ir budinčio pareigūno atliekamo jų stebėjimo rankiniu būdu.
Dėl daugelio dalykų turėtų būti Savaime išgijantis — raudonai užsidegė stebėjimo lemputės ir mes patys nuėjome ir uždėjome gyslotį ten, kur skaudėjo.

Ir čia mes taip pat stebime ne tik atskirus įrenginius, bet ir viso tinklo būklę, tiek „whitebox“, kas yra gana suprantama, tiek „blackbox“, kuri yra sudėtingesnė.

Ko mums reikės norint įgyvendinti tokius ambicingus planus?

• Turėkite visų tinkle esančių įrenginių sąrašą, jų vietą, vaidmenis, modelius, programinės įrangos versijas.
  kazan-leaf-1.lmu.net, Kazanė, lapas, Kadagys QFX 5120, R18.3.
• Turėti tinklo paslaugų apibūdinimo sistemą.
  IGP, BGP, L2/3VPN, politika, ACL, NTP, SSH.
• Gebėti inicijuoti įrenginį.
  Pagrindinio kompiuterio pavadinimas, Mgmt IP, Mgmt maršrutas, vartotojai, RSA raktai, LLDP, NETCONF
• Sukonfigūruokite įrenginį ir nustatykite norimą (įskaitant seną) versiją.
• Bandymo konfigūracija
• Periodiškai tikrinkite visų įrenginių būseną, ar nėra nukrypimų nuo esamų, ir praneškite, kam ji turėtų būti.
  Per naktį kažkas tyliai pridėjo taisyklę prie ACL.
• Stebėti našumą.

Fondai

Tai skamba pakankamai sudėtingai, kad būtų galima pradėti skaidyti projektą į komponentus.

Ir jų bus dešimt:

1. Inventorizacijos sistema
2. IP erdvės valdymo sistema
3. Tinklo paslaugų aprašymo sistema
4. Įrenginio inicijavimo mechanizmas
5. Pardavėjo-agnostinės konfigūracijos modelis
6. Pardavėjo specifinė tvarkyklės sąsaja
7. Konfigūracijos pateikimo į įrenginį mechanizmas
8. CI / CD
9. Atsarginio kopijavimo ir nukrypimų paieškos mechanizmas
10. Stebėjimo sistema

Tai, beje, pavyzdys, kaip pasikeitė požiūris į ciklo tikslus – projekte buvo 4 komponentai.

Iliustracijoje pavaizdavau visus komponentus ir patį įrenginį.
Susikertantys komponentai sąveikauja vienas su kitu.
Kuo didesnis blokas, tuo daugiau dėmesio reikia skirti šiam komponentui.

1 komponentas: inventoriaus sistema

Akivaizdu, kad norime žinoti, kokia įranga kur yra, prie ko prijungta.
Atsargų sistema yra neatsiejama bet kurios įmonės dalis.
Dažniausiai įmonė turi atskirą tinklo įrenginių inventorizavimo sistemą, kuri išsprendžia konkretesnes problemas.
Kaip šios straipsnių serijos dalį pavadinsime jį DCIM – duomenų centro infrastruktūros valdymu. Nors pats terminas DCIM, griežtai kalbant, apima daug daugiau.

Savo tikslais jame saugosime šią informaciją apie įrenginį:

• Inventoriaus numeris
• Pavadinimas / aprašymas
• Modelis („Huawei CE12800“, „Juniper QFX5120“ ir kt.)
• Būdingi parametrai (plokštės, sąsajos ir kt.)
• Vaidmuo (Lapas, stuburas, Border Router ir kt.)
• Vieta (regionas, miestas, duomenų centras, stovas, įrenginys)
• Sujungimai tarp įrenginių
• Tinklo topologija

Visiškai aišku, kad mes patys norime visa tai žinoti.
Bet ar tai padės automatizavimo tikslais?
Žinoma.
Pavyzdžiui, žinome, kad tam tikrame Leaf jungiklių duomenų centre, jei tai yra „Huawei“, ACL tam tikram srautui filtruoti turėtų būti taikomas VLAN, o jei tai yra „Juniper“, tada 0 fizinės sąsajos bloke.
Arba turite įdiegti naują Syslog serverį visose regiono sienose.

Jame saugosime virtualius tinklo įrenginius, pavyzdžiui, virtualius maršrutizatorius arba šakninius reflektorius. Galime pridėti DNS serverius, NTP, Syslog ir apskritai viską, kas vienaip ar kitaip susiję su tinklu.

2 komponentas: IP erdvės valdymo sistema

Taip, ir šiais laikais yra žmonių komandos, kurios seka priešdėlius ir IP adresus Excel faile. Tačiau šiuolaikinis požiūris vis dar yra duomenų bazė su nginx/apache sąsaja, API ir plačiomis funkcijomis, leidžiančiomis įrašyti IP adresus ir tinklus, suskirstytus į VRF.
IPAM – IP adresų valdymas.

Savo tikslams joje saugosime šią informaciją:

• VLAN
• VRF
• Tinklai / potinkliai
• IP adresai
• Adresų susiejimas su įrenginiais, tinklų su vietomis ir VLAN numeriais

Vėlgi, aišku, kad norime užtikrinti, kad skirdami naują IP adresą ToR loopback, nesukluptume dėl to, kad jis kažkam jau buvo priskirtas. Arba du kartus naudojome tą patį priešdėlį skirtinguose tinklo galuose.
Bet kaip tai padeda automatizuoti?
Tai lengva.
Sistemoje prašome priešdėlio su Loopbacks vaidmeniu, kuriame yra IP adresai, kuriuos galima skirti – jei randame, skiriame adresą, jei ne, prašome sukurti naują priešdėlį.
Arba kurdami įrenginio konfigūraciją iš tos pačios sistemos galime sužinoti, kurioje VRF turi būti sąsaja.
O paleidus naują serverį, scenarijus prisijungia prie sistemos, išsiaiškina, kuriame komutatoriuje yra serveris, kuriame prievade ir koks potinklis priskirtas sąsajai – ir iš jo paskirs serverio adresą.

Tai rodo norą sujungti DCIM ir IPAM į vieną sistemą, kad nedubliuotų funkcijos ir neaptarnautų dviejų panašių objektų.
Taip ir padarysime.

3 komponentas. Tinklo paslaugų aprašymo sistema

Jei pirmosiose dviejose sistemose saugomi kintamieji, kuriuos vis tiek reikia kažkaip naudoti, tada trečiojoje kiekvienam įrenginio vaidmeniui aprašoma, kaip jis turėtų būti sukonfigūruotas.
Verta išskirti du skirtingus tinklo paslaugų tipus:

• Infrastruktūra
• Klientas.

Pirmieji yra skirti užtikrinti pagrindinį ryšį ir įrenginio valdymą. Tai apima VTY, SNMP, NTP, Syslog, AAA, maršruto parinkimo protokolus, CoPP ir kt.
Pastarieji klientui organizuoja paslaugą: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP ir kt.
Žinoma, yra ir ribinių atvejų – kur įtraukti MPLS LDP, BGP? Taip, ir maršruto parinkimo protokolai gali būti naudojami klientams. Bet tai nėra svarbu.

Abiejų tipų paslaugos yra suskirstytos į konfigūracijos primityvus:

• fizinės ir loginės sąsajos (tag/anteg, mtu)
• IP adresai ir VRF (IP, IPv6, VRF)
• ACL ir srauto apdorojimo politika
• Protokolai (IGP, BGP, MPLS)
• Maršruto strategijos (priedėlių sąrašai, bendruomenės, ASN filtrai).
• Komunalinės paslaugos (SSH, NTP, LLDP, Syslog...)
• ir kt.

Kaip tiksliai tai padarysime, kol kas neįsivaizduoju. Mes tai panagrinėsime atskirame straipsnyje.

Jei šiek tiek arčiau gyvenimo, galėtume tai apibūdinti
„Leaf“ jungiklis turi turėti BGP seansus su visais prijungtais „Spine“ jungikliais, importuoti prijungtus tinklus į procesą ir priimti tik tinklus iš tam tikro priešdėlio iš „Spine“ jungiklių. Apriboti CoPP IPv6 ND iki 10 pps ir kt.
Savo ruožtu stuburai rengia seansus su visais prijungtais laidais, veikdami kaip šaknų atšvaitai, ir iš jų priima tik tam tikro ilgio ir tam tikros bendruomenės maršrutus.

4 komponentas: įrenginio inicijavimo mechanizmas

Šioje antraštėje sujungiu daugelį veiksmų, kurie turi būti atliekami, kad įrenginys būtų rodomas radare ir būtų pasiekiamas nuotoliniu būdu.

1. Įveskite įrenginį į inventoriaus sistemą.
2. Pasirinkite valdymo IP adresą.
3. Nustatykite pagrindinę prieigą prie jo:
   Pagrindinio kompiuterio pavadinimas, valdymo IP adresas, maršrutas į valdymo tinklą, vartotojai, SSH raktai, protokolai - telnet/SSH/NETCONF

Yra trys požiūriai:

• Viskas visiškai rankiniu būdu. Įrenginys atnešamas į stendą, kur paprastas organiškas žmogus įves jį į sistemas, prisijungs prie pulto ir sukonfigūruos. Gali dirbti mažuose statiniuose tinkluose.
• ZTP – „Zero Touch Provisioning“. Atvyko aparatūra, atsistojo, gavo adresą per DHCP, nuėjo į specialų serverį ir susikonfigūravo.
• Konsolių serverių infrastruktūra, kur pradinė konfigūracija vyksta per konsolės prievadą automatiniu režimu.

Apie visus tris pakalbėsime atskirame straipsnyje.

5 komponentas: pardavėjo ir agnostinės konfigūracijos modelis

Iki šiol visos sistemos buvo skirtingos pataisos, kuriose pateikiami kintamieji ir deklaratyvus aprašymas, ką mes norėtume matyti tinkle. Tačiau anksčiau ar vėliau teks susidurti su specifika.
Šiame etape kiekvienam konkrečiam įrenginiui primityvai, paslaugos ir kintamieji sujungiami į konfigūracijos modelį, kuris iš tikrųjų apibūdina visą konkretaus įrenginio konfigūraciją, tik neatsižvelgiant į pardavėją.
Ką daro šis žingsnis? Kodėl iš karto nesukūrus įrenginio konfigūracijos, kurią galėtumėte tiesiog įkelti?
Tiesą sakant, tai išsprendžia tris problemas:

1. Neprisitaikykite prie konkrečios sąsajos sąveikai su įrenginiu. Ar tai būtų CLI, NETCONF, RESTCONF, SNMP – modelis bus tas pats.
2. Nelaikykite šablonų/skriptų skaičiaus pagal tiekėjų skaičių tinkle, o pasikeitus dizainui keiskite tą patį keliose vietose.
3. Įkelkite konfigūraciją iš įrenginio (atsarginės kopijos), įdėkite ją į lygiai tą patį modelį ir tiesiogiai palyginkite tikslinę konfigūraciją su esama, kad apskaičiuotumėte delta ir paruoštumėte konfigūracijos pataisą, kuris pakeis tik tas dalis, kurios yra būtinos arba nustatys nukrypimus.

Šio etapo metu gauname nuo pardavėjo nepriklausomą konfigūraciją.

6 komponentas. Tiekėjo specifinė tvarkyklės sąsaja

Nereikėtų savęs lepinti viltimi, kad vieną dieną bus galima sukonfigūruoti ciską lygiai taip pat, kaip kadagio, tiesiog siunčiant jiems lygiai tokius pačius skambučius. Nepaisant augančio baltųjų dėžučių populiarumo ir NETCONF, RESTCONF, OpenConfig palaikymo atsiradimo, specifinis šių protokolų teikiamas turinys skiriasi nuo tiekėjo iki tiekėjo, ir tai yra vienas iš jų konkurencinių skirtumų, kurių jie taip lengvai nepasiduos.
Tai yra maždaug tas pats, kas „OpenContrail“ ir „OpenStack“, kurių „NorthBound“ sąsaja yra RestAPI, tikisi visiškai skirtingų skambučių.

Taigi, penktajame žingsnyje nuo pardavėjo nepriklausomas modelis turi įgyti tokią formą, kokia jis bus nukreiptas į aparatinę įrangą.
O čia visos priemonės geros (ne): CLI, NETCONF, RESTCONF, SNMP tiesiog.

Todėl mums reikės tvarkyklės, kuri perkels ankstesnio žingsnio rezultatą į reikiamą konkretaus tiekėjo formatą: CLI komandų rinkinio, XML struktūros.

7 komponentas. Konfigūracijos pateikimo į įrenginį mechanizmas

Sugeneravome konfigūraciją, bet ją vis tiek reikia pristatyti į įrenginius – ir, aišku, ne ranka.
Pirma, susiduriame su klausimu, kokiu transportu naudosimės? Ir šiandien pasirinkimas nebėra mažas:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• POILSIO API
• „OpenFlow“ (nors tai yra nuokrypis, nes tai būdas pateikti FIB, o ne nustatymus)

Pažymėkime t čia. CLI yra palikimas. SNMP... kosulys kosulys.
RESTCONF vis dar nežinomas gyvūnas; REST API nepalaiko beveik niekas. Todėl serijoje daugiausia dėmesio skirsime NETCONF.

Tiesą sakant, kaip skaitytojas jau suprato, šiuo metu mes jau nusprendėme dėl sąsajos - ankstesnio veiksmo rezultatas jau pateikiamas pasirinktos sąsajos formatu.

Antra, o su kokiais įrankiais tai darysime?
Čia taip pat didelis pasirinkimas:

• Savarankiškai parašytas scenarijus arba platforma. Apsaugokime save ncclient ir asyncIO ir darykime viską patys. Kiek mums kainuoja sukurti diegimo sistemą nuo nulio?
• Ansible su savo turtinga tinklo modulių biblioteka.
• Druska su savo menku darbu su tinklu ir ryšiu su Napalm.
• Tiesą sakant, Napalmas, kuris žino keletą pardavėjų, ir viskas, atsisveikink.
• Nornir yra dar vienas gyvūnas, kurį mes išskrosime ateityje.

Čia mėgstamiausias dar neišrinktas – ieškosime.

Kas čia dar svarbu? Konfigūracijos taikymo pasekmės.
Sėkmingas ar ne. Ar vis dar yra prieiga prie aparatinės įrangos, ar ne?
Atrodo, kad įsipareigojimas čia padės patvirtinti ir patvirtinti, kas buvo atsisiųsta į įrenginį.
Tai kartu su teisingu NETCONF įdiegimu žymiai susiaurina tinkamų įrenginių asortimentą – nedaug gamintojų palaiko įprastus įsipareigojimus. Bet tai tik viena iš būtinų sąlygų RFP. Galų gale niekas nesijaudina, kad nei vienas Rusijos pardavėjas neatitiks 32*100GE sąsajos sąlygos. O gal jis nerimauja?

Komponentas 8. CI/CD

Šiuo metu jau turime visų tinklo įrenginių konfigūraciją.
Rašau „už viską“, nes kalbame apie tinklo būsenos versijų nustatymą. Ir net jei reikia pakeisti tik vieno jungiklio nustatymus, pakeitimai skaičiuojami visam tinklui. Akivaizdu, kad daugumai mazgų jie gali būti lygūs nuliui.

Bet, kaip jau buvo sakyta aukščiau, mes nesame kažkokie barbarai, norintys viską perkelti tiesiai į gamybą.
Sugeneruota konfigūracija pirmiausia turi pereiti per „Pupeline CI“ / kompaktinį diską.

CI/CD reiškia Continuous Integration, Continuous Deployment. Tai metodas, pagal kurį komanda kas šešis mėnesius ne tik išleidžia naują pagrindinį leidimą, visiškai pakeičiantį senąjį, bet ir reguliariai palaipsniui diegia (diegia) naujas funkcijas mažomis dalimis, kurių kiekvienos suderinamumas, saugumas ir našumas (integracija).

Norėdami tai padaryti, turime versijų valdymo sistemą, kuri stebi konfigūracijos pakeitimus, laboratoriją, kuri tikrina, ar klientų aptarnavimas neveikia, stebėjimo sistemą, kuri tikrina šį faktą, o paskutinis žingsnis yra gamybos tinklo pakeitimų diegimas.

Išskyrus derinimo komandas, absoliučiai visi tinklo pakeitimai turi vykti per CI/CD vamzdyną – tai mūsų ramaus gyvenimo ir ilgos, laimingos karjeros garantija.

9 komponentas. Atsarginė kopija ir anomalijų aptikimo sistema

Na, nereikia vėl kalbėti apie atsargines kopijas.
Mes tiesiog pridėsime juos prie karūnos arba pakeitę git konfigūraciją.

Tačiau antroji dalis įdomesnė – kas nors turėtų stebėti šias atsargines kopijas. Ir kai kuriais atvejais šis žmogus turi eiti ir viską paversti taip, kaip buvo, o kitais – kažkam miaukti, kad kažkas negerai.
Pavyzdžiui, jei atsirado naujas vartotojas, kuris nėra registruotas kintamuosiuose, turite jį pašalinti iš įsilaužimo. Ir jei geriau neliesti naujos ugniasienės taisyklės, galbūt kažkas ką tik įjungė derinimą, o gal nauja paslauga, bungler, buvo užregistruota ne pagal taisykles, bet žmonės jau prisijungė prie jos.

Nepaisant automatizavimo sistemų ir tvirtos valdymo rankos, vis tiek neišvengsime nedidelės viso tinklo delta. Norėdami derinti problemas, niekas vis tiek nepridės sistemų konfigūracijos. Be to, jie gali būti net neįtraukti į konfigūracijos modelį.

Pavyzdžiui, užkardos taisyklė, skirta skaičiuoti paketų skaičių konkrečiame IP, siekiant lokalizuoti problemą, yra visiškai įprasta laikina konfigūracija.

10 komponentas. Stebėjimo sistema

Iš pradžių neketinau nagrinėti stebėjimo temos – tai vis dar didelė, prieštaringa ir sudėtinga tema. Tačiau viskas vyko į priekį, paaiškėjo, kad tai buvo neatsiejama automatizavimo dalis. Ir to apeiti neįmanoma net be praktikos.

Evolving Thought yra natūrali CI/CD proceso dalis. Išleidę konfigūraciją tinkle, turime sugebėti nustatyti, ar dabar viskas gerai.
Ir mes kalbame ne tik ir ne tiek apie sąsajos naudojimo grafikus ar mazgų prieinamumą, bet apie subtilesnius dalykus - reikiamų maršrutų buvimą, atributus juose, BGP seansų skaičių, OSPF kaimynus, našumą nuo galo iki galo. papildomų paslaugų.
Ar išorinio serverio syslog'ai nustojo kauptis, ar sugedo SFlow agentas, ar pradėjo mažėti eilės, ar nutrūko ryšys tarp kai kurių priešdėlių porų?

Apie tai apžvelgsime atskirame straipsnyje.

išvada

Kaip pagrindą pasirinkau vieną iš šiuolaikinių duomenų centrų tinklo konstrukcijų – L3 Clos Fabric su BGP kaip maršruto parinkimo protokolu.
Šį kartą tinklą kursime „Juniper“, nes dabar „JunOs“ sąsaja yra „vanlove“.

Apsunkinkime savo gyvenimą naudodami tik atvirojo kodo įrankius ir kelių pardavėjų tinklą – taigi, be Juniper, pakeliui išrinksiu dar vieną laimingąjį.

Būsimų leidinių planas yra maždaug toks:
Pirmiausia pakalbėsiu apie virtualius tinklus. Visų pirma dėl to, kad noriu, o antra, dėl to, kad be šito infrastruktūros tinklo projektavimas nebus labai aiškus.
Tada apie patį tinklo dizainą: topologiją, maršrutą, politiką.
Surinkime laboratorinį stendą.
Pagalvokime apie tai ir galbūt pabandykime inicijuoti įrenginį tinkle.
Ir tada apie kiekvieną komponentą išsamiai.

Ir taip, nežadu grakščiai užbaigti šio ciklo jau paruoštu sprendimu. 🙂

Naudingos nuorodos

• Prieš gilinantis į seriją, verta perskaityti Natašos Samoilenko knygą Python tinklo inžinieriams. Ir gal praeis kursas.
• Taip pat bus naudinga paskaityti RFC apie duomenų centrų gamyklų dizainą iš „Facebook“, kurį sukūrė Peteris Lapukhovas.
• Architektūros dokumentacija suteiks jums supratimą apie tai, kaip veikia Overlay SDN. Volframo audinys (anksčiau Open Contrail).

Ačiū

Romos tarpeklis. Dėl komentarų ir redagavimo.
Artiomas Černobėjus. Dėl KDPV.

Šaltinis: www.habr.com