SDSM finiĝis, sed la neregebla deziro skribi restas.

Dum multaj jaroj, nia frato suferis pro farado de rutina laboro, krucante la fingrojn antaŭ ol fari kaj malhavante dormon pro noktaj retrovojoj.
Sed la mallumaj tempoj finiĝas.

Kun ĉi tiu artikolo mi komencos serion pri kiel mi aŭtomatigo vidiĝas.
Survoje, ni komprenos la stadiojn de aŭtomatigo, stokado de variabloj, formaligo de dezajno, RestAPI, NETCONF, YANG, YDK kaj ni faros multan programadon.
Al mi signifas, ke a) ĝi ne estas objektiva vero, b) ĝi ne estas senkondiĉe la plej bona aliro, c) mia opinio, eĉ dum la movado de la unua ĝis la lasta artikolo, povas ŝanĝiĝi - sincere, de la skiza etapo ĝis publikigo, mi ĉion reverkis tute dufoje.

Enhavo

1. Objektivoj
   1. La reto estas kiel ununura organismo
   2. Testado de agordo
   3. Versiado
   4. Monitorado kaj mem-resanigo de servoj

2. Rimedoj
   1. Sistemo de inventaro
   2. IP-spaca administradsistemo
   3. Reta servo priskriba sistemo
   4. Mekanismo de inicialigo de aparato
   5. Vend-agnostika agorda modelo
   6. Vend-specifa ŝoforinterfaco
   7. Mekanismo por liveri agordon al la aparato
   8. CI / KD
   9. Mekanismo por sekurkopio kaj serĉado de devioj
   10. Monitora sistemo

3. konkludo

Mi provos fari ADSM en formato iomete malsama ol SDSM. Grandaj, detalaj, numeritaj artikoloj daŭre aperos, kaj inter ili mi publikigos etajn notojn el ĉiutaga sperto. Mi provos batali perfektismon ĉi tie kaj ne leki ĉiun el ili.

Kiel amuze estas, ke la duan fojon oni devas iri tra la sama vojo.

Komence mi mem devis verki artikolojn pri retoj pro tio, ke ili ne estis en la RuNet.

Nun mi ne povis trovi ampleksan dokumenton, kiu sistemigus alirojn al aŭtomatigo kaj analizus la suprajn teknologiojn uzante simplajn praktikajn ekzemplojn.

Mi eble eraras, do bonvolu doni ligilojn al utilaj rimedoj. Tamen tio ne ŝanĝos mian decidon skribi, ĉar la ĉefa celo estas mem lerni ion, kaj faciligi la vivon al aliaj estas agrabla bonuso, kiu karesas la genon por kunhavi sperton.

Ni provos preni mezgrandan LAN DC-datumcentron kaj ellabori la tutan aŭtomatigan skemon.
Mi faros kelkajn aferojn preskaŭ por la unua fojo kun vi.

Mi ne estos originala en la ideoj kaj iloj priskribitaj ĉi tie. Dmitry Figol havas bonegan kanalo kun riveretoj pri ĉi tiu temo.
La artikoloj interkovros kun ili en multaj aspektoj.

La LAN DC havas 4 DC-ojn, ĉirkaŭ 250 ŝaltilojn, duon dekduon da enkursigiloj kaj kelkajn fajroŝirmilojn.
Ne Facebook, sed sufiĉa por pensi profunde pri aŭtomatigo.
Tamen ekzistas opinio, ke se vi havas pli ol 1 aparaton, aŭtomatigo jam bezonas.
Fakte, estas malfacile imagi, ke iu ajn nun povas vivi sen almenaŭ pako da genuaj skriptoj.
Kvankam mi aŭdis, ke ekzistas oficejoj, kie IP-adresoj estas konservitaj en Excel, kaj ĉiu el la miloj da retaj aparatoj estas agordita permane kaj havas sian propran unikan agordon. Ĉi tio, kompreneble, povas esti pasigita kiel moderna arto, sed la sentoj de la inĝeniero certe estos ofenditaj.

Objektivoj

Nun ni starigos la plej abstraktajn celojn:

• La reto estas kiel ununura organismo
• Testado de agordo
• Reta stato-versiado
• Monitorado kaj mem-resanigo de servoj

Poste en ĉi tiu artikolo ni rigardos kiajn rimedojn ni uzos, kaj en la sekvanta, ni rigardos la celojn kaj rimedojn detale.

La reto estas kiel ununura organismo

La difina frazo de la serio, kvankam unuavide ĝi eble ne ŝajnas tiel signifa: ni agordos la reton, ne individuajn aparatojn.
En la lastaj jaroj, ni vidis ŝanĝon en emfazo al traktado de la reto kiel ununura unuo, tial la Retumado de programaro, Intencaj Retoj и Aŭtonomaj Retoj.
Post ĉio, kion aplikaĵoj bezonas tutmonde de la reto: konektebleco inter punktoj A kaj B (nu, foje +B-Z) kaj izolado de aliaj aplikaĵoj kaj uzantoj.

Kaj do nia tasko en ĉi tiu serio estas konstrui sistemon, konservante la nunan agordon la tuta reto, kiu jam estas malkomponita en la realan agordon sur ĉiu aparato laŭ sia rolo kaj loko.
sistemo administrado de reto implicas, ke por fari ŝanĝojn ni kontaktas ĝin, kaj ĝi, siavice, kalkulas la deziratan staton por ĉiu aparato kaj agordas ĝin.
Tiamaniere, ni minimumigas manan aliron al la CLI al preskaŭ nulo - ajnaj ŝanĝoj en aparataj agordoj aŭ reto-dezajno devas esti formaligitaj kaj dokumentitaj - kaj nur tiam eligitaj al la necesaj retaj elementoj.

Tio estas, ekzemple, se ni decidus, ke ekde nun rakaj ŝaltiloj en Kazan anoncu du retojn anstataŭ unu, ni

1. Unue ni dokumentas ŝanĝojn en sistemoj
2. Generante la celan agordon de ĉiuj retaj aparatoj
3. Ni lanĉas la retan agordan ĝisdatigprogramon, kiu kalkulas, kio devas esti forigita de ĉiu nodo, kion aldoni, kaj alportas la nodojn al la dezirata stato.

Samtempe ni faras ŝanĝojn permane nur en la unua paŝo.

Testado de agordo

Estas konatake 80% de problemoj okazas dum agordaj ŝanĝoj - nerekta pruvo pri tio estas, ke dum la novjaraj ferioj ĉio estas kutime trankvila.
Mi persone atestis dekojn da tutmondaj malfunkcioj pro homa eraro: la malĝusta komando, la agordo estis efektivigita en la malĝusta branĉo, la komunumo forgesis, MPLS estis disfaligita tutmonde sur la enkursigilo, kvin pecoj da aparataro estis agordita, sed la eraro ne estis. rimarkite je la sesa, malnovaj ŝanĝoj faritaj de alia persono estis faritaj. Estas amaso da scenaroj.

Aŭtomatigo permesos al ni fari malpli da eraroj, sed sur pli granda skalo. Tiel vi povas briki ne nur unu aparaton, sed la tutan reton samtempe.

De antikvaj tempoj, niaj avoj kontrolis la ĝustecon de la ŝanĝoj faritaj per akra okulo, buloj el ŝtalo kaj la funkciecon de la reto post kiam ili estis lanĉitaj.
Tiuj avoj, kies laboro kaŭzis malfunkcion kaj katastrofajn perdojn, lasis malpli da idoj kaj devus formorti kun la tempo, sed evoluo estas malrapida procezo, kaj tial ne ĉiuj ankoraŭ testas ŝanĝojn en la laboratorio unue.
Tamen, ĉe la avangardo de progreso estas tiuj, kiuj aŭtomatigis la procezon de testado de la agordo kaj ĝia plua apliko al la reto. Alivorte, mi pruntis la proceduron CI/CD (Kontinua Integriĝo, Kontinua Deplojo) de la programistoj.
En unu el la partoj ni rigardos kiel efektivigi ĉi tion per versio-kontrolsistemo, verŝajne Github.

Kiam vi alkutimiĝos al la ideo de reto CI/KD, dum la nokto la metodo kontroli agordon aplikante ĝin al produktada reto ŝajnos frua mezepoka nescio. Ia kiel frapi eksplodilon per martelo.

Organika daŭrigo de ideoj pri sistemo retadministrado kaj CI/KD iĝas plena versio de la agordo.

Versiado

Ni supozos, ke kun iuj ŝanĝoj, eĉ la plej malgrandaj, eĉ sur unu nerimarkebla aparato, la tuta reto moviĝas de unu ŝtato al alia.
Kaj ni ĉiam ne plenumas komandon sur la aparato, ni ŝanĝas la staton de la reto.
Do ni nomu ĉi tiujn ŝtatojn versioj?

Ni diru, ke la nuna versio estas 1.0.0.
Ĉu la IP-adreso de la Loopback-interfaco sur unu el la ToR ŝanĝiĝis? Ĉi tio estas negrava versio kaj estos numerita 1.0.1.
Ni reviziis la politikojn por importi itinerojn en BGP - iom pli serioze - jam 1.1.0
Ni decidis forigi IGP kaj ŝanĝi nur al BGP - ĉi tio jam estas radikala dezajnŝanĝo - 2.0.0.

Samtempe, malsamaj DC-oj povas havi malsamajn versiojn - la reto disvolviĝas, novaj ekipaĵoj estas instalitaj, novaj niveloj de spinoj estas aldonitaj ie, ne en aliaj, ktp.

pri semantika versio ni parolos en aparta artikolo.

Mi ripetas - ĉiu ŝanĝo (krom sencimigaj komandoj) estas versio ĝisdatigo. Administrantoj devas esti sciigitaj pri ajnaj devioj de la nuna versio.

La sama validas por retrovigi ŝanĝojn - ĉi tio ne nuligas la lastajn komandojn, ĉi tio ne estas retrovoko uzante la operaciumon de la aparato - ĉi tio alportas la tutan reton al nova (malnova) versio.

Monitorado kaj mem-resanigo de servoj

Ĉi tiu memkomprenebla tasko atingis novan nivelon en modernaj retoj.
Ofte, grandaj servoprovizantoj prenas la aliron ke malsukcesa servo devas esti riparita tre rapide kaj nova levita, anstataŭ eltrovi kio okazis.
"Tre" signifas, ke vi devas esti malavare kovrita ĉiuflanke per monitorado, kiu ene de sekundoj detektos la plej etajn deviojn de la normo.
Kaj ĉi tie la kutimaj metrikoj, kiel interfaco-ŝarĝado aŭ noda havebleco, ne plu sufiĉas. Mana kontrolado de ili fare de la deĵoranto ankaŭ ne sufiĉas.
Por multaj aferoj devus ekzisti Mem-resanigo — la monitoraj lumoj ruĝiĝis kaj ni mem iris kaj aplikis la plantagon, kie ĝi doloris.

Kaj ĉi tie ni ankaŭ kontrolas ne nur individuajn aparatojn, sed ankaŭ la sanon de la tuta reto, ambaŭ whitebox, kiu estas relative komprenebla, kaj blackbox, kiu estas pli komplika.

Kion ni bezonos por efektivigi tiajn ambiciajn planojn?

• Havu liston de ĉiuj aparatoj en la reto, ilia loko, roloj, modeloj, programaj versioj.
  kazan-leaf-1.lmu.net, Kazan, folio, Junipero QFX 5120, R18.3.
• Havu sistemon por priskribi retajn servojn.
  IGP, BGP, L2/3VPN, Politiko, ACL, NTP, SSH.
• Estu kapabla pravalorigi la aparaton.
  Gastigantonomo, Mgmt IP, Gmt Route, Uzantoj, RSA-Ŝlosiloj, LLDP, NETCONF
• Agordu la aparaton kaj alportu la agordon al la dezirata (inkluzive de malnova) versio.
• Testa agordo
• Periode kontrolu la staton de ĉiuj aparatoj por devioj de la nunaj kaj raportu al kiu ĝi devus esti.
  Dum la nokto, iu trankvile aldonis regulon al la ACL.
• Monitoru rendimenton.

Rimedoj

Sonas sufiĉe komplike por komenci malkomponi la projekton en komponantojn.

Kaj estos dek el ili:

1. Sistemo de inventaro
2. IP-spaca administradsistemo
3. Reta servo priskriba sistemo
4. Mekanismo de inicialigo de aparato
5. Vend-agnostika agorda modelo
6. Vend-specifa ŝoforinterfaco
7. Mekanismo por liveri agordon al la aparato
8. CI / KD
9. Mekanismo por sekurkopio kaj serĉado de devioj
10. Monitora sistemo

Ĉi tio, cetere, estas ekzemplo de kiel la vido pri la celoj de la ciklo ŝanĝiĝis - estis 4 komponantoj en la skizo.

En la ilustraĵo mi prezentis ĉiujn komponantojn kaj la aparaton mem.
Intersekcantaj komponantoj interagas unu kun la alia.
Ju pli granda estas la bloko, des pli da atento devas esti pagita al ĉi tiu komponanto.

Komponanto 1: Stokrosistemo

Evidente, ni volas scii, kia ekipaĵo troviĝas kie, al kio estas konektita.
La inventa sistemo estas integra parto de iu ajn entrepreno.
Plej ofte, entrepreno havas apartan inventarsistemon por retaj aparatoj, kiu solvas pli specifajn problemojn.
Kiel parto de ĉi tiu serio de artikoloj, ni nomos ĝin DCIM - Data Center Infrastructure Management. Kvankam la termino DCIM mem, strikte parolante, inkluzivas multe pli.

Por niaj celoj, ni stokos la jenajn informojn pri la aparato en ĝi:

• Nombro de inventaro
• Titolo/Priskribo
• Modelo (Huawei CE12800, Juniper QFX5120, ktp.)
• Karakterizaj parametroj (tabuloj, interfacoj, ktp.)
• Rolo (Folio, Spine, Border Router, ktp.)
• Loko (regiono, urbo, datumcentro, rako, unuo)
• Interkonektoj inter aparatoj
• Reta topologio

Estas tute klare, ke ni mem volas scii ĉion ĉi.
Sed ĉu ĉi tio helpos por aŭtomatigaj celoj?
Sendube.
Ekzemple, ni scias, ke en donita datumcentro sur Leaf-ŝaltiloj, se ĝi estas Huawei, ACL-oj por filtri certan trafikon devus esti aplikataj sur la VLAN, kaj se ĝi estas Juniper, tiam sur unuo 0 de la fizika interfaco.
Aŭ vi devas ruliĝi novan Syslog-servilon al ĉiuj landlimoj en la regiono.

En ĝi ni stokos virtualajn retajn aparatojn, ekzemple virtualajn enkursigilojn aŭ radikajn reflektorojn. Ni povas aldoni DNS-servilojn, NTP, Syslog kaj ĝenerale ĉion, kio iel aŭ alia rilatas al la reto.

Komponanto 2: IP-spaca administradsistemo

Jes, kaj nuntempe ekzistas teamoj de homoj, kiuj konservas prefiksojn kaj IP-adresojn en Excel-dosiero. Sed la moderna aliro ankoraŭ estas datumbazo, kun front-end sur nginx/apache, API kaj ampleksaj funkcioj por registri IP-adresojn kaj retojn dividitajn en VRF-ojn.
IPAM - Administrado pri IP-adreso.

Por niaj celoj, ni stokos la jenajn informojn en ĝi:

• VLANO
• VRF
• Retoj/Subretoj
• IP-adresoj
• Ligante adresojn al aparatoj, retoj al lokoj kaj VLAN-numeroj

Denove, estas klare, ke ni volas certigi, ke kiam ni asignas novan IP-adreson por la ToR-loopback, ni ne falpusxigxos pri la fakto, ke ĝi jam estis asignita al iu. Aŭ ke ni uzis la saman prefikson dufoje ĉe malsamaj finoj de la reto.
Sed kiel ĉi tio helpas kun aŭtomatigo?
Facila
Ni petas prefikson en la sistemo kun la rolo Loopbacks, kiu enhavas IP-adresojn disponeblajn por atribuo - se ĝi estas trovita, ni atribuas la adreson, se ne, ni petas la kreadon de nova prefikso.
Aŭ dum kreado de aparato-agordo, ni povas ekscii de la sama sistemo, en kiu VRF la interfaco devas esti lokita.
Kaj kiam ekfunkciigas novan servilon, la skripto ensalutas en la sistemon, malkovras en kiu ŝaltilo estas la servilo, en kiu haveno kaj kiu subreto estas asignita al la interfaco - kaj asignos la servilan adreson de ĝi.

Ĉi tio sugestas deziron kombini DCIM kaj IPAM en unu sistemon por ne duobligi funkciojn kaj ne servi du similajn entojn.
Tion ni faros.

Komponanto 3. Sistemo por priskribi retajn servojn

Se la unuaj du sistemoj konservas variablojn, kiuj ankoraŭ devas esti uzataj iel, tiam la tria priskribas por ĉiu aparato-rolo kiel ĝi estu agordita.
Indas distingi du malsamajn specojn de retaj servoj:

• Infrastrukturo
• Kliento.

La unuaj estas dizajnitaj por disponigi bazan konekteblecon kaj aparato-kontrolon. Ĉi tiuj inkluzivas VTY, SNMP, NTP, Syslog, AAA, vojprotokolojn, CoPP, ktp.
Ĉi-lastaj organizas la servon por la kliento: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, ktp.
Kompreneble, estas ankaŭ limaj kazoj - kie inkluzivi MPLS LDP, BGP? Jes, kaj vojprotokoloj povas esti uzataj por klientoj. Sed ĉi tio ne estas grava.

Ambaŭ specoj de servoj estas malkomponitaj en agordajn primitivojn:

• fizikaj kaj logikaj interfacoj (etikedo/anteg, mtu)
• IP-adresoj kaj VRF-oj (IP, IPv6, VRF)
• ACLoj kaj trafikaj prilaboraj politikoj
• Protokoloj (IGP, BGP, MPLS)
• Enrutaj politikoj (prefiksaj listoj, komunumoj, ASN-filtriloj).
• Servoj (SSH, NTP, LLDP, Syslog...)
• Ktp.

Kiel precize ni faros tion, mi ankoraŭ ne havas ideon. Ni rigardos ĝin en aparta artikolo.

Se iom pli proksime al la vivo, tiam ni povus priskribi tion
La Leaf-ŝaltilo devas havi BGP-sesiojn kun ĉiuj konektitaj Spine-ŝaltiloj, importi konektitajn retojn en la procezon, kaj akcepti nur retojn de certa prefikso de Spine-ŝaltiloj. Limigu CoPP IPv6 ND al 10 pps, ktp.
Siavice, spinoj okazigas kunsidojn kun ĉiuj konektitaj kondukoj, agante kiel radikaj reflektiloj, kaj akceptas de ili nur itinerojn de certa longeco kaj kun certa komunumo.

Komponanto 4: Aparato Inicialiga Mekanismo

Sub ĉi tiu rubriko mi kombinas multajn el la agoj kiuj devas okazi por ke aparato aperu sur radaro kaj estu alirebla malproksime.

1. Enigu la aparaton en la inventara sistemo.
2. Elektu administradan IP-adreson.
3. Agordu bazan aliron al ĝi:
   Gastnomo, administra IP-adreso, itinero al la administra reto, uzantoj, SSH-ŝlosiloj, protokoloj - telnet/SSH/NETCONF

Estas tri aliroj:

• Ĉio estas tute manlibro. La aparato estas alportita al la stando, kie ordinara organika persono eniros ĝin en la sistemojn, konektos al la konzolo kaj agordos ĝin. Povas labori sur malgrandaj senmovaj retoj.
• ZTP - Zero Touch Provisioning. La aparataro alvenis, ekstaris, ricevis adreson per DHCP, iris al speciala servilo kaj agordis sin.
• La infrastrukturo de konzolserviloj, kie la komenca agordo okazas tra la konzola haveno en aŭtomata reĝimo.

Pri ĉiuj tri ni parolos en aparta artikolo.

Komponanto 5: Vend-agnostika agorda modelo

Ĝis nun, ĉiuj sistemoj estis malsimilaj diakiloj, kiuj provizas variablojn kaj deklaran priskribon de tio, kion ni ŝatus vidi en la reto. Sed baldaŭ aŭ malfrue, vi devos trakti specifaĵojn.
En ĉi tiu etapo, por ĉiu specifa aparato, primitivuloj, servoj kaj variabloj estas kombinitaj en agordan modelon kiu fakte priskribas la kompletan agordon de specifa aparato, nur en vendisto-neŭtrala maniero.
Kion faras ĉi tiu paŝo? Kial ne tuj krei aparaton agordon, kiun vi povas simple alŝuti?
Fakte, ĉi tio solvas tri problemojn:

1. Ne adaptiĝu al specifa interfaco por interagi kun la aparato. Ĉu ĝi estas CLI, NETCONF, RESTCONF, SNMP - la modelo estos la sama.
2. Ne konservu la nombron da ŝablonoj/skriptoj laŭ la nombro da vendistoj en la reto, kaj se la dezajno ŝanĝiĝas, ŝanĝu la samon en pluraj lokoj.
3. Ŝarĝu la agordon de la aparato (rezervo), metu ĝin en precize la saman modelon kaj rekte komparu la celan agordon kun la ekzistanta por kalkuli la delton kaj prepari agordan diakilon, kiu ŝanĝos nur tiujn partojn necesajn aŭ por identigi deviojn.

Kiel rezulto de ĉi tiu etapo, ni akiras vendon-sendependan agordon.

Komponanto 6. Vendisto-specifa ŝoforinterfaco

Vi ne devus flati vin per espero, ke iam eblos agordi ciska ĝuste same kiel Junipero, simple sendante al ili ĝuste la samajn vokojn. Malgraŭ la kreskanta populareco de blankskatoloj kaj la apero de subteno por NETCONF, RESTCONF, OpenConfig, la specifa enhavo kiun ĉi tiuj protokoloj liveras diferencas de vendisto al vendisto, kaj ĉi tiu estas unu el iliaj konkurencivaj diferencoj, kiujn ili ne rezignas tiel facile.
Ĉi tio estas proksimume la sama kiel OpenContrail kaj OpenStack, kiuj havas RestAPI kiel sia NorthBound-interfaco, atendas tute malsamajn vokojn.

Do, en la kvina paŝo, la vendisto-sendependa modelo devas preni la formon en kiu ĝi iros al aparataro.
Kaj ĉi tie ĉiuj rimedoj estas bonaj (ne): CLI, NETCONF, RESTCONF, SNMP simple.

Tial ni bezonos pelilon, kiu transdonos la rezulton de la antaŭa paŝo en la bezonatan formaton de specifa vendisto: aro de CLI-komandoj, XML-strukturo.

Komponanto 7. Mekanismo por liverado de agordo al la aparato

Ni generis la agordon, sed ĝi ankoraŭ devas esti liverita al la aparatoj - kaj, evidente, ne mane.
Unue, ni estas antaŭ la demando, kian transporton ni uzos? Kaj hodiaŭ la elekto ne plu estas malgranda:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST-API
• OpenFlow (kvankam ĝi estas eksterordinara ĉar ĝi estas maniero liveri FIB, ne agordojn)

Ni punktu la t ĉi tie. CLI estas heredaĵo. SNMP... tuso tuso.
RESTCONF ankoraŭ estas nekonata besto; la REST API estas subtenata de preskaŭ neniu. Tial ni koncentriĝos pri NETCONF en la serio.

Fakte, kiel la leganto jam komprenis, ĝis ĉi tiu punkto ni jam decidis pri la interfaco - la rezulto de la antaŭa paŝo jam estas prezentita en la formato de la interfaco, kiu estis elektita.

Dua, kaj per kiuj iloj ni faros tion?
Ankaŭ estas granda elekto ĉi tie:

• Memskribita skripto aŭ platformo. Ni armu nin per ncclient kaj asyncIO kaj faru ĉion mem. Kiom kostas al ni konstrui disfaldan sistemon de nulo?
• Ansible kun ĝia riĉa biblioteko de interkonektaj moduloj.
• Salo kun ĝia magra laboro kun la reto kaj rilato kun Napalm.
• Fakte Napalm, kiu konas kelkajn vendistojn kaj jen, adiaŭ.
• Nornir estas alia besto, kiun ni dissemos en la estonteco.

Ĉi tie la plej ŝatata ankoraŭ ne estas elektita - ni serĉos.

Kio alia estas grava ĉi tie? Konsekvencoj de aplikado de la agordo.
Sukcesa aŭ ne. Ĉu ankoraŭ ekzistas aliro al la aparataro aŭ ne?
Ŝajnas, ke kommit helpos ĉi tie kun konfirmo kaj validigo de tio, kio estis elŝutita al la aparato.
Ĉi tio, kombinita kun la ĝusta efektivigo de NETCONF, signife malvastigas la gamon de taŭgaj aparatoj - ne multaj fabrikantoj subtenas normalajn komitojn. Sed ĉi tio estas nur unu el la antaŭkondiĉoj en RFP. En la fino, neniu maltrankviliĝas, ke neniu rusa vendisto plenumos la 32 * 100GE interfackondiĉon. Aŭ ĉu li maltrankviliĝas?

Komponanto 8. CI/KD

Je ĉi tiu punkto, ni jam havas la agordon preta por ĉiuj retaj aparatoj.
Mi skribas "por ĉio" ĉar ni parolas pri versio de la reto-stato. Kaj eĉ se vi bezonas ŝanĝi la agordojn de nur unu ŝaltilo, ŝanĝoj estas kalkulitaj por la tuta reto. Evidente, ili povas esti nul por plej multaj nodoj.

Sed, kiel jam dirite supre, ni ne estas iaj barbaroj, kiuj volas ĉion ruliĝi rekte en produktadon.
La generita agordo unue devas trairi Pipeline CI/CD.

CI/CD signifas Continuous Integration, Continuous Deployment. Ĉi tio estas aliro en kiu la teamo ne nur eldonas novan gravan eldonon ĉiujn ses monatojn, tute anstataŭigante la malnovan, sed regule pliige efektivigas (Deplojo) novajn funkciojn en malgrandaj partoj, ĉiu el kiuj estas amplekse provita por kongruo, sekureco kaj rendimento (Integriĝo).

Por fari tion, ni havas version-kontrolan sistemon, kiu kontrolas agordajn ŝanĝojn, laboratorion, kiu kontrolas ĉu la klienta servo estas rompita, monitoran sistemon, kiu kontrolas ĉi tiun fakton, kaj la lasta paŝo estas efektivigi ŝanĝojn al la produktada reto.

Escepte de sencimigaj komandoj, absolute ĉiuj ŝanĝoj en la reto devas trairi la CI/CD Pipeline - ĉi tio estas nia garantio de trankvila vivo kaj longa, feliĉa kariero.

Komponanto 9. Rezerva kaj detekta sistemo de anomalioj

Nu, ne necesas denove paroli pri sekurkopioj.
Ni simple aldonos ilin al la krono aŭ al la fakto de agorda ŝanĝo en git.

Sed la dua parto estas pli interesa - iu devus observi tiujn sekurkopiojn. Kaj en iuj kazoj, ĉi tiu iu devas iri kaj turni ĉion kiel ĝi estis, kaj en aliaj, miaŭi al iu, ke io estas malĝusta.
Ekzemple, se aperis nova uzanto, kiu ne estas registrita en la variabloj, vi devas forigi lin for de la hako. Kaj se estas pli bone ne tuŝi novan regulon de fajroŝirmilo, eble iu ĵus ŝaltis sencimigon, aŭ eble la nova servo, fuŝulo, ne estis registrita laŭ la regularo, sed homoj jam aliĝis al ĝi.

Ni ankoraŭ ne eskapos iun malgrandan delton en la skalo de la tuta reto, malgraŭ iuj aŭtomatigaj sistemoj kaj la ŝtala mano de administrado. Por sencimigi problemojn, neniu aldonos agordon al la sistemoj ĉiukaze. Krome, ili eble eĉ ne estas inkluditaj en la agorda modelo.

Ekzemple, regulo de fajroŝirmilo por kalkuli la nombron da pakaĵoj per specifa IP por lokalizi problemon estas tute ordinara provizora agordo.

Komponanto 10. Monitorsistemo

Komence mi ne intencis pritrakti la temon pri monitorado - ĝi ankoraŭ estas volumena, polemika kaj kompleksa temo. Sed dum la aferoj progresis, montriĝis, ke tio estas integra parto de aŭtomatigo. Kaj estas neeble preteriri ĝin, eĉ sen praktiko.

Evoluanta Penso estas organika parto de la CI/CD-procezo. Post lanĉo de la agordo al la reto, ni devas povi determini ĉu ĉio estas en ordo kun ĝi nun.
Kaj ni parolas ne nur kaj ne tiom pri interfaco-uzadohoraroj aŭ noda havebleco, sed pri pli subtilaj aferoj - la ĉeesto de la necesaj itineroj, atributoj sur ili, la nombro da BGP-sesioj, OSPF-najbaroj, End-to-End-agado. de supraj servoj.
Ĉu la sislogs al la ekstera servilo ĉesis aldoniĝi, aŭ ĉu la SFlow-agento malfunkciis, aŭ ĉu la gutoj en la vicoj komencis kreski, aŭ ĉu la konektebleco inter iu paro da prefiksoj rompiĝis?

Pri tio ni pripensos en aparta artikolo.

konkludo

Kiel bazo, mi elektis unu el la modernaj datumcentraj retodezajnoj - L3 Clos Fabric kun BGP kiel la enruta protokolo.
Ĉi-foje ni konstruos la reton sur Juniper, ĉar nun la interfaco de JunOs estas vanlove.

Ni malfaciligu nian vivon uzante nur Malfermfontajn ilojn kaj plurvendan reton - do krom Juniper, mi elektos unu plian bonŝancan personon survoje.

La plano por venontaj publikaĵoj estas io kiel ĉi tio:
Unue mi parolos pri virtualaj retoj. Unue, ĉar mi volas, kaj due, ĉar sen ĉi tio, la dezajno de la infrastruktura reto ne estos tre klara.
Poste pri la reto-dezajno mem: topologio, vojigo, politikoj.
Ni kunvenu laboratoriostandon.
Ni pensu pri tio kaj eble praktiku pravalorigon de la aparato en la reto.
Kaj tiam pri ĉiu komponanto en intima detalo.

Kaj jes, mi ne promesas gracie fini ĉi tiun ciklon per preta solvo. 🙂

utilaj ligoj

• Antaŭ ol enprofundiĝi en la serion, indas legi la libron de Nataŝa Samoilenko Python por Retaj Inĝenieroj. Kaj eble pasu la kurso.
• Ankaŭ estos utile legi RFC pri la dezajno de datumcentraj fabrikoj de Fejsbuko de Peter Lapukhov.
• La arkitektura dokumentaro donos al vi ideon pri kiel funkcias Overlay SDN. Tungsteno Ŝtofo (antaŭe Open Contrail).

Dankon

Roman Gorĝo. Por komentoj kaj redaktoj.
Artjom Ĉernobajo. Por KDPV.

fonto: www.habr.com