SDSM er over, men den ukontrollerbare skrivelysten består.

I mange år led broren vår av å gjøre rutinearbeid, krysse fingrene før han forpliktet seg og mangel på søvn på grunn av nattlige tilbakeføringer.
Men de mørke tidene går mot slutten.

Med denne artikkelen vil jeg starte en serie om hvordan meg automatisering sees.
Underveis vil vi forstå stadiene med automatisering, lagring av variabler, formalisering av design, RestAPI, NETCONF, YANG, YDK og vi vil gjøre mye programmering.
Me betyr at a) det ikke er en objektiv sannhet, b) det er ikke ubetinget den beste tilnærmingen, c) min mening, selv under bevegelsen fra den første til den siste artikkelen, kan endre seg - for å være ærlig, fra utkaststadiet til publisering, jeg skrev om alt fullstendig to ganger.

Innhold

1. mål
   1. Nettverket er som en enkelt organisme
   2. Konfigurasjonstesting
   3. Versjonskontroll
   4. Overvåking og selvhelbredelse av tjenester

2. midler
   1. Inventarsystem
   2. IP plass administrasjonssystem
   3. System for beskrivelse av nettverkstjenester
   4. Enhetsinitieringsmekanisme
   5. Leverandør-agnostisk konfigurasjonsmodell
   6. Leverandørspesifikt drivergrensesnitt
   7. Mekanisme for å levere konfigurasjon til enheten
   8. CI / CD
   9. Mekanisme for backup og søk etter avvik
   10. Overvåkningsstystem

3. Konklusjon

Jeg vil prøve å gjennomføre ADSM i et format som er litt annerledes enn SDSM. Store, detaljerte, nummererte artikler vil fortsette å dukke opp, og mellom dem vil jeg publisere små notater fra hverdagserfaring. Jeg skal prøve å bekjempe perfeksjonisme her og ikke slikke hver og en av dem.

Så morsomt det er at andre gang må du gå gjennom samme vei.

Først måtte jeg selv skrive artikler om nettverk på grunn av at de ikke var på RuNet.

Nå kunne jeg ikke finne et omfattende dokument som ville systematisere tilnærminger til automatisering og analysere de ovennevnte teknologiene ved å bruke enkle praktiske eksempler.

Jeg kan ta feil, så vennligst oppgi lenker til nyttige ressurser. Dette vil imidlertid ikke endre min vilje til å skrive, for hovedmålet er å lære noe selv, og å gjøre livet lettere for andre er en hyggelig bonus som kjærtegner genet for erfaringsdeling.

Vi vil prøve å ta et mellomstort LAN DC-datasenter og utarbeide hele automatiseringsopplegget.
Jeg skal gjøre noen ting nesten for første gang med deg.

Jeg vil ikke være original i ideene og verktøyene som er beskrevet her. Dmitry Figol har en utmerket kanal med strømmer om dette emnet.
Artiklene vil overlappe med dem på mange måter.

LAN DC har 4 DC-er, ca 250 switcher, et halvt dusin rutere og et par brannmurer.
Ikke Facebook, men nok til å få deg til å tenke dypt på automatisering.
Det er imidlertid en oppfatning at hvis du har mer enn 1 enhet, er automatisering allerede nødvendig.
Faktisk er det vanskelig å forestille seg at noen nå kan leve uten minst en pakke med kne-manus.
Selv om jeg hørte at det er kontorer der IP-adresser holdes i Excel, og hver av de tusenvis av nettverksenhetene er konfigurert manuelt og har sin egen unike konfigurasjon. Dette kan selvfølgelig avgis som moderne kunst, men ingeniørens følelser vil definitivt bli fornærmet.

mål

Nå skal vi sette de mest abstrakte målene:

• Nettverket er som en enkelt organisme
• Konfigurasjonstesting
• Nettverksstatus versjonering
• Overvåking og selvhelbredelse av tjenester

Senere i denne artikkelen skal vi se på hvilke virkemidler vi skal bruke, og i det følgende skal vi se på målene og midlene i detalj.

Nettverket er som en enkelt organisme

Den definerende frasen til serien, selv om den ved første øyekast kanskje ikke virker så viktig: vi vil konfigurere nettverket, ikke individuelle enheter.
De siste årene har vi sett et skifte i vekt mot å behandle nettverket som en enkelt enhet, derav Definert nettverksprogramvare, Intensjonsdrevne nettverk и Autonome nettverk.
Tross alt, hva trenger applikasjoner globalt fra nettverket: tilkobling mellom punkt A og B (vel, noen ganger +B-Z) og isolasjon fra andre applikasjoner og brukere.

Og så er oppgaven vår i denne serien bygge et system, opprettholde gjeldende konfigurasjon hele nettverket, som allerede er dekomponert til den faktiske konfigurasjonen på hver enhet i samsvar med dens rolle og plassering.
System nettverksadministrasjon innebærer at vi kontakter den for å gjøre endringer, og den beregner på sin side ønsket tilstand for hver enhet og konfigurerer den.
På denne måten minimerer vi manuell tilgang til CLI til nesten null - eventuelle endringer i enhetsinnstillinger eller nettverksdesign må formaliseres og dokumenteres - og først da rulles ut til nødvendige nettverkselementer.

Det vil si at hvis vi for eksempel bestemte oss for at fra nå av skal racksvitsjer i Kazan annonsere to nettverk i stedet for ett,

1. Først dokumenterer vi endringer i systemene
2. Genererer målkonfigurasjonen for alle nettverksenheter
3. Vi lanserer nettverkskonfigurasjonsoppdateringsprogrammet, som beregner hva som må fjernes på hver node, hva som skal legges til, og bringer nodene til ønsket tilstand.

Samtidig gjør vi endringer manuelt kun i første trinn.

Konfigurasjonstesting

Er kjentat 80 % av problemene oppstår under konfigurasjonsendringer - indirekte bevis på dette er at i løpet av nyttårsferien er alt vanligvis rolig.
Jeg har personlig vært vitne til dusinvis av globale nedetider på grunn av menneskelig feil: feil kommando, konfigurasjonen ble utført i feil gren, samfunnet glemte, MPLS ble revet globalt på ruteren, fem maskinvare ble konfigurert, men feilen var ikke lagt merke til den sjette, gamle endringer gjort av en annen person ble begått. Det er massevis av scenarier.

Automatisering vil tillate oss å gjøre færre feil, men i større skala. På denne måten kan du mure ikke bare én enhet, men hele nettverket samtidig.

I uminnelige tider sjekket våre bestefedre riktigheten av endringene som ble gjort med et godt øye, kuler av stål og funksjonaliteten til nettverket etter at de ble rullet ut.
De bestefedrene hvis arbeid førte til nedetid og katastrofale tap etterlot færre avkom og skulle dø ut over tid, men evolusjon er en langsom prosess, og derfor tester ikke alle fortsatt endringer i laboratoriet først.
I forkant av fremgangen er imidlertid de som har automatisert prosessen med å teste konfigurasjonen og dens videre applikasjon på nettverket. Med andre ord, jeg lånte CI/CD-prosedyren (Kontinuerlig integrasjon, kontinuerlig utrulling) fra utviklerne.
I en av delene skal vi se på hvordan man implementerer dette ved hjelp av et versjonskontrollsystem, sannsynligvis Github.

Når du først har blitt vant til ideen om nettverk CI/CD, vil metoden for å sjekke en konfigurasjon ved å bruke den på et produksjonsnettverk over natten virke som tidlig middelaldersk uvitenhet. Litt som å slå et stridshode med en hammer.

En organisk fortsettelse av ideer om system nettverksadministrasjon og CI/CD blir en fullversjon av konfigurasjonen.

Versjonskontroll

Vi vil anta at med alle endringer, selv de minste, selv på en umerkelig enhet, flytter hele nettverket seg fra en tilstand til en annen.
Og vi utfører alltid ikke en kommando på enheten, vi endrer statusen til nettverket.
Så la oss kalle disse statene versjoner?

La oss si at den nåværende versjonen er 1.0.0.
Har IP-adressen til Loopback-grensesnittet på en av ToR-ene endret seg? Dette er en mindre versjon og vil bli nummerert 1.0.1.
Vi reviderte retningslinjene for import av ruter til BGP - litt mer seriøst - allerede 1.1.0
Vi bestemte oss for å kvitte oss med IGP og bytte til bare BGP - dette er allerede en radikal designendring - 2.0.0.

Samtidig kan forskjellige DC-er ha forskjellige versjoner - nettverket utvikler seg, nytt utstyr blir installert, nye nivåer av spines blir lagt til et sted, ikke i andre, etc.

Про semantisk versjonering vi vil snakke i en egen artikkel.

Jeg gjentar - enhver endring (bortsett fra feilsøkingskommandoer) er en versjonsoppdatering. Administratorer må varsles om eventuelle avvik fra gjeldende versjon.

Det samme gjelder for tilbakestilling av endringer - dette er ikke å avbryte de siste kommandoene, dette er ikke en tilbakeføring ved å bruke enhetens operativsystem - dette bringer hele nettverket til en ny (gammel) versjon.

Overvåking og selvhelbredelse av tjenester

Denne selvinnlysende oppgaven har nådd et nytt nivå i moderne nettverk.
Ofte tar store tjenesteleverandører den tilnærmingen at en mislykket tjeneste må rettes opp veldig raskt og en ny reises, i stedet for å finne ut hva som har skjedd.
"Veldig" betyr at du må være sjenerøst belagt på alle sider med overvåking, som i løpet av sekunder vil oppdage de minste avvik fra normen.
Og her er ikke de vanlige beregningene, som grensesnittlasting eller nodetilgjengelighet, lenger nok. Manuell overvåking av dem av vakthavende er heller ikke nok.
For mange ting skal det være Selv helbreding — overvåkingslysene ble røde og vi gikk og la plantainen selv der det gjorde vondt.

Og her overvåker vi også ikke bare individuelle enheter, men også helsen til hele nettverket, både whitebox, som er relativt forståelig, og blackbox, som er mer komplisert.

Hva trenger vi for å gjennomføre slike ambisiøse planer?

• Ha en liste over alle enheter på nettverket, deres plassering, roller, modeller, programvareversjoner.
  kazan-leaf-1.lmu.net, Kazan, blad, Juniper QFX 5120, R18.3.
• Ha et system for å beskrive nettverkstjenester.
  IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH.
• Kunne initialisere enheten.
  Vertsnavn, Mgmt IP, Mgmt Route, Users, RSA-keys, LLDP, NETCONF
• Konfigurer enheten og bring konfigurasjonen til ønsket (inkludert gammel) versjon.
• Test konfigurasjon
• Sjekk med jevne mellomrom statusen til alle enheter for avvik fra de gjeldende og rapporter til hvem det skal være.
  Over natten la noen stille til en regel til ACL.
• Overvåk ytelsen.

midler

Det høres komplisert nok ut til å begynne å dekomponere prosjektet i komponenter.

Og det skal være ti av dem:

1. Inventarsystem
2. IP plass administrasjonssystem
3. System for beskrivelse av nettverkstjenester
4. Enhetsinitieringsmekanisme
5. Leverandør-agnostisk konfigurasjonsmodell
6. Leverandørspesifikt drivergrensesnitt
7. Mekanisme for å levere konfigurasjon til enheten
8. CI / CD
9. Mekanisme for backup og søk etter avvik
10. Overvåkningsstystem

Dette er forresten et eksempel på hvordan synet på målene for syklusen endret seg – det var 4 komponenter i utkastet.

I illustrasjonen avbildet jeg alle komponentene og selve enheten.
Kryssende komponenter samhandler med hverandre.
Jo større blokken er, desto mer oppmerksomhet må det rettes mot denne komponenten.

Komponent 1: Inventarsystem

Vi ønsker selvsagt å vite hvilket utstyr som er plassert hvor, hva som er koblet til.
Lagersystemet er en integrert del av enhver bedrift.
Oftest har en bedrift et eget lagersystem for nettverksenheter, som løser mer spesifikke problemer.
Som en del av denne artikkelserien vil vi kalle den DCIM – Data Center Infrastructure Management. Selv om begrepet DCIM i seg selv strengt tatt inkluderer mye mer.

For våre formål vil vi lagre følgende informasjon om enheten i den:

• Lagernummer
• Tittel Beskrivelse
• Modell (Huawei CE12800, Juniper QFX5120, etc.)
• Karakteristiske parametere (tavler, grensesnitt osv.)
• Rolle (Blad, ryggrad, kantruter, etc.)
• Plassering (region, by, datasenter, stativ, enhet)
• Sammenkoblinger mellom enheter
• Nettverkstopologi

Det er helt klart at vi selv ønsker å vite alt dette.
Men vil dette hjelpe for automatiseringsformål?
Sikkert.
For eksempel vet vi at i et gitt datasenter på Leaf-svitsjer, hvis det er Huawei, bør ACL-er for å filtrere viss trafikk brukes på VLAN, og hvis det er Juniper, så på enhet 0 i det fysiske grensesnittet.
Eller du må rulle ut en ny Syslog-server til alle grenser i regionen.

I den vil vi lagre virtuelle nettverksenheter, for eksempel virtuelle rutere eller rotreflektorer. Vi kan legge til DNS-servere, NTP, Syslog og generelt alt som på en eller annen måte relaterer seg til nettverket.

Komponent 2: IP-plassadministrasjonssystem

Ja, og i dag er det team av mennesker som holder styr på prefikser og IP-adresser i en Excel-fil. Men den moderne tilnærmingen er fortsatt en database, med front-end på nginx/apache, API og omfattende funksjoner for å registrere IP-adresser og nettverk delt inn i VRF-er.
IPAM - administrasjon av IP-adresser.

For våre formål vil vi lagre følgende informasjon i den:

• VLAN
• VRF utvidelse
• Nettverk/undernett
• IP-adresser
• Binding av adresser til enheter, nettverk til lokasjoner og VLAN-numre

Igjen, det er klart at vi vil forsikre oss om at når vi tildeler en ny IP-adresse for ToR loopback, vil vi ikke snuble over det faktum at den allerede var tildelt noen. Eller at vi brukte samme prefiks to ganger i forskjellige ender av nettverket.
Men hvordan hjelper dette med automatisering?
Det er enkelt.
Vi ber om et prefiks i systemet med Loopbacks-rollen, som inneholder IP-adresser som er tilgjengelige for tildeling - hvis det blir funnet, tildeler vi adressen, hvis ikke ber vi om opprettelse av et nytt prefiks.
Eller når vi oppretter en enhetskonfigurasjon, kan vi finne ut fra samme system i hvilken VRF grensesnittet skal ligge.
Og når du starter en ny server, logger scriptet inn i systemet, finner ut hvilken svitsj serveren er i, hvilken port og hvilket subnett som er tilordnet grensesnittet - og vil tildele serveradressen fra det.

Dette antyder et ønske om å kombinere DCIM og IPAM til ett system for ikke å duplisere funksjoner og ikke betjene to lignende enheter.
Det er det vi skal gjøre.

Komponent 3. System for å beskrive nettverkstjenester

Hvis de to første systemene lagrer variabler som fortsatt må brukes på en eller annen måte, så beskriver den tredje for hver enhetsrolle hvordan den skal konfigureres.
Det er verdt å skille mellom to forskjellige typer nettverkstjenester:

• Infrastruktur
• Klient.

Førstnevnte er designet for å gi grunnleggende tilkobling og enhetskontroll. Disse inkluderer VTY, SNMP, NTP, Syslog, AAA, rutingprotokoller, CoPP, etc.
Sistnevnte organiserer tjenesten for klienten: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etc.
Det er selvfølgelig også grensetilfeller – hvor skal man inkludere MPLS LDP, BGP? Ja, og rutingprotokoller kan brukes for klienter. Men dette er ikke viktig.

Begge typer tjenester er dekomponert i konfigurasjonsprimitiver:

• fysiske og logiske grensesnitt (tag/anteg, mtu)
• IP-adresser og VRF-er (IP, IPv6, VRF)
• ACLer og retningslinjer for trafikkbehandling
• Protokoller (IGP, BGP, MPLS)
• Rutingpolicyer (prefikslister, fellesskap, ASN-filtre).
• Verktøytjenester (SSH, NTP, LLDP, Syslog...)
• Etc.

Hvordan vi skal gjøre dette, har jeg ingen anelse om ennå. Vi skal se nærmere på det i en egen artikkel.

Hvis det er litt nærmere livet, så kan vi beskrive det
Leaf-svitsjen må ha BGP-økter med alle tilkoblede Spine-svitsjer, importere tilkoblede nettverk inn i prosessen, og kun godta nettverk fra et bestemt prefiks fra Spine-svitsjer. Begrens CoPP IPv6 ND til 10 pps osv.
I sin tur holder spines økter med alle tilkoblede ledninger, fungerer som rotreflektorer, og aksepterer fra dem bare ruter av en viss lengde og med et visst fellesskap.

Komponent 4: Enhetsinitialiseringsmekanisme

Under denne overskriften kombinerer jeg mange av handlingene som må skje for at en enhet skal vises på radar og få tilgang til eksternt.

1. Skriv inn enheten i inventarsystemet.
2. Velg en administrasjons-IP-adresse.
3. Konfigurer grunnleggende tilgang til det:
   Vertsnavn, administrasjons-IP-adresse, rute til administrasjonsnettverket, brukere, SSH-nøkler, protokoller - telnet/SSH/NETCONF

Det er tre tilnærminger:

• Alt er helt manuelt. Enheten bringes til stativet, hvor en vanlig organisk person vil legge den inn i systemene, koble til konsollen og konfigurere den. Kan fungere på små statiske nettverk.
• ZTP – Zero Touch Provisioning. Maskinvaren kom, reiste seg, mottok en adresse via DHCP, gikk til en spesiell server og konfigurerte seg selv.
• Infrastrukturen til konsollservere, der den første konfigurasjonen skjer gjennom konsollporten i automatisk modus.

Vi vil snakke om alle tre i en egen artikkel.

Komponent 5: Leverandør-agnostisk konfigurasjonsmodell

Til nå har alle systemer vært forskjellige patcher som gir variabler og en deklarativ beskrivelse av hva vi ønsker å se på nettverket. Men før eller siden må du forholde deg til detaljer.
På dette stadiet, for hver spesifikk enhet, kombineres primitiver, tjenester og variabler til en konfigurasjonsmodell som faktisk beskriver den komplette konfigurasjonen av en spesifikk enhet, bare på en leverandørnøytral måte.
Hva gjør dette trinnet? Hvorfor ikke umiddelbart lage en enhetskonfigurasjon som du enkelt kan laste opp?
Faktisk løser dette tre problemer:

1. Ikke tilpass et spesifikt grensesnitt for samhandling med enheten. Det være seg CLI, NETCONF, RESTCONF, SNMP - modellen vil være den samme.
2. Ikke oppbevar antall maler/skript i henhold til antall leverandører på nettverket, og endres designet endres det samme flere steder.
3. Last inn konfigurasjonen fra enheten (backup), legg den inn i nøyaktig samme modell og sammenlign målkonfigurasjonen direkte med den eksisterende for å beregne deltaet og forberede en konfigurasjonsoppdatering som vil endre bare de delene som er nødvendige eller for å identifisere avvik.

Som et resultat av dette stadiet får vi en leverandøruavhengig konfigurasjon.

Komponent 6. Leverandørspesifikt drivergrensesnitt

Du bør ikke smigre deg selv med håp om at det en dag vil være mulig å konfigurere en ciska på nøyaktig samme måte som en Juniper, ganske enkelt ved å sende nøyaktig de samme anropene til dem. Til tross for den økende populariteten til whiteboxer og fremveksten av støtte for NETCONF, RESTCONF, OpenConfig, er det spesifikke innholdet som disse protokollene leverer forskjellig fra leverandør til leverandør, og dette er en av deres konkurranseforskjeller som de ikke vil gi opp så lett.
Dette er omtrent det samme som OpenContrail og OpenStack, som har RestAPI som NorthBound-grensesnitt, forventer helt andre anrop.

Så i det femte trinnet må den leverandøruavhengige modellen ha den formen den vil gå til maskinvare.
Og her er alle midler gode (ikke): CLI, NETCONF, RESTCONF, SNMP rett og slett.

Derfor vil vi trenge en driver som vil overføre resultatet av forrige trinn til det nødvendige formatet til en spesifikk leverandør: et sett med CLI-kommandoer, en XML-struktur.

Komponent 7. Mekanisme for å levere konfigurasjon til enheten

Vi har generert konfigurasjonen, men den må fortsatt leveres til enhetene – og selvsagt ikke for hånd.
Først, står vi overfor spørsmålet om hvilken transport vi vil bruke? Og i dag er valget ikke lenger lite:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (selv om det er en uteligger fordi det er en måte å levere FIB på, ikke innstillinger)

La oss prikke t-en her. CLI er arv. SNMP... hoste hoste.
RESTCONF er fortsatt et ukjent dyr; REST API støttes av nesten ingen. Derfor vil vi fokusere på NETCONF i serien.

Faktisk, som leseren allerede har forstått, på dette tidspunktet har vi allerede bestemt oss for grensesnittet - resultatet av forrige trinn er allerede presentert i formatet til grensesnittet som ble valgt.

Dernest, og hvilke verktøy vil vi gjøre dette med?
Det er også et stort utvalg her:

• Selvskrevet manus eller plattform. La oss bevæpne oss med ncclient og asyncIO og gjøre alt selv. Hva koster det oss å bygge et distribusjonssystem fra bunnen av?
• Ansible med sitt rike bibliotek med nettverksmoduler.
• Salt med sitt magre arbeid med nettverket og forbindelse med Napalm.
• Faktisk Napalm, som kjenner et par leverandører og det er det, farvel.
• Nornir er et annet dyr som vi skal dissekere i fremtiden.

Her er favoritten ennå ikke valgt – vi skal lete.

Hva annet er viktig her? Konsekvenser av å bruke konfigurasjonen.
Vellykket eller ikke. Er det fortsatt tilgang til maskinvaren eller ikke?
Det ser ut til at commit vil hjelpe her med bekreftelse og validering av det som ble lastet ned til enheten.
Dette, kombinert med riktig implementering av NETCONF, begrenser utvalget av passende enheter betydelig - ikke mange produsenter støtter normale commits. Men dette er bare en av forutsetningene i RFP. Til slutt er ingen bekymret for at ikke en eneste russisk leverandør vil overholde 32*100GE grensesnittbetingelsen. Eller er han bekymret?

Komponent 8. CI/CD

På dette tidspunktet har vi allerede konfigurasjonen klar for alle nettverksenheter.
Jeg skriver "for alt" fordi vi snakker om versjonering av nettverkstilstanden. Og selv om du trenger å endre innstillingene til bare én bryter, beregnes endringer for hele nettverket. Selvfølgelig kan de være null for de fleste noder.

Men, som allerede nevnt ovenfor, er vi ikke en slags barbarer som ønsker å rulle alt rett i produksjon.
Den genererte konfigurasjonen må først gå gjennom Pipeline CI/CD.

CI/CD står for Continuous Integration, Continuous Deployment. Dette er en tilnærming der teamet ikke bare legger ut en ny hovedversjon hver sjette måned, som fullstendig erstatter den gamle, men regelmessig implementerer (Deployment) ny funksjonalitet i små porsjoner, som hver er omfattende testet for kompatibilitet, sikkerhet og ytelse (Integrasjon).

For å gjøre dette har vi et versjonskontrollsystem som overvåker konfigurasjonsendringer, et laboratorium som sjekker om klienttjenesten er ødelagt, et overvåkingssystem som sjekker dette faktum, og siste trinn er å rulle ut endringer i produksjonsnettverket.

Med unntak av feilsøkingskommandoer, må absolutt alle endringer på nettverket gå gjennom CI/CD Pipeline - dette er vår garanti for et stille liv og en lang, lykkelig karriere.

Komponent 9. System for sikkerhetskopiering og anomalideteksjon

Vel, det er ikke nødvendig å snakke om sikkerhetskopier igjen.
Vi vil ganske enkelt sette dem i git i henhold til kronen eller ved en konfigurasjonsendring.

Men den andre delen er mer interessant - noen bør holde øye med disse sikkerhetskopiene. Og i noen tilfeller må denne noen gå og snu alt som det var, og i andre mjauer til noen at noe er galt.
For eksempel, hvis en ny bruker har dukket opp som ikke er registrert i variablene, må du fjerne ham fra hacket. Og hvis det er bedre å ikke røre en ny brannmurregel, kanskje noen nettopp har slått på feilsøking, eller kanskje den nye tjenesten, en bungler, ikke ble registrert i henhold til regelverket, men folk har allerede sluttet seg til den.

Vi vil fortsatt ikke unnslippe et lite delta på skalaen til hele nettverket, til tross for eventuelle automatiseringssystemer og den stålsatte hånden til ledelsen. For å feilsøke problemer, vil ingen legge til konfigurasjon til systemene uansett. Dessuten er de kanskje ikke engang inkludert i konfigurasjonsmodellen.

For eksempel er en brannmurregel for å telle antall pakker per spesifikk IP for å lokalisere et problem en helt vanlig midlertidig konfigurasjon.

Komponent 10. Overvåkingssystem

Først hadde jeg ikke tenkt å dekke temaet overvåking – det er fortsatt et omfangsrikt, kontroversielt og komplekst tema. Men etter hvert som ting skred frem, viste det seg at dette var en integrert del av automatisering. Og det er umulig å omgå det, selv uten trening.

Evolving Thought er en organisk del av CI/CD-prosessen. Etter å ha rullet ut konfigurasjonen til nettverket, må vi kunne finne ut om alt er i orden med det nå.
Og vi snakker ikke bare og ikke så mye om grensesnittbruksplaner eller nodetilgjengelighet, men om mer subtile ting - tilstedeværelsen av nødvendige ruter, attributter på dem, antall BGP-økter, OSPF-naboer, End-to-End-ytelse av overliggende tjenester.
Sluttet sysloggene til den eksterne serveren å legge seg sammen, eller brøt SFlow-agenten sammen, eller begynte nedgangene i køene å vokse, eller brøt tilkoblingen mellom et par prefikser?

Vi vil reflektere over dette i en egen artikkel.

Konklusjon

Som grunnlag valgte jeg en av de moderne datasenternettverksdesignene - L3 Clos Fabric med BGP som rutingprotokoll.
Denne gangen skal vi bygge nettverket på Juniper, for nå er JunOs-grensesnittet en vanlove.

La oss gjøre livet vårt vanskeligere ved å bruke bare åpen kildekode-verktøy og et nettverk av flere leverandører - så i tillegg til Juniper velger jeg enda en heldig person på veien.

Planen for kommende publikasjoner er omtrent slik:
Først skal jeg snakke om virtuelle nettverk. For det første fordi jeg vil, og for det andre fordi uten dette vil ikke utformingen av infrastrukturnettverket være veldig tydelig.
Så om selve nettverksdesignet: topologi, ruting, policyer.
La oss sette sammen et laboratoriestativ.
La oss tenke på det og kanskje øve på å initialisere enheten på nettverket.
Og så om hver komponent i intime detaljer.

Og ja, jeg lover ikke å avslutte denne syklusen elegant med en ferdig løsning. 🙂

Nyttige lenker

• Før du går inn i serien, er det verdt å lese boken til Natasha Samoilenkos Python for nettverksingeniører. Og kanskje bestå kurs.
• Det vil også være nyttig å lese RFC om design av datasenterfabrikker fra Facebook av Peter Lapukhov.
• Arkitekturdokumentasjonen vil gi deg en ide om hvordan Overlay SDN fungerer. Tungsten stoff (tidligere Open Contrail).

Takk skal du ha

Roman Gorge. For kommentarer og redigeringer.
Artyom Chernobay. For KDPV.

Kilde: www.habr.com