ProHoster > Log > administrasjon > Nettverksautomatisering. En sak fra ens liv

Nettverksautomatisering. En sak fra ens liv

Hei Habr!

I denne artikkelen vil vi gjerne snakke om automatisering av nettverksinfrastruktur. Et arbeidsdiagram over nettverket som opererer i ett lite, men veldig stolt selskap vil bli presentert. Alle kamper med ekte nettverksutstyr er tilfeldige. Vi skal se på en sak som oppsto i dette nettverket, som kunne ha ført til bedriftsstans i lang tid og alvorlige økonomiske tap. Løsningen på denne saken passer veldig godt inn i konseptet "Automasjon av nettverksinfrastruktur". Ved hjelp av automatiseringsverktøy vil vi vise hvordan du effektivt kan løse komplekse problemer på kort tid, og vi vil reflektere over hvorfor disse problemene bør løses på denne måten og ikke på annen måte (via konsollen).

Ansvarsfraskrivelse

Våre hovedverktøy for automatisering er Ansible (som et automatiseringsverktøy) og Git (som et arkiv for Ansible playbooks). Jeg vil umiddelbart ta forbehold om at dette ikke er en introduksjonsartikkel, der vi snakker om logikken til Ansible eller Git, og forklarer grunnleggende ting (for eksempel hva er rolletaskimoduler, inventarfiler, variabler i Ansible, eller hva som skjer når du skriver inn git push eller git commit kommandoer). Denne historien handler ikke om hvordan du kan øve Ansible og konfigurere NTP eller SMTP på utstyret ditt. Dette er en historie om hvordan du raskt og helst kan løse et nettverksproblem uten feil. Det er også tilrådelig å ha en god forståelse av hvordan nettverket fungerer, spesielt hva TCP/IP, OSPF, BGP protokollstack er. Vi tar også valget av Ansible og Git ut av ligningen. Hvis du fortsatt trenger å velge en spesifikk løsning, anbefaler vi på det sterkeste å lese boken «Nettverksprogrammerbarhet og automatisering. Skills for the Next-Generation Network Engineer" av Jason Edelman, Scott S. Lowe og Matt Oswalt.

Nå til poenget.

Formulering av problemet

La oss forestille oss en situasjon: Klokken 3 om morgenen sover du raskt og drømmer. Telefonsamtale. Teknisk direktør ringer:

– Ja?
— ###, ####, #####, brannmurklyngen har falt og stiger ikke!!!
Du gnir deg i øynene, prøver å forstå hva som skjer og forestille deg hvordan dette til og med kan skje. På telefonen kan du høre håret på direktørens hode rive, og han ber om å få ringe tilbake fordi generalen ringer ham på andre linje.

En halvtime senere samlet du de første innledende notatene fra vaktvakten, vekket alle som kunne vekkes. Som et resultat løy ikke den tekniske direktøren, alt er som det er, hovedklyngen av brannmurer har falt, og ingen grunnleggende kroppsbevegelser bringer ham til fornuft. Alle tjenestene som selskapet tilbyr fungerer ikke.

Velg et problem etter din smak, alle vil huske noe annerledes. For eksempel, etter en oppdatering over natten i fravær av tung belastning, fungerte alt bra, og alle gikk fornøyde til sengs. Trafikken begynte å flyte, og grensesnittbuffere begynte å renne over på grunn av en feil i nettverkskortdriveren.

Jackie Chan kan godt beskrive situasjonen.

Nettverksautomatisering. En sak fra ens liv

Takk, Jackie.

Ikke en veldig hyggelig situasjon, er det?

La oss forlate nettverket vårt bro med sine triste tanker for en stund.

La oss diskutere hvordan hendelser vil utvikle seg videre.

Vi foreslår følgende rekkefølge for presentasjon av materialet

  1. La oss se på nettverksdiagrammet og se hvordan det fungerer;
  2. Vi vil beskrive hvordan vi overfører innstillinger fra en ruter til en annen ved hjelp av Ansible;
  3. La oss snakke om automatisering av IT-infrastrukturen som helhet.

Nettverksdiagram og beskrivelse

Ordningen

Nettverksautomatisering. En sak fra ens liv

La oss vurdere det logiske diagrammet for organisasjonen vår. Vi vil ikke nevne spesifikke utstyrsprodusenter; for formålet med denne artikkelen spiller det ingen rolle (Den oppmerksomme leser vil gjette hva slags utstyr som brukes). Dette er bare en av de gode fordelene ved å jobbe med Ansible; når vi setter opp, bryr vi oss vanligvis ikke om hva slags utstyr det er. Bare for å forstå, dette er utstyr fra kjente leverandører, som Cisco, Juniper, Check Point, Fortinet, Palo Alto...du kan erstatte ditt eget alternativ.

Vi har to hovedoppgaver for å flytte trafikk:

  1. Sikre publisering av våre tjenester, som er selskapets virksomhet;
  2. Gi kommunikasjon med filialer, et eksternt datasenter og tredjepartsorganisasjoner (partnere og kunder), samt tilgang til filialer til Internett gjennom sentralkontoret.

La oss starte med de grunnleggende elementene:

  1. To grenseruter (BRD-01, BRD-02);
  2. Brannmurklynge (FW-CLUSTER);
  3. Kjernebryter (L3-CORE);
  4. En ruter som vil bli en livline (når vi løser problemet, vil vi overføre nettverksinnstillingene fra FW-CLUSTER til EMERGENCY) (EMERGENCY);
  5. Brytere for administrasjon av nettverksinfrastruktur (L2-MGMT);
  6. Virtuell maskin med Git og Ansible (VM-AUTOMASJON);
  7. En bærbar PC hvor testing og utvikling av playbooks for Ansible (Laptop-Automation) utføres.

Nettverket er konfigurert med en dynamisk OSPF-rutingsprotokoll med følgende områder:

  • Område 0 – område som inkluderer rutere som er ansvarlige for å flytte trafikk i EXCHANGE-sonen;
  • Område 1 – område som inkluderer rutere som er ansvarlige for driften av selskapets tjenester;
  • Område 2 – område som inkluderer rutere som er ansvarlige for å rute administrasjonstrafikk;
  • Område N – områder med filialnett.

På grense-rutere opprettes en virtuell ruter (VRF-INTERNET), hvor eBGP full view er installert med tilsvarende tildelt AS. iBGP er konfigurert mellom VRF-er. Selskapet har en pool av hvite adresser som er publisert på disse VRF-INTERNETTET. Noen av de hvite adressene blir rutet direkte til FW-CLUSTER (adresser som selskapets tjenester opererer på), noen rutes gjennom EXCHANGE-sonen (interne bedriftstjenester som krever eksterne IP-adresser, og eksterne NAT-adresser for kontorer). Deretter går trafikken til virtuelle rutere opprettet på L3-CORE med hvite og grå adresser (sikkerhetssoner).

Administrasjonsnettverket bruker dedikerte svitsjer og representerer et fysisk dedikert nettverk. Ledelsesnettverket er også delt inn i sikkerhetssoner.
NØD-ruteren dupliserer fysisk og logisk FW-CLUSTER. Alle grensesnitt på den er deaktivert bortsett fra de som ser inn i administrasjonsnettverket.

Automatisering og dens beskrivelse

Vi fant ut hvordan nettverket fungerer. La oss nå ta en steg-for-steg-kikk på hva vi vil gjøre for å overføre trafikk fra FW-CLUSTER til EMERGENCY:

  1. Vi deaktiverer grensesnittene på kjernesvitsjen (L3-CORE) som kobler den til FW-CLUSTER;
  2. Vi deaktiverer grensesnittene på L2-MGMT-kjernesvitsjen som kobler den til FW-CLUSTER;
  3. Vi konfigurerer EMERGENCY-ruteren (som standard er alle grensesnitt deaktivert på den, bortsett fra de som er knyttet til L2-MGMT):

  • Vi aktiverer grensesnitt på NØD;
  • Vi konfigurerer den eksterne IP-adressen (for NAT) som var på FW-klyngen;
  • Vi genererer gARP-forespørsler slik at poppy-adressene i L3-CORE arp-tabellene endres fra FW-Cluster til EMERGENCY;
  • Vi registrerer standardruten som statisk til BRD-01, BRD-02;
  • Lag NAT-regler;
  • Hev til NØD OSPF-område 1;
  • Hev til NØD OSPF-område 2;
  • Vi endrer kostnadene for ruter i område 1 til 10;
  • Vi endrer kostnaden for standardruten i område 1 til 10;
  • Vi endrer IP-adressene knyttet til L2-MGMT (til de som var på FW-CLUSTER);
  • Vi genererer gARP-forespørsler slik at valmueadressene i L2-MGMT arp-tabellene endres fra FW-CLUSTER til EMERGENCY.

Igjen går vi tilbake til den opprinnelige formuleringen av problemet. Klokken tre om morgenen, enormt stress, en feil på ethvert stadium kan føre til nye problemer. Klar til å skrive kommandoer via CLI? Ja? Ok, skyll i det minste ansiktet, drikk litt kaffe og saml viljestyrken.
Bruce, vær så snill å hjelpe gutta.

Nettverksautomatisering. En sak fra ens liv

Vel, vi fortsetter å forbedre automatiseringen vår.
Nedenfor er et diagram over hvordan spilleboken fungerer i Ansible-termer. Denne ordningen gjenspeiler det vi beskrev like ovenfor, det er bare en spesifikk implementering i Ansible.
Nettverksautomatisering. En sak fra ens liv

På dette stadiet innså vi hva som må gjøres, utviklet en lekebok, gjennomførte testing, og nå er vi klare til å lansere den.

Nok en liten lyrisk digresjon. Den enkle historien bør ikke villede deg. Prosessen med å skrive lekebøker var ikke så enkel og rask som den kan virke. Testing tok ganske mye tid, et virtuelt stativ ble laget, løsningen ble testet mange ganger, rundt 100 tester ble utført.

La oss lansere... Det er en følelse av at alt skjer veldig sakte, det er en feil et sted, noe vil ikke fungere til slutt. Følelsen av å hoppe med fallskjerm, men fallskjermen vil ikke åpne seg med en gang ... dette er normalt.

Deretter leser vi resultatet av de utførte operasjonene til Ansible playbook (IP-adressene ble erstattet av hensyn til hemmelighold):

[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml 

PLAY [------->Emergency on VCF] ********************************************************

TASK [vcf_junos_emergency_on : Disable PROD interfaces to FW-CLUSTER] *********************
changed: [vcf]

PLAY [------->Emergency on MGMT-CORE] ************************************************

TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]

PLAY [------->Emergency on] ****************************************************

TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)

TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)

TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

TASK [mk_routeros_emergency_on : Generate gARPs for MGMT interfaces] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

PLAY RECAP ************************************************************************

Ferdig!

Faktisk er det ikke helt klart, ikke glem konvergensen av dynamiske rutingprotokoller og laster et stort antall ruter inn i FIB. Vi kan ikke påvirke dette på noen måte. Vi venter. Det ordnet seg. Nå er den klar.

Og i landsbyen Vilabajo (som ikke ønsker å automatisere nettverksoppsettet) fortsetter de å vaske opp. Bruce (riktignok allerede annerledes, men ikke mindre kul) prøver å forstå hvor mye mer manuell rekonfigurering av utstyret vil finne sted.

Nettverksautomatisering. En sak fra ens liv

Jeg vil også dvele ved ett viktig punkt. Hvordan kan vi få alt tilbake? Etter en tid vil vi bringe FW-KLUSTEREN til live igjen. Dette er hovedutstyret, ikke backup, nettverket må kjøre på det.

Føler du hvordan nettverksfolk begynner å brenne ut? Teknisk direktør vil høre tusen argumenter for hvorfor dette ikke bør gjøres, hvorfor dette kan gjøres senere. Dessverre er dette hvordan nettverket fungerer fra en haug med patcher, deler og rester av sin tidligere luksus. Det viser seg å være et lappeteppe. Vår oppgave generelt, ikke i denne spesifikke situasjonen, men generelt i prinsippet, som IT-spesialister, er å bringe arbeidet til nettverket til det vakre engelske ordet "konsistens", det er veldig mangefasettert, det kan oversettes som: koherens , konsistens, logikk, sammenheng, systematikk, sammenlignbarhet, sammenheng. Alt handler om ham. Bare i denne tilstanden er nettverket håndterbart, vi forstår tydelig hva som fungerer og hvordan, vi forstår tydelig hva som må endres, om nødvendig, vi vet tydelig hvor vi skal se hvis problemer oppstår. Og bare i et slikt nettverk kan du utføre triks som de vi nettopp har beskrevet.

Faktisk ble det utarbeidet en annen spillebok, som returnerte innstillingene til deres opprinnelige tilstand. Logikken i driften er den samme (det er viktig å huske at rekkefølgen på oppgavene er veldig viktig), for ikke å forlenge en allerede ganske lang artikkel, bestemte vi oss for å ikke legge ut en liste over utførelsen av spilleboken. Etter å ha utført slike øvelser, vil du føle deg mye roligere og mer selvsikker i fremtiden, i tillegg vil eventuelle krykker som du stablet opp der, umiddelbart avsløre seg selv.

Alle kan skrive til oss og motta kildene til all den skrevne koden, sammen med alle palybooks. Kontakter i profilen.

Funn

Etter vår mening har prosesser som kan automatiseres ennå ikke utkrystallisert seg. Basert på hva vi har møtt og hva våre vestlige kolleger diskuterer, er følgende temaer synlige så langt:

  • Enhetsklargjøring;
  • Datainnsamling;
  • Rapportering;
  • Feilsøking;
  • Compliance.

Hvis det er interesse, kan vi fortsette diskusjonen om et av de oppgitte temaene.

Jeg vil også snakke litt om automatisering. Hva det burde være i vår forståelse:

  • Systemet må leve uten en person, samtidig som det forbedres av en person. Systemet skal ikke være avhengig av mennesker;
  • Driften må være sakkyndig. Det er ingen klasse spesialister som utfører rutineoppgaver. Det er eksperter som har automatisert hele rutinen og løser bare komplekse problemer;
  • Rutinemessige standardoppgaver utføres automatisk "ved å trykke på en knapp", ingen ressurser er bortkastet. Resultatet av slike oppgaver er alltid forutsigbart og forståelig.

Og hva bør disse punktene føre til:

  • Åpenhet av IT-infrastruktur (Mindre risiko ved drift, modernisering, implementering. Mindre nedetid per år);
  • Muligheten til å planlegge IT-ressurser (Kapasitetsplanleggingssystem - du kan se hvor mye som forbrukes, du kan se hvor mange ressurser som kreves i et enkelt system, og ikke ved brev og besøk til toppavdelingene);
  • Mulighet for å redusere antall IT-ansatte.

Forfattere av artikkelen: Alexander Chelovekov (CCIE RS, CCIE SP) og Pavel Kirillov. Vi er interessert i å diskutere og foreslå løsninger på temaet IT-infrastrukturautomatisering.


Kilde: www.habr.com

Legg til en kommentar