SDSM on läbi, aga ohjeldamatu kirjutamissoov jääb alles.

Meie vend kannatas aastaid rutiinse töö tegemise, enne pühendumist näpud ristis ja öiste tagasilükkamiste tõttu unepuuduse all.
Kuid pimedad ajad hakkavad läbi saama.

Selle artikliga alustan seeriat, kuidas mind ilmub automaatika.
Teel mõistame automatiseerimise etappe, muutujate salvestamist, disaini vormistamist, RestAPI, NETCONF, YANG, YDK ja teeme palju programmeerimist.
Mind tähendab, et a) see ei ole objektiivne tõde, b) see ei ole tingimusteta parim lähenemine, c) minu arvamus võib isegi esimesest artiklist viimaseni liikumise ajal muutuda – ausalt öeldes mustandi etapist kuni väljaanne, kirjutasin kõik täiesti kaks korda ümber.

Sisu

1. Eesmärgid
   1. Võrk on nagu üksik organism
   2. Konfiguratsiooni testimine
   3. Versioonide koostamine
   4. Teenuste jälgimine ja enesetervendamine

2. Tähendab
   1. Inventari süsteem
   2. IP-ruumi haldussüsteem
   3. Võrguteenuse kirjeldamise süsteem
   4. Seadme lähtestamise mehhanism
   5. Tarnija-agnostiline konfiguratsioonimudel
   6. Tarnijapõhine draiveri liides
   7. Konfiguratsiooni seadmesse edastamise mehhanism
   8. CI / CD
   9. Varundamise ja kõrvalekallete otsimise mehhanism
   10. Järelevalvesüsteem

3. Järeldus

Püüan ADSM-i läbi viia SDSM-ist veidi erinevas vormingus. Jätkuvalt ilmuvad suured, üksikasjalikud, nummerdatud artiklid, mille vahele avaldan väikesed märkmed igapäevakogemusest. Püüan siin perfektsionismiga võidelda ja mitte kõiki neist lakkuda.

Kui naljakas on see, et teist korda tuleb sama rada läbida.

Algul pidin ise võrkude kohta artikleid kirjutama, kuna neid RuNetis polnud.

Nüüd ei leidnud ma terviklikku dokumenti, mis süstematiseeriks automatiseerimise lähenemisviise ja analüüsiks ülaltoodud tehnoloogiaid lihtsate praktiliste näidete abil.

Ma võin eksida, seega lisage kasulike ressursside lingid. Minu kirjutamiskindlust see aga ei muuda, sest peamine eesmärk on ise midagi õppida ning teiste elu lihtsamaks tegemine on meeldiv boonus, mis paitab kogemuste jagamise geeni.

Proovime võtta keskmise suurusega LAN DC andmekeskuse ja töötada välja kogu automatiseerimisskeemi.
Ma teen mõnda asja peaaegu esimest korda koos teiega.

Ma ei ole siin kirjeldatud ideede ja vahendite osas originaalne. Dmitri Figolil on suurepärane kanal selle teema voogudega.
Artiklid kattuvad nendega paljudes aspektides.

LAN DC-l on 4 alalisvoolu, umbes 250 lülitit, pool tosinat ruuterit ja paar tulemüüri.
Mitte Facebook, aga piisavalt, et panna sind automatiseerimise üle sügavalt mõtlema.
Siiski on arvamus, et kui teil on rohkem kui 1 seade, on automatiseerimine juba vajalik.
Tegelikult on raske ette kujutada, et keegi saab nüüd elada ilma vähemalt paki põlveskriptideta.
Kuigi kuulsin, et on kontoreid, kus IP-aadresse hoitakse Excelis ja iga tuhandetest võrguseadmetest on käsitsi konfigureeritud ja sellel on oma unikaalne konfiguratsioon. Seda võib muidugi pidada moodsaks kunstiks, kuid inseneri tunded solvavad kindlasti.

Eesmärgid

Nüüd seame kõige abstraktsemad eesmärgid:

• Võrk on nagu üksik organism
• Konfiguratsiooni testimine
• Võrgu oleku versioonide loomine
• Teenuste jälgimine ja enesetervendamine

Hiljem selles artiklis vaatleme, milliseid vahendeid me kasutame, ja järgmises vaatleme eesmärke ja vahendeid üksikasjalikult.

Võrk on nagu üksik organism

Sarja määrav fraas, kuigi esmapilgul ei pruugi see nii tähendusrikas tunduda: me konfigureerime võrgu, mitte üksikuid seadmeid.
Viimastel aastatel oleme näinud rõhuasetuse nihkumist võrgu käsitlemisele ühtse üksusena, mistõttu Tarkvara määratletud võrgundus, Kavatsusega juhitud võrgud и Autonoomsed võrgud.
Lõppude lõpuks, mida vajavad rakendused võrgust globaalselt: ühenduvust punktide A ja B vahel (noh, mõnikord +B-Z) ja eraldatust teistest rakendustest ja kasutajatest.

Ja nii on meie ülesanne selles sarjas ehitada süsteem, säilitades praeguse konfiguratsiooni kogu võrk, mis on juba jagatud tegelikuks konfiguratsiooniks igas seadmes vastavalt selle rollile ja asukohale.
Süsteem võrguhaldus tähendab, et muudatuste tegemiseks võtame temaga ühendust ja see omakorda arvutab iga seadme jaoks soovitud oleku ja konfigureerib selle.
Nii minimeerime käsitsi juurdepääsu CLI-le peaaegu nullini – kõik muudatused seadme sätetes või võrgukujunduses tuleb vormistada ja dokumenteerida – ning alles seejärel levitada vajalikele võrguelementidele.

Näiteks kui otsustaksime, et nüüdsest peaksid Kaasani rack-lülitid teatama kahest võrgust ühe asemel,

1. Kõigepealt dokumenteerime süsteemide muudatused
2. Kõigi võrguseadmete sihtkonfiguratsiooni genereerimine
3. Käivitame võrgukonfiguratsiooni uuendamise programmi, mis arvutab välja, mis tuleb igal sõlmel eemaldada, mida lisada ning viib sõlmed soovitud olekusse.

Samal ajal teeme käsitsi muudatusi alles esimeses etapis.

Konfiguratsiooni testimine

On teadaet 80% probleemidest tekivad konfiguratsiooni muutmise ajal – kaudne tõend selle kohta on, et uusaastapühade ajal on tavaliselt kõik rahulik.
Olen isiklikult olnud tunnistajaks kümnetele inimliku vea tõttu globaalsetele seisakutele: vale käsk, konfiguratsioon teostati vales harus, kogukond unustas, MPLS lammutati ruuteris globaalselt, viis riistvara oli seadistatud, kuid viga ei olnud märkas kuuendal, tehti vanad muudatused, mille tegi teine ​​inimene . Stsenaariume on palju.

Automatiseerimine võimaldab meil teha vähem vigu, kuid suuremas ulatuses. Nii saate tellida mitte ainult ühe seadme, vaid kogu võrgu korraga.

Juba ammusest ajast kontrollisid meie vanaisad pärast lahtirullimist terava pilguga tehtud muudatuste õigsust, teraskuule ja võrgu funktsionaalsust.
Need vanaisad, kelle töö tõi kaasa seisakuid ja katastroofilisi kaotusi, jätsid vähemaks järglasi ja peaksid aja jooksul välja surema, kuid evolutsioon on aeglane protsess ja seetõttu ei katseta kõik ikka esmalt muudatusi laboris.
Edusammude eesotsas on aga need, kes on automatiseerinud konfiguratsiooni testimise protsessi ja selle edasise rakendamise võrku. Teisisõnu, ma laenasin CI/CD protseduuri (Pidev integreerimine, pidev juurutamine) arendajatelt.
Ühes osas vaatleme, kuidas seda versioonihaldussüsteemi, tõenäoliselt Githubi abil rakendada.

Kui olete võrgu CI/CD ideega harjunud, tundub üleöö konfiguratsiooni kontrollimise meetod, rakendades seda tootmisvõrku, varakeskaegse teadmatusena. Umbes nagu haamriga lõhkepea löömine.

Orgaaniline jätk ideedele teemal süsteem võrguhaldus ja CI/CD muutub konfiguratsiooni täisversiooniks.

Versioonide koostamine

Eeldame, et isegi kõige väiksemate muudatuste korral liigub kogu võrk isegi ühest märkamatus seadmes ühest olekust teise.
Ja me ei täida alati seadmes käsku, vaid muudame võrgu olekut.
Nimetagem neid osariike siis versioonideks?

Oletame, et praegune versioon on 1.0.0.
Kas ühe ToR-i Loopback-liidese IP-aadress on muutunud? See on väikeversioon ja kannab numbrit 1.0.1.
Vaatasime üle BGP-sse marsruutide importimise eeskirjad – veidi tõsisemalt – juba 1.1.0
Otsustasime IGP-st lahti saada ja minna üle ainult BGP-le – see on juba radikaalne disainimuudatus – 2.0.0.

Samal ajal võivad erinevatel DC-del olla erinevad versioonid - võrk areneb, paigaldatakse uusi seadmeid, kuhugi lisatakse uusi spine tasemeid, teistes mitte jne.

edasi semantiline versioonimine räägime eraldi artiklis.

Kordan – iga muudatus (välja arvatud silumiskäsud) on versiooniuuendus. Kõikidest kõrvalekalletest praegusest versioonist tuleb administraatoreid teavitada.

Sama kehtib ka muudatuste tagasipööramise kohta - see ei ole viimaste käskude tühistamine, see ei ole seadme operatsioonisüsteemi abil tagasipööramine - see toob kogu võrgu uuele (vanale) versioonile.

Teenuste jälgimine ja enesetervendamine

See enesestmõistetav ülesanne on jõudnud kaasaegsetes võrkudes uuele tasemele.
Sageli võtavad suured teenusepakkujad lähenemise, et ebaõnnestunud teenus tuleb väga kiiresti parandada ja uus tõsta, selle asemel et aru saada, mis juhtus.
"Väga" tähendab, et peate olema igast küljest heldelt kaetud jälgimisega, mis tuvastab mõne sekundi jooksul vähimadki kõrvalekalded normist.
Ja siin ei piisa enam tavalistest mõõdikutest, nagu liidese laadimine või sõlmede saadavus. Ei piisa ka nende käsitsi jälgimisest korrapidaja poolt.
Paljude asjade jaoks peaks olema Enesetervendamine — seiretuled läksid punaseks ja läksime ja panime ise jahubanaani sinna, kus valus.

Ja siinkohal ei jälgi me ka mitte ainult üksikuid seadmeid, vaid ka kogu võrgu tervist, nii whiteboxi, mis on suhteliselt arusaadav, kui ka blackboxi, mis on keerulisem.

Mida on meil selliste ambitsioonikate plaanide elluviimiseks vaja?

• Teil on kõigi võrgus olevate seadmete loend, nende asukoht, rollid, mudelid, tarkvara versioonid.
  kazan-leaf-1.lmu.net, Kaasan, leht, kadakas QFX 5120, R18.3.
• Omama süsteemi võrguteenuste kirjeldamiseks.
  IGP, BGP, L2/3VPN, poliitika, ACL, NTP, SSH.
• Oskab seadet lähtestada.
  Hostinimi, Mgmt IP, Mgmt marsruut, kasutajad, RSA-võtmed, LLDP, NETCONF
• Seadistage seade ja viige konfiguratsioon soovitud (sh vana) versioonini.
• Testi konfiguratsioon
• Kontrollige perioodiliselt kõigi seadmete olekut olemasolevatest kõrvalekallete osas ja andke teada, kellele see peaks olema.
  Üleöö lisas keegi vaikselt ACL-i reegli.
• Jälgige jõudlust.

Tähendab

See kõlab piisavalt keeruliselt, et alustada projekti komponentideks jagamist.

Ja neid saab olema kümme:

1. Inventari süsteem
2. IP-ruumi haldussüsteem
3. Võrguteenuse kirjeldamise süsteem
4. Seadme lähtestamise mehhanism
5. Tarnija-agnostiline konfiguratsioonimudel
6. Tarnijapõhine draiveri liides
7. Konfiguratsiooni seadmesse edastamise mehhanism
8. CI / CD
9. Varundamise ja kõrvalekallete otsimise mehhanism
10. Järelevalvesüsteem

See on muide näide sellest, kuidas vaade tsükli eesmärkidele muutus - eelnõus oli 4 komponenti.

Joonisel kujutasin kõiki komponente ja seadet ennast.
Ristuvad komponendid suhtlevad üksteisega.
Mida suurem on plokk, seda rohkem tuleb sellele komponendile tähelepanu pöörata.

1. komponent: laoseisusüsteem

Ilmselgelt tahame teada, millised seadmed kus asuvad, millega on ühendatud.
Varude süsteem on iga ettevõtte lahutamatu osa.
Enamasti on ettevõttel võrguseadmete jaoks eraldi inventarisüsteem, mis lahendab spetsiifilisemad probleemid.
Selle artiklite sarja osana nimetame seda DCIM-iks – andmekeskuse infrastruktuuri haldamine. Kuigi mõiste DCIM ise hõlmab rangelt võttes palju enamat.

Oma eesmärkidel salvestame sellesse seadme kohta järgmise teabe:

• Inventari number
• Pealkiri/kirjeldus
• Mudel (Huawei CE12800, Juniper QFX5120 jne.)
• Iseloomulikud parameetrid (tahvlid, liidesed jne.)
• Roll (Leaf, Spine, Border Router jne.)
• Asukoht (piirkond, linn, andmekeskus, rack, üksus)
• Seadmetevahelised ühendused
• Võrgu topoloogia

On täiesti selge, et me ise tahame seda kõike teada.
Kuid kas see aitab automatiseerimisel?
Kindlasti.
Näiteks teame, et antud andmekeskuses Leafi lülitites, kui see on Huawei, tuleks teatud liikluse filtreerimiseks ACL-e rakendada VLAN-is ja kui see on Juniper, siis füüsilise liidese üksuses 0.
Või peate uue Syslogi serveri juurutama kõigis piirkonna piirides.

Sellesse salvestame virtuaalsed võrguseadmed, näiteks virtuaalsed ruuterid või juurreflektorid. Saame lisada DNS-servereid, NTP-d, Syslogi ja üldiselt kõike, mis ühel või teisel viisil võrguga seotud on.

2. komponent: IP-ruumi haldussüsteem

Jah, ja tänapäeval on inimesi, kes jälgivad eesliiteid ja IP-aadresse Exceli failis. Kuid kaasaegne lähenemisviis on endiselt andmebaas, millel on nginx/apache'i esiots, API ja ulatuslikud funktsioonid IP-aadresside ja VRF-ideks jagatud võrkude salvestamiseks.
IPAM – IP-aadressi haldus.

Oma eesmärkidel salvestame sellesse järgmise teabe:

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

Jällegi on selge, et tahame olla kindlad, et kui eraldame ToR loopbacki jaoks uue IP-aadressi, ei komistaks me tõsiasja, et see on juba kellelegi määratud. Või kasutasime sama eesliidet kaks korda võrgu erinevates otstes.
Aga kuidas see automatiseerimisele kaasa aitab?
See on lihtne.
Nõuame süsteemis eesliidet rolliga Loopbacks, mis sisaldab eraldamiseks saadaolevaid IP-aadresse - kui see leitakse, eraldame aadressi, kui ei, siis taotleme uue prefiksi loomist.
Või seadme konfiguratsiooni loomisel saame samast süsteemist teada, millises VRF-is peaks liides asuma.
Ja uue serveri käivitamisel logib skript süsteemi sisse, selgitab välja, millises lülitis server on, millises pordis ja milline alamvõrk on liidesele määratud – ja eraldab sealt serveri aadressi.

See viitab soovile ühendada DCIM ja IPAM üheks süsteemiks, et mitte dubleerida funktsioone ja mitte teenindada kahte sarnast olemit.
Seda me teemegi.

Komponent 3. Süsteem võrguteenuste kirjeldamiseks

Kui kaks esimest süsteemi salvestavad muutujaid, mida on vaja veel kuidagi kasutada, siis kolmas kirjeldab iga seadme rolli puhul, kuidas seda konfigureerida.
Tasub eristada kahte erinevat tüüpi võrguteenuseid:

• Infrastruktuur
• Klient.

Esimesed on loodud pakkuma põhilist ühenduvust ja seadme juhtimist. Nende hulka kuuluvad VTY, SNMP, NTP, Syslog, AAA, marsruutimisprotokollid, CoPP jne.
Viimased korraldavad kliendile teenust: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP jne.
Muidugi on ka piirjuhtumeid – kuhu lisada MPLS LDP, BGP? Jah, ja klientide jaoks saab kasutada marsruutimisprotokolle. Kuid see pole oluline.

Mõlemat tüüpi teenused on jaotatud konfiguratsiooniprimitiivideks:

• füüsilised ja loogilised liidesed (tag/anteg, mtu)
• IP-aadressid ja VRF-id (IP, IPv6, VRF)
• ACL-id ja liikluse töötlemise poliitikad
• Protokollid (IGP, BGP, MPLS)
• Marsruutimise poliitikad (eesliidete loendid, kogukonnad, ASN-filtrid).
• Kommunaalteenused (SSH, NTP, LLDP, Syslog...)
• Jne.

Kuidas me seda täpselt teeme, pole mul veel õrna aimugi. Vaatleme seda eraldi artiklis.

Kui natukene elule lähemale, siis võiks seda kirjeldada
Leaf-lülitil peavad olema BGP-seansid kõigi ühendatud Spine-lülititega, see peab protsessi importima ühendatud võrgud ja aktsepteerima Spine-lülititest ainult teatud prefiksi võrke. Piirake CoPP IPv6 ND kuni 10 pps jne.
Seljad omakorda peavad seansse kõigi ühendatud juhtmetega, toimides juurreflektoritena ja võtavad neilt vastu ainult teatud pikkusega ja teatud kogukonnaga marsruute.

4. komponent: seadme lähtestamismehhanism

Selle pealkirja all ühendan paljud toimingud, mis peavad toimuma, et seade ilmuks radarile ja sellele oleks kaugjuurdepääs.

1. Sisestage seade laosüsteemi.
2. Valige halduse IP-aadress.
3. Seadistage sellele põhijuurdepääs:
   Hostinimi, halduse IP-aadress, marsruut haldusvõrku, kasutajad, SSH-võtmed, protokollid - telnet/SSH/NETCONF

On kolm lähenemist:

• Kõik on täiesti käsitsi. Seade tuuakse stendile, kus tavaline maheinimene sisestab selle süsteemidesse, ühendab konsooliga ja seadistab. Võib töötada väikestes staatilistes võrkudes.
• ZTP – Zero Touch Provisioning. Riistvara saabus, tõusis püsti, sai DHCP kaudu aadressi, läks spetsiaalsesse serverisse ja seadistas ennast.
• Konsooliserverite infrastruktuur, kus esialgne seadistamine toimub automaatrežiimis konsooli pordi kaudu.

Kõigist kolmest räägime eraldi artiklis.

Komponent 5: tarnija-agnostiline konfiguratsioonimudel

Seni on kõik süsteemid olnud erinevad paigad, mis pakuvad muutujaid ja deklaratiivset kirjeldust selle kohta, mida me võrgus näha tahaksime. Kuid varem või hiljem peate tegelema üksikasjadega.
Selles etapis kombineeritakse iga konkreetse seadme primitiivid, teenused ja muutujad konfiguratsioonimudeliks, mis tegelikult kirjeldab konkreetse seadme täielikku konfiguratsiooni, ainult müüja suhtes neutraalsel viisil.
Mida see samm teeb? Miks mitte luua kohe seadme konfiguratsioon, mille saate lihtsalt üles laadida?
Tegelikult lahendab see kolm probleemi:

1. Ärge kohanege seadmega suhtlemiseks konkreetse liidesega. Olgu selleks siis CLI, NETCONF, RESTCONF, SNMP – mudel jääb samaks.
2. Ärge hoidke mallide/skriptide arvu vastavalt võrgus olevate hankijate arvule ja kui kujundus muutub, muutke sama asja mitmes kohas.
3. Laadige seadmest konfiguratsioon (varukoopia), pange see täpselt samasse mudelisse ja võrrelge sihtkonfiguratsiooni otse olemasolevaga, et arvutada delta ja koostada konfiguratsiooniplaaster, mis muudab ainult neid osi, mis on vajalikud või tuvastavad kõrvalekalded.

Selle etapi tulemusena saame hankijast sõltumatu konfiguratsiooni.

Komponent 6. Tarnijapõhine draiveri liides

Ei tasu meelitada end lootusega, et kunagi on võimalik ciskat seadistada täpselt samamoodi nagu Kadakat, lihtsalt neile täpselt samad kõned saates. Vaatamata valgete kastide kasvavale populaarsusele ning NETCONF-i, RESTCONF-i, OpenConfigi toe tekkimisele on nende protokollide konkreetne sisu tarnijati erinev ja see on üks nende konkurentsierinevusi, millest nad nii kergesti alla ei anna.
See on ligikaudu sama, mis OpenContrail ja OpenStack, mille NorthBoundi liides on RestAPI, ootavad täiesti erinevaid kõnesid.

Niisiis, viiendas etapis peab müüjast sõltumatu mudel võtma sellise vormi, nagu see riistvarasse läheb.
Ja siin on kõik vahendid head (mitte): CLI, NETCONF, RESTCONF, SNMP lihtsalt.

Seetõttu vajame draiverit, mis kannab eelmise sammu tulemuse konkreetse müüja nõutavasse vormingusse: CLI-käskude komplekt, XML-struktuur.

Komponent 7. Konfiguratsiooni seadmesse edastamise mehhanism

Oleme konfiguratsiooni loonud, kuid see tuleb siiski seadmetesse toimetada – ja ilmselgelt mitte käsitsi.
Esiteks, seisame silmitsi küsimusega, millist transporti me kasutame? Ja täna pole valik enam väike:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (kuigi see on kõrvalekalle, sest see on viis FIB-i edastamiseks, mitte seaded)

Tähistame t-tähe siia. CLI on pärand. SNMP... köha köha.
RESTCONF on endiselt tundmatu loom; REST API-d ei toeta peaaegu keegi. Seetõttu keskendume sarjas NETCONF-ile.

Tegelikult, nagu lugeja juba aru sai, oleme selleks hetkeks juba liidese üle otsustanud - eelmise sammu tulemus on juba esitatud valitud liidese vormingus.

Teiseks, ja milliste vahenditega me seda teeme?
Siin on ka suur valik:

• Ise kirjutatud skript või platvorm. Varustame end ncclienti ja asyncIO-ga ning teeme kõik ise. Kui palju meil läheb juurutussüsteemi nullist ülesehitamine maksma?
• Ansible oma rikkaliku võrgumoodulite raamatukoguga.
• Sool oma kasina tööga võrguga ja ühendusega Napalmiga.
• Tegelikult Napalm, mis tunneb paari müüjat ja ongi kõik, hüvasti.
• Nornir on veel üks loom, keda me tulevikus lahkame.

Siin pole lemmikut veel valitud - hakkame otsima.

Mis siin veel oluline on? Konfiguratsiooni rakendamise tagajärjed.
Edukas või mitte. Kas riistvarale on veel juurdepääs või mitte?
Tundub, et commit aitab siin seadmesse allalaaditu kinnitamise ja valideerimisega.
See koos NETCONF-i õige juurutamisega kitsendab märkimisväärselt sobivate seadmete valikut – mitte paljud tootjad ei toeta tavalisi kohustusi. Kuid see on vaid üks eeltingimustest Küsi hinnapakkumist. Lõpuks ei muretse keegi, et ükski Venemaa müüja ei täida liidese 32*100GE tingimust. Või on ta mures?

Komponent 8. CI/CD

Praeguseks on meil juba kõigi võrguseadmete konfiguratsioon valmis.
Kirjutan "kõige jaoks", sest me räägime võrgu oleku versioonimisest. Ja isegi kui teil on vaja muuta ainult ühe lüliti sätteid, arvutatakse muudatused kogu võrgu jaoks. Ilmselgelt võivad need enamiku sõlmede puhul olla nullid.

Kuid nagu eespool juba öeldud, me ei ole mingid barbarid, kes tahavad kõike otse tootmisse veeretada.
Loodud konfiguratsioon peab esmalt läbima Pipeline CI/CD.

CI/CD tähistab Continuous Integration, Continuous Deployment. See on lähenemisviis, mille puhul meeskond mitte ainult ei anna iga kuue kuu järel välja uut suurt väljalaset, asendades täielikult vana, vaid rakendab regulaarselt (juurutus) uusi funktsioone väikeste portsjonitena, millest igaühe ühilduvust, turvalisust ja turvalisust on põhjalikult testitud. jõudlus (Integratsioon).

Selleks on meil versioonikontrollisüsteem, mis jälgib konfiguratsioonimuudatusi, labor, mis kontrollib, kas klienditeenindus on katki, jälgimissüsteem, mis kontrollib seda fakti ning viimase sammuna on muudatuste juurutamine tootmisvõrku.

Kui silumiskäsud välja arvata, peavad absoluutselt kõik muudatused võrgus läbima CI/CD torujuhtme – see on meie vaikse elu ja pika õnneliku karjääri tagatis.

Komponent 9. Varundus- ja anomaaliate tuvastamise süsteem

Noh, varukoopiatest pole vaja uuesti rääkida.
Me paneme need lihtsalt giti vastavalt kroonile või konfiguratsiooni muutmise faktile.

Aga teine ​​osa on huvitavam – keegi peaks neil varukoopiatel silma peal hoidma. Ja mõnel juhul peab see keegi minema ja pöörama kõik nii, nagu see oli, ja mõnel juhul mõutama kellelegi, et midagi on valesti.
Näiteks kui ilmus uus kasutaja, kes pole muutujates registreeritud, peate ta häkkimisest eemale eemaldama. Ja kui parem on uut tulemüürireeglit mitte puudutada, võib-olla lülitas keegi lihtsalt silumise sisse või ei registreeritud uut teenust, bunglerit, eeskirjade kohaselt, kuid inimesed on sellega juba liitunud.

Vaatamata automatiseerimissüsteemidele ja juhtimise terasele käele ei pääse me ikkagi väikesest deltast kogu võrgu ulatuses. Probleemide silumiseks ei lisa keegi niikuinii süsteemidele konfiguratsiooni. Lisaks ei pruugi need isegi konfiguratsioonimudelisse kaasata.

Näiteks tulemüüri reegel konkreetse IP pakettide arvu loendamiseks probleemi lokaliseerimiseks on täiesti tavaline ajutine konfiguratsioon.

Komponent 10. Seiresüsteem

Esialgu ei kavatsenud ma monitooringu teemat käsitleda – see on ikkagi mahukas, vastuoluline ja keeruline teema. Kuid asjade edenedes selgus, et see oli automatiseerimise lahutamatu osa. Ja sellest on võimatu mööda minna, isegi ilma harjutamiseta.

Evolving Thought on CI/CD protsessi orgaaniline osa. Pärast konfiguratsiooni võrku juurutamist peame suutma kindlaks teha, kas sellega on nüüd kõik korras.
Ja me ei räägi mitte ainult ja mitte niivõrd liidese kasutusgraafikutest või sõlmede saadavusest, vaid peenematest asjadest - vajalike marsruutide olemasolust, nendel olevatest atribuutidest, BGP-seansside arvust, OSPF-i naabritest, otsast lõpuni jõudlusest. teenustest.
Kas välise serveri syslogs lakkas lisandumast või SFlow agent läks katki või hakkas järjekordade vähenemine kasvama või katkes mõne prefiksipaari vaheline ühenduvus?

Me käsitleme seda eraldi artiklis.

Järeldus

Aluseks valisin ühe kaasaegse andmekeskuste võrgukujunduse - marsruutimisprotokolliks BGP-ga L3 Clos Fabric.
Seekord ehitame võrgu Juniperile, sest nüüd on JunOs liides vanlove.

Teeme oma elu keerulisemaks, kasutades ainult avatud lähtekoodiga tööriistu ja mitme tootja võrgustikku – seega valin lisaks Juniperile veel ühe õnneliku inimese.

Eelseisvate väljaannete plaan on umbes selline:
Kõigepealt räägin virtuaalsetest võrkudest. Esiteks sellepärast, et ma tahan, ja teiseks sellepärast, et ilma selleta ei saa taristuvõrgu kujundus väga selgeks.
Siis võrgukujundusest endast: topoloogiast, marsruutimisest, poliitikatest.
Paneme kokku laboratooriumi.
Mõelgem sellele ja võib-olla harjutame seadme initsialiseerimist võrgus.
Ja siis iga komponendi kohta intiimsete üksikasjadega.

Ja jah, ma ei luba seda tsüklit graatsiliselt valmislahendusega lõpetada. 🙂

Kasulikud lingid

• Enne sarja süvenemist tasub läbi lugeda Nataša Samoilenko raamat Python võrguinseneridele. Ja võib-olla möödub muidugi.
• Kasulik on ka lugeda RFC Peter Lapukhovi andmekeskuste tehaste disainist Facebookist.
• Arhitektuuridokumentatsioon annab teile ülevaate Overlay SDN-i toimimisest. Volfram kangas (endine Open Contrail).

Aitäh

Rooma kuru. Kommentaarideks ja toimetusteks.
Artjom Tšernobai. KDPV jaoks.

Allikas: www.habr.com