SDSM on lõppenud, kuid kontrollimatu soov kirjutada on jäänud.

Pikki aastaid on meie vend kannatanud rutiinse töö täitmise alla, paludes sõrmedega edu enne kommitimist ja saamata und öiste rollback'ide tõttu.
Aga pimedatele aegadele tuleb lõp.

Selle artikliga alustan seeriat teemal, kuidas mulle näib automatiseerimine.
Liikudes edasi, vaatame üle automatiseerimise etapid, muutujate salvestamise, disaini formaliseerimise, RestAPI, NETCONF, YANG, YDK ning programmeerime väga palju.
Minu tähendab, et a) see ei ole objektiivne tõde, b) mitte absoluutne parim lähenemine, c) minu arvamus võib isegi liikuda esimesest viimaseni artiklini — ausalt öeldes, olen ma mustandist avaldamiseni kõik kaks korda täielikult ümber kirjutanud.

Sisukord

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

2. Tööriistad
   1. Inventari süsteem
   2. IP-ruumi haldamise süsteem
   3. Võrguteenuste kirjeldussüsteem
   4. Seadmete initsialiseerimise mehhanism
   5. Tarnetööstuse agnostiline konfiguratsioonimudel
   6. Tarnetööstuse spetsiifiline draiver
   7. Konfiguratsiooni seadmele edastamise mehhanism
   8. CI/CD
   9. Konfiguratsiooni varundamise ja kõrvalekallete leidmise mehhanism
   10. Jälgimissüsteem

3. Kokkuvõte

Püüan viia ADSMi veidi teistsugusesse formaati võrreldes SDSMiga. Suured üksikasjalikud artiklid ilmuvad endiselt, kuid nende vahepeal avaldan väikeseid märkmeid igapäevasest kogemusest. Püüan siin võidelda perfektsionismi vastu ja mitte igaüks neist üle nühkida.

Kuidas on naljakas, et teist korda peab läbima sama teed.

Esialgu pidin ma ise kirjutama artikleid võrkudest, sest neid ei olnud venemaal.

Nüüd ei suutnud ma leida ulatuslikku dokumenti, mis süsteematiseeriks automatiseerimise lähenemised ja analüüsiks eespool nimetatud tehnoloogiaid lihtsate praktiliste näidete abil.

Võib-olla eksin, seega visake linke väärtuslikele ressurssidele. Kuid see ei muuda minu otsust kirjutada, sest peamine eesmärk on ikkagi enda õppimine ja teiste elu lihtsustamine on meeldiv boonus, mis paitab kogemuse levitamise geeni.

Püüame võtta keskmise suurusega andmekeskuse LAN DC ja töötada välja kogu automatiseerimise skeem.
Mõningate asjade tegemine on mul praktiliselt esmakordselt koos teiega.

Selles artiklis käsitletud ideedes ja tööriistades ei ole ma originaalne. Dmitri Figoli kanalil on suurepärased vood, mis käsitlevad seda teemat.
Artiklid sageli kattuvad nendega mitmes aspektis.

LAN DC-s on 4 andmekeskust, umbes 250 lülitit, pool tosinat ruuterit ja paar tulemüüri.
See ei ole Facebook, kuid piisab, et sügavalt mõelda automatiseerimisele.
Kuid on arvamus, et kui teil on rohkem kui 1 seade, on automatiseerimine juba vajalik.
Tegelikult on raske ette kujutada, et keegi suudab elada ilma vähemalt päeva jagu skripte.
Kuigi ma olen kuulnud, et on selliseid ettevõtteid, kus IP-aadresside arvestust hoitakse Excelis ja iga tuhande võrgu seadme seadistamine toimub käsitsi, igaühel on oma ainulaadne konfiguratsioon. Seda võib muidugi müüa kui kaasaegset kunsti, kuid inseneri tunded saavad kindlasti solvatud.

Eesmärgid

Nüüd seame maksimaalselt abstraktsed eesmärgid:

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

Hiljem selles artiklis vaatame, milliseid vahendeid me kasutame, ning järgmistes artiklites eesmärke ja vahendeid üksikasjalikult.

Võrk — nagu üks organism

Määrav fraas tsükli kohta, kuigi esmapilgul võib see tunduda mitte nii oluline: me seadistame võrku, mitte eraldi seadmeid.
Viimastel aastatel oleme näinud suundi, et hakkame käsitlema võrku kui ühtset tervikut, sealt ka tuuakse meie ellu Tarkvara määratletud võrgundus, Intent Driven Networks ja Autonomous Networks.
Sest mida rakendused võrult globaalset vajavad: ühendus punktide A ja B vahel (ja mõnikord +B-J) ning isolatsioon teistest rakendustest ja kasutajatest.

Ja seega on meie ülesanne selles seerias - luua süsteem, mis toetab aktuaarseid konfiguratsioone kogu võrgus, mis jaguneb juba aktuaarseks konfiguratsiooniks igas seadmes vastavalt tema rollile ja asukohale.
Süsteem võrgu juhtimine tähendab, et muudatuste tegemiseks pöördume selle poole, ning see omakorda arvutab vajaliku oleku iga seadme jaoks ja seadistab selle.
Nii minimeerime peaaegu nulli käsitsi CLI-s käimist — kõik seadistuste või võrgu disaini muutused peavad olema formalisatsioonitud ja dokumenteritud — ning alles siis saavad nad rakenduda võrgu vajalikele elementidele.

Näiteks, kui me oleme otsustanud, et alates nüüd peavad rack-lülitid Kazanis kuulutama kahte võrku ühe asemel, siis

1. Dokumenteerime esmalt muudatused süsteemides
2. Loome kõikide võrgu seadmete eesmärgipärase konfiguratsiooni
3. Käivitame võrgu konfiguratsiooni värskendamise programmi, mis arvutab välja, mida igast sõlmpunktist eemaldada, mida lisada, ning viib sõlmed soovitud olekusse.

Sellegipoolest teeme kätega muudatusi ainult esimeses etapis.

Konfiguratsiooni testimine

On teada, et 80% probleemidest tekib konfiguratsiooni muutmise ajal — kaudne tõestus sellele on see, et uusaastapühade ajal on tavaliselt kõik rahulik.
Olen isiklikult olnud pealtnägija kümnetele laiaulatuslikele seiskumistele inimliku vea tõttu: vale käsk, vale konfiguratsiooniharu, unustatud kogukond, kustutatud MPLS globaalselt marsruuteril, seadistatud viis seadet, kuid kuuendal ei märgatud viga, commit’itud vanad muudatused, mille tegi keegi teine. Stsenaariume on tohutult.

Automaatika võimaldab meil teha vähem vigu, kuid suuremas ulatuses. Nii saab ühe seadme asemel kogu võrku segamini ajada.

Aja jooksul on meie vanaisad kontrollinud sisseviidud muudatuste õigsust terava vaatamise, rauast munade ja võrgu töövõime abil pärast nende kasutuselevõttu.
Need vanaisad, kelle töö tõi kaasa seiskumist ja katastroofilisi kahjusid, jätavad vähem järeltulijaid ja peaksid aja jooksul välja surema, kuid evolutsioon on aeglane protsess, ja seetõttu ei kontrolli kõik muudetud kohandusi eelnevalt laboris.
Kuid edusammude tipus on need, kes automatiseerivad konfiguratsiooni testimise protsessi ning selle edasise rakendamise võrku. Teisisõnu — laenatud CI/CD protseduur (Continuous Integration, Continuous Deployment) arendajatelt.
Ühes osas vaatame, kuidas seda teostada versioonihaldussüsteemi abil, tõenäoliselt Githubi kaudu.

Niipea kui olete harjunud mõttega võrgu CI/CD-st, tundub konfiguratsiooni kontrollimise meetod selle rakendamise kaudu töövõrgus tõeliselt varajanes keskaja ilmalikkusena. Umbes nagu lüüa haamriga tuumapead.

Ideede loomulik jätk võrgu juhtimisest ja CI/CD-st on täielik konfiguratsiooni versioonihaldus. süsteemi toimub.

Versioonihaldus

Me võtame arvesse, et igasuguste muudatuste korral, isegi kõige vähematel, isegi ühel nähtamatul seadmel, liigub kogu võrk ühe oleku pealt teise.
Ja me ei tee kunagi käsku seadmes, me muudame võrgu seisundit.
Kuidas nimetame neid olekuid versioonideks?

Oletame, et praegune versioon on 1.0.0.
Kas Loopback-interfeisi IP-aadress muutus ühel ToR-il? See on väiksem versioon - saab numbri 1.0.1.
Kui muutsime BGP-s marsruutide impordi poliitikaid - see on juba tõsisem - 1.1.0.
Otsustasime loobuda IGP-st ja minna ainult BGP-le - see on juba radikaalne disaini muutus - 2.0.0.

Samuti võivad erinevatel andmekeskustel olla erinevad versioonid - võrk areneb, paigaldatakse uus varustus, kuskil lisatakse uusi spine-tasemeid, kuskil - mitte jne.

Küsimus semantiline versioonimine me räägime sellest eraldi artiklis.

Korrutan - iga muutmine (välja arvatud silumise käsud) on versiooni uuendamine. Administraatorid peavad olema teavitatud muudatustest kehtivast versioonist.

Sama kehtib muudatuste tagasivõtmise kohta - see ei tähenda viimaste käskude tühistamist, see ei ole seadme operatsioonisüsteemi kaudu rollback - see tähendab, et kogu võrk viiakse uude (vana) versiooni.

Teenuste jälgimine ja iseparandamine

See iseeneslik ülesanne kaasaegsetes võrkudes jõuab uuele tasemele.
Tihti praktiseerivad suured teenusepakkujad lähenemist, et kukkunud teenus tuleb väga kiiresti lõpetada ja uus käivitada, selle asemel, et selgitada välja, mis juhtus.
«Väga» tähendab, et igast küljest tuleb rikkalikult katta jälgimisega, mis leiab sekundite jooksul isegi kõige väiksemad kõrvalekalded normist.
Ja siin ei piisa enam harilikest mõõtmetest, nagu liidese koormus või sõlme kättesaadavus. Ka ei piisa jaamas jälgimise käsitsi jälgimisest.
Paljude asjade jaoks peaks olema Self-Healing — jälgimised süttisid punaselt ja läksid ise plaastrit viima sinna, kus valutab.

Ja siin me jälgime mitte ainult üksikute seadmete, vaid ka kogu võrgu tervist, ja nii valgekarbiga, mis on suhteliselt arusaadav, kui ka musta karbiga, mis on juba keerulisem.

Mida meil on vaja selliste ambitsioonikate plaanide elluviimiseks?

• Omada kõigi võrgus olevate seadmete nimekirja, nende asukohti, rolle, mudeleid, tarkvara versioone.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Omada võrguteenuste kirjeldamise süsteemi.
  IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH.
• Oskama seadme algkäivitamiseks.
  Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF
• Seadme konfigureerimine ja konfiguratsiooni viimine soovitud (sealhulgas ka varasema) versioonini.
• Konfiguratsiooni testimine
• Perioodiliselt kontrollida kõikide seadmete olekut, et tuvastada kõrvalekaldeid aktuaalsest ning teavitada vastavaid osapoole.
  Öösel lisas keegi vaikselt reegli ACL-i..
• Jälgida töökindlust.

Tööriistad

Tundub piisavalt keeruline, et alustada projekti dekomponeerimist komponentideks.

Ja neid on kümme:

1. Inventari süsteem
2. IP-ruumi haldamise süsteem
3. Võrguteenuste kirjeldussüsteem
4. Seadmete initsialiseerimise mehhanism
5. Tarnetööstuse agnostiline konfiguratsioonimudel
6. Tarnetööstuse spetsiifiline draiver
7. Konfiguratsiooni seadmele edastamise mehhanism
8. CI/CD
9. Konfiguratsiooni varundamise ja kõrvalekallete leidmise mehhanism
10. Jälgimissüsteem

See on muide näide sellest, kuidas on muutunud arusaam tsükli eesmärkidest — komponente käsitlevas mustandis oli neid neli.

Illustreerimisel kujutasin ma ette kõiki komponente ning seadmet.
Üksikute komponente omavahel suhtlevad.
Mida suurem on plokk, seda rohkem tähelepanu tuleb sellele komponendile pöörata.

Komponent 1. Inventeerimissüsteem

Ilmselgelt tahame me teada, milline varustus kus asub ja millele on see ühendatud.
Inventeerimissüsteem on igasuguste ettevõtete jaoks hädavajalik osa.
Sageli on ettevõted seotud spetsiifiliste ülesannete lahendamiseks erineva inventeerimissüsteemiga, mis on mõeldud võrguseadmetele.
Artiklite tsükli kontekstis nimetame seda DCIM-iks — Andmekeskuse infrastruktuuri haldamine. Kuigi DCIM mõiste hõlmab rangelt võttes palju rohkem.

Meie ülesannete jaoks salvestame siin järgmised andmed seadme kohta:

• Inventeerimisnumber
• Nimi/kuva
• Mudel (Huawei CE12800, Juniper QFX5120 jt)
• Iseloomulikud parameetrid (plaadid, liidesed jt)
• Roll (Leaf, Spine, Border Router jt)
• Asukoht (regioon, linn, andmekeskus, Rack, unit)
• Seadmete vaheline interconnect
• Võrgu topoloogia

On selgelt arusaadav, et ka meie tahame teada kogu seda teavet.
Aga kas see aitab automatiseerimise eesmärkidel?
Ilma tingimata.
Näiteks teame, et selles andmekeskuses Leaf-lülititel, kui need on Huawei, peavad krahhi filtreerimiseks ACL-d rakendama VLAN-ide peal, ja kui need on Juniper, siis unit 0 füüsilise liidese peal.
Või peab uue Syslog-serveri paigaldama kõikidele piirkonna borderitele.

Selles süsteemis salvestame me ka virtuaalsed võrguseadmed, näiteks virtuaalsed marsruuterid või route-reflektorid. Võime lisada DNS-serverid, NTP, Syslog ja üldiselt kõike, mis on kuidagi seotud võrguga.

Komponent 2. IP-ruumi haldamise süsteem

Jah, ka meie ajal on inimesi, kes peavad Exceli faili abil arvestust prefiksite ja IP-aadresside üle. Kuid kaasaegne lähenemine on siiski andmebaas, millel on Nginx/Apache frontend, API ja laiad funktsioonid IP-aadresside ja võrkude haldamiseks, jagatuna VRF-ideks.
IPAM — IP Aadressi Halduse süsteem.

Meie vajaduste jaoks salvestame selles järgmise teabe:

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

Igal juhul tahame olla kindlad, et kui jagame uue IP-aadressi ToR'i loopback'ile, ei juhtu, et see on juba kellelegi määratud. Või et sama prefiksi oleme kasutanud kaks korda võrgu erinevates otstes.
Aga kuidas see aitab automatiseerimisele?
Lihtne.
Küsime süsteemist prefiksi, millel on Loopback'i roll ja kus on väljastamiseks vabade IP-aadresside olemasolu — kui see leitakse, väljastame aadressi, kui ei, küsime uue prefiksi loomist.
Või seadme konfiguratsiooni loomisel saame samast süsteemist teada, millises VRF-is peaks liides olema.
Ja kui käivitame uue serveri, läheb skript süsteemi, et teada saada, millises serveri lülitises, millises porti ja milline alavõrk on liidesele määratud — sellest ka väljastatakse serveri aadress.

Tuleb soov DCIM ja IPAM ühendada üheks süsteemiks, et mitte dubleerida funktsioone ja mitte hooldada kahte sarnast entsyklopaediate.
Nii me ka teeme.

Komponent 3. Võrguteenuste kirjeldussüsteem

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

• Infrastruktuuri
• Klienditeenuseid.

Esimesed on mõeldud seadme põhivõimaluste ja halduse tagamiseks. Siia kuuluvad VTY, SNMP, NTP, Syslog, AAA, marsruutimisprotokollid, CoPP jne.
Teised korraldavad kliendile teenuse: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP jne.
Muidugi on ka piirjuhtumeid — kuhu liigitada MPLS LDP, BGP? Ja marsruutimisprotokolle võivad kasutada kliendid. Kuid see pole põhimõtteline.

Mõlemad teenuste tüübid jaotuvad konfiguratsiooni primitiivideks:

• füüsilised ja loogilised liidesed (tag, anteg, mtu)
• IP-aadressid ja VRF (IP, IPv6, VRF)
• ACL ja liikluse töötlemise poliitikad
• Protokollid (IGP, BGP, MPLS)
• Marsruutimise poliitikad (prefiksilisted, kogukonnad, ASN-filtrid).
• Teenindavad teenused (SSH, NTP, LLDP, Syslog…)
• Itd.

Kuidas me seda täpselt teeme, selle üle pole mul veel aimugi. Räägime sellest eraldi artiklis.

Kui nüüd pisut elulähedasemalt rääkida, siis võiksime kirjeldada, et
Leaf-lüliti peab omama BGP-seansse kõigi ühendatud Spine-lülititega, importima protsessi ühendatud võrgud, võtma Spine-lülititelt vastu ainult teatud prefiksiga võrke. Piirama CoPP IPv6 ND kuni 10 pps jne.
Spines omakorda hoiab seansse kõigi ühendatud lehtede kanssa, toimides juurreflektoritena, ja võtab neilt vastu ainult teatud pikkusega marsruute ja teatud kogukonnaga.

Komponent 4. Seadme initsialiseerimise mehhanism

Selle pealkirja all koondan mitmeid tegevusi, mis peavad toimuma, et seade ilmuks radaritele ja sellele saaks kaugelt ligi pääseda.

1. Seadmise seadme varude süsteemi.
2. Eraldada haldust IP-aadress.
3. Seada seadmele sissepääs:
   Hostname, haldus IP-aadress, marsruut haldusvõrku, kasutajad, SSH-võtmed, protokollid — telnet/SSH/NETCONF

Siin on kolm lähenemist:

• Täielikult käsitsi. Seade toimetatakse stendile, kus tavainimene sisestab selle süsteemidesse, ühendab konsooli ja seadistab. See võib töötada väikestes staatilistes võrkudes.
• ZTP — Zero Touch Provisioning. Riistvara tuli, seisis paigal, sai DHCP kaudu aadressi, läks spetsiaalsele serverile ja seadistus automaatselt.
• Konsoliserverite infrastruktuur, kus esialgne seadistamine toimub automaatrežiimis konsoolipordi kaudu.

Kõik kolm arutame eraldi artiklis.

Komponent 5. Tootjast sõltumatu konfiguratsioonimudel

Senini olid kõik süsteemid killustatud tükkidest, mis andsid muutlikke ja deklaratiivseid kirjelduse sellest, mida me võrgus näha tahame. Kuid varem või hiljem tuleb tegeleda konkreetsusega.
Sellel etapil kombineeritakse iga konkreetse seadme jaoks primitiivid, teenused ja muutujad konfiguratsioonimudeliks, mis kirjeldab tegelikku kogu konfiguratsiooni konkreetse seadme jaoks, vaid tootjast sõltumatus vormis.
Mida see samm annab? Miks mitte kohe luua seadme konfiguratsiooni, mille saab lihtsalt laadida?
Tegelikult võimaldab see lahendada kolm ülesannet:

1. Ära kohanda ennast konkreetse seadme suhtlusliidese järgi. Ükskõik, kas see on CLI, NETCONF, RESTCONF, SNMP — mudel jääb samaks.
2. Ära hoia mallide/skripti arvu vastavalt võrgu tarnijatele, ja juhul kui disain muutub, muuda ühes ja samas kohas mitmes kohas.
3. Laadi seadme konfiguratsioon (varukoopiast), paiguta see täpselt sellisesse mudelisse ja compare the target configuration with the existing one to calculate the delta and prepare the configuration patch that will modify only those parts that are necessary or to identify deviations.

Selle etapi tulemusena saame tarnijast sõltumatu konfiguratsiooni.

Komponent 6. Tarnijale spetsiifiline liidese draiver

Ära petta end lootusega, et ühel päeval saab Cisco seadme konfigureerida täpselt nagu Juniperi, saatnud neile täiesti identseid kutsungi. Kuigi valge kastide populaarsus kasvab ja NETCONF, RESTCONF, OpenConfig toetamist on rohkem, erineb nende protokollide kaudu edastatav konkreetne sisu tarnijate lõikes ja see on üks nende konkurentsieeliseid, mida nad kergesti ei loobu.
See on umbes sama, nagu OpenContrail ja OpenStack, milles REST API on nende NorthBound-liidese peamine rusikas, ootavad täiesti erinevaid kutsungeid.

Nii et viienda sammu käigus peab tarnijast sõltumatu mudel võtma kujul, milles see edasi läheb riistvarale.
Ja siin on kõik vahendid head (ei ole): CLI, NETCONF, RESTCONF, SNMP lihtsalt mitte.

Seetõttu vajame draiverit, mis eelneva sammu tulemuse sisestab konkreetse tarnija vajaliku formaati: CLI käskude kogum, XML struktuur.

Komponent 7. Konfiguratsiooni edastamise mehhanism seadmele

Me oleme konfiguratsiooni genereerinud, kuid see tuleb seadmetesse edastada — ja ilmselgelt mitte käsitsi.
Esiteks, see seab meie ees küsimuse, millist transporti kasutame? Ja valik tänapäeval on juba suur:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (kuigi see jääb nimekirjast välja, kuna see on viis edastada FIB, mitte konfigureerimist)

Selgitame siin asjad selgeks. CLI on pärand. SNMP… khette.
RESTCONF — veel teadmata asi, REST API-d toetab peaaegu keegi. Seetõttu keskendume tsüklis NETCONF-ile.

Nagu lugeja juba mõistis, oleme selle hetkeks liidese osas juba otsuse teinud — eelmise sammu tulemus on esitatud valitud liidese formaadis.

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

• Oma skript või platvorm. Varustame end ncclient ja asyncIO’ga ning teeme kõik ise. Mis takistab meil süsteemi deploy’imist nullist?
• Ansible oma rikka võrgumoodulite raamatukoguga.
• Salt, mis teeb võrgu osas vaevalt midagi ja seondub Napalmiga.
• Isegi Napalm, mis tunneb paar tarnijat ja kõik, head aega.
• Nornir — veel üks loom, kelle me tulevikus dissekteerime.

Siin pole veel lemmik valitud — uurime.

Mis on siin veel oluline? Konfiguratsiooni rakendamise tagajärjed.
Olgu see edukas või mitte. Kas juurdepääs seadmele on säilinud või mitte.
Tundub, et siin aitab commit koos kinnitamise ja seadmele laadimise valideerimisega.
See koos õige NETCONF’i rakendamisega kitsendab sobivate seadmete ringi — tavalised commit’id ei toeta palju tootjaid. Kuid see on lihtsalt üks vajalik tingimus RFP’s. . Lõppude lõpuks ei muretse keegi selle pärast, et ükski Venemaa tootja ei sobi 32*100GE liidese tingimustega. Või muretseb?Komponent 8. CI/CD

Selleks hetkeks on meil juba kõikide võrguseadmete konfiguratsioon valmis.

Ma ütlen «kõikide», sest räägime võrguseisundi versioonimisest. Ja isegi kui on vajalik muuta ainult ühe lüliti seadeid, arvutatakse muudatused kogu võrgu jaoks. Ilmselgelt võivad need enamikus sõlmedes olla nullid.
Kuid nagu juba mainitud, me ei ole ju barbarid, et kõik kohe tootmisse saata.

Genereeritud konfiguratsioon peab esmalt läbi minema Pipeline CI/CD’st.
CI/CD tähendab Continuous Integration, Continuous Deployment. See on lähenemine, kus meeskond ei postita uut suuremat versiooni iga kuue kuu tagant, asendades täielikult vana, vaid rakendab pidevalt järkjärgulisi uusi funktsioone väikestes osades, millest igaüht testitakse põhjalikult ühilduvuse, turvalisuse ja töökindluse osas.

CI/CD tähendab pidevat integreerimist ja pidevat juurutamist. See on lähenemine, kus meeskond ei avalda uut peamist versiooni iga kuue kuu tagant, asendades täielikult vana, vaid rakendab regulaarselt järkjärguliselt uut funktsionaalsust väikeste osade kaupa, millest igaüht testitakse põhjalikult ühilduvuse, turvalisuse ja toimivuse osas.

Selle jaoks on meil versioonihaldussüsteem, mis jälgib konfiguratsiooni muudatusi, laboratoorium, kus testitakse, kas klienditeenus ei katke, jälgimissüsteem, mis kontrollib seda ja viimane samm - muudatuste juurutamine tootmisvõrku.

Välja arvatud silumisvõimalused, peavad kõik muudatused võrgus läbima CI/CD torujuhtme - see on meie rahu ja pikka ja õnnelikku karjääri tagatis.

Komponent 9. Varundus- ja kõrvalekaldumise tuvastamise süsteem

Varundustest ei ole mõtet üleliia rääkida.
Lihtsalt salvestame need kas cron'i järgi või konfiguratsiooni muutuse korral git'i.

Kuid teine osa on huvitavam - nende varukoopiate eest peab keegi jälgima. Ja mõnel juhul peab see keegi minema ja taastama kõik nagu enne, teistes aga ütlema kellelegi, et midagi on valesti.
Näiteks, kui tekib uus kasutaja, keda ei ole muutujaid kirja pandud, peab ta olema eemaldatud võimalikult kaugele häkkimisest. Ja kui uus tulemüüri reegel - parem mitte puutuda, võib-olla on keegi lihtsalt silumise sisse lülitanud või on uus teenus, kes ei ole regulatiivselt kirja pannud, kuid keegi on juba temaga liitunud.

Mõningatest väikestest kõrvalekaldumistest kogu võrgu ulatuses me ei pääse, vaatamata mis tahes automatiseerimissüsteemidele ja tugevale juhtimisele. Probleemide silumiseks ei hakka keegi konfigureerimist süsteemidesse viima. Rääkimata sellest, et neid võib isegi konfigureerimis mudel välja ei näha.

Näiteks, tulemüüri reegel teatud IP-dega pakettide arvu arvestamiseks, probleemi lokaliseerimiseks - täiesti tavaline ajutine konfiguratsioon.

Komponent 10. Jälgimissüsteem

Alguses ei kavatsenud ma jälgimisteemat käsitleda - see on mahukas, vaieldav ja keeruline teema. Kuid protsessi käigus osutus see automatiseerimise lahutamatuks osaks. Ja mitte mingil juhul ei saa seda tõhusalt ignoreerida.

Mõtte arendamine - see on orgaaniline osa CI/CD protsessist. Pärast konfiguratsiooni juurutamist võrgus peame olema suutlikud määrama, kas kõik on nüüd korras.
Ja jutt ei ole ainult ja mitte niivõrd liideste kasutamise graafikutest või sõlmede kättesaadavusest, vaid peenemates asjades - vajalike marsruutide olemasolu, nende atribuudid, BGP sessioonide arv, OSPF naabrid, end-to-end funktsionaalsus kõrgema taseme teenustes.
Kas te ei ole lõpetanud logide kogumist väliserverisse, kas SFlow-agent ei ole katki läinud, kas järjekordades ei ole hakanud dropid kasvama ja kas mõni prefiksite paar ei ole kaotanud ühendust?

Me mõtleme selle üle eraldi artiklis.

Kokkuvõte

Aluseks valisin ühe tänapäeva andmekeskuse võrgudisaini — L3 Clos Fabric BGP marsruutimisprotokolliga.
Seekord ehitame võrku Juniperi põhjal, sest nüüd on JunOSi liides sarnane vaniljele.

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

Lähitulevikus plaanid on järgmised:
Esiteks räägin virtuaalvõrkudest. Esiteks, sest ma soovin seda, ja teiseks, sest ilma selleta ei ole infrastruktuuri võrgu disain väga arusaadav.
Siis räägime võrgu disainist: topoloogiast, marsruutimisest ja poliitikatest.
Kogume laboriseina.
Mõtleme ja võib-olla harjutame seadme sisse seadmist võrgus.
Ja pärast räägin igast komponendist intiimsetes detailides.

Ja jah, ma ei lubanud elegantset lõpetamist selle sarja valmislahendusega. 🙂

Kasulikud lingid

• Enne süvenemist seeriasse on soovitatav lugeda Natasha Samoylenko raamatut Python võrguinseneridele. Võib-olla võiks ka läbida kursus.
• Kasulik oleks lugeda ka RFC Facebooki andmekeskuse tehastest artiklit Peeter Lapukhovi autorilt.
• Kuidas töötab Overlay SDN, annab teile ülevaate dokumentatsioon arhitektuurist Tungsten Fabric (varem Open Contrail).

Aitäh

Roman Gorge. Tänu kommentaaride ja paranduste eest.
Artyom Chernobai. KDPV eest.

Allikas: habr.com