Hej Habr!
I den här artikeln skulle vi vilja prata om automatisering av nätverksinfrastruktur. Ett arbetsdiagram över nätverket som verkar i ett litet men mycket stolt företag kommer att presenteras. Alla matchningar med riktig nätverksutrustning är slumpmässiga. Vi kommer att titta på ett fall som inträffade i det här nätverket, vilket kunde ha lett till en affärsnedläggning under lång tid och allvarliga ekonomiska förluster. Lösningen på det här fallet passar mycket väl in i konceptet "Automation av nätverksinfrastruktur". Med hjälp av automationsverktyg kommer vi att visa hur du effektivt kan lösa komplexa problem på kort tid, och vi kommer att reflektera över varför dessa problem ska lösas på detta sätt och inte på annat sätt (via konsolen).
Villkor
Våra huvudverktyg för automatisering är Ansible (som ett automationsverktyg) och Git (som ett arkiv för Ansible playbooks). Jag vill omedelbart reservera mig för att detta inte är en introduktionsartikel, där vi pratar om logiken i Ansible eller Git, och förklarar grundläggande saker (till exempel vad är roletaskimodules, inventory-filer, variabler i Ansible, eller vad som händer när du anger git push eller git commit kommandon). Den här historien handlar inte om hur du kan träna Ansible och konfigurera NTP eller SMTP på din utrustning. Det här är en berättelse om hur du snabbt och helst kan lösa ett nätverksproblem utan fel. Det är också tillrådligt att ha en god förståelse för hur nätverket fungerar, i synnerhet vad TCP/IP, OSPF, BGP-protokollstacken är. Vi tar också valet av Ansible och Git ur ekvationen. Om du ändå behöver välja en specifik lösning rekommenderar vi starkt att du läser boken “Network Programmability and Automation. Skills for the Next-Generation Network Engineer" av Jason Edelman, Scott S. Lowe och Matt Oswalt.
Nu till affärer.
Problem uttalande
Låt oss föreställa oss en situation: klockan 3 på morgonen sover du snabbt och drömmer. Telefonsamtal. Den tekniska chefen ringer:
- Ja?
— ###, ####, #####, brandväggsklustret har fallit och stiger inte!!!
Du gnuggar dina ögon, försöker förstå vad som händer och föreställer dig hur detta ens kunde hända. På telefonen kan du höra håret på regissörens huvud slita, och han ber att få ringa tillbaka eftersom generalen ringer honom på andra linjen.
En halvtimme senare samlade du de första introduktionsanteckningarna från vaktskiftet, väckte alla som kunde väckas. Som ett resultat ljög den tekniska direktören inte, allt är som det är, huvudklustret av brandväggar har fallit och inga grundläggande kroppsrörelser får honom till sinnes. Alla tjänster som företaget erbjuder fungerar inte.
Välj ett problem efter din smak, alla kommer ihåg något annat. Till exempel, efter en uppdatering över natten i frånvaro av tung belastning, fungerade allt bra, och alla gick och la sig nöjda. Trafiken började flöda och gränssnittsbuffertar började flöda över på grund av en bugg i nätverkskortets drivrutin.
Jackie Chan kan väl beskriva situationen.
Tack, Jackie.
Inte en särskilt trevlig situation, eller hur?
Låt oss lämna vårt nätverk bror med sina sorgliga tankar ett tag.
Låt oss diskutera hur händelserna kommer att utvecklas vidare.
Vi föreslår följande presentationsordning för materialet
- Låt oss titta på nätverksdiagrammet och se hur det fungerar;
- Vi kommer att beskriva hur vi överför inställningar från en router till en annan med Ansible;
- Låt oss prata om automatisering av IT-infrastrukturen som helhet.
Nätverksdiagram och beskrivning
Schemat
Låt oss överväga det logiska diagrammet för vår organisation. Vi kommer inte att nämna specifika utrustningstillverkare, för denna artikel spelar det ingen roll (Den uppmärksamma läsaren kommer att gissa vilken typ av utrustning som används). Det här är bara en av de goda fördelarna med att arbeta med Ansible; när vi konfigurerar, bryr vi oss i allmänhet inte om vilken typ av utrustning det är. Bara för att förstå, detta är utrustning från välkända leverantörer, som Cisco, Juniper, Check Point, Fortinet, Palo Alto...du kan ersätta ditt eget alternativ.
Vi har två huvuduppgifter för att flytta trafik:
- Säkerställa publicering av våra tjänster, som är företagets verksamhet;
- Tillhandahålla kommunikation med filialer, ett fjärrdatacenter och tredjepartsorganisationer (partners och kunder), samt tillgång till filialer till Internet via centralkontoret.
Låt oss börja med de grundläggande delarna:
- Två gränsroutrar (BRD-01, BRD-02);
- Brandväggskluster (FW-CLUSTER);
- Kärnomkopplare (L3-CORE);
- En router som kommer att bli en livlina (när vi löser problemet kommer vi att överföra nätverksinställningarna från FW-CLUSTER till EMERGENCY) (EMERGENCY);
- Switchar för hantering av nätverksinfrastruktur (L2-MGMT);
- Virtuell maskin med Git och Ansible (VM-AUTOMATION);
- En bärbar dator på vilken testning och utveckling av playbooks för Ansible (Laptop-Automation) utförs.
Nätverket är konfigurerat med ett dynamiskt OSPF-routingprotokoll med följande områden:
- Område 0 – område som inkluderar routrar som ansvarar för att flytta trafik i EXCHANGE-zonen;
- Område 1 – område som inkluderar routrar som ansvarar för driften av företagets tjänster;
- Område 2 – område som inkluderar routrar som ansvarar för routing av ledningstrafik;
- Område N – områden med filialnät.
På gränsroutrar skapas en virtuell router (VRF-INTERNET), på vilken eBGP full view installeras med motsvarande tilldelade AS. iBGP konfigureras mellan VRF:er. Företaget har en pool av vita adresser som publiceras på dessa VRF-INTERNET. Vissa av de vita adresserna dirigeras direkt till FW-CLUSTER (adresser som företagets tjänster verkar på), en del dirigeras genom EXCHANGE-zonen (interna företagstjä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åa adresser (säkerhetszoner).
Managementnätverket använder dedikerade switchar och representerar ett fysiskt dedikerat nätverk. Ledningsnätverket är också indelat i säkerhetszoner.
EMERGENCY-routern duplicerar fysiskt och logiskt FW-CLUSTER. Alla gränssnitt på den är inaktiverade förutom de som tittar in i hanteringsnätverket.
Automation och dess beskrivning
Vi kom på hur nätverket fungerar. Låt oss nu ta en steg-för-steg titt på vad vi kommer att göra för att överföra trafik från FW-CLUSTER till EMERGENCY:
- Vi inaktiverar gränssnitten på kärnomkopplaren (L3-CORE) som ansluter den till FW-CLUSTER;
- Vi inaktiverar gränssnitten på L2-MGMT-kärnväxeln som ansluter den till FW-CLUSTER;
- Vi konfigurerar EMERGENCY-routern (som standard är alla gränssnitt inaktiverade på den, förutom de som är associerade med L2-MGMT):
- Vi aktiverar gränssnitt på NÖD;
- Vi konfigurerar den externa IP-adressen (för NAT) som fanns på FW-klustret;
- Vi genererar gARP-förfrågningar så att poppy-adresserna i L3-CORE arp-tabellerna ändras från FW-Cluster till EMERGENCY;
- Vi registrerar standardrutten som statisk till BRD-01, BRD-02;
- Skapa NAT-regler;
- Lyft till NÖD OSPF-område 1;
- Lyft till NÖD OSPF-område 2;
- Vi ändrar kostnaden för rutter i område 1 till 10;
- Vi ändrar kostnaden för standardrutten i område 1 till 10;
- Vi ändrar IP-adresserna associerade med L2-MGMT (till de som fanns på FW-CLUSTER);
- Vi genererar gARP-förfrågningar så att poppy-adresserna i L2-MGMT arp-tabellerna ändras från FW-CLUSTER till EMERGENCY.
Återigen, vi återgår till den ursprungliga formuleringen av problemet. Klockan tre på morgonen, enorm stress, ett misstag i vilket skede som helst kan leda till nya problem. Är du redo att skriva kommandon via CLI? Ja? Ok, gå åtminstone att skölja ansiktet, dricka kaffe och samla din viljestyrka.
Bruce, snälla hjälp killarna.
Tja, vi fortsätter att förbättra vår automatisering.
Nedan är ett diagram över hur spelboken fungerar i Ansible-termer. Det här schemat återspeglar det vi beskrev precis ovan, det är bara en specifik implementering i Ansible.
I det här skedet insåg vi vad som måste göras, utvecklade en spelbok, genomförde tester och nu är vi redo att lansera den.
Ännu en liten lyrisk utvikning. Lättheten i berättelsen bör inte vilseleda dig. Processen att skriva lekböcker var inte så enkel och snabb som det kan verka. Testningen tog ganska lång tid, en virtuell monter skapades, lösningen testades många gånger, cirka 100 tester genomfördes.
Låt oss lansera... Det finns en känsla av att allt händer väldigt långsamt, det finns ett fel någonstans, något kommer inte att fungera till slut. Känslan av att hoppa med fallskärm, men fallskärmen vill inte öppnas direkt... detta är normalt.
Därefter läser vi resultatet av de utförda operationerna i Ansible-spelboken (IP-adresserna ersattes av sekretesskäl):
[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 ************************************************************************Klart!
Faktum är att det inte är helt klart, glöm inte konvergensen av dynamiska routingprotokoll och ladda ett stort antal rutter till FIB. Vi kan inte påverka detta på något sätt. Vi väntar. Det löste sig. Nu är det klart.
Och i byn Vilabajo (som inte vill automatisera nätverksuppställningen) fortsätter man att diska. Bruce (visserligen redan annorlunda, men inte mindre cool) försöker förstå hur mycket mer manuell omkonfigurering av utrustningen kommer att ske.
Jag skulle också vilja uppehålla mig vid en viktig punkt. Hur kan vi få tillbaka allt? Efter en tid kommer vi att återuppliva vårt FW-CLUSTER. Detta är huvudutrustningen, inte backup, nätverket måste köras på den.
Känner du hur nätverkare börjar brinna ut? Den tekniska direktören kommer att få höra tusen argument för varför detta inte bör göras, varför detta kan göras senare. Tyvärr är det så här nätverket fungerar från ett gäng patchar, bitar och rester av dess tidigare lyx. Det visar sig vara ett lapptäcke. Vår uppgift i allmänhet, inte i denna specifika situation, utan i allmänhet i princip, som IT-specialister, är att föra nätverkets arbete till det vackra engelska ordet "konsistens", det är mycket mångfacetterat, det kan översättas som: koherens , konsistens, logik, koherens, systematik, jämförbarhet, koherens. Allt handlar om honom. Endast i detta tillstånd är nätverket hanterbart, vi förstår tydligt vad som fungerar och hur, vi förstår tydligt vad som behöver ändras, om det behövs, vi vet tydligt var vi ska leta om problem uppstår. Och bara i ett sådant nätverk kan du utföra trick som de vi just har beskrivit.
Faktiskt förbereddes en annan spelbok som återställde inställningarna till deras ursprungliga tillstånd. Logiken i dess funktion är densamma (det är viktigt att komma ihåg att ordningen på uppgifterna är mycket viktig), för att inte förlänga en redan ganska lång artikel, bestämde vi oss för att inte lägga upp en lista över spelbokens utförande. Efter att ha genomfört sådana övningar kommer du att känna dig mycket lugnare och mer självsäker i framtiden, dessutom kommer alla kryckor som du samlat där omedelbart att avslöja sig.
Vem som helst kan skriva till oss och få källorna till all skriven kod, tillsammans med alla palybooks. Kontakter i profilen.
Resultat
Enligt vår uppfattning har processer som kan automatiseras ännu inte utkristalliserats. Baserat på vad vi har stött på och vad våra västerländska kollegor diskuterar, är följande teman synliga än så länge:
- Enhetsförsörjning;
- Datainsamling;
- Rapportering;
- Felsökning;
- Compliance.
Om det finns intresse kan vi fortsätta diskussionen om något av de givna ämnena.
Jag skulle också vilja prata lite om automatisering. Vad det borde vara i vår förståelse:
- Systemet måste leva utan en person, samtidigt som det förbättras av en person. Systemet ska inte vara beroende av människor;
- Driften måste vara expert. Det finns ingen klass av specialister som utför rutinuppgifter. Det finns experter som har automatiserat hela rutinen och bara löser komplexa problem;
- Rutinmässiga standarduppgifter görs automatiskt "med en knapptryckning", inga resurser slösas bort. Resultatet av sådana uppgifter är alltid förutsägbart och begripligt.
Och vad ska dessa punkter leda till:
- Transparens av IT-infrastruktur (Mindre risker för drift, modernisering, implementering. Mindre stillestånd per år);
- Möjligheten att planera IT-resurser (Kapacitetsplaneringssystem - du kan se hur mycket som förbrukas, du kan se hur många resurser som krävs i ett enda system, och inte genom brev och besök på de översta avdelningarna);
- Möjlighet att minska antalet IT-personal.
Författare till artikeln: Alexander Chelovekov (CCIE RS, CCIE SP) och Pavel Kirillov. Vi är intresserade av att diskutera och föreslå lösningar på temat automatisering av IT-infrastruktur.
Källa: will.com