SDSM is verby, maar die onbeheerbare begeerte om te skryf bly.

Ons broer het vir baie jare gely as gevolg van roetinewerk, sy vingers kruis voordat hy pleeg en gebrek aan slaap as gevolg van nagtelike terugdraaie.
Maar die donker tye kom tot 'n einde.

Met hierdie artikel sal ek 'n reeks begin oor hoe vir my outomatisering gesien word.
Langs die pad sal ons die stadiums van outomatisering, die stoor van veranderlikes, die formalisering van ontwerp, RestAPI, NETCONF, YANG, YDK verstaan ​​en ons sal baie programmering doen.
My beteken dat a) dit nie 'n objektiewe waarheid is nie, b) dit nie onvoorwaardelik die beste benadering is nie, c) my mening, selfs tydens die beweging van die eerste na die laaste artikel, kan verander - om eerlik te wees, van die konsepfase tot publikasie, ek het alles heeltemal twee keer herskryf.

inhoud

1. Doelwitte
   1. Die netwerk is soos 'n enkele organisme
   2. Konfigurasie toets
   3. Weergawe
   4. Monitering en selfgenesing van dienste

2. fondse
   1. Voorraadstelsel
   2. IP-ruimtebestuurstelsel
   3. Netwerkdiensbeskrywingstelsel
   4. Toestel inisialisering meganisme
   5. Verkoper-agnostiese konfigurasiemodel
   6. Verkoper-spesifieke bestuurder-koppelvlak
   7. Meganisme vir die lewering van konfigurasie aan die toestel
   8. CI / CD
   9. Meganisme vir rugsteun en soek na afwykings
   10. Moniteringstelsel

3. Gevolgtrekking

Ek sal probeer om ADSM uit te voer in 'n formaat wat effens anders is as SDSM. Groot, gedetailleerde, genommerde artikels sal voortgaan om te verskyn, en tussen hulle sal ek klein notas uit alledaagse ervaring publiseer. Ek sal probeer om perfeksionisme hier te beveg en nie elkeen van hulle te lek nie.

Hoe snaaks is dit dat jy die tweede keer deur dieselfde pad moet gaan.

Ek moes eers self artikels oor netwerke skryf weens die feit dat dit nie op die RuNet was nie.

Nou kon ek nie 'n omvattende dokument vind wat benaderings tot outomatisering sou sistematiseer en die bogenoemde tegnologieë sou ontleed deur eenvoudige praktiese voorbeelde te gebruik nie.

Ek kan verkeerd wees, so verskaf asseblief skakels na nuttige hulpbronne. Dit sal egter nie my vasberadenheid om te skryf verander nie, want die hoofdoel is om self iets te leer, en om die lewe vir ander makliker te maak, is 'n aangename bonus wat die gene streel om ervaring te deel.

Ons sal probeer om 'n mediumgrootte LAN DC-datasentrum te neem en die hele outomatiseringskema uit te werk.
Ek sal 'n paar dinge amper vir die eerste keer saam met jou doen.

Ek sal nie oorspronklik wees in die idees en gereedskap wat hier beskryf word nie. Dmitry Figol het 'n uitstekende kanaal met strome oor hierdie onderwerp.
Die artikels sal in baie aspekte daarmee oorvleuel.

Die LAN DC het 4 DC's, ongeveer 250 skakelaars, 'n halfdosyn routers en 'n paar firewalls.
Nie Facebook nie, maar genoeg om jou diep te laat dink oor outomatisering.
Daar is egter 'n mening dat as jy meer as 1 toestel het, outomatisering reeds nodig is.
Trouens, dit is moeilik om te dink dat enigiemand nou sonder ten minste 'n pak knie-skrifte kan lewe.
Alhoewel ek gehoor het dat daar kantore is waar IP-adresse in Excel gehou word, en elkeen van die duisende netwerktoestelle is met die hand gekonfigureer en het sy eie unieke konfigurasie. Dit kan natuurlik as moderne kuns deurgegee word, maar die ingenieur se gevoelens sal beslis aanstoot neem.

Doelwitte

Nou sal ons die mees abstrakte doelwitte stel:

• Die netwerk is soos 'n enkele organisme
• Konfigurasie toets
• Netwerkstaatweergawe
• Monitering en selfgenesing van dienste

Later in hierdie artikel sal ons kyk na watter middele ons sal gebruik, en in die volgende sal ons kyk na die doelwitte en middele in detail.

Die netwerk is soos 'n enkele organisme

Die bepalende frase van die reeks, hoewel dit met die eerste oogopslag dalk nie so betekenisvol lyk nie: ons sal die netwerk opstel, nie individuele toestelle nie.
In onlangse jare het ons 'n klemverskuiwing gesien om die netwerk as 'n enkele entiteit te behandel, vandaar die Sagteware gedefinieerde Networking, Opsetgedrewe netwerke и Outonome netwerke.
Na alles, wat het toepassings wêreldwyd van die netwerk nodig: konneksie tussen punte A en B (wel, soms +B-Z) en isolasie van ander toepassings en gebruikers.

En so is ons taak in hierdie reeks bou 'n stelsel, die huidige konfigurasie in stand te hou die hele netwerk, wat reeds in die werklike konfigurasie op elke toestel ontbind is in ooreenstemming met sy rol en ligging.
System netwerkbestuur impliseer dat ons dit kontak om veranderinge aan te bring, en dit bereken op sy beurt die verlangde toestand vir elke toestel en konfigureer dit.
Op hierdie manier verminder ons handmatige toegang tot die CLI tot byna nul - enige veranderinge in toestelinstellings of netwerkontwerp moet geformaliseer en gedokumenteer word - en eers dan na die nodige netwerkelemente uitgerol word.

Dit is, byvoorbeeld, as ons besluit dat van nou af rekskakelaars in Kazan twee netwerke in plaas van een moet aankondig, sal ons

1. Eerstens dokumenteer ons veranderinge in stelsels
2. Genereer die teikenkonfigurasie van alle netwerktoestelle
3. Ons begin die netwerkkonfigurasie-opdateringsprogram, wat bereken wat op elke nodus verwyder moet word, wat om by te voeg, en die nodusse na die verlangde toestand bring.

Terselfdertyd maak ons ​​veranderinge met die hand slegs in die eerste stap.

Konfigurasie toets

Bekenddat 80% van probleme tydens konfigurasieveranderinge voorkom - indirekte bewys hiervan is dat tydens die Nuwejaarsvakansies alles gewoonlik rustig is.
Ek het persoonlik dosyne wêreldwye stilstand aanskou as gevolg van menslike foute: die verkeerde opdrag, die konfigurasie is in die verkeerde tak uitgevoer, die gemeenskap het vergeet, MPLS is wêreldwyd op die router afgebreek, vyf stukke hardeware is opgestel, maar die fout was nie opgemerk op die sesde, ou veranderinge wat deur 'n ander persoon gemaak is, is gepleeg. Daar is 'n ton van scenario's.

Outomatisering sal ons toelaat om minder foute te maak, maar op 'n groter skaal. Op hierdie manier kan jy nie net een toestel bak nie, maar die hele netwerk op een slag.

Van ouds af het ons oupas die korrektheid van die veranderinge wat gemaak is, met 'n skerp oog, balle staal en die funksionaliteit van die netwerk nagegaan nadat dit uitgerol is.
Daardie oupas wie se werk tot stilstand en katastrofiese verliese gelei het, het minder nageslag gelaat en behoort mettertyd uit te sterf, maar evolusie is 'n stadige proses, en daarom toets almal nog nie eers veranderinge in die laboratorium nie.
Aan die voorpunt van vordering is egter diegene wat die proses van toetsing van die konfigurasie en die verdere toepassing daarvan op die netwerk geoutomatiseer het. Met ander woorde, ek het die CI/CD-prosedure geleen (Deurlopende integrasie, deurlopende ontplooiing) van die ontwikkelaars.
In een van die dele sal ons kyk hoe om dit te implementeer met behulp van 'n weergawebeheerstelsel, waarskynlik Github.

Sodra jy gewoond geraak het aan die idee van netwerk CI/CD, sal die metode om 'n konfigurasie te kontroleer deur dit op 'n produksienetwerk toe te pas, oornag na vroeë Middeleeuse onkunde lyk. Soort soos om 'n plofkop met 'n hamer te slaan.

N organiese voortsetting van idees oor stelsel netwerkbestuur en CI/CD word 'n volledige weergawe van die konfigurasie.

Weergawe

Ons sal aanvaar dat met enige veranderinge, selfs die kleinste, selfs op een onopvallende toestel, die hele netwerk van een staat na 'n ander beweeg.
En ons voer altyd nie 'n opdrag op die toestel uit nie, ons verander die toestand van die netwerk.
So kom ons noem hierdie state weergawes?

Kom ons sê die huidige weergawe is 1.0.0.
Het die IP-adres van die Loopback-koppelvlak op een van die ToR's verander? Dit is 'n minderjarige weergawe en sal 1.0.1 genommer word.
Ons het die beleide vir die invoer van roetes na BGP hersien - 'n bietjie ernstiger - reeds 1.1.0
Ons het besluit om van IGP ontslae te raak en slegs na BGP oor te skakel - dit is reeds 'n radikale ontwerpverandering - 2.0.0.

Terselfdertyd kan verskillende DC's verskillende weergawes hê - die netwerk ontwikkel, nuwe toerusting word geïnstalleer, nuwe vlakke van stekels word iewers bygevoeg, nie in ander nie, ens.

op semantiese weergawe ons sal in 'n aparte artikel praat.

Ek herhaal - enige verandering (behalwe vir ontfoutingsopdragte) is 'n weergawe-opdatering. Administrateurs moet in kennis gestel word van enige afwykings van die huidige weergawe.

Dieselfde geld vir die terugrol van veranderinge - dit is nie die kanselleer van die laaste opdragte nie, dit is nie 'n terugrol deur die toestel se bedryfstelsel te gebruik nie - dit bring die hele netwerk na 'n nuwe (ou) weergawe.

Monitering en selfgenesing van dienste

Hierdie vanselfsprekende taak het 'n nuwe vlak in moderne netwerke bereik.
Dikwels volg groot diensverskaffers die benadering dat 'n mislukte diens baie vinnig reggemaak moet word en 'n nuwe een opgewek moet word, in plaas daarvan om uit te vind wat gebeur het.
“Baie” beteken dat jy aan alle kante mildelik bedek moet word met monitering, wat binne sekondes die geringste afwykings van die norm sal opspoor.
En hier is die gewone maatstawwe, soos koppelvlaklaai of nodusbeskikbaarheid, nie meer genoeg nie. Handmatige monitering van hulle deur die diensbeampte is ook nie genoeg nie.
Vir baie dinge moet daar wees Selfgenesing — die moniteringsligte het rooi geword en ons het die plantain self gaan aansit waar dit seergekry het.

En hier monitor ons ook nie net individuele toestelle nie, maar ook die gesondheid van die hele netwerk, beide whitebox, wat relatief verstaanbaar is, en blackbox, wat meer ingewikkeld is.

Wat sal ons nodig hê om sulke ambisieuse planne te implementeer?

• Het 'n lys van alle toestelle op die netwerk, hul ligging, rolle, modelle, sagteware weergawes.
  kazan-leaf-1.lmu.net, Kazan, blaar, Juniper QFX 5120, R18.3.
• Het 'n stelsel om netwerkdienste te beskryf.
  IGP, BGP, L2/3VPN, Beleid, ACL, NTP, SSH.
• In staat wees om die toestel te inisialiseer.
  Gasheernaam, Mgmt IP, Mgmt Route, Gebruikers, RSA-sleutels, LLDP, NETCONF
• Stel die toestel op en bring die konfigurasie na die verlangde (insluitend ou) weergawe.
• Toets konfigurasie
• Kontroleer gereeld die status van alle toestelle vir afwykings van die huidige en rapporteer aan wie dit moet wees.
  Oornag het iemand stilweg 'n reël by die ACL gevoeg.
• Monitor prestasie.

fondse

Dit klink ingewikkeld genoeg om die projek in komponente te begin ontbind.

En daar sal tien van hulle wees:

1. Voorraadstelsel
2. IP-ruimtebestuurstelsel
3. Netwerkdiensbeskrywingstelsel
4. Toestel inisialisering meganisme
5. Verkoper-agnostiese konfigurasiemodel
6. Verkoper-spesifieke bestuurder-koppelvlak
7. Meganisme vir die lewering van konfigurasie aan die toestel
8. CI / CD
9. Meganisme vir rugsteun en soek na afwykings
10. Moniteringstelsel

Dit is terloops 'n voorbeeld van hoe die siening oor die doelwitte van die siklus verander het - daar was 4 komponente in die konsep.

In die illustrasie het ek al die komponente en die toestel self uitgebeeld.
Snyende komponente is in wisselwerking met mekaar.
Hoe groter die blok, hoe meer aandag moet aan hierdie komponent gegee word.

Komponent 1: Voorraadstelsel

Uiteraard wil ons weet watter toerusting waar geleë is, waaraan gekoppel is.
Die voorraadstelsel is 'n integrale deel van enige onderneming.
Dikwels het 'n onderneming 'n aparte voorraadstelsel vir netwerktoestelle, wat meer spesifieke probleme oplos.
As deel van hierdie reeks artikels sal ons dit DCIM - Data Centre Infrastructure Management noem. Alhoewel die term DCIM self, streng gesproke, baie meer insluit.

Vir ons doeleindes sal ons die volgende inligting oor die toestel daarin stoor:

• Inventaris nommer
• Titel/beskrywing
• Model (Huawei CE12800, Juniper QFX5120, ens.)
• Kenmerkende parameters (borde, koppelvlakke, ens.)
• Rol (Blaar, Ruggraat, Border Router, ens.)
• Ligging (streek, stad, datasentrum, rek, eenheid)
• Interverbindings tussen toestelle
• Netwerktopologie

Dit is heeltemal duidelik dat ons dit alles self wil weet.
Maar sal dit help vir outomatiseringsdoeleindes?
Ongetwyfeld.
Byvoorbeeld, ons weet dat in 'n gegewe datasentrum op Leaf-skakelaars, as dit Huawei is, ACL's om sekere verkeer te filter op die VLAN toegepas moet word, en as dit Juniper is, dan op eenheid 0 van die fisiese koppelvlak.
Of jy moet 'n nuwe Syslog-bediener na alle grense in die streek uitrol.

Daarin sal ons virtuele netwerktoestelle stoor, byvoorbeeld virtuele routers of wortelreflektors. Ons kan DNS-bedieners, NTP, Syslog en in die algemeen alles wat op een of ander manier met die netwerk verband hou, byvoeg.

Komponent 2: IP-ruimtebestuurstelsel

Ja, en deesdae is daar spanne mense wat tred hou met voorvoegsels en IP-adresse in 'n Excel-lêer. Maar die moderne benadering is steeds 'n databasis, met 'n front-end op nginx/apache, API en uitgebreide funksies vir die opneem van IP-adresse en netwerke wat in VRF's verdeel is.
IPAM - IP-adresbestuur.

Vir ons doeleindes sal ons die volgende inligting daarin stoor:

• VLAN's
• VRF
• Netwerke/Subnette
• IP-adresse
• Bind adresse aan toestelle, netwerke aan liggings en VLAN-nommers

Weereens, dit is duidelik dat ons wil seker maak dat wanneer ons 'n nuwe IP-adres vir die ToR-lusback toeken, ons nie sal struikel oor die feit dat dit reeds aan iemand toegewys is nie. Of dat ons dieselfde voorvoegsel twee keer op verskillende punte van die netwerk gebruik het.
Maar hoe help dit met outomatisering?
Maklik.
Ons versoek 'n voorvoegsel in die stelsel met die Loopbacks-rol, wat IP-adresse bevat wat beskikbaar is vir toekenning - as dit gevind word, ken ons die adres toe, indien nie, versoek ons ​​die skepping van 'n nuwe voorvoegsel.
Of wanneer ons 'n toestelkonfigurasie skep, kan ons uit dieselfde stelsel uitvind waarin die VRF die koppelvlak moet wees.
En wanneer 'n nuwe bediener begin word, meld die skrif by die stelsel aan, vind uit in watter skakelaar die bediener is, watter poort en watter subnet aan die koppelvlak toegewys is - en sal die bedieneradres daarvan toeken.

Dit dui op 'n begeerte om DCIM en IPAM in een stelsel te kombineer om nie funksies te dupliseer en nie twee soortgelyke entiteite te bedien nie.
Dit is wat ons sal doen.

Komponent 3. Stelsel vir die beskrywing van netwerkdienste

As die eerste twee stelsels veranderlikes stoor wat nog op een of ander manier gebruik moet word, dan beskryf die derde vir elke toestelrol hoe dit gekonfigureer moet word.
Dit is die moeite werd om twee verskillende tipes netwerkdienste te onderskei:

• Infrastruktuur
• Kliënt.

Eersgenoemde is ontwerp om basiese konnektiwiteit en toestelbeheer te verskaf. Dit sluit in VTY, SNMP, NTP, Syslog, AAA, roeteringsprotokolle, CoPP, ens.
Laasgenoemde organiseer die diens vir die kliënt: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, ens.
Natuurlik is daar ook grensgevalle - waar om MPLS LDP, BGP in te sluit? Ja, en roeteerprotokolle kan vir kliënte gebruik word. Maar dit is nie belangrik nie.

Beide tipes dienste word ontbind in konfigurasie-primitiewe:

• fisiese en logiese koppelvlakke (tag/anteg, mtu)
• IP-adresse en VRF's (IP, IPv6, VRF)
• ACL's en verkeersverwerkingsbeleide
• Protokolle (IGP, BGP, MPLS)
• Roeteringsbeleide (voorvoegsellyste, gemeenskappe, ASN-filters).
• Nutsdienste (SSH, NTP, LLDP, Syslog...)
• Ens.

Hoe presies ons dit gaan doen, het ek nog geen idee nie. Ons sal in 'n aparte artikel daarna kyk.

As 'n bietjie nader aan die lewe, dan kan ons dit beskryf
Die Leaf-skakelaar moet BGP-sessies hê met alle gekoppelde Spine-skakelaars, gekoppelde netwerke in die proses invoer, en slegs netwerke vanaf 'n sekere voorvoegsel vanaf Spine-skakelaars aanvaar. Beperk CoPP IPv6 ND tot 10 pps, ens.
Op hul beurt hou stekels sessies met alle gekoppelde leidings, wat as wortelreflektors optree, en aanvaar van hulle slegs roetes van 'n sekere lengte en met 'n sekere gemeenskap.

Komponent 4: Toestelinisialiseringsmeganisme

Onder hierdie opskrif kombineer ek baie van die aksies wat moet plaasvind sodat 'n toestel op radar kan verskyn en op afstand verkry kan word.

1. Voer die toestel in die voorraadstelsel in.
2. Kies 'n bestuurs-IP-adres.
3. Stel basiese toegang daartoe op:
   Gasheernaam, bestuurs-IP-adres, roete na die bestuursnetwerk, gebruikers, SSH-sleutels, protokolle - telnet/SSH/NETCONF

Daar is drie benaderings:

• Alles is heeltemal handmatig. Die toestel word na die staanplek gebring, waar 'n gewone organiese persoon dit in die stelsels sal inskryf, aan die konsole sal koppel en dit instel. Kan op klein statiese netwerke werk.
• ZTP - Zero Touch-voorsiening. Die hardeware het opgedaag, opgestaan, 'n adres via DHCP ontvang, na 'n spesiale bediener gegaan en homself gekonfigureer.
• Die infrastruktuur van konsolebedieners, waar die aanvanklike konfigurasie deur die konsolepoort in outomatiese modus plaasvind.

Ons sal oor al drie in 'n aparte artikel praat.

Komponent 5: Verkoper-agnostiese konfigurasiemodel

Tot nou toe was alle stelsels uiteenlopende kolle wat veranderlikes en 'n verklarende beskrywing verskaf van wat ons graag op die netwerk wil sien. Maar vroeër of later sal jy met besonderhede te doen kry.
Op hierdie stadium, vir elke spesifieke toestel, word primitiewe, dienste en veranderlikes gekombineer in 'n konfigurasiemodel wat eintlik die volledige konfigurasie van 'n spesifieke toestel beskryf, slegs op 'n verkoper-neutrale wyse.
Wat doen hierdie stap? Hoekom skep jy nie dadelik 'n toestelkonfigurasie wat jy eenvoudig kan oplaai nie?
Trouens, dit los drie probleme op:

1. Moenie aanpas by 'n spesifieke koppelvlak vir interaksie met die toestel nie. Of dit nou CLI, NETCONF, RESTCONF, SNMP is - die model sal dieselfde wees.
2. Moenie die aantal sjablone/skrifte volgens die aantal verskaffers op die netwerk hou nie, en as die ontwerp verander, verander dieselfde ding op verskeie plekke.
3. Laai die konfigurasie vanaf die toestel (rugsteun), plaas dit in presies dieselfde model en vergelyk die teikenkonfigurasie direk met die bestaande een om die delta te bereken en 'n konfigurasiepleister voor te berei wat slegs die dele wat nodig is sal verander of om afwykings te identifiseer.

As gevolg van hierdie stadium kry ons 'n verskaffer-onafhanklike konfigurasie.

Komponent 6. Verkoper-spesifieke bestuurder-koppelvlak

Jy moenie jouself vlei met die hoop dat dit eendag moontlik sal wees om 'n ciska op presies dieselfde manier as 'n Juniper te konfigureer nie, bloot deur presies dieselfde oproepe na hulle te stuur. Ten spyte van die groeiende gewildheid van witkassies en die opkoms van ondersteuning vir NETCONF, RESTCONF, OpenConfig, verskil die spesifieke inhoud wat hierdie protokolle lewer van verkoper tot verkoper, en dit is een van hul mededingende verskille wat hulle nie so maklik sal prysgee nie.
Dit is ongeveer dieselfde as OpenContrail en OpenStack, wat RestAPI as hul NorthBound-koppelvlak het, verwag heeltemal ander oproepe.

Dus, in die vyfde stap, moet die verkoper-onafhanklike model die vorm aanneem waarin dit na hardeware gaan.
En hier is al die middele goed (nie): CLI, NETCONF, RESTCONF, SNMP eenvoudig.

Daarom sal ons 'n bestuurder nodig hê wat die resultaat van die vorige stap sal oordra na die vereiste formaat van 'n spesifieke verskaffer: 'n stel CLI-opdragte, 'n XML-struktuur.

Komponent 7. Meganisme vir die lewering van konfigurasie aan die toestel

Ons het die konfigurasie gegenereer, maar dit moet steeds by die toestelle afgelewer word - en natuurlik nie met die hand nie.
Eerstens, word ons gekonfronteer met die vraag watter vervoer ons sal gebruik? En vandag is die keuse nie meer klein nie:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (alhoewel dit 'n uitskieter is omdat dit 'n manier is om FIB te lewer, nie instellings nie)

Kom ons stip die t's hier. CLI is nalatenskap. SNMP... hoes hoes.
RESTCONF is steeds 'n onbekende dier; die REST API word deur byna niemand ondersteun nie. Daarom sal ons fokus op NETCONF in die reeks.

Trouens, soos die leser reeds verstaan ​​het, het ons op hierdie stadium reeds op die koppelvlak besluit - die resultaat van die vorige stap word reeds aangebied in die formaat van die koppelvlak wat gekies is.

Tweedens, en met watter gereedskap sal ons dit doen?
Hier is ook 'n groot keuse:

• Selfgeskrewe draaiboek of platform. Kom ons bewapen ons met nclient en asincIO en doen alles self. Wat kos dit ons om 'n ontplooiingstelsel van nuuts af te bou?
• Ansible met sy ryk biblioteek van netwerkmodules.
• Sout met sy karige werk met die netwerk en verbinding met Napalm.
• Eintlik Napalm, wat 'n paar verkopers ken en dit is dit, totsiens.
• Nornir is nog 'n dier wat ons in die toekoms sal dissekteer.

Hier is die gunsteling nog nie gekies nie - ons sal soek.

Wat is nog belangrik hier? Gevolge van die toepassing van die konfigurasie.
Suksesvol of nie. Is daar nog toegang tot die hardeware of nie?
Dit blyk dat commit hier sal help met bevestiging en validering van wat na die toestel afgelaai is.
Dit, gekombineer met die korrekte implementering van NETCONF, verklein die reeks geskikte toestelle aansienlik – nie baie vervaardigers ondersteun normale commits nie. Maar dit is net een van die voorvereistes in RFP. Op die ou end is niemand bekommerd dat nie 'n enkele Russiese verkoper aan die 32*100GE-koppelvlakvoorwaarde sal voldoen nie. Of is hy bekommerd?

Komponent 8. CI/CD

Op hierdie stadium het ons reeds die konfigurasie gereed vir alle netwerktoestelle.
Ek skryf "vir alles" omdat ons praat oor weergawe van die netwerkstatus. En selfs al moet jy die instellings van net een skakelaar verander, word veranderinge vir die hele netwerk bereken. Dit is duidelik dat hulle nul kan wees vir die meeste nodusse.

Maar, soos reeds hierbo gesê is, is ons nie 'n soort barbare wat alles reguit in produksie wil rol nie.
Die gegenereerde konfigurasie moet eers deur Pipeline CI/CD gaan.

CI/CD staan ​​vir Continuous Integration, Continuous Deployment. Dit is 'n benadering waarin die span nie net elke ses maande 'n nuwe groot vrystelling uitbring wat die ou een heeltemal vervang nie, maar gereeld inkrementeel (Ontplooiing) nuwe funksionaliteit in klein porsies bekendstel, wat elkeen omvattend getoets word vir versoenbaarheid, sekuriteit en prestasie (Integrasie).

Om dit te doen, het ons 'n weergawebeheerstelsel wat konfigurasieveranderinge moniteer, 'n laboratorium wat kontroleer of die kliëntdiens stukkend is, 'n moniteringstelsel wat hierdie feit kontroleer, en die laaste stap is om veranderinge aan die produksienetwerk uit te voer.

Met die uitsondering van ontfoutingsopdragte, moet absoluut alle veranderinge op die netwerk deur die CI/CD-pyplyn gaan - dit is ons waarborg van 'n stil lewe en 'n lang, gelukkige loopbaan.

Komponent 9. Rugsteun- en anomalie-opsporingstelsel

Wel, dit is nie nodig om weer oor rugsteun te praat nie.
Ons sal hulle eenvoudig in git plaas volgens die kroon of op die feit van 'n konfigurasieverandering.

Maar die tweede deel is interessanter – iemand moet hierdie rugsteun dophou. En in sommige gevalle moet hierdie iemand alles gaan omdraai soos dit was, en in ander vir iemand miaau dat iets fout is.
Byvoorbeeld, as 'n nuwe gebruiker verskyn het wat nie in die veranderlikes geregistreer is nie, moet jy hom weg van die hack verwyder. En as dit beter is om nie aan 'n nuwe firewall-reël te raak nie, het iemand dalk net ontfouting aangeskakel, of dalk is die nuwe diens, 'n bungler, nie volgens die regulasies geregistreer nie, maar mense het reeds daarby aangesluit.

Ons sal steeds nie 'n klein delta op die skaal van die hele netwerk vryspring nie, ten spyte van enige outomatiseringstelsels en die saai hand van bestuur. Om probleme te ontfout, sal niemand in elk geval konfigurasie by die stelsels voeg nie. Boonop is hulle dalk nie eens by die konfigurasiemodel ingesluit nie.

Byvoorbeeld, 'n brandmuurreël vir die tel van die aantal pakkies per spesifieke IP om 'n probleem te lokaliseer, is 'n heeltemal gewone tydelike konfigurasie.

Komponent 10. Moniteringstelsel

Ek was eers nie van plan om die onderwerp van monitering te dek nie – dit is steeds ’n lywige, omstrede en komplekse onderwerp. Maar soos dinge gevorder het, het dit geblyk dat dit 'n integrale deel van outomatisering was. En dit is onmoontlik om dit te omseil, selfs sonder oefening.

Evolving Thought is 'n organiese deel van die CI/CD-proses. Nadat ons die konfigurasie na die netwerk uitgerol het, moet ons kan bepaal of alles nou reg is daarmee.
En ons praat nie net en nie soseer oor koppelvlakgebruikskedules of nodus beskikbaarheid nie, maar oor meer subtiele dinge - die teenwoordigheid van die nodige roetes, eienskappe daarop, die aantal BGP-sessies, OSPF bure, End-to-End prestasie van oorliggende dienste.
Het die syslogs na die eksterne bediener opgehou om op te tel, of het die SFlow-agent gebreek, of het die druppels in die rye begin groei, of het die konneksie tussen een of ander paar voorvoegsels gebreek?

Ons sal in 'n aparte artikel hieroor besin.

Gevolgtrekking

As basis het ek een van die moderne datasentrumnetwerkontwerpe gekies - L3 Clos Fabric met BGP as die roeteprotokol.
Hierdie keer sal ons die netwerk op Juniper bou, want nou is die JunOs-koppelvlak 'n vanlove.

Kom ons maak ons ​​lewe moeiliker deur slegs Open Source-nutsgoed en 'n multi-verskaffer-netwerk te gebruik - so benewens Juniper, sal ek nog een gelukkige persoon langs die pad kies.

Die plan vir komende publikasies is iets soos volg:
Eerstens sal ek praat oor virtuele netwerke. Eerstens, omdat ek wil, en tweedens, want daarsonder sal die ontwerp van die infrastruktuurnetwerk nie baie duidelik wees nie.
Dan oor die netwerkontwerp self: topologie, roetering, beleide.
Kom ons stel 'n laboratoriumstaander bymekaar.
Kom ons dink daaroor en oefen dalk om die toestel op die netwerk te inisialiseer.
En dan oor elke komponent in intieme besonderhede.

En ja, ek belowe nie om hierdie siklus grasieus af te sluit met 'n klaargemaakte oplossing nie. 🙂

nuttige skakels

• Voordat jy in die reeks delf, is dit die moeite werd om Natasha Samoilenko se boek te lees Python vir netwerkingenieurs. En dalk slaag natuurlik.
• Dit sal ook nuttig wees om te lees RFC oor die ontwerp van datasentrumfabrieke van Facebook deur Peter Lapukhov.
• Die argitektuurdokumentasie sal jou 'n idee gee van hoe Overlay SDN werk. Wolfram stof (voorheen Open Contrail).

Dankie

Romeinse kloof. Vir kommentaar en wysigings.
Artyom Chernobay. Vir KDPV.

Bron: will.com