SDSM er forbi, men den ustyrlige lyst til at skrive består.

I mange år led vores bror af at lave rutinearbejde, krydse fingre inden han forpligtede sig og mangle søvn på grund af natlige tilbagevendinger.
Men de mørke tider er ved at være slut.

Med denne artikel vil jeg begynde en serie om hvordan mig automatisering ses.
Undervejs vil vi forstå stadierne af automatisering, lagring af variabler, formalisering af design, RestAPI, NETCONF, YANG, YDK, og vi vil lave en masse programmering.
Me betyder, at a) det ikke er en objektiv sandhed, b) det ikke ubetinget er den bedste tilgang, c) min mening, selv under bevægelsen fra den første til den sidste artikel, kan ændre sig - for at være ærlig, fra udkaststadiet til udgivelse, jeg omskrev alt fuldstændig to gange.

Indhold

1. mål
   1. Netværket er som en enkelt organisme
   2. Konfigurationstest
   3. Versionering
   4. Overvågning og selvhelbredelse af tjenester

2. midler
   1. Lagersystem
   2. IP space management system
   3. Netværkstjenestebeskrivelsessystem
   4. Enhedens initialiseringsmekanisme
   5. Leverandør-agnostisk konfigurationsmodel
   6. Leverandørspecifik drivergrænseflade
   7. Mekanisme til levering af konfiguration til enheden
   8. CI / CD
   9. Mekanisme til backup og søgning efter afvigelser
   10. Overvågningssystem

3. Konklusion

Jeg vil forsøge at udføre ADSM i et format, der er lidt anderledes end SDSM. Store, detaljerede, nummererede artikler vil fortsat dukke op, og mellem dem vil jeg udgive små noter fra hverdagens erfaringer. Jeg vil prøve at bekæmpe perfektionisme her og ikke slikke hver enkelt af dem.

Hvor er det sjovt, at du anden gang skal gennem den samme vej.

Først skulle jeg selv skrive artikler om netværk på grund af, at de ikke var på RuNet.

Nu kunne jeg ikke finde et omfattende dokument, der ville systematisere tilgange til automatisering og analysere ovenstående teknologier ved hjælp af simple praktiske eksempler.

Jeg tager muligvis fejl, så giv venligst links til nyttige ressourcer. Dette vil dog ikke ændre på min beslutsomhed til at skrive, for hovedmålet er at lære noget selv, og at gøre livet lettere for andre er en behagelig bonus, der kærtegner genet for at dele erfaringer.

Vi vil forsøge at tage et mellemstort LAN DC datacenter og udarbejde hele automatiseringsskemaet.
Jeg vil gøre nogle ting næsten for første gang med dig.

Jeg vil ikke være original i de ideer og værktøjer, der er beskrevet her. Dmitry Figol har en fremragende kanal med streams om dette emne.
Artiklerne vil overlappe dem i mange aspekter.

LAN DC har 4 DC'er, omkring 250 switche, et halvt dusin routere og et par firewalls.
Ikke Facebook, men nok til at få dig til at tænke dybt over automatisering.
Der er dog en opfattelse af, at hvis du har mere end 1 enhed, er automatisering allerede nødvendig.
Faktisk er det svært at forestille sig, at nogen nu kan leve uden mindst en pakke knæ-scripts.
Selvom jeg hørte, at der er kontorer, hvor IP-adresser opbevares i Excel, og hver af de tusindvis af netværksenheder er konfigureret manuelt og har sin egen unikke konfiguration. Dette kan selvfølgelig udgives som moderne kunst, men ingeniørens følelser vil helt sikkert blive stødt.

mål

Nu vil vi sætte de mest abstrakte mål:

• Netværket er som en enkelt organisme
• Konfigurationstest
• Netværkstilstand versionering
• Overvågning og selvhelbredelse af tjenester

Senere i denne artikel vil vi se på, hvilke midler vi vil bruge, og i det følgende vil vi se nærmere på målene og midlerne.

Netværket er som en enkelt organisme

Seriens definerende sætning, selvom den ved første øjekast måske ikke virker så vigtig: vi konfigurerer netværket, ikke individuelle enheder.
I de senere år har vi set et skift i vægt i retning af at behandle netværket som en enkelt enhed, derfor Software -defineret netværk, Intentionsdrevne netværk и Autonome netværk.
Når alt kommer til alt, hvad har applikationer brug for globalt fra netværket: forbindelse mellem punkt A og B (nå, nogle gange +B-Z) og isolation fra andre applikationer og brugere.

Og så er vores opgave i denne serie bygge et system, vedligeholde den aktuelle konfiguration hele netværket, som allerede er opdelt i den faktiske konfiguration på hver enhed i overensstemmelse med dens rolle og placering.
System netværksstyring indebærer, at vi kontakter den for at foretage ændringer, og den beregner til gengæld den ønskede tilstand for hver enhed og konfigurerer den.
På denne måde minimerer vi manuel adgang til CLI til næsten nul - eventuelle ændringer i enhedsindstillinger eller netværksdesign skal formaliseres og dokumenteres - og først derefter rulles ud til de nødvendige netværkselementer.

Det vil sige, at hvis vi for eksempel besluttede, at rack-switche i Kazan fra nu af skulle annoncere to netværk i stedet for ét,

1. Først dokumenterer vi ændringer i systemer
2. Generering af målkonfigurationen for alle netværksenheder
3. Vi starter netværkskonfigurationsopdateringsprogrammet, som beregner, hvad der skal fjernes på hver knude, hvad der skal tilføjes og bringer knudepunkterne til den ønskede tilstand.

Samtidig foretager vi kun ændringer manuelt i det første trin.

Konfigurationstest

Kendtat 80 % af problemerne opstår under konfigurationsændringer - indirekte bevis på dette er, at i nytårsferien er alt normalt roligt.
Jeg har personligt været vidne til snesevis af globale nedetider på grund af menneskelige fejl: den forkerte kommando, konfigurationen blev udført i den forkerte gren, samfundet glemte, MPLS blev revet ned globalt på routeren, fem stykker hardware blev konfigureret, men fejlen var ikke bemærket den sjette, gamle ændringer foretaget af en anden person blev begået. Der er et væld af scenarier.

Automatisering vil give os mulighed for at lave færre fejl, men i større skala. På denne måde kan du mure ikke kun én enhed, men hele netværket på én gang.

I umindelige tider kontrollerede vores bedstefædre rigtigheden af ​​de ændringer, der blev foretaget med et skarpt øje, stålkugler og netværkets funktionalitet, efter at de blev rullet ud.
De bedstefædre, hvis arbejde førte til nedetid og katastrofale tab, efterlod færre afkom og skulle dø ud over tid, men evolution er en langsom proces, og derfor er det ikke alle, der stadig tester ændringer i laboratoriet først.
Men på forkant med fremskridtet er dem, der har automatiseret processen med at teste konfigurationen og dens videre anvendelse på netværket. Med andre ord, jeg lånte CI/CD-proceduren (Kontinuerlig integration, kontinuerlig implementering) fra udviklerne.
I en af ​​delene vil vi se på, hvordan man implementerer dette ved hjælp af et versionskontrolsystem, sandsynligvis Github.

Når du først har vænnet dig til ideen om netværk CI/CD, vil metoden til at kontrollere en konfiguration ved at anvende den på et produktionsnetværk fra den ene dag til den anden virke som tidlig middelalderlig uvidenhed. Lidt som at slå et sprænghoved med en hammer.

En organisk fortsættelse af ideer vedr system netværksstyring og CI/CD bliver en fuld version af konfigurationen.

Versionering

Vi vil antage, at med alle ændringer, selv de mindste, selv på en umærkelig enhed, flytter hele netværket fra en tilstand til en anden.
Og vi udfører altid ikke en kommando på enheden, vi ændrer netværkets tilstand.
Så lad os kalde disse stater versioner?

Lad os sige, at den nuværende version er 1.0.0.
Er IP-adressen på Loopback-grænsefladen på en af ​​ToR'erne ændret? Dette er en mindre version og vil blive nummereret 1.0.1.
Vi reviderede politikkerne for import af ruter til BGP - lidt mere seriøst - allerede 1.1.0
Vi besluttede at slippe af med IGP og kun skifte til BGP - dette er allerede en radikal designændring - 2.0.0.

Samtidig kan forskellige DC'er have forskellige versioner - netværket udvikler sig, nyt udstyr bliver installeret, nye niveauer af spines tilføjes et eller andet sted, ikke i andre osv.

Про semantisk versionering vi vil tale i en separat artikel.

Jeg gentager - enhver ændring (undtagen fejlretningskommandoer) er en versionsopdatering. Administratorer skal underrettes om eventuelle afvigelser fra den aktuelle version.

Det samme gælder for tilbagerulning af ændringer - dette er ikke annullering af de sidste kommandoer, dette er ikke en tilbagerulning ved hjælp af enhedens operativsystem - dette bringer hele netværket til en ny (gammel) version.

Overvågning og selvhelbredelse af tjenester

Denne selvindlysende opgave har nået et nyt niveau i moderne netværk.
Ofte tager store tjenesteudbydere den tilgang, at en fejlbehæftet tjeneste skal rettes meget hurtigt og en ny rejses, i stedet for at finde ud af, hvad der skete.
"Meget" betyder, at du skal være generøst belagt på alle sider med overvågning, som inden for få sekunder vil opdage de mindste afvigelser fra normen.
Og her er de sædvanlige målinger, såsom grænsefladeindlæsning eller nodetilgængelighed, ikke længere nok. Manuel overvågning af dem af vagtchefen er heller ikke nok.
For mange ting burde der være Selvhelbredende — overvågningslysene blev røde, og vi gik hen og påsatte selv plantainen, hvor det gjorde ondt.

Og her overvåger vi også ikke kun individuelle enheder, men også hele netværkets helbred, både whitebox, som er relativt forståeligt, og blackbox, som er mere kompliceret.

Hvad skal vi bruge for at gennemføre sådanne ambitiøse planer?

• Få en liste over alle enheder på netværket, deres placering, roller, modeller, softwareversioner.
  kazan-leaf-1.lmu.net, Kazan, blad, Juniper QFX 5120, R18.3.
• Har et system til at beskrive netværkstjenester.
  IGP, BGP, L2/3VPN, Politik, ACL, NTP, SSH.
• Være i stand til at initialisere enheden.
  Værtsnavn, Mgmt IP, Mgmt Route, Brugere, RSA-nøgler, LLDP, NETCONF
• Konfigurer enheden og bring konfigurationen til den ønskede (inklusive gamle) version.
• Test konfiguration
• Tjek med jævne mellemrum status på alle enheder for afvigelser fra de nuværende og rapporter til hvem det skal være.
  Over natten tilføjede nogen stille en regel til ACL.
• Overvåg ydeevne.

midler

Det lyder kompliceret nok til at begynde at dekomponere projektet i komponenter.

Og der vil være ti af dem:

1. Lagersystem
2. IP space management system
3. Netværkstjenestebeskrivelsessystem
4. Enhedens initialiseringsmekanisme
5. Leverandør-agnostisk konfigurationsmodel
6. Leverandørspecifik drivergrænseflade
7. Mekanisme til levering af konfiguration til enheden
8. CI / CD
9. Mekanisme til backup og søgning efter afvigelser
10. Overvågningssystem

Dette er i øvrigt et eksempel på, hvordan synet på cyklussens mål ændrede sig - der var 4 komponenter i udkastet.

I illustrationen afbildede jeg alle komponenterne og selve enheden.
Skærende komponenter interagerer med hinanden.
Jo større blokken er, jo mere opmærksomhed skal der lægges vægt på denne komponent.

Komponent 1: Lagersystem

Vi vil selvfølgelig gerne vide, hvilket udstyr der er placeret hvor, hvad der er tilsluttet.
Lagersystemet er en integreret del af enhver virksomhed.
Oftest har en virksomhed et separat lagersystem til netværksenheder, som løser mere specifikke problemer.
Som en del af denne artikelserie vil vi kalde det DCIM - Data Center Infrastructure Management. Selvom begrebet DCIM i sig selv strengt taget omfatter meget mere.

Til vores formål gemmer vi følgende oplysninger om enheden i den:

• Inventarnummer
• Titel/beskrivelse
• Model (Huawei CE12800, Juniper QFX5120 osv.)
• Karakteristiske parametre (tavler, interfaces mv.)
• Rolle (Blade, Rygsøjle, Border Router osv.)
• Beliggenhed (region, by, datacenter, rack, enhed)
• Sammenkoblinger mellem enheder
• Netværkstopologi

Det er helt klart, at vi selv ønsker at vide alt dette.
Men vil dette hjælpe til automatiseringsformål?
Bestemt.
For eksempel ved vi, at i et givet datacenter på Leaf-switches, hvis det er Huawei, skal ACL'er til at filtrere bestemt trafik anvendes på VLAN'et, og hvis det er Juniper, så på enhed 0 af den fysiske grænseflade.
Eller du skal udrulle en ny Syslog-server til alle grænser i regionen.

I den vil vi gemme virtuelle netværksenheder, for eksempel virtuelle routere eller rodreflektorer. Vi kan tilføje DNS-servere, NTP, Syslog og i det hele taget alt hvad der på den ene eller anden måde relaterer sig til netværket.

Komponent 2: IP-pladsstyringssystem

Ja, og i dag er der hold af mennesker, der holder styr på præfikser og IP-adresser i en Excel-fil. Men den moderne tilgang er stadig en database, med en front-end på nginx/apache, API og omfattende funktioner til registrering af IP-adresser og netværk opdelt i VRF'er.
IPAM - IP-adressestyring.

Til vores formål gemmer vi følgende oplysninger i den:

• VLAN
• VRF forlængelse
• Netværk/undernet
• IP-adresser
• Binding af adresser til enheder, netværk til lokationer og VLAN-numre

Igen er det klart, at vi vil sikre os, at når vi tildeler en ny IP-adresse til ToR loopback, vil vi ikke snuble over det faktum, at den allerede var tildelt til nogen. Eller at vi brugte det samme præfiks to gange i forskellige ender af netværket.
Men hvordan hjælper dette med automatisering?
Det er nemt.
Vi anmoder om et præfiks i systemet med Loopbacks-rollen, som indeholder IP-adresser, der er tilgængelige for tildeling - hvis det findes, tildeler vi adressen, hvis ikke, anmoder vi om oprettelse af et nyt præfiks.
Eller når vi opretter en enhedskonfiguration, kan vi fra samme system finde ud af, hvilken VRF grænsefladen skal være placeret i.
Og når en ny server startes, logger scriptet ind i systemet, finder ud af hvilken switch serveren er i, hvilken port og hvilket subnet der er tildelt interfacet - og vil allokere serveradressen fra den.

Dette tyder på et ønske om at kombinere DCIM og IPAM i ét system for ikke at duplikere funktioner og ikke betjene to lignende enheder.
Det er, hvad vi vil gøre.

Komponent 3. System til beskrivelse af netværkstjenester

Hvis de første to systemer gemmer variabler, der stadig skal bruges på en eller anden måde, så beskriver det tredje for hver enhedsrolle, hvordan det skal konfigureres.
Det er værd at skelne mellem to forskellige typer netværkstjenester:

• Infrastruktur
• Klient.

Førstnævnte er designet til at give grundlæggende tilslutningsmuligheder og enhedskontrol. Disse inkluderer VTY, SNMP, NTP, Syslog, AAA, routingprotokoller, CoPP osv.
Sidstnævnte organiserer tjenesten for klienten: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP osv.
Der er selvfølgelig også grænsetilfælde - hvor skal MPLS LDP, BGP medtages? Ja, og routingprotokoller kan bruges til klienter. Men dette er ikke vigtigt.

Begge typer tjenester er opdelt i konfigurationsprimitiver:

• fysiske og logiske grænseflader (tag/anteg, mtu)
• IP-adresser og VRF'er (IP, IPv6, VRF)
• ACL'er og trafikbehandlingspolitikker
• Protokoller (IGP, BGP, MPLS)
• Routingpolitikker (præfikslister, fællesskaber, ASN-filtre).
• Hjælpetjenester (SSH, NTP, LLDP, Syslog...)
• Etc.

Hvordan vi præcist vil gøre dette, aner jeg endnu ikke. Vi vil se nærmere på det i en separat artikel.

Hvis det er lidt tættere på livet, så kunne vi beskrive det
Leaf-switchen skal have BGP-sessioner med alle tilsluttede Spine-switche, importere tilsluttede netværk til processen og kun acceptere netværk fra et bestemt præfiks fra Spine-switches. Begræns CoPP IPv6 ND til 10 pps osv.
Til gengæld holder spines sessioner med alle forbundne ledninger, der fungerer som rodreflektorer og accepterer kun ruter af en vis længde og med et bestemt fællesskab fra dem.

Komponent 4: Enhedsinitialiseringsmekanisme

Under denne overskrift kombinerer jeg mange af de handlinger, der skal ske, for at en enhed vises på radaren og kan fås eksternt.

1. Indtast enheden i lagersystemet.
2. Vælg en administrations-IP-adresse.
3. Konfigurer grundlæggende adgang til det:
   Værtsnavn, administrations-IP-adresse, rute til administrationsnetværket, brugere, SSH-nøgler, protokoller - telnet/SSH/NETCONF

Der er tre tilgange:

• Alt er helt manuelt. Enheden bringes til standen, hvor en almindelig organisk person vil indtaste den i systemerne, forbinde til konsollen og konfigurere den. Kan arbejde på små statiske netværk.
• ZTP - Zero Touch Provisioning. Hardwaren ankom, rejste sig, modtog en adresse via DHCP, gik til en speciel server og konfigurerede sig selv.
• Infrastrukturen af ​​konsolservere, hvor den indledende konfiguration sker gennem konsolporten i automatisk tilstand.

Vi vil tale om alle tre i en separat artikel.

Komponent 5: Leverandør-agnostisk konfigurationsmodel

Indtil nu har alle systemer været forskellige patches, der giver variabler og en deklarativ beskrivelse af, hvad vi gerne vil se på netværket. Men før eller siden bliver du nødt til at forholde dig til detaljer.
På dette trin kombineres primitiver, tjenester og variabler for hver specifik enhed til en konfigurationsmodel, der faktisk beskriver den komplette konfiguration af en specifik enhed, kun på en leverandørneutral måde.
Hvad gør dette trin? Hvorfor ikke straks oprette en enhedskonfiguration, som du blot kan uploade?
Faktisk løser dette tre problemer:

1. Tilpas ikke en specifik grænseflade til interaktion med enheden. Det være sig CLI, NETCONF, RESTCONF, SNMP - modellen vil være den samme.
2. Opbevar ikke antallet af skabeloner/scripts i forhold til antallet af leverandører på netværket, og hvis designet ændres, skal du ændre det samme flere steder.
3. Indlæs konfigurationen fra enheden (backup), sæt den i nøjagtig den samme model og sammenlign målkonfigurationen direkte med den eksisterende for at beregne deltaet og forberede en konfigurationspatch, der kun vil ændre de dele, der er nødvendige, eller for at identificere afvigelser.

Som et resultat af denne fase opnår vi en leverandøruafhængig konfiguration.

Komponent 6. Leverandørspecifik drivergrænseflade

Du skal ikke smigre dig selv med håb om, at det en dag vil være muligt at konfigurere en ciska på nøjagtig samme måde som en Juniper, blot ved at sende præcis de samme opkald til dem. På trods af den voksende popularitet af whiteboxes og fremkomsten af ​​understøttelse af NETCONF, RESTCONF, OpenConfig, er det specifikke indhold, som disse protokoller leverer, forskelligt fra leverandør til leverandør, og dette er en af ​​deres konkurrencemæssige forskelle, som de ikke vil give op så let.
Dette er nogenlunde det samme som OpenContrail og OpenStack, som har RestAPI som deres NorthBound-grænseflade, forventer helt andre opkald.

Så i det femte trin skal den leverandøruafhængige model have den form, som den vil gå til hardware.
Og her er alle midlerne gode (ikke): CLI, NETCONF, RESTCONF, SNMP simpelthen.

Derfor har vi brug for en driver, der overfører resultatet af det foregående trin til det påkrævede format for en specifik leverandør: et sæt CLI-kommandoer, en XML-struktur.

Komponent 7. Mekanisme til levering af konfiguration til enheden

Vi har genereret konfigurationen, men den skal stadig leveres til enhederne - og naturligvis ikke i hånden.
For det første, står vi over for spørgsmålet om, hvilken transport vi vil bruge? Og i dag er valget ikke længere lille:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST-API
• OpenFlow (selvom det er en outlier, fordi det er en måde at levere FIB på, ikke indstillinger)

Lad os prikke t'et her. CLI er arv. SNMP... hoste hoste.
RESTCONF er stadig et ukendt dyr; REST API understøttes af næsten ingen. Derfor vil vi fokusere på NETCONF i serien.

Faktisk, som læseren allerede har forstået, har vi allerede på dette tidspunkt besluttet grænsefladen - resultatet af det foregående trin er allerede præsenteret i formatet af den valgte grænseflade.

For det andet, og hvilke værktøjer vil vi gøre dette med?
Der er også et stort udvalg her:

• Selvskrevet manuskript eller platform. Lad os bevæbne os med ncclient og asyncIO og gøre alt selv. Hvad koster det os at bygge et implementeringssystem fra bunden?
• Ansible med sit rige bibliotek af netværksmoduler.
• Salt med sit sparsomme arbejde med netværket og forbindelse med Napalm.
• Faktisk Napalm, som kender et par sælgere, og det er det, farvel.
• Nornir er et andet dyr, som vi vil dissekere i fremtiden.

Her er favoritten endnu ikke valgt - vi skal søge.

Hvad er ellers vigtigt her? Konsekvenser af at anvende konfigurationen.
Vellykket eller ej. Er der stadig adgang til hardwaren eller ej?
Det ser ud til, at commit vil hjælpe her med bekræftelse og validering af, hvad der blev downloadet til enheden.
Dette, kombineret med den korrekte implementering af NETCONF, indsnævrer udvalget af passende enheder markant - ikke mange producenter understøtter normale commits. Men dette er blot en af ​​forudsætningerne i RFP. I sidste ende er ingen bekymret for, at ikke en eneste russisk leverandør vil overholde 32*100GE-grænsefladebetingelsen. Eller er han bekymret?

Komponent 8. CI/CD

På dette tidspunkt har vi allerede konfigurationen klar til alle netværksenheder.
Jeg skriver "for alt", fordi vi taler om versionering af netværkstilstanden. Og selvom du skal ændre indstillingerne for kun én switch, beregnes ændringer for hele netværket. Det er klart, at de kan være nul for de fleste noder.

Men, som det allerede blev sagt ovenfor, er vi ikke en slags barbarer, der ønsker at rulle alt direkte i produktion.
Den genererede konfiguration skal først gå gennem Pipeline CI/CD.

CI/CD står for Continuous Integration, Continuous Deployment. Dette er en tilgang, hvor teamet ikke kun udgiver en ny større udgivelse hvert halve år, der fuldstændig erstatter den gamle, men regelmæssigt gradvist implementerer (Deployment) ny funktionalitet i små portioner, som hver især er grundigt testet for kompatibilitet, sikkerhed og ydeevne (Integration).

For at gøre dette har vi et versionskontrolsystem, der overvåger konfigurationsændringer, et laboratorium, der kontrollerer, om klientservicen er i stykker, et overvågningssystem, der tjekker dette faktum, og det sidste trin er udrulning af ændringer til produktionsnetværket.

Med undtagelse af fejlfindingskommandoer skal absolut alle ændringer på netværket gå gennem CI/CD Pipeline - dette er vores garanti for et roligt liv og en lang, lykkelig karriere.

Komponent 9. Backup- og anomalidetektionssystem

Nå, der er ingen grund til at tale om sikkerhedskopier igen.
Vi vil simpelthen sætte dem i git i henhold til kronen eller ved en konfigurationsændring.

Men den anden del er mere interessant - nogen burde holde øje med disse sikkerhedskopier. Og i nogle tilfælde skal denne nogen gå hen og vende alt, som det var, og i andre, mjave til nogen, at der er noget galt.
For eksempel, hvis en ny bruger er dukket op, som ikke er registreret i variablerne, skal du fjerne ham væk fra hacket. Og hvis det er bedre ikke at røre ved en ny firewall-regel, er der måske nogen, der lige har slået fejlretning til, eller måske er den nye tjeneste, en bungler, ikke registreret i henhold til reglerne, men folk har allerede tilsluttet sig den.

Vi vil stadig ikke undslippe et lille delta på skalaen af ​​hele netværket, på trods af eventuelle automatiseringssystemer og ledelsens stålsatte hånd. For at fejlfinde problemer vil ingen tilføje konfiguration til systemerne alligevel. Desuden er de muligvis ikke engang inkluderet i konfigurationsmodellen.

For eksempel er en firewallregel for at tælle antallet af pakker pr. specifik IP for at lokalisere et problem en helt almindelig midlertidig konfiguration.

Komponent 10. Overvågningssystem

Først ville jeg ikke dække emnet overvågning - det er stadig et omfangsrigt, kontroversielt og komplekst emne. Men som tingene skred frem, viste det sig, at dette var en integreret del af automatisering. Og det er umuligt at omgå det, selv uden øvelse.

Evolving Thought er en organisk del af CI/CD-processen. Efter at have rullet konfigurationen ud til netværket, skal vi være i stand til at afgøre, om alt er okay med det nu.
Og vi taler ikke kun og ikke så meget om grænsefladebrugsplaner eller noder tilgængelighed, men om mere subtile ting - tilstedeværelsen af ​​de nødvendige ruter, attributter på dem, antallet af BGP-sessioner, OSPF-naboer, End-to-End-ydelse af overliggende tjenester.
Holdte syslog'erne til den eksterne server op med at tilføjes, eller gik SFlow-agenten i stykker, eller begyndte faldene i køerne at vokse, eller gik forbindelsen mellem et par præfikser i stykker?

Vi vil reflektere over dette i en separat artikel.

Konklusion

Som grundlag valgte jeg et af de moderne datacenter netværksdesigns - L3 Clos Fabric med BGP som routingprotokol.
Denne gang vil vi bygge netværket på Juniper, for nu er JunOs-grænsefladen en vanlove.

Lad os gøre vores liv sværere ved kun at bruge Open Source-værktøjer og et netværk med flere leverandører - så ud over Juniper vil jeg vælge en heldig person mere hen ad vejen.

Planen for kommende udgivelser er sådan her:
Først vil jeg tale om virtuelle netværk. Først og fremmest fordi jeg gerne vil, og for det andet fordi uden dette, vil designet af infrastrukturnettet ikke være særlig klart.
Så om selve netværksdesignet: topologi, routing, politikker.
Lad os samle et laboratoriestander.
Lad os tænke over det og måske øve os i at initialisere enheden på netværket.
Og så om hver komponent i intime detaljer.

Og ja, jeg lover ikke at afslutte denne cyklus med en færdig løsning. 🙂

Nyttige links

• Før du dykker ned i serien, er det værd at læse Natasha Samoilenkos bog Python for netværksingeniører. Og måske bestå kurset.
• Det vil også være nyttigt at læse RFC om design af datacenterfabrikker fra Facebook af Peter Lapukhov.
• Arkitekturdokumentationen vil give dig en idé om, hvordan Overlay SDN fungerer. Wolfram stof (tidligere Open Contrail).

Tak

Romersk kløft. For kommentarer og redigeringer.
Artyom Chernobay. For KDPV.

Kilde: www.habr.com