SDSMi lõppes, aga kontrollimatu soov kirjutada on jäänud.

Pikki aastaid on meie vend kannatanud rutiinse töö tegemise all, ristunud sõrmed enne commit'i ja unetuks jäänud öiste rollback'ide tõttu.
Aga tumedatele aegadele tuleb lõpp.

Selle artikliga alustan seeriat sellest, kuidas mulle automaatika paistab.
Teeme üle etapid automaatikas, muutuja salvestamise, disaini formaliseerimise, RestAPI, NETCONF, YANG, YDK ja programmeerime palju.
Minu tähendab, et a) see pole objektiivne tõde, b) mitte absoluutne parim lähenemine c) minu vaated võivad isegi liikuda esimesest artiklist viimase juurde — ausalt öeldes, mustandist avaldamiseni olen kõik täielikult kaks korda ümber kirjutanud.

Sisu

1. Eesmärgid
   1. Võrk — nagu üks organism
   2. Konfiguratsiooni testimine
   3. Versioonimine
   4. Teenuste jälgimine ja enese taastamine

2. Tööriistad
   1. Inventeerimisse süsteem
   2. IP-ruumi haldamise süsteem
   3. Võrguteenuste kirjeldamise süsteem
   4. Seadmete initsialiseerimise mehhanism
   5. Müügi sõltumatu konfiguratsioonimudel
   6. Müüja-spetsiifiline seadme draiver
   7. Konfiguratsiooni seadmesse saatmise mehhanism
   8. CI/CD
   9. Andmete varundamise ja kõrvalekallete otsimise mehhanism
   10. Jälgimisseade

3. Kokkuvõte

Proovin ADSMi juhtida veidi erinevas formaadis kui SDMS. Suured, põhjalikud numbrilised lood jätkuvad, kuid nende vahele avaldan igapäevaelust väikeseid märkmeid. Püüan ka siin perfektsionismiga võidelda ja mitte igaüht liiga palju lihvida.

On naljakas, et teist korda tuleb läbida sama teed.

Alguses pidin ise kirjutama artikleid võrkude kohta, sest neid ei olnud venekeelses internetis.

Nüüd ei suutnud ma leida ühtegi põhjalikku dokumenti, mis süsteemiliselt käsitleks automatiseerimise lähenemisviise ning tutvustaks eeltoodud tehnoloogiaid lihtsate praktiliste näidete abil.

Võib-olla ma eksin, seega saatke lingid headest ressurssidest. Siiski ei muuda see minu otsust kirjutada, sest peamine eesmärk on ikkagi õppida midagi ise, ja lähedaste elu lihtsustamine on meeldiv boonus, mis hellitab kogemuste levimise geeni.

Püüdleme keskmise suurusega LAN DC andmekeskuse poole ja töötame välja kogu automatiseerimise skeemi.
Mõningaid asju teen ma koos teiega praktiliselt esmakordselt.

Siin kirjeldatud ideedel ja tööriistadel ei ole mul suurt originaalsust. Dmitri Figoly'l on suurepärane kanal selle teema kohta otseülekannete jaoks..
Artiklid kattuvad mitmetes aspektides nende ideedega.

LAN DC-s on 4 andmekeskust, umbes 250 lülitit, paar marsruuterit ja paar tulemüüri.
See pole Facebook, aga piisav, et sügavalt mõelda automatiseerimisele.
Käib küll müüt, et kui teil on rohkem kui 1 seade, on automatiseerimine juba vajalik.
Tegelikult on raske ette kujutada, et keegi suudab nüüd elada ilma vähemalt kamp skriptidest.
Kuigi olen kuulnud, et on selliseid ettevõtteid, kus IP-aadresside arvestust peetakse Excelis, iga tuhandete võrguseadmete seadistamine käib käsitsi ja igal neist on oma kordumatu konfiguratsioon. Seda võib muidugi pidada kaasaegsesse kunstiks, aga inseneri tunded on kindlasti solvatud.

Eesmärgid

Praegu seame me maksimaalselt abstraktsed eesmärgid:

• Võrk — nagu üks organism
• Konfiguratsiooni testimine
• Võrgu oleku versioonimine.
• Teenuste jälgimine ja enese taastamine

Hiljem selles artiklis käsitleme, milliseid vahendeid kasutame, ja järgmistes täpsustame nii eesmärke kui ka vahendeid.

Võrk — nagu üks organism

Määrav tsükkel, kuigi esmapilgul võib see tunduda mitte nii oluline: me seadistame võrku, mitte eraldiseisvaid seadmeid.
Viimastel aastatel oleme märganud suunda, kus võrku käsitletakse kui ühtset üksust, seetõttu ilmuvad meie ellu Tarkvara Määratud Võrgud, Intent Driven Networks ja Autonoomsed võrgud.
Mida rakendused võrgu puhul globaalsetel eesmärkidel vajavad: ühendus punktide A ja B vahel (mõnikord ka +B-Y) ja isolatsioon teiste rakenduste ja kasutajate eest.

Seega on meie ülesanne selles seerias — ehitada süsteem, mis toetab aktuaarset konfiguratsiooni kogu võrgu, mis juba dekomponeeritakse aktuaalsesse konfiguratsiooni igas seadmes vastavalt selle rollile ja asukohale.
Süsteem võrgu haldamine tähendab, et muudatuste tegemiseks pöördume selle poole, ning see arvutab vajalikku olekut igas seadmes ja seadistab selle.
Nii vähendame praktiliselt nullini käsitsi CLI-s liikumise — kõik seadmete seadistustes või võrgu disainis tehtavad muudatused peavad olema formaliseeritud ja dokumenteeritud — ja alles siis rakendatakse need vajalikele võrgu elementidele.

See, for example, if we decided that from now on, the rack switches in Kazan should announce two networks instead of one, we

1. First, we document the changes in the systems
2. We generate the target configuration for all network devices
3. We launch the network configuration update program, which calculates what needs to be removed on each node, what to add, and brings the nodes to the desired state.

At the same time, we manually make changes only at the first step.

Konfiguratsiooni testimine

It is known, that 80% of problems occur during configuration changes — an indirect indication is that during the New Year holidays, everything is usually calm.
I have personally witnessed dozens of global downtimes due to human error: running an incorrect command, executing it in the wrong configuration branch, forgetting to notify the community, globally deleting MPLS on a router, configuring five devices, and missing an error on the sixth, committing old changes made by someone else. The scenarios are countless.

Automation will allow us to make fewer mistakes, but on a larger scale. This way, we can brick not just one device, but the entire network at once.

Aegade jooksul on meie vanaisad kontrollinud muudatuste õigsust terava silmaga, tipptehnoloogia ja võrgu töökindluse abil pärast nende juurutamist.
Need vanaisad, kelle tööd tõid kaasa seiskamisi ja katastroofilisi kahjusid, jätsid vähem järglasi ja pidid ajaga välja surema, kuid evolutsiooniprotsess on aeglane ning seetõttu ei kontrolli kõik siiani muudatusi laboratooriumis ette.
Kuid progressi tipus on need, kes automatiseerisid konfiguratsiooni testimise protsessi ning selle edasise rakendamise võrku. Teisisõnu — laenatud CI/CD protseduur (Continuous Integration, Continuous Deployment) arendajatelt.
Üks osa käsitleb, kuidas seda rakendada versioonihaldussüsteemiga, tõenäoliselt GitHubiga.

Kui olete harjunud mõttega võrgu CI/CD-st, tundub teise konfiguratsiooni kontrollimise meetod selle rakendamise kaudu töösse võrku ühel hetkel varakeskaegse inimesena. Umbes nagu lüüa haamriga tuumarelvade kallale.

Ideede loogiline jätk süsteemile võrgu juhtimise ja CI/CD osas on täielik konfiguratsiooni versioonimine.

Versioonimine

Kujutame ette, et iga muudatuse korral, isegi kõige vähesema, isegi ühel märkamatul seadmel, muutub kogu võrk ühest olekust teise.
Ja me ei täida kunagi käsku seadmes, me muutume võrgustikku.
Kuidas kutsuda neid olekuid versioonideks?

Oletame, et praegune versioon on 1.0.0.
Kui Loopback-liidese IP-aadress muutus ühes ToR-seadmest, on see väike versioon — saab numbri 1.0.1.
Muutisime BGP-s marsruudi impordi poliitikaid — pisut tõsisem — juba 1.1.0.
Otsustasime loobuda IGP-st ja minna ainult BGP peale — see on juba radikaalne disainimuudatus — 2.0.0.

Erinevate andmekeskuste versioonid võivad olla erinevad — võrk areneb, paigaldatakse uus varustus, kuskil lisanduvad uued spina tasemed, kuskil — ei, jne.

Umbes semantiline versioneerimine me räägime sellest eraldi artiklis.

Kordan — iga muudatus (välja arvatud silumis käsud) on versiooniuuendus. Kõikest kõrvalekaldumistest kehtivast versioonist peavad administraatorid olema teavitatud.

Sama kehtib ka muudatuste tagasikutsumise kohta - see ei ole viimaste käskude tühistamine, see ei ole seadme opsüsteemi kaudu teostatud rollback - see on kogu võrgu viimine uut (vana) versiooni.

Teenuste jälgimine ja enese taastamine

See iseenesestmõistetav ülesanne tänapäevastes võrkudes tõuseb uuele tasemele.
Sageli praktiseerivad suured teenusepakkujad lähenemist, et kukkunud teenus tuleb kiiresti korda teha ja uus püstitada, selle asemel et uurida, mis juhtus.
„Kiire” tähendab, et kõikjalt tuleb ümbritseda end jälgimisega, mis mõne sekundi jooksul tuvastab vähimadki kõrvalekalded normist.
Ja siin ei piisa enam harjumuspärasest mõõtmisest, nagu liidese koormus või sõlme kättesaadavus. Ei piisa ka dežuuriva töötaja käsitsi jälgimisest.
Paljuski peab olema Self-Healing — monitorid põlevad punases ja lähevad ise kummeli lehte leidma, kus valutab.

Ja siin jälgime me mitte ainult üksikute seadmete, vaid ka kogu võrgu tervist, samuti nii valgekarbi lähenemisest, mis on suhteliselt selge, kui ka musta karbi lähenemisest, mis on juba keerulisem.

Mida vajame selliste ambitsioonikate plaanide elluviimiseks?

• Ole kõikide võrgu seadmete loend, nende asukohad, rollid, mudelid ja tarkvaraversioonid.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Ole süsteem, mis kirjeldab võrgu teenuseid.
  IGP, BGP, L2/3VPN, Poliitika, ACL, NTP, SSH.
• Osata seadet initsialiseerida.
  Hostname, Mgmt IP, Mgmt Route, Kasutajad, RSA-võtmed, LLDP, NETCONF
• Seadistada seade ja viia konfiguratsioon soovitud (ka vanemasse) versiooni.
• Testida konfiguratsiooni
• Perioodiliselt kontrollida kõikide seadmete seisukorda, et tuvastada kõrvalekaldeid ja informeerida vajalikku isikut.
  Öösel lisas keegi vaikselt reeglile ACL..
• Jälgida töökorrasolekut.

Tööriistad

Tundub piisavalt keeruline, et alustada projekti komponente dekomponeerimist.

Ja neid on kümme:

1. Inventeerimisse süsteem
2. IP-ruumi haldamise süsteem
3. Võrguteenuste kirjeldamise süsteem
4. Seadmete initsialiseerimise mehhanism
5. Müügi sõltumatu konfiguratsioonimudel
6. Müüja-spetsiifiline seadme draiver
7. Konfiguratsiooni seadmesse saatmise mehhanism
8. CI/CD
9. Andmete varundamise ja kõrvalekallete otsimise mehhanism
10. Jälgimisseade

See on muide näide sellest, kuidas vaade tsükli eesmärkidele on aja jooksul muutunud — komponentide mustandis oli neli.

Illustratsioonil olen välja joonistanud kõik komponendid ja seadme.
Üksteisega suhtlevad üksteisega kattuvad komponendid.
Mida suurem on plokk, seda rohkem tähelepanu tuleb sellele komponendile pöörata.

Komponent 1. Inventariseerimissüsteem

Ilmselgelt tahame teada, milline varustus kus asub ja millega see on ühendatud.
Inventariseerimissüsteem on iga ettevõtte lahutamatu osa.
Tavaliselt on ettevõttel erinev inventeerimissüsteem võrguseadmete jaoks, mis lahendab spetsiifilisemaid ülesandeid.
Artiklite seerias nimetame seda DCIM-iks — Data Center Infrastructure Management. Kuigi termin DCIM hõlmab rangelt võttes palju rohkem.

Oma ülesannetes hoiame seal järgmisi seadme kohta käivaid andmeid:

• Inventarinumber
• Nimi/description
• Mudel (Huawei CE12800, Juniper QFX5120 jne.)
• Iseloomulikud parameetrid (plaadid, liidesed jne.)
• Roll (Leaf, Spine, Border Router jne.)
• Asukoht (region, linn, andmekeskus, rack, unit)
• Seadmete vahelised interkonektid
• Võrgu topoloogia

On täiesti arusaadav, et tahame ise kõike seda teada.
Kuid kas see aitab automatiseerimise eesmärkidel?
Ilmselgelt.
Näiteks teame, et antud andmekeskuses Leaf-lülititel, kui need on Huawei, tuleks ACL filtreerimiseks rakendada VLAN-is, ja kui need on Juniper, siis füüsilise liidese unit 0-l.
Või tuleb levitada uus Syslog-server kõigile regiooni piirdele.

Selle eesmärgi jaoks hoiame me virtuaalseid võrgu seadmeid, näiteks virtuaalseid ruutereid või rutreflektoreid. Saame lisada DNS-servereid, NTP, Syslog ja üldiselt kõike, mis on võrguga seotud.

Komponent 2. IP-ruumi haldamise süsteem

Jah, meie ajal on endiselt gruppe inimesi, kes peavad IP-e ja prefikseid Exceli failides. Kuid kaasaegne lähenemine on ikkagi andmebaas, millel on frontend nginxi/apache'i, API ja laiad funktsioonid IP-aadresside ja võrkude arvestamiseks, jagatuna VRF-ideks.
IPAM — IP Aadressi Halduse süsteem.

Meie vajaduste jaoks hoiame selles järgmisi andmeid:

• VLAN
• VRF
• Võrgud/Subvõrgud
• IP-aadressid
• Aadresside sidumine seadmetega, võrkude sidumine asukohtade ja VLAN-numbritega

On selge, et soovime olla kindlad, et kui määrame uue IP-aadressi ToR-i loopbackile, ei juhtu, et see on juba kellelegi määratud. Või et sama prefiks on kasutatud kaks korda võrgu erinevates otsades.
Aga kuidas see aitab automatiseerimisel?
Lihtne.
Küsimiseks loodud süsteemis prefiks, millel on Loopbacks roll, kus on saadaval määramiseks IP-aadressid — kui leiatakse, määrame aadressi, kui ei, küsime uue prefiksi loomist.
Või seadme konfigureerimise loomisel saame samast süsteemist teada, millises VRF-is peaks liides asuma.
Ja kui uus server käivitub, siis skript kontrollib süsteemis, millises serveri lülitises, millises porti ja milline alamvõrk on liidesele määratud — sellest väljastatakse serveri aadress.

Tuleb soov DCIM ja IPAM ühendada ühte süsteemi, et mitte dubleerida funktsioone ja mitte teenindada kahte sarnast subjekt.
Nii me ka teeme.

Komponent 3. Võrguteenuste kirjeldamise süsteem.

Kui esimesed kaks süsteemi salvestavad muutujaid, mida tuleb kuidagi kasutada, siis kolmas kirjeldab iga seadme rolli jaoks, kuidas see peaks olema seadistatud.
Tasub esile tuua kaks erinevat tüüpi võrguteenuseid:

• Infrastruktuuri
• Klienditeenused.

Esimesed on mõeldud põhiliidese ja seadme haldamise tagamiseks. Siia kuuluvad VTY, SNMP, NTP, Syslog, AAA, marsruutimisprotokollid, CoPP jne.
Teised korraldavad kliendi teenust: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP jne.
Muidugi on ka piiritapjuhud — kuhu liigitada MPLS LDP, BGP? Ja marsruutimisprotokolle võib kasutada ka klientide jaoks. Kuid see ei ole põhimõtteline.

Mõlemad teenustüübid jagunevad konfigureeritavateks primitiivideks:

• füüsilised ja loogilised liidesed (tahvel/antahvel, mtu)
• IP-aadressid ja VRF (IP, IPv6, VRF)
• ACL ja liikluse töötlemise poliitikad
• Protokollid (IGP, BGP, MPLS)
• Marsruudistamise poliitikad (prefikside loendid, kogukonnad, ASN-filterid).
• Teenused (SSH, NTP, LLDP, Syslog…)
• jne.

Kuidas me seda täpselt teeme, ei oska praegu öelda. Tegeleme sellega eraldi artiklis.

Kuid kui minna reaalsuse lähedale, võiksime kirjeldada, et
Lehe lüliti peab olema BGP-seansid kõikide ühendatud Spine-lülititega, importima ühendatud võrke ja aktsepteerima Spine-lülititest ainult kindlatest prefiksidest võrke. Piirama CoPP IPv6 ND-d 10 pps jne.
Spine-lülitid peavad omakorda hoidma seansse kõigi ühendatud lehtedega, toimides juurepeegeldajatena, ja aktsepteerima nendelt ainult teatud pikkusega marsruute ja teatud kogukonnaga.

Komponent 4. Seadmestiku initsialiseerimise mehhanism

Selle pealkirja all ühendame mitmeid tegevusi, mis peavad toimuma, et seade ilmuks radaritele ja et sellele saaks kaugjuhtimisse siseneda.

1. Seade tuleb registreerida inventeerimissüsteemis.
2. Halda juhte IP-aadress.
3. Seadista sellele põhjuurdepääs:
   Hostname, juhte IP-aadress, haldusvõrgu marsruut, kasutajad, SSH-võtmed, protokollid — telnet/SSH/NETCONF

Siin on kolm lähenemist:

• Kõik teha käsitsi. Seade tuuakse lauale, kus tavaline inimene siseneb süsteemidesse, ühendub konsooliga ja seadistab. See võib töötada väikestes staatilistes võrkudes.
• ZTP — Zero Touch Provisioning. Riistvara on kohal, paigaldatud, DNS-i saab DHCP-lt ja läheb eraldi serverisse, et ise seadistuda.
• Konsooli serverite infrastruktuur, kus esmase seadistamise teeb automaatne konsoolipordist.

KÕIK kolm neist arutame eraldi artiklis.

Komponent 5. Tarnija-agnostiline konfiguratsioonimudel

Siiani on kõik süsteemid olnud killustunud tükid, andes muutlikku ja deklareerivat kirjeldust sellest, mida me sooviksime näha võrgus. Kuid varem või hiljem tuleb tegeleda konkreetse asjaga.
Selles etapis kombineeritakse iga konkreetse seadme jaoks primitiivid, teenused ja muutujaid konfiguratsioonimudeliks, mis tegelikult kirjeldab konkreetse seadme täielikku konfiguratsiooni tootjaspetsiifiliselt sõltumatul viisil.
Mida annab see samm? Miks mitte kohe luua seadme konfiguratsioon, mille lihtsalt üles laadida?
Tegelikult võimaldab see lahendada kolm ülesannet:

1. Ei pea kohanduma konkreetse seadme suhtlusliidese järgi. Olgu see CLI, NETCONF, RESTCONF, SNMP — mudel jääb samaks.
2. Ei pea hoidma šablonite/skripte arvu vastavalt võrgus olevate tootjate arvule, ning disaini muutumisel, tuleb korraga muuta sama asja mitmes kohas.
3. Laadida seadmest konfiguratsioon (varukoopia), hajutada see täpselt sellesse mudelisse ja otseselt võrrelda sihtkonfiguratsiooni olemasolevaga, et arvutada delta ja valmistada meie valmistatav konfiguratsioonipatch, mis muudab ainult neid osi, mis on vajalikud või kõrvalekallete tuvastamiseks.

Selle etapi tulemusena saame tootjaspetsiifiliselt sõltumatu konfiguratsiooni.

Komponent 6. Tootjaspetsiifiline liidese draiver

Ärge lootke, et Cisco seadistamine on kunagi sama lihtne kui Juniper, lihtsalt saates neile täiesti ühesugused käsklused. Vaatamata kasvavale valgekarvaliste seadmete populaarsusele ja NETCONF'i, RESTCONF'i, OpenConfig'i toe ilmumisele, on sisuhaldus, mida need protokollid edastavad, erinev igal tootjal ning see on üks nende konkurentsieeliseid, millest nad lihtsalt ei loobu.
See on umbes sama, kuidas OpenContrail ja OpenStack, mis kasutavad RestAPI-d kui oma põhiliidest, ootavad täiesti erinevaid käsklusi.

Nii et viiendaks sammuks peab tootjavaba mudel võtma kuju, millega see jõuab riistvarani.
Ja siin on kõik viisid head (mitte tõesti): CLI, NETCONF, RESTCONF, SNMP ja niisugused lihtsad lahendused.

Seega vajame draiverit, mis eelmist sammu tulemus viib õiges formaadis konkreetse tootja jaoks: CLI käskude komplekt, XML struktuur.

Komponent 7. Konfiguratsiooni edastamise mehhanism seadmesse.

Konfiguratsioon on genereeritud, kuid see tuleb seadmetesse ka veel toimetada — ja selgelt mitte käsitsi.
Esiteks, meil on küsimus, millist transporti kasutame? Ja valik on tänapäeval juba päris suur:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (kuigi see on nimekirjast välja jäetud, kuna see on meetod FIB-i edastamiseks, mitte seadistamiseks)

Kohandame siin mõned punktid. CLI on vananenud. SNMP… ahem.
RESTCONF on veel tundmatu loom, REST API-d toetab peaaegu keegi. Seega keskendume tsüklis NETCONF-ile.

Tegelikult, nagu lugeja on tõenäoliselt mõistnud, oleme selle hetkel juba liidese valguses selgusele jõudnud — eelneva sammu tulemus on juba esitatud valitud liidese formaadis.

Teiseks, aga milliste tööriistadega me seda teeme?
Siin on valik samuti suur:

• Kohandatud skript või platvorm. Vaatame ncclienti ja asyncIO-d ning teeme ise kõik ära. Mis takistab meil süsteemi juurutamist nullist?
• Ansible oma rikkaliku võrgumoodulite kogumiga.
• Salt, mille võrgutöö on miskitki napp ja seotud Napalmiga.
• Isegi Napalm, kes tunneb paar tootjat ja see ongi kõik, head aega.
• Nornir — veel üks loom, keda me tulevikus uurime.

Siin pole veel lemmik välja valitud — hakkame uurima.

Mis siin veel oluline on? Konfiguratsiooni rakendamise tagajärjed.
Kas õnnestub või mitte. Kas juurdepääs seadmele on säilinud või mitte.
Tundub, et siin aitab commit koos kinnitamise ja valideerimisega selle kohta, mis seadmesse laaditi.
See koos õigesti rakendatud NETCONF-iga oluliselt kitsendab sobivate seadmete valikut — normaalsed commit'id ei toeta nii palju tootjaid. Kuid see on lihtsalt üks tingimus, mis peab olema RFP-s. RFP. Lõppkokkuvõttes ei muretse keegi selle üle, et ükski Venemaa tarnija ei vasta 32*100GE liidese nõudele. Või muretsevad?

Komponent 8. CI/CD

Selleks ajaks on meil juba kõikide võrgu seadmete konfiguratsioon valmis.
Kirjutan "kõikide", sest räägime võrgu oleku versioonist. Ja isegi kui on vaja muuta ainult ühe lüliti seadeid, arvutatakse muudatused kogu võrgu jaoks. Ilmselgelt võivad need samal ajal olla nullid enamikus sõlmedes.

Kuid nagu juba varem öeldud, ei ole me ju mingid barbarid, et kõik kohe tootmisse saata.
Genereritud konfiguratsioon peab esmalt läbima Pipeline CI/CD.

CI/CD tähendab pidevat integreerimist ja pidevat juurutamist. See on lähenemine, kus meeskond ei avalda uut põhiversiooni kord kuue kuu jooksul, asendades täielikult vana, vaid juurutab pidevalt uusimat funktsionaalsust väikeste osade kaupa, millest igaüht testitakse põhjalikult ühilduvuse, turvalisuse ja funktsionaalsuse osas.

Selleks on meil versioonihaldussüsteem, mis jälgib konfiguratsiooni muutusi, laboratoorium, kus kontrollitakse, et kliendiservice ei riku, jälgimisseade, mis kontrollib seda, ja viimane samm — muudatuste tegemine tootmisvõrgus.

Välja arvatud silumis käsud, peavad kõik muudatused võrgus läbima CI/CD torujuhtme — see on meie rahuliku elu ja pika õnneliku karjääri garantii.

Komponent 9. Varundussüsteem ja kõrvalekallete leidmine

Backup'idest ei ole mõtet liialt rääkida.
Paneme need lihtsalt kas cron'i järgi või konfiguratsiooni muutuse korral git'i.

Teine osa on huvitavam — nende varukoopiate üle peab keegi silma peal hoidma. Ühes olukorras peab see keegi minema ja taastama kõik tagasi, teises aga peab ta kellelegi kellestki teavitama, et asjad ei ole korras.
Näiteks kui tuleb uus kasutaja, kes ei ole määratud muutujates, tuleb ta häkkimise eest eemaldada. Kui on uus tulemüürireegel — parem seda mitte puudutada, äkki on keegi lihtsalt silumiseks selle sisse lülitanud, või võib-olla on uus teenus, karjus, määranud selle valesti, ja nüüd on sinna juba inimesi tulnud.

Mingist väikesest erinevusest kogu võrgu kontekstis ei pääse me hoolimata kõigist automatiseerimissüsteemidest ja raudkäest juhtimises. Probleemide lahendamiseks ei hakka keegi ikkagi süsteemidesse konfiguratsiooni tegema. Veel enam, et nende jaoks ei pruugi isegi konfiguratsioonimudelit ette näha.

Näiteks paketihulga arvu jälgimise tulemüürireegel teatud IP jaoks, et probleemi lokaliseerida — täiesti tavaline ajutine konfiguratsioon.

Komponent 10. Monitoringsüsteem

Alguses ei olnud mul plaanis teemat jälgimisest käsitleda - see on siiski ulatuslik, vaieldav ja keeruline teema. Kuid protsessi käigus selgus, et see on hädavajalik osa automatiseerimisest. Selle ümbersidumine praktikata on võimatu.

Arendades mõtet - see on orgaaniline osa CI/CD protsessist. Pärast konfiguratsiooni rakendamist võrgus peame suutma kindlaks teha, kas kõik on nüüd korras.
Ja jutt ei ole ainult ja mitte niivõrd graafikutest, vaid ka kasutajaliidete või sõlmpunktide kättesaadavusest, vaid ka keerukamatest asjadest - vajalikest marsruutidest, nende atribuutidest, BGP sessioonide arvust, OSPF naabritest, teenuste end-to-end töökindlusest.
Kas logid ei lakka kogumast välisele serverile, kas SFlow-agent ei ole katki, kas kõikuvus ei ole suurenenud järjekordades, kas mingite prefiksi paaride vahel ei ole rikkumist?

Erinevas artiklis arutame ka selle üle.

Kokkuvõte

Põhjaks valisin tänapäevase andakeskuse võrgu kujunduse - L3 Clos Fabric koos BGP-ga marsruutimisprotokollina.
Seekord ehitame võrku Juniperil, sest nüüd on JunOs liidese kasutamine standart.

Teeme endale elu keerulisemaks, kasutades ainult avatud lähtekoodiga tööriistu ja mitme müüja võrku — seetõttu valin lisaks Juniperile veel ühe õnneliku.

Tulevaste avaldamiste plaan on umbes selline:
Esiteks räägin virtuaalsetest võrkudest. Esiteks seetõttu, et ma tahan, ja teiseks seetõttu, et ilma selleta pole infrastruktuuri võrgu kujundamine eriti arusaadav.
Siis räägime võrgukujundusest: topoloogiast, marsruutimisest, poliitikatest.
Kogume laboriseina.
Mõtleme järele ja võib-olla harjutame seadme võrku käivitamist.
Ja edasi iga kompoondi intiimsetes detailides.

Ja jah, ma ei lubanud selle tsükli kenasti lõpetada valmis lahendusega. 🙂

Kasulikud lingid

• Enne süvenemist seeriasse, tasub lugeda Natasha Samojlenko raamatut Python seadmeinseneridele. Ja võib-olla ka läbida kursus.
• Samuti on kasulik lugeda RFC Facebooki andmekeskuse tehaste kujundamist Peeter Lapukhovi autorluses.
• Kuidas töötavad overlay SDN, annab teile aimu arhitektuuri dokumentatsioon Tungsten Fabric (varasem Open Contrail).

Aitäh

Roman Gorgi. Kommentaaride ja paranduste eest.
Artyom Chornobay. KDPV eest.

Allikas: habr.com