Hej, Habr!
I den här artikeln vill vi prata om automatisering av nätverksinfrastruktur. Vi kommer att presentera en arbetsstruktur för ett nätverk som fungerar i ett litet, men mycket stolt företag. Alla likheter med verklig nätverksutrustning är tillfälliga. Vi kommer att granska ett fall som inträffade i detta nätverk, vilket skulle kunna leda till långvariga driftstopp och betydande ekonomiska förluster. Lösningen på detta fall passar mycket väl in i konceptet "Automatisering av nätverksinfrastruktur". Genom automatiseringsverktyg kommer vi att visa hur man effektivt kan lösa komplexa uppgifter på kort tid och reflektera över varför dessa uppgifter bör lösas på detta sätt istället för genom konsolen.
Ansvarsfriskrivning
De främsta verktygen för automatisering som vi använder är Ansible (som automatiseringsverktyg) och Git (som lagring för Ansible-playbooks). Jag vill genast påpeka att detta inte är en introduktionsartikel där vi pratar om Ansible eller Gits logik, och förklarar grundläggande saker (till exempel vad roller, moduler, inventariefiler, variabler i Ansible är, eller vad som händer när man skriver kommandona git push eller git commit). Detta är inte en berättelse om hur man kan öva med Ansible och konfigurera NTP eller SMTP på utrustning. Det här handlar om hur man snabbt och helst utan misstag kan lösa ett nätverksproblem. Det är också önskvärt att ha en god förståelse för hur nätverket fungerar, särskilt vad TCP/IP-protokollstacken, OSPF och BGP är. Valet av Ansible och Git tar vi också för givet. Om ni fortfarande står inför valet av en specifik lösning rekommenderar vi starkt att läsa boken "Network Programmability and Automation. Skills for the Next-Generation Network Engineer" av Jason Edelman, Scott S. Lowe och Matt Oswalt.
Nu till saken.
Uppgiftsställande
Låt oss föreställa oss situationen: klockan är 3 på morgonen, du sover djupt och drömmer. Telefonen ringer. Teknikchefen ringer:
— Ja?
— ###, ####, #####, klustret av brandväggar har gått ner och går inte att starta!!!
Du gnuggar ögonen, försöker förstå vad som händer och föreställa dig hur detta överhuvudtaget kunde ske. I luren hörs hur chefens hår rivs ut, och han ber att få återkomma eftersom hans generaldirektör ringer på en andra led.
Efter en halvtimme hade ni samlat in de första inledande uppgifterna från det skift som stod på vakt, väckt alla som kunde väckas. I slutändan ljög inte den tekniska chefen, allt är som det ska, den huvudsakliga klustern av brandväggar har kraschat, och inga grundläggande åtgärder gör att den kommer till liv. Alla tjänster som företaget erbjuder fungerar inte.
Välj ett problem som passar er, alla kommer att minnas något eget. Till exempel efter nattuppdateringen, när det inte var mycket belastning, fungerade allt bra, och alla nöjda gick och lade sig. Trafiken började, och buffrarna i gränssnittet blev överfulla på grund av en bugg i nätverkskortets drivrutin.
Situationen kan väl beskrivas av Jackie Chan.
Tack, Jackie.
Situationen är inte så trevlig, eller hur?
Låt oss lämna vår nätverkskompis med hans sorgsna tankar för en stund.
Vi diskuterar hur händelserna kommer att utvecklas vidare.
Vi föreslår följande ordning av materialet
- Vi kommer att granska nätverksdiagrammet och analysera hur det fungerar;
- Vi ska beskriva hur vi överför inställningar från en router till en annan med hjälp av Ansible;
- Vi pratar om automatiseringen av IT-infrastrukturen i stort.
Nätverksdiagram och dess beskrivning
Diagram
Vi kommer att granska den logiska schemat för vår organisation. Vi kommer inte att nämna specifika hårdvarutillverkare, vilket inte spelar någon roll i denna artikel. (Den uppmärksamma läsaren kommer själv att lista ut vilken utrustning som används). Detta är verkligen en av de stora fördelarna med att arbeta med Ansible, när vi konfigurerar oss gör det oss generellt sett inget att veta vilken utrustning det handlar om. Bara för att förstå, denna utrustning kommer från kända leverantörer, som Cisco, Juniper, Check Point, Fortinet, Palo Alto ... ni kan sätta in er egen variant.
Vi har två huvuduppgifter när det kommer till trafikflytt:
- För att säkerställa publiceringen av våra tjänster som är företagets affär;
- Säkerställa kommunikation med filialer, avlägsna datacenter och externa organisationer (partners och kunder), samt filialers utgång till internet genom huvudkontoret.
Vi börjar med de grundläggande elementen:
- Två gränsrouter (BRD-01, BRD-02);
- Klustret av brandväggar (FW-CLUSTER);
- Kärnväxeln (L3-CORE);
- Routern som kommer att fungera som livboj (under problemlösningen kommer vi att flytta nätverksinställningarna från FW-CLUSTER till EMERGENCY) (EMERGENCY);
- Switchar för att hantera nätverksinfrastrukturen (L2-MGMT);
- Virtuell maskin med Git och Ansible (VM-AUTOMATION);
- Bärbara datorer som används för att testa och utveckla playbooks för Ansible (Laptop-Automation).
I nätverket har den dynamiska routingprotokollet OSPF konfigurerats med följande områden:
- Område 0 – det område som inkluderar routrar ansvariga för att flytta trafik i EXCHANGE-zonen;
- Område 1 – det område som inkluderar routrar ansvariga för att hantera företagets tjänster;
- Område 2 – det område som inkluderar routrar ansvariga för att styra management-trafik;
- Område N – områden för filialnätverk.
På gränsroutrarna har det skapats en virtuell router (VRF-INTERNET), där eBGP full view har aktiverats med lämplig tilldelad AS. Mellan VRF:erna har iBGP konfigurerats. Företaget har ett pool av vita adresser som publicerats på VRF-INTERNET. En del vita adresser routas direkt till FW-CLUSTER (adresser som används av företagets tjänster), en del routas via EXCHANGE-zonen (interna tjänster som kräver externa IP-adresser och externa NAT-adresser för kontor). Därefter går trafiken till virtuella routrar, skapade på L3-CORE med vita och grå adresser (sårbarhetszoner).
I managementnätverket används dedikerade switchar och representerar ett fysiskt avskilt nätverk. Managementnätverket är också indelat i säkerhetszoner.
Routern EMERGENCY duplicerar fysiskt och logiskt FW-CLUSTER. Alla gränssnitt är avstängda förutom de som är anslutna till managementnätverket.
Automatisering och dess beskrivning
Vi har förstått hur nätverket fungerar. Nu går vi steg för steg igenom vad vi ska göra för att omdirigera trafiken från FW-CLUSTER till EMERGENCY:
- Stäng av gränssnitten på kärnswitcharna (L3-CORE) som kopplar dem till FW-CLUSTER;
- Stäng av gränssnitten på L2-MGMT-kärnswitcharna som kopplar dem till FW-CLUSTER;
- Konfigurera routern EMERGENCY (alla gränssnitt är avstängda som standard, förutom de som är kopplade till L2-MGMT):
- Slå på gränssnitten på EMERGENCY;
- Konfigurera den externa IP-adressen (för NAT) som var på FW-Cluster;
- Generera gARP-förfrågningar för att byta MAC-adresser i arp-tabellerna från FW-Cluster till EMERGENCY;
- Skriv en standardrutt som statik till BRD-01, BRD-02;
- Skapa NAT-regler;
- Aktivera OSPF Area 1 på EMERGENCY;
- Aktivera OSPF Area 2 på EMERGENCY;
- Ändra kostnaden för rutterna i område 1 till 10;
- Ändra kostnaden för standardrutten i område 1 till 10;
- Ändra IP-adress, relaterat till L2-MGMT (till dem som var på FW-CLUSTER);
- Vi genererar gARP-förfrågningar för att MAC-adresserna i L2-MGMT-arp-tabellerna ska byta från FW-CLUSTER till EMERGENCY.
Återigen återkommer vi till den ursprungliga uppgiften. Klockan är tre på natten, enorm stress, ett misstag i något steg kan leda till nya problem. Är ni redo att skriva kommandon via CLI? Ja? Okej, gå åtminstone och tvätta ansiktet, ta en kopp kaffe och samla mod.
Bruce, snälla hjälp killarna.
Men vi fortsätter att arbeta på vår automatisering.
Nedan presenteras schemat för hur playbooken fungerar i termer av Ansible. Detta schema återspeglar det vi beskrev tidigare, nu som en konkret implementation i Ansible.
I detta skede har vi förstått vad som måste göras, utvecklat en playbook, genomfört tester, och nu är vi redo att köra den.
Ytterligare en liten lyrisk avstickare. Berättelsens lätthet bör inte lura er. Processen att skriva playbooks var inte så enkel och snabb som det kan verka. Testningen tog ganska lång tid, en virtuell miljö skapades, lösningen testades upprepade gånger och cirka 100 tester genomfördes.
Vi startar... Det känns som om allt går mycket långsamt, det finns ett fel någonstans, något kommer till slut inte att fungera. Känslan av att hoppa med fallskärm, men fallskärmen vill inte öppnas direkt... det är normalt.
Därefter läser vi resultatet av de utförda operationerna i Ansible-playbooken (IP-adresser har ersatts för att skydda identiteten):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Akut på VCF] ********************************************************
TASK [vcf_junos_emergency_on : Inaktivera PROD-gränssnitt till FW-CLUSTER] *********************
ändrat: [vcf]
PLAY [------->Akut på MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Inaktivera MGMT-gränssnitt till FW-CLUSTER] ******************
ändrat: [m9-03-sw-03-mgmt-core]
PLAY [------->Akut på] ****************************************************
TASK [mk_routeros_emergency_on : Aktivera EXT-INTERNET-gränssnitt] **************************
ändrat: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Generera gARP för EXT-INTERNET-gränssnitt] ****************
ändrat: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Aktivera statisk standardrutt till EXT-INTERNET] ****************
ändrat: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Ändra NAT-regel till EXT-INTERNET-gränssnitt] ****************
ändrat: [m9-04-r-04] => (item=12)
ändrat: [m9-04-r-04] => (item=14)
ändrat: [m9-04-r-04] => (item=15)
ändrat: [m9-04-r-04] => (item=16)
ändrat: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : Aktivera OSPF Area 1 PROD] ******************************
ändrat: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Aktivera OSPF Area 2 MGMT] *****************************
ändrat: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Ändra OSPF Area 1-gränssnittkostnader till 10] *****************
ändrat: [m9-04-r-04] => (item=VLAN-1001)
ändrat: [m9-04-r-04] => (item=VLAN-1002)
ändrat: [m9-04-r-04] => (item=VLAN-1003)
ändrat: [m9-04-r-04] => (item=VLAN-1004)
ändrat: [m9-04-r-04] => (item=VLAN-1005)
ändrat: [m9-04-r-04] => (item=VLAN-1006)
ändrat: [m9-04-r-04] => (item=VLAN-1007)
ändrat: [m9-04-r-04] => (item=VLAN-1008)
ändrat: [m9-04-r-04] => (item=VLAN-1009)
ändrat: [m9-04-r-04] => (item=VLAN-1010)
ändrat: [m9-04-r-04] => (item=VLAN-1011)
ändrat: [m9-04-r-04] => (item=VLAN-1012)
ändrat: [m9-04-r-04] => (item=VLAN-1013)
ändrat: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Ändra OSPF area1 standardkostnad till 10] ******************
ändrat: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Ändra MGMT-gränssnittens IP-adresser] ********************
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
ändern: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
TASK [mk_routeros_emergency_on : Generera gARPs för MGMT-gränssnitt] *********************
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
ändrat: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY RECAP ************************************************************************Klart!
Egentligen är det inte riktigt klart, vi får inte glömma konvergensen av dynamiska routingprotokoll och belastningen av stora mängder rutter i FIB. Vi kan inte påverka detta. Vi väntar. Det sammanföll. Nu är det klart.
I byn Vilabaggio (som inte vill automatisera nätverksinställningarna) fortsätter man att diska. Bruce (visserligen en annan, men inte mindre imponerande) försöker förstå hur mycket mer som behöver omkonfigureras manuellt.
Jag skulle också vilja lyfta fram en viktig punkt. Hur får vi allt tillbaka? Efter en tid kommer vi att återuppliva vår FW-CLUSTER. Detta är den huvudsakliga utrustningen, inte reservutrustningen, nätverket ska fungera på den.
Känner du hur nätverksteknikernas tålamod börjar prövas? Teknikchefen kommer att höra tusen argument om varför detta inte ska göras, varför det kan göras senare. Tyvärr är det så nätverket ofta fungerar, en massa lappar, bitar, rester av forna dagar av överflöd. Det blir en lapptäck. Vår övergripande uppgift, inte bara i denna specifika situation utan som IT-specialister generellt, är att leda nätverksarbetet mot det vackra engelska ordet 'consistency', vilket är mycket mångfacetterat och kan översättas till: överensstämmelse, konsekvens, logik, samordning, systematik, jämförbarhet, sammanhängande. Allt detta handlar om det. Endast i ett sådant tillstånd är nätverket hanterbart, vi förstår tydligt vad som fungerar och hur, vi är medvetna om vad som behöver förändras vid behov, vi vet exakt vart vi ska titta vid eventuella problem. Endast i ett sådant nätverk kan man utföra trick som de vi just har beskrivit.
Egentligen har en annan playbook förberetts, som återställde inställningarna till ursprungligt tillstånd. Logiken för dess funktion är densamma (det är viktigt att minnas att ordningen på uppgifterna är mycket viktig), för att inte förlänga den redan ganska långa artikeln har vi beslutat att inte publicera listningen av playbookens körning. Genom att genomföra sådana övningar kommer du att känna dig mycket lugnare och mer självsäker i framtiden, dessutom kommer alla provisoriska lösningar du har byggt upp att omedelbart avslöja sig.
Alla som är intresserade kan skriva till oss och få källkoden till allt skrivet kod, tillsammans med alla playbooks. Kontakterna finns i profilen.
Slutsatser
Enligt vår bedömning har processerna som kan automatiseras ännu inte kristalliserats. Utifrån vad vi har stött på och vad våra västerländska kollegor diskuterar, syns följande teman:
- Enhetskonfigurering;
- Datainsamling;
- Rapportering;
- Felsökning;
- Efterlevnad.
Om det finns intresse kan vi fortsätta diskussionen om något av de angivna ämnena.
Det är också värt att reflektera över automatisering. Hur bör den enligt vår mening se ut:
- Systemet ska fungera utan mänsklig inblandning, men förbättras av människor. Systemet ska inte vara beroende av människor;
- Driften ska vara expertbaserad. Det saknas en klass av specialister som utför rutinuppgifter. Det finns experter som har automatiserat all rutin och bara hanterar komplexa uppgifter;
- Rutinstandarduppgifter utförs automatiskt "med en knapptryckning", resurser sparas. Resultatet av sådana uppgifter är alltid förutsägbart och tydligt.
Och vad dessa punkter bör leda till:
- Transparens i IT-infrastrukturen (mindre risker vid drift, uppgradering och implementering. Mindre nedetid per år);
- Möjlighet att planera IT-resurser (kapacitetsplaneringssystem – att se hur mycket som förbrukas, att se vilka resurser som behövs i ett enhetligt system, snarare än genom e-post och besök hos avdelningens chefer);
- Möjlighet att minska antalet IT-personal.
Artiklarnas författare: Alexander Tjumanov (CCIE RS, CCIE SP) och Pavel Kirillov. Vi är intresserade av att diskutera och föreslå lösningar på temat automatisering av IT-infrastrukturen.
Källa: habr.com
