Hej Habr!
I denne artikel vil vi gerne tale om automatisering af netværksinfrastruktur. Et arbejdsdiagram over netværket, der opererer i en lille, men meget stolt virksomhed vil blive præsenteret. Alle kampe med rigtigt netværksudstyr er tilfældige. Vi vil se på en sag, der opstod i dette netværk, som kunne have ført til en virksomhedsnedlukning i lang tid og alvorlige økonomiske tab. Løsningen på denne sag passer meget godt ind i konceptet "Automation af netværksinfrastruktur". Ved hjælp af automatiseringsværktøjer vil vi vise, hvordan du effektivt kan løse komplekse problemer på kort tid, og vi vil reflektere over, hvorfor disse problemer skal løses på denne måde og ikke på anden måde (via konsollen).
Ansvarsfraskrivelse
Vores vigtigste værktøjer til automatisering er Ansible (som et automatiseringsværktøj) og Git (som et opbevaringssted for Ansible playbooks). Jeg vil straks tage forbehold for, at dette ikke er en introduktionsartikel, hvor vi taler om logikken i Ansible eller Git, og forklarer grundlæggende ting (f.eks. hvad er roletaskimoduler, inventarfiler, variabler i Ansible, eller hvad der sker, når du indtaster git push eller git commit kommandoerne). Denne historie handler ikke om, hvordan du kan øve Ansible og konfigurere NTP eller SMTP på dit udstyr. Dette er en historie om, hvordan du hurtigt og helst kan løse et netværksproblem uden fejl. Det er også tilrådeligt at have en god forståelse af, hvordan netværket fungerer, især hvad TCP/IP, OSPF, BGP protokolstakken er. Vi tager også valget af Ansible og Git ud af ligningen. Hvis du stadig skal vælge en specifik løsning, anbefaler vi stærkt at læse bogen “Netværksprogrammerbarhed og automatisering. Skills for the Next-Generation Network Engineer" af Jason Edelman, Scott S. Lowe og Matt Oswalt.
Nu til sagen.
Formulering af problemet
Lad os forestille os en situation: Klokken 3 om morgenen sover du hurtigt og drømmer. Telefon opkald. Teknisk direktør ringer:
- Ja?
— ###, ####, #####, firewall-klyngen er faldet og stiger ikke!!!
Du gnider dine øjne, prøver at forstå, hvad der sker, og forestiller dig, hvordan dette overhovedet kunne ske. I telefonen kan man høre håret på direktørens hoved rive, og han beder om at ringe tilbage, fordi generalen ringer til ham på anden linje.
En halv time senere samlede du de første indledende notater fra vagtvagten, vækkede alle, der kunne vækkes. Som et resultat løj den tekniske direktør ikke, alt er som det er, hovedklyngen af firewalls er faldet, og ingen grundlæggende kropsbevægelser bringer ham til fornuft. Alle de tjenester, som virksomheden tilbyder, virker ikke.
Vælg et problem efter din smag, alle vil huske noget forskelligt. For eksempel, efter en opdatering natten over i mangel af en tung belastning, fungerede alt godt, og alle gik glade i seng. Trafikken begyndte at flyde, og grænsefladebuffere begyndte at flyde over på grund af en fejl i netværkskortdriveren.
Jackie Chan kan godt beskrive situationen.
Tak, Jackie.
Ikke en særlig behagelig situation, vel?
Lad os forlade vores netværk bro med hans triste tanker for et stykke tid.
Lad os diskutere, hvordan begivenheder vil udvikle sig yderligere.
Vi foreslår følgende rækkefølge for præsentation af materialet
- Lad os se på netværksdiagrammet og se, hvordan det virker;
- Vi vil beskrive, hvordan vi overfører indstillinger fra en router til en anden ved hjælp af Ansible;
- Lad os tale om automatisering af IT-infrastrukturen som helhed.
Netværksdiagram og beskrivelse
Ordningen
Lad os overveje det logiske diagram af vores organisation. Vi vil ikke nævne specifikke udstyrsproducenter; i forbindelse med denne artikel er det ligegyldigt (Den opmærksomme læser vil gætte, hvilken slags udstyr der bruges). Dette er blot en af de gode fordele ved at arbejde med Ansible; når vi konfigurerer, er vi generelt ligeglade med, hvilken slags udstyr det er. Bare for at forstå, dette er udstyr fra velkendte leverandører, såsom Cisco, Juniper, Check Point, Fortinet, Palo Alto...du kan erstatte din egen mulighed.
Vi har to hovedopgaver til at flytte trafik:
- Sikre offentliggørelse af vores tjenester, som er virksomhedens virksomhed;
- Sørg for kommunikation med filialer, et fjerntliggende datacenter og tredjepartsorganisationer (partnere og kunder), samt filialers adgang til internettet via hovedkontoret.
Lad os starte med de grundlæggende elementer:
- To grænseroutere (BRD-01, BRD-02);
- Firewall Cluster (FW-CLUSTER);
- Kerneafbryder (L3-CORE);
- En router, der bliver en livline (efterhånden som vi løser problemet, overfører vi netværksindstillingerne fra FW-CLUSTER til EMERGENCY) (EMERGENCY);
- Switche til netværksinfrastrukturstyring (L2-MGMT);
- Virtuel maskine med Git og Ansible (VM-AUTOMATION);
- En bærbar computer, hvorpå der udføres test og udvikling af playbooks til Ansible (Laptop-Automation).
Netværket er konfigureret med en dynamisk OSPF-routingprotokol med følgende områder:
- Område 0 – område, der inkluderer routere, der er ansvarlige for at flytte trafik i EXCHANGE-zonen;
- Område 1 – område, der omfatter routere, der er ansvarlige for driften af virksomhedens tjenester;
- Område 2 – område, der omfatter routere, der er ansvarlige for routing af styringstrafik;
- Område N – områder af filialnet.
På grænseroutere oprettes en virtuel router (VRF-INTERNET), hvorpå eBGP full view er installeret med det tilsvarende tildelte AS. iBGP er konfigureret mellem VRF'er. Virksomheden har en pulje af hvide adresser, der offentliggøres på disse VRF-INTERNET. Nogle af de hvide adresser dirigeres direkte til FW-CLUSTER (adresser, som virksomhedens tjenester opererer på), nogle dirigeres gennem EXCHANGE-zonen (interne virksomhedstjenester, der kræver eksterne IP-adresser, og eksterne NAT-adresser til kontorer). Dernæst går trafikken til virtuelle routere oprettet på L3-CORE med hvide og grå adresser (sikkerhedszoner).
Management-netværket bruger dedikerede switches og repræsenterer et fysisk dedikeret netværk. Administrationsnetværket er også opdelt i sikkerhedszoner.
NØD-routeren dublerer fysisk og logisk FW-CLUSTER. Alle grænseflader på den er deaktiveret undtagen dem, der ser ind i administrationsnetværket.
Automatisering og dens beskrivelse
Vi fandt ud af, hvordan netværket fungerer. Lad os nu tage et trin-for-trin kig på, hvad vi vil gøre for at overføre trafik fra FW-CLUSTER til EMERGENCY:
- Vi deaktiverer grænsefladerne på kerne-switchen (L3-CORE), der forbinder den til FW-CLUSTER;
- Vi deaktiverer grænsefladerne på L2-MGMT-kerneswitchen, der forbinder den til FW-KLUSTEREN;
- Vi konfigurerer EMERGENCY-routeren (som standard er alle grænseflader deaktiveret på den, undtagen dem, der er forbundet med L2-MGMT):
- Vi aktiverer grænseflader på NØD;
- Vi konfigurerer den eksterne IP-adresse (til NAT), der var på FW-klyngen;
- Vi genererer gARP-anmodninger, så poppy-adresserne i L3-CORE arp-tabellerne ændres fra FW-Cluster til EMERGENCY;
- Vi registrerer standardruten som statisk til BRD-01, BRD-02;
- Opret NAT-regler;
- Hæv til NØD OSPF-område 1;
- Hæv til NØD OSPF-område 2;
- Vi ændrer prisen på ruter i område 1 til 10;
- Vi ændrer prisen på standardruten i område 1 til 10;
- Vi ændrer IP-adresserne forbundet med L2-MGMT (til dem, der var på FW-CLUSTER);
- Vi genererer gARP-anmodninger, så poppy-adresserne i L2-MGMT arp-tabellerne ændres fra FW-CLUSTER til EMERGENCY.
Igen vender vi tilbage til den oprindelige formulering af problemet. Klokken tre om morgenen, enorm stress, en fejl på ethvert tidspunkt kan føre til nye problemer. Klar til at skrive kommandoer via CLI? Ja? Ok, skyl i det mindste dit ansigt, drik noget kaffe og saml din viljestyrke.
Bruce, vær venlig at hjælpe fyrene.
Nå, vi fortsætter med at forbedre vores automatisering.
Nedenfor er et diagram over, hvordan playbook fungerer i Ansible termer. Denne ordning afspejler det, vi beskrev lige ovenfor, det er bare en specifik implementering i Ansible.
På dette tidspunkt indså vi, hvad der skal gøres, udviklede en playbook, gennemførte test, og nu er vi klar til at lancere den.
Endnu en lille lyrisk digression. Historiens lethed bør ikke vildlede dig. Processen med at skrive playbooks var ikke så enkel og hurtig, som det kunne se ud. Testning tog ret lang tid, en virtuel stand blev oprettet, løsningen blev testet mange gange, omkring 100 test blev udført.
Lad os starte... Der er en følelse af, at alt sker meget langsomt, der er en fejl et eller andet sted, noget vil ikke fungere i sidste ende. Følelsen af at hoppe med faldskærm, men faldskærmen vil ikke åbne med det samme... det er normalt.
Dernæst læste vi resultatet af de udførte handlinger af Ansible-spillebogen (IP-adresserne blev erstattet af hensyn til hemmeligholdelse):
[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 ************************************************************************Udført!
Faktisk er det ikke helt klar, glem ikke konvergensen af dynamiske routingprotokoller og indlæsning af et stort antal ruter i FIB. Det kan vi ikke påvirke på nogen måde. Vi venter. Det lykkedes. Nu er den klar.
Og i landsbyen Vilabajo (som ikke ønsker at automatisere netværksopsætningen) fortsætter de med at vaske op. Bruce (indrømmet, allerede anderledes, men ikke mindre cool) forsøger at forstå, hvor meget mere manuel omkonfiguration af udstyret vil finde sted.
Jeg vil også gerne dvæle ved et vigtigt punkt. Hvordan kan vi få alt tilbage? Efter et stykke tid vil vi bringe vores FW-CLUSTER til live igen. Dette er hovedudstyret, ikke backup, netværket skal køre på det.
Føler du, hvordan netværksfolk begynder at brænde ud? Den tekniske direktør vil høre tusinde argumenter for, hvorfor det ikke skal lade sig gøre, hvorfor det kan lade sig gøre senere. Desværre er det sådan, netværket fungerer ud fra en masse patches, stykker og rester af dets tidligere luksus. Det viser sig at være et patchwork-tæppe. Vores opgave generelt, ikke i denne specifikke situation, men generelt i princippet, som IT-specialister, er at bringe netværkets arbejde til det smukke engelske ord "konsistens", det er meget mangefacetteret, det kan oversættes til: sammenhæng , konsistens, logik, sammenhæng, systematik, sammenlignelighed, sammenhæng. Det hele handler om ham. Kun i denne tilstand er netværket overskueligt, vi forstår tydeligt, hvad der virker og hvordan, vi forstår tydeligt, hvad der skal ændres, om nødvendigt ved vi tydeligt, hvor vi skal kigge, hvis der opstår problemer. Og kun i et sådant netværk kan du udføre tricks som dem, vi lige har beskrevet.
Faktisk blev der udarbejdet en anden playbook, som returnerede indstillingerne til deres oprindelige tilstand. Logikken i dens drift er den samme (det er vigtigt at huske, at rækkefølgen af opgaver er meget vigtig), for ikke at forlænge en allerede ret lang artikel, besluttede vi ikke at sende en liste over udførelse af playbook. Efter at have udført sådanne øvelser vil du føle dig meget roligere og mere selvsikker i fremtiden, desuden vil eventuelle krykker, som du har stablet op der, straks afsløre sig selv.
Alle kan skrive til os og modtage kilderne til al den skrevne kode sammen med alle palybooks. Kontakter i profilen.
Fund
Efter vores mening er processer, der kan automatiseres, endnu ikke udkrystalliseret. Baseret på det, vi er stødt på, og hvad vores vestlige kolleger diskuterer, er følgende temaer synlige indtil videre:
- Enhedsforsyning;
- Dataindsamling;
- Rapportering;
- Fejlfinding;
- Overholdelse.
Hvis der er interesse, kan vi fortsætte diskussionen om et af de givne emner.
Jeg vil også gerne tale lidt om automatisering. Hvad det burde være i vores forståelse:
- Systemet skal leve uden en person, samtidig med at det bliver forbedret af en person. Systemet bør ikke afhænge af mennesker;
- Betjening skal være sagkyndig. Der er ingen klasse af specialister, der udfører rutineopgaver. Der er eksperter, der har automatiseret hele rutinen og kun løser komplekse problemer;
- Rutinemæssige standardopgaver udføres automatisk "ved et tryk på en knap", ingen ressourcer spildes. Resultatet af sådanne opgaver er altid forudsigeligt og forståeligt.
Og hvad skal disse punkter føre til:
- Gennemsigtighed af IT-infrastruktur (Mindre risici ved drift, modernisering, implementering. Mindre nedetid om året);
- Evnen til at planlægge it-ressourcer (Kapacitetsplanlægningssystem - du kan se hvor meget der forbruges, du kan se hvor mange ressourcer der kræves i et enkelt system, og ikke ved breve og besøg i de øverste afdelinger);
- Mulighed for at reducere antallet af IT-medarbejdere.
Forfattere af artiklen: Alexander Chelovekov (CCIE RS, CCIE SP) og Pavel Kirillov. Vi er interesserede i at diskutere og foreslå løsninger på emnet IT-infrastrukturautomatisering.
Kilde: www.habr.com