SDSM amaitu da, baina idazteko gogo kontrolaezina geratzen da.

Urte askotan, gure anaiak ohiko lanak egitea sufritu zuen, konprometitu baino lehen behatzak gurutzatu eta lo falta izan zuen gaueko atzerapenen ondorioz.
Baina garai ilunak amaitzen ari dira.

Artikulu honekin nola azaltzen den serie bat hasiko dut me automatizazioa ikusten da.
Bide horretan, automatizazioaren etapak ulertuko ditugu, aldagaiak gordetzea, diseinua formalizatzea, RestAPI, NETCONF, YANG, YDK eta programazio asko egingo dugu.
Me esan nahi du a) ez dela egia objektiboa, b) ez dela baldintzarik gabe planteamendu onena, c) nire iritzia, nahiz eta lehen artikulutik azkeneko mugimenduan zehar, alda daiteke - zintzoa izateko, zirriborro fasetik argitalpena, dena guztiz berridatzi nuen bi aldiz.

Edukia

1. helburuak
   1. Sarea organismo bakar bat bezalakoa da
   2. Konfigurazio-probak
   3. Bertsioa
   4. Zerbitzuen jarraipena eta autosendapena

2. Funtsak
   1. Inbentario-sistema
   2. IP espazioa kudeatzeko sistema
   3. Sareko zerbitzuen deskribapen-sistema
   4. Gailua hasieratzeko mekanismoa
   5. Saltzaileen arteko konfigurazio eredua
   6. Saltzaileen berariazko gidariaren interfazea
   7. Gailuari konfigurazioa emateko mekanismoa
   8. CI/CD
   9. Babeskopia egiteko eta desbideratzeak bilatzeko mekanismoa
   10. Jarraipen-sistema

3. Ondorioa

ADSM SDSMtik apur bat desberdina den formatu batean egiten saiatuko naiz. Artikulu handiak, zehatzak, zenbakituak agertzen jarraituko dute, eta bien artean eguneroko esperientziatik ateratako ohar txikiak argitaratuko ditut. Hemen perfekzionismoari aurre egiten saiatuko naiz eta ez horietako bakoitza miazkatzen.

Zein barregarria den bigarren aldian bide beretik joan behar izatea.

Hasieran nik neuk idatzi behar izan nituen sareei buruzko artikuluak RuNet-en ez zeudenez.

Orain, ezin izan dut aurkitu automatizazioaren ikuspegiak sistematizatu eta adibide praktiko errazak erabiliz goiko teknologiak aztertuko zituen dokumentu integralik.

Baliteke oker egotea, beraz, mesedez eman baliabide erabilgarriak dituzten estekak. Hala ere, horrek ez du aldatuko nire idazteko gogoa, helburu nagusia neuk zerbait ikastea baita, eta besteei bizitza erraztea esperientzia partekatzeko genea laztantzen duen bonus atsegina baita.

Saiatuko gara tamaina ertaineko LAN DC datu-zentro bat hartzen eta automatizazio-eskema osoa lantzen.
Gauza batzuk ia lehen aldiz egingo ditut zurekin.

Ez naiz originala izango hemen azaldutako ideia eta tresnetan. Dmitry Figolek bikaina du gai honi buruzko korronteak dituen kanala.
Artikuluak alderdi askotan gainjarri egingo zaizkie.

LAN DCak 4 DC, 250 etengailu inguru, dozena erdi bideratzaile eta suebaki pare bat ditu.
Ez Facebook, baina nahikoa automatizazioari buruz sakon hausnartzeko.
Bada, hala ere, gailu 1 baino gehiago baldin baduzu, automatizazioa behar dela dagoeneko.
Izan ere, zaila da imajinatzea orain edonor bizi daitekeela gutxienez belauneko gidoi sortarik gabe.
Entzun nuen arren IP helbideak Excel-en gordetzen diren bulegoak daudela, eta sareko milaka gailuetako bakoitza eskuz konfiguratuta dagoela eta bere konfigurazio berezia duela. Hori, noski, arte moderno gisa pasa daiteke, baina ingeniariaren sentimenduak mindu egingo dira zalantzarik gabe.

helburuak

Orain helburu abstraktuenak ezarriko ditugu:

• Sarea organismo bakar bat bezalakoa da
• Konfigurazio-probak
• Sarearen egoeraren bertsioa
• Zerbitzuen jarraipena eta autosendapena

Geroago artikulu honetan zer bitarteko erabiliko ditugun aztertuko dugu, eta jarraian, helburuak eta bitartekoak zehatz-mehatz aztertuko ditugu.

Sarea organismo bakar bat bezalakoa da

Seriearen definizio esaldia, nahiz eta lehen begiratuan hain esanguratsua ez dirudien: sarea konfiguratuko dugu, ez gailu indibidualak.
Azken urteotan, sarea entitate bakar gisa tratatzeko enfasiaren aldaketa ikusi dugu, horregatik Software definitutako sareak, Asmoa bultzatutako sareak и Sare autonomoak.
Azken finean, zer behar dute aplikazioek saretik globalki: A eta B puntuen arteko konektibitatea (beno, batzuetan +B-Z) eta beste aplikazio eta erabiltzaileekiko isolamendua.

Eta, beraz, gure zeregina serie honetan da sistema bat eraiki, egungo konfigurazioa mantenduz sare osoa, dagoeneko gailu bakoitzaren benetako konfigurazioan deskonposatuta dagoena, bere eginkizunaren eta kokapenaren arabera.
Sistema sarearen kudeaketak aldaketak egiteko berarekin harremanetan jartzen garela esan nahi du, eta, aldi berean, gailu bakoitzaren nahi den egoera kalkulatu eta konfiguratzen du.
Modu honetan, CLIrako eskuzko sarbidea ia zerora murrizten dugu (gailuaren ezarpenetan edo sarearen diseinuan egiten diren aldaketak formalizatu eta dokumentatu behar dira) eta, ondoren, beharrezko sareko elementuetara zabaldu.

Hau da, adibidez, erabakitzen bagenu hemendik aurrera Kazan-eko rack etengailuek bi sare iragarri behar dituztela bat baino,

1. Lehenik eta behin sistemen aldaketak dokumentatzen ditugu
2. Sareko gailu guztien xede-konfigurazioa sortzea
3. Sarearen konfigurazioa eguneratzeko programa abiarazten dugu, nodo bakoitzean zer kendu behar den kalkulatzen du, zer gehitu eta nodoak nahi den egoerara eramaten ditu.

Aldi berean, eskuz egiten ditugu aldaketak lehen urratsean soilik.

Konfigurazio-probak

Ezaguna daarazoen % 80 konfigurazio-aldaketetan gertatzen direla - horren zeharkako froga da Urte Berriko oporretan dena lasai egon ohi dela.
Pertsonalki, giza akatsen ondoriozko hamarnaka etenaldi global ikusi ditut: komando okerra, konfigurazioa adar okerrean exekutatu zen, komunitatea ahaztu zen, MPLS bideratzailean globalki eraitsi zen, bost hardware konfiguratu ziren, baina errorea ez zen. seigarrenean ohartu ziren, beste pertsona batek egindako aldaketa zaharrak egin ziren. Eszenatoki asko daude.

Automatizazioak akats gutxiago egiteko aukera emango digu, baina eskala handiagoan. Horrela, gailu bat ez ezik, sare osoa aldi berean har dezakezu.

Antzinatik, gure aitonek begi onez, altzairuzko bolak eta sarearen funtzionaltasuna egiaztatzen zuten egindako aldaketen zuzentasuna zabaldu ondoren.
Lanak geldialdia eta galera katastrofikoak ekarri zituen aitona haiek kume gutxiago utzi zituzten eta denborarekin hil beharko lirateke, baina eboluzioa prozesu motela da, eta, beraz, denek ez dute oraindik aldaketak probatzen laborategian lehenik.
Dena den, aurrerapenaren abangoardian konfigurazioa probatzeko prozesua eta sarean gehiago aplikatzeko prozesua automatizatu dutenak daude. Beste era batera esanda, CI/CD prozedura maileguan hartu nuen (Etengabeko Integrazioa, Etengabeko Hedapena) garatzaileen eskutik.
Ataletako batean hau bertsio-kontrol sistema bat erabiliz nola inplementatu ikusiko dugu, ziurrenik Github.

Sare CI/CD ideiara ohitzen zarenean, egun batetik bestera konfigurazio bat produkzio sare batean aplikatuz egiaztatzeko metodoak Erdi Aroko hasierako ezjakintasuna dirudi. Burua mailu batekin jotzea bezalakoa.

buruzko ideien jarraipena organikoa sistema sarearen kudeaketa eta CI/CD konfigurazioaren bertsio osoa bihurtzen da.

Bertsioa

Suposatuko dugu edozein aldaketarekin, txikienekin ere, oharkabeko gailu batean ere, sare osoa egoera batetik bestera mugitzen dela.
Eta beti ez dugu komandorik exekutatzen gailuan, sarearen egoera aldatzen dugu.
Beraz, dei diezaiegun estatu horiei bertsioak?

Demagun oraingo bertsioa 1.0.0 dela.
ToRetako batean Loopback interfazearen IP helbidea aldatu al da? Bertsio txiki bat da eta 1.0.1 zenbakia izango du.
Ibilbideak BGPra inportatzeko politikak berrikusi ditugu - apur bat serioago - dagoeneko 1.1.0
IGP kentzea eta BGPra soilik aldatzea erabaki genuen - dagoeneko diseinu aldaketa erradikala da - 2.0.0.

Aldi berean, DC ezberdinek bertsio desberdinak izan ditzakete: sarea garatzen ari da, ekipamendu berriak instalatzen ari dira, bizkarrezurra maila berriak gehitzen ari dira nonbait, ez besteetan, etab.

Про bertsio semantikoa aparteko artikulu batean hitz egingo dugu.

Berriro diot - edozein aldaketa (arazketa komandoak izan ezik) bertsio eguneratzea da. Administratzaileei uneko bertsioaren desbideratzeen berri eman behar zaie.

Gauza bera gertatzen da aldaketak atzera botatzearekin - hau ez da azken komandoak bertan behera uzten, hau ez da gailuaren sistema eragilea erabiliz atzera egitea - hau sare osoa bertsio berri batera (zahar) batera eramaten ari da.

Zerbitzuen jarraipena eta autosendapena

Berez ageriko zeregin hori maila berri batera iritsi da sare modernoetan.
Sarritan, zerbitzu hornitzaile handiek huts egiten duten zerbitzu bat oso azkar konpondu behar dela eta berri bat planteatu behar dute, zer gertatu den jakin beharrean.
"Oso" esan nahi du alde guztietatik eskuzabal estali behar duzula monitorizazioaz, segundoren buruan arauaren desbideratze txikienak detektatuko dituena.
Eta hemen ohiko neurketak, hala nola, interfazearen karga edo nodoen erabilgarritasuna, ez dira nahikoak. Gutuneko funtzionarioak eskuz kontrolatzea ere ez da nahikoa.
Gauza askotarako egon beharko luke Auto-sendatzea — kontrol-argiak gorri jarri ziren eta geuk min egiten zuen lekuan plantaina jarri genuen.

Eta hemen gailu indibidualak ez ezik, sare osoaren osasuna ere kontrolatzen dugu, bai whitebox, nahiko ulergarria dena, bai blackbox, konplikatuagoa dena.

Zer beharko dugu halako anbizio handiko planak martxan jartzeko?

• Izan sareko gailu guztien zerrenda, haien kokapena, rolak, ereduak, software bertsioak.
  kazan-leaf-1.lmu.net, Kazan, hostoa, Juniper QFX 5120, R18.3.
• Sareko zerbitzuak deskribatzeko sistema bat edukitzea.
  IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH.
• Gailua hasieratzeko gai izan.
  Ostalari-izena, Mgmt IP, Mgmt Route, Erabiltzaileak, RSA-gakoak, LLDP, NETCONF
• Konfiguratu gailua eta eraman konfigurazioa nahi duzun bertsiora (zaharra barne).
• Proba konfigurazioa
• Aldian-aldian egiaztatu gailu guztien egoera egungoekiko desbideratzerik dagoen eta jakinarazi nori izan behar duen.
  Egun batetik bestera, norbaitek isil-isilik arau bat gehitu zion ACLari.
• Errendimendua kontrolatu.

Funtsak

Nahikoa konplikatua dirudi proiektua osagaietan deskonposatzen hastea.

Eta hamar izango dira:

1. Inbentario-sistema
2. IP espazioa kudeatzeko sistema
3. Sareko zerbitzuen deskribapen-sistema
4. Gailua hasieratzeko mekanismoa
5. Saltzaileen arteko konfigurazio eredua
6. Saltzaileen berariazko gidariaren interfazea
7. Gailuari konfigurazioa emateko mekanismoa
8. CI/CD
9. Babeskopia egiteko eta desbideratzeak bilatzeko mekanismoa
10. Jarraipen-sistema

Hau, bide batez, zikloaren helburuei buruzko ikuspegia nola aldatu den erakusten duen adibidea da: 4 osagai zeuden zirriborroan.

Ilustrazioan osagai guztiak eta gailua bera irudikatu ditut.
Elkar gurutzatzen diren osagaiak elkarri eragiten diote.
Blokea zenbat eta handiagoa izan, orduan eta arreta handiagoa jarri behar zaio osagai honi.

1. osagaia: Inbentario-sistema

Jakina, jakin nahi dugu zer ekipo dagoen non, zertara konektatuta.
Inbentario-sistema edozein enpresaren zati bat da.
Gehienetan, enpresa batek sareko gailuetarako inbentario sistema bereizia du, arazo zehatzagoak konpontzen dituena.
Artikulu sorta honen barruan, DCIM - Data Center Infrastructure Management deituko diogu. DCIM terminoak berak, hertsiki esanda, askoz gehiago barne hartzen duen arren.

Gure helburuetarako, gailuari buruzko informazio hau gordeko dugu bertan:

• Inbentario zenbakia
• Izenburua/Deskribapena
• Eredua (Huawei CE12800, Juniper QFX5120, etab.)
• Parametro ezaugarriak (plakak, interfazeak, etab.)
• Rola (Hostoa, bizkarrezurra, ertzaren bideratzailea, etab.)
• Kokapena (eskualdea, hiria, datu-zentroa, rack, unitatea)
• Gailuen arteko interkonexioak
• Sarearen topologia

Guztiz argi dago guk geuk jakin nahi dugula hori guztia.
Baina horrek lagunduko al du automatizazio helburuetarako?
Zalantzarik gabe.
Esate baterako, badakigu Leaf etengailuetako datu-zentro jakin batean, Huawei bada, trafiko jakin batzuk iragazteko ACLak aplikatu behar direla VLANean, eta Juniper bada, interfaze fisikoko 0 unitatean.
Edo Syslog zerbitzari berri bat zabaldu behar duzu eskualdeko muga guztietara.

Bertan sare birtualeko gailuak gordeko ditugu, bideratzaile birtualak edo root islatzaileak adibidez. DNS zerbitzariak, NTP, Syslog eta, oro har, modu batera edo bestera sarearekin zerikusia duen guztia gehi ditzakegu.

2. osagaia: IP espazioa kudeatzeko sistema

Bai, eta gaur egun Excel fitxategi batean aurrizkien eta IP helbidearen jarraipena egiten duten talde-taldeak daude. Baina ikuspegi modernoa datu-base bat da oraindik, nginx/apache-n, API-n eta IP helbideak eta sareak VRFetan banatuta grabatzeko funtzio zabalak dituena.
IPAM - IP Helbideen Kudeaketa.

Gure helburuetarako, informazio hau gordeko dugu bertan:

• VLANak
• VRF
• Sareak/azpisareak
• IP helbideak
• Helbideak gailuei, sareak kokapenei eta VLAN zenbakiei lotzea

Berriz ere, argi dago ziurtatu nahi dugula ToR loopback-erako IP helbide berri bat esleitzen dugunean, ez dugula estropezu egingo jada norbaiti esleituta zegoela. Edo aurrizki bera bi aldiz erabili dugula sarearen mutur ezberdinetan.
Baina nola laguntzen du honek automatizazioan?
Erraza da.
Loopbacks rola duen sisteman aurrizki bat eskatzen dugu, esleitzeko eskuragarri dauden IP helbideak dituena - aurkitzen bada, helbidea esleitzen dugu, ez bada, aurrizki berri bat sortzea eskatzen dugu.
Edo gailuaren konfigurazioa sortzerakoan, sistema beretik jakin dezakegu zein VRFtan kokatu behar den interfazea.
Eta zerbitzari berri bat abiaraztean, script-a sisteman hasten da, zerbitzaria zein etengailutan dagoen, zein ataka eta zein azpisare esleituta dagoen interfazeari eta zerbitzariaren helbidea esleituko du.

Honek DCIM eta IPAM sistema bakarrean konbinatzeko gogoa iradokitzen du, funtzioak ez bikoiztu eta antzeko bi entitate ez zerbitzatzeko.
Horixe egingo dugu.

3. osagaia. Sareko zerbitzuak deskribatzeko sistema

Lehen bi sistemek oraindik nolabait erabili behar diren aldagaiak gordetzen badituzte, hirugarrenak gailu bakoitzaren rola nola konfiguratu behar den deskribatzen du.
Merezi du bi sare-zerbitzu mota bereiztea:

• Azpiegiturak
• Bezeroa.

Lehenengoak oinarrizko konektibitatea eta gailuen kontrola eskaintzeko diseinatuta daude. Besteak beste, VTY, SNMP, NTP, Syslog, AAA, bideratze-protokoloak, CoPP, etab.
Azken hauek bezeroarentzako zerbitzua antolatzen dute: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etab.
Noski, mugako kasuak ere badaude - non sartu MPLS LDP, BGP? Bai, eta bideratze-protokoloak erabil daitezke bezeroentzat. Baina hau ez da garrantzitsua.

Bi zerbitzu motak konfigurazio primitiboetan deskonposatzen dira:

• interfaze fisikoak eta logikoak (tag/anteg, mtu)
• IP helbideak eta VRFak (IP, IPv6, VRF)
• ACLak eta trafikoa prozesatzeko politikak
• Protokoloak (IGP, BGP, MPLS)
• Bideratze-politikak (aurrizki-zerrendak, komunitateak, ASN iragazkiak).
• Utilitate zerbitzuak (SSH, NTP, LLDP, Syslog...)
• Etab.

Zehazki nola egingo dugun hau, oraindik ez daukat ideiarik. Aparteko artikulu batean aztertuko dugu.

Bizitzatik pixka bat hurbilago bada, hori deskriba genezake
Leaf etengailuak BGP saioak izan behar ditu konektatutako Spine etengailu guztiekin, konektatutako sareak prozesura inportatu eta Spine etengailuetatik aurrizki jakin bateko sareak soilik onartu behar ditu. Mugatu CoPP IPv6 ND 10 pps-era, etab.
Aldi berean, bizkarrezurrek konektaturiko kable guztiekin egiten dituzte saioak, erro islatzaile gisa jokatuz, eta haiengandik luzera jakin bateko eta komunitate jakin bateko ibilbideak baino ez dituzte onartzen.

4. osagaia: Gailua hasieratzeko mekanismoa

Izenburu honen azpian gailu bat radar batean agertzeko eta urrunetik atzitzeko egin behar diren ekintza asko konbinatzen ditut.

1. Sartu gailua inbentario-sisteman.
2. Hautatu kudeaketa IP helbide bat.
3. Konfiguratu oinarrizko sarbidea:
   Ostalariaren izena, kudeaketa IP helbidea, kudeaketa sarerako ibilbidea, erabiltzaileak, SSH gakoak, protokoloak - telnet/SSH/NETCONF

Hiru ikuspegi daude:

• Dena guztiz eskuzkoa da. Gailua standera eramaten da, non pertsona organiko arrunt batek sistemetan sartu, kontsolara konektatu eta konfiguratuko du. Sare estatiko txikietan lan egin dezake.
• ZTP - Zero Touch hornidura. Hardwarea iritsi, zutitu, DHCP bidez helbide bat jaso, zerbitzari berezi batera joan eta bere burua konfiguratu zuen.
• Kontsola zerbitzarien azpiegitura, non hasierako konfigurazioa kontsolaren atakaren bidez gertatzen den modu automatikoan.

Hirurei buruz hitz egingo dugu aparteko artikulu batean.

5. osagaia: hornitzailearekiko konfigurazio eredua

Orain arte, sistema guztiak sarean ikusi nahiko genukeen aldagaiak eta deskribapen deklaratiboa eskaintzen duten adabaki desberdinak izan dira. Baina lehenago edo beranduago, zehatzei aurre egin beharko diezu.
Etapa honetan, gailu zehatz bakoitzerako, primitiboak, zerbitzuak eta aldagaiak konfigurazio-eredu batean konbinatzen dira, gailu zehatz baten konfigurazio osoa benetan deskribatzen duena, saltzaileen aldetik neutral moduan soilik.
Zer egiten du urrats honek? Zergatik ez sortu berehala kargatu dezakezun gailuaren konfigurazio bat?
Izan ere, honek hiru arazo konpontzen ditu:

1. Ez egokitu gailuarekin elkarreragiteko interfaze zehatz batera. Izan CLI, NETCONF, RESTCONF, SNMP - eredua berdina izango da.
2. Ez mantendu txantiloi/script-kopurua sareko saltzaile kopuruaren arabera, eta diseinua aldatzen bada, aldatu gauza bera hainbat lekutan.
3. Kargatu konfigurazioa gailutik (backup), jarri zehazki eredu berean eta zuzenean alderatu helburuko konfigurazioa lehendik dagoenarekin delta kalkulatzeko eta beharrezkoak diren zatiak bakarrik aldatuko dituen edo desbideraketak identifikatzeko konfigurazio-adabaki bat prestatu.

Etapa honen ondorioz, saltzaileen araberako konfigurazio bat lortzen dugu.

6. osagaia. Saltzaileen berariazko gidariaren interfazea

Ez zenuke zeure burua lausenkatu behar egunen batean ciska bat Juniper baten modu berean konfiguratu ahal izango den itxaropenarekin, haiei dei berdinak bidaliz. Kutxa zurien ospea gero eta handiagoa izan arren eta NETCONF, RESTCONF, OpenConfig-en euskarria agertu arren, protokolo hauek ematen duten eduki espezifikoa desberdina da saltzaile batetik bestera, eta hori da hain erraz amore emango ez duten lehiakortasun-desberdintasunetako bat.
Hau gutxi gorabehera OpenContrail eta OpenStack-en berdina da, RestAPI duten NorthBound interfazea, dei guztiz desberdinak espero dituzte.

Beraz, bosgarren urratsean, saltzailetik independentea den ereduak hardwarera joango den forma hartu behar du.
Eta hemen bitarteko guztiak onak dira (ez): CLI, NETCONF, RESTCONF, SNMP besterik gabe.

Hori dela eta, aurreko urratsaren emaitza saltzaile zehatz baten behar den formatura transferituko duen kontrolatzaile bat beharko dugu: CLI komando multzo bat, XML egitura bat.

7. osagaia. Gailuari konfigurazioa emateko mekanismoa

Konfigurazioa sortu dugu, baina oraindik gailuetara entregatu behar da, eta, jakina, ez eskuz.
Lehenik eta behin, zein garraio erabiliko dugun galderaren aurrean gaude? Eta gaur aukera ez da txikia:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (nahiz eta kanpokoa den FIB emateko modu bat delako, ez ezarpenak)

Dezagun t-a hemen. CLI ondarea da. SNMP... eztul eztula.
RESTCONF animalia ezezaguna da oraindik; REST APIa ez du ia inork onartzen. Hori dela eta, seriean NETCONF-en zentratuko gara.

Izan ere, irakurleak dagoeneko ulertu duen bezala, puntu honetarako interfazea erabaki dugu jada - aurreko urratsaren emaitza aukeratu zen interfazearen formatuan aurkezten da jada.

Bigarrenik, eta zein tresnarekin egingo dugu hau?
Hemen ere aukera zabala dago:

• Norberak idatzitako gidoia edo plataforma. Arma gaitezen ncclient eta asyncIOrekin eta egin dezagun dena. Zer kostatzen zaigu inplementazio sistema hutsetik eraikitzea?
• Ansible sareko moduluen liburutegi aberatsarekin.
• Gatza sarearekin duen lan eskasarekin eta Napalmarekin duen loturarekin.
• Egia esan Napalm, saltzaile pare bat ezagutzen dituena eta kitto, agur.
• Nornir etorkizunean disekzionatuko dugun beste animalia bat da.

Hemen gogokoena oraindik ez da aukeratu - bilatzen arituko gara.

Zer gehiago da garrantzitsua hemen? Konfigurazioa aplikatzearen ondorioak.
Arrakastatsua ala ez. Oraindik hardwarerako sarbidea dago edo ez?
Badirudi commit-ek hemen lagunduko duela gailuan deskargatutakoa berresten eta balioztatzen.
Horrek, NETCONF inplementazio zuzenarekin batera, gailu egokien sorta nabarmen murrizten du - fabrikatzaile askok ez dute onartzen ohiko konpromisoak. Baina hau ezinbesteko baldintza bat baino ez da RFP. Azkenean, inor ez da kezkatzen Errusiako saltzaile bakar batek 32 * 100GE interfazearen baldintza beteko ez duelako. Edo kezkatuta dago?

8. osagaia. CI/CD

Une honetan, dagoeneko prest daukagu ​​sareko gailu guztietarako konfigurazioa.
"Dena" idazten dut sarearen egoera bertsioratzeaz ari garelako. Eta etengailu baten ezarpenak aldatu behar badituzu ere, aldaketak sare osorako kalkulatzen dira. Jakina, zero izan daitezke nodo gehienentzat.

Baina, lehen esan bezala, ez gara dena zuzenean produkziora eraman nahi dugun barbaro mota batzuk.
Sortutako konfigurazioa Pipeline CI/CDtik pasatu behar da lehenik.

CI/CD Continuous Integration, Continuous Deployment esan nahi du. Hau da, taldeak sei hilabetean behin kaleratze nagusi berri bat kaleratzen ez ezik, zaharra guztiz ordezkatuz, aldizka funtzionaltasun berriak (Inplementazioa) inplementatzen ditu zati txikietan, eta horietako bakoitza bateragarritasuna, segurtasuna eta errendimendua (Integrazioa).

Horretarako, konfigurazio aldaketak kontrolatzen dituen bertsioak kontrolatzeko sistema bat dugu, bezeroaren zerbitzua apurtuta dagoen ala ez egiaztatzen duen laborategia, gertakari hori egiaztatzen duen monitorizazio sistema bat eta azken urratsa ekoizpen sarean aldaketak zabaltzea da.

Arazketa-komandoak izan ezik, sareko aldaketa guztiak CI/CD Pipelinetik pasatu behar dira - hau da gure bizitza lasaia eta karrera luze eta zoriontsu baten bermea.

9. osagaia. Babeskopia eta anomaliak detektatzeko sistema

Beno, ez dago berriro babeskopiei buruz hitz egin beharrik.
Besterik gabe, koroan edo git-en konfigurazio-aldaketa baten gainean gehituko ditugu.

Baina bigarren zatia interesgarriagoa da: norbaitek babeskopia hauek adi egon beharko lituzke. Eta kasu batzuetan, norbaitek joan behar du dena zegoen bezala buelta eman, eta beste batzuetan, norbaiti miau zerbait gaizki dagoela.
Adibidez, aldagaietan erregistratuta ez dagoen erabiltzaile berri bat agertu bada, hacketik kendu behar duzu. Eta hobe bada suebaki-arau berri bat ez ukitzea, agian norbaitek arazketa aktibatu berri du, edo agian zerbitzu berria, bungler bat, ez zegoen araudiaren arabera erregistratuta, baina jendea dagoeneko sartu da.

Oraindik ez dugu sare osoaren eskalako delta txiki bati ihes egingo, automatizazio sistemaren bat eta kudeaketaren esku altzairua izan arren. Arazoak arazketa egiteko, inork ez du konfiguraziorik gehituko sistemei, hala ere. Gainera, baliteke konfigurazio ereduan ere ez egotea.

Adibidez, arazo bat lokalizatzeko IP espezifiko bakoitzeko pakete kopurua zenbatzeko suebaki-araua aldi baterako konfigurazio guztiz arrunta da.

10. osagaia. Jarraipen-sistema

Hasieran ez nuen monitorizazioaren gaia landuko - oraindik gai bolumentsua, polemikoa eta konplexua da. Baina gauzak aurrera egin ahala, hori automatizazioaren zati bat zela ikusi zen. Eta ezinezkoa da saihestea, praktikarik gabe ere.

Evolving Thought CI/CD prozesuaren zati organikoa da. Konfigurazioa sarera zabaldu ondoren, orain dena ondo dagoen ala ez zehazteko gai izan behar dugu.
Eta ez bakarrik eta ez hainbeste interfazearen erabilera-egutegiei edo nodoen erabilgarritasunari buruz hitz egiten ari gara, baizik eta gauza sotilagoez: beharrezko bideen presentzia, horien atributuak, BGP saio kopurua, OSPF bizilagunak, End-to-End errendimendua. gaineko zerbitzuen.
Kanpoko zerbitzarirako syslog-ak gehitzeari utzi al dio, edo SFlow agentea hautsi al zen, edo ilaretako tantak hazten hasi ziren, edo aurrizki batzuen arteko konexioa hautsi al zen?

Horri buruz hausnartuko dugu aparteko artikulu batean.

Ondorioa

Oinarri gisa, datu-zentroen sarearen diseinu modernoetako bat aukeratu nuen - L3 Clos Fabrica BGP bideratze-protokolo gisa.
Oraingoan sarea Juniper-en eraikiko dugu, orain JunOs interfazea vanlove bat delako.

Zaildu dezagun gure bizitza Kode irekiko tresnak eta hornitzaile anitzeko sarea soilik erabiliz; beraz, Juniperez gain, zorte handiko pertsona bat aukeratuko dut bidean.

Datozen argitalpenen plana honelakoa da:
Lehenik eta behin sare birtualei buruz hitz egingo dut. Lehenik eta behin, nahi dudalako, eta bigarrenik, hori gabe azpiegitura sarearen diseinua ez delako oso argi izango.
Gero sarearen diseinuari buruz berari buruz: topologia, bideratzea, politikak.
Munta dezagun laborategiko stand bat.
Pentsa dezagun eta agian praktika dezagun gailua sarean hasieratzen.
Eta gero osagai bakoitzari buruz xehetasun intimoan.

Eta bai, ez dut agintzen ziklo hau dotorez amaituko denik prest egindako irtenbide batekin. 🙂

Esteka interesgarriak

• Seriean sakondu aurretik, merezi du Natasha Samoilenkoren liburua irakurtzea Sare ingeniarientzako Python. Eta agian pasa ikastaroa.
• Irakurtzeko ere baliagarria izango da RFC Peter Lapukhov-ek Facebooketik datu-zentroen lantegien diseinuari buruz.
• Arkitekturaren dokumentazioak Overlay SDN-k nola funtzionatzen duen jakiteko ideia emango dizu. Tungsteno ehuna (lehen Open Contrail).

Eskerrik asko

Erromako arroila. Iruzkinak eta aldaketak egiteko.
Artyom Txernobaia. KDPVrako.

Iturria: www.habr.com