Ciao, Habr!
In questo articolo vorremmo parlare dell'automazione delle infrastrutture di rete. Verrà presentato uno schema di rete funzionante in una piccola, ma molto orgogliosa azienda. Ogni somiglianza con apparecchiature di rete reali è puramente casuale. Esamineremo un caso che è successo in questa rete, che avrebbe potuto portare a una fermata dell'attività prolungata e a gravi perdite economiche. La soluzione a questo caso si sposa perfettamente con il concetto di "Automazione delle infrastrutture di rete". Con l'ausilio degli strumenti di automazione, mostreremo come affrontare con efficienza compiti complessi in tempi ristretti e rifletteremo su perché sia più vantaggioso risolvere questi compiti in questo modo piuttosto che in altro modo (tramite console).
Avviso
I principali strumenti per l'automazione sono Ansible (come mezzo di automazione) e Git (come repository dei playbook Ansible). Vorrei chiarire subito che questo non è un articolo introduttivo in cui parliamo della logica di funzionamento di Ansible o Git e spieghiamo le cose di base (ad esempio, cosa sono i ruoli, i moduli, i file di inventario, le variabili in Ansible, o cosa succede quando si inseriscono i comandi git push o git commit). Questa storia non riguarda come esercitarsi con Ansible, o configurare NTP o SMTP sull'hardware. Questa storia riguarda come risolvere rapidamente, e auspicabilmente senza errori, un problema di rete. È anche auspicabile avere una buona comprensione di come funziona la rete, in particolare, cosa sia lo stack dei protocolli TCP/IP, OSPF, BGP. La scelta di Ansible e Git sarà anch'essa messa da parte. Se siete ancora indecisi su una soluzione specifica, vi raccomandiamo di leggere il libro "Network Programmability and Automation. Skills for the Next-Generation Network Engineer" di Jason Edelman, Scott S. Lowe e Matt Oswalt.
Ora passiamo al punto.
Definizione del compito
Immaginate la situazione: sono le 3 di notte, state dormendo profondamente e sognando. Suona il telefono. È il direttore tecnico:
— Pronto?
— ###, ####, #####, il cluster dei firewall è andato in crash e non si riavvia!!!
Vi strofinate gli occhi, cercate di comprendere cosa stia succedendo e immaginare come sia potuto accadere. Nella cornetta si sente come i capelli del direttore stiano strapazzandosi, e lui chiede di richiamare perché sull'altra linea sta chiamando l'amministratore delegato.
Dopo mezz'ora avete raccolto le prime informazioni dal turno di guardia, avete svegliato tutti quelli che potevate svegliare. In effetti, il CTO non ha mentito, è tutto vero, il cluster principale dei firewall è andato giù, e nessuna manovra di base riesce a farlo riprendere. Tutti i servizi offerti dall'azienda non funzionano.
Scegliete un problema a vostro piacere, ognuno ricorderà qualcosa di personale. Per esempio, dopo l'aggiornamento notturno, in assenza di un grande carico, tutto funzionava bene e tutti soddisfatti sono andati a dormire. È cominciato il traffico, e i buffer delle interfacce hanno iniziato a riempirsi a causa di un bug nel driver della scheda di rete.
La situazione può essere ben descritta da Jackie Chan.
Grazie, Jackie.
Non è una situazione molto piacevole, vero?
Lasciamo da parte il nostro amico di rete con i suoi pensieri tristi.
Discutiamo di come si svilupperanno gli eventi in futuro.
Proponiamo il seguente ordine di esposizione dei materiali
- Esamineremo lo schema di rete e analizzeremo come funziona;
- Descriveremo come trasferiamo le impostazioni da un router all'altro utilizzando Ansible;
- Parleremo dell'automazione dell'infrastruttura IT in generale.
Schema di rete e sua descrizione
Schema
Esamineremo lo schema logico della nostra organizzazione. Non nomineremo i produttori specifici dell'hardware, in questo articolo non ha importanza. (Il lettore attento dedurrà da solo quale hardware viene utilizzato). Questo è uno dei buoni vantaggi di lavorare con Ansible, nella configurazione non ci preoccupiamo affatto di quale sia l'hardware. Solo per comprendere, questo hardware è di noti fornitori, come Cisco, Juniper, Check Point, Fortinet, Palo Alto... potete inserire la vostra scelta.
Abbiamo due compiti principali per il trasferimento del traffico:
- Garantire la pubblicazione dei nostri servizi, che costituiscono il business dell'azienda;
- Garantire la connessione con le filiali, il data center remoto e le organizzazioni esterne (partner e clienti), così come l'accesso di queste filiali a Internet attraverso l'ufficio centrale.
Iniziamo dagli elementi principali:
- Due router di confine (BRD-01, BRD-02);
- Cluster di firewall (FW-CLUSTER);
- Switch del core (L3-CORE);
- Router che diventerà un salvagente (nel corso della soluzione del problema trasferiremo le impostazioni di rete da FW-CLUSTER a EMERGENCY) (EMERGENCY);
- Switch per gestire l'infrastruttura di rete (L2-MGMT);
- Macchina virtuale con Git e Ansible (VM-AUTOMATION);
- Laptop utilizzato per il testing e lo sviluppo dei playbook per Ansible (Laptop-Automation).
Nella rete è configurato il protocollo di routing dinamico OSPF con le seguenti aree:
- Area 0 – area che comprende i router responsabili del trasferimento del traffico nella zona EXCHANGE;
- Area 1 – area che comprende i router responsabili delle operazioni dei servizi aziendali;
- Area 2 – area che comprende i router responsabili del routing del traffico di management;
- Area N – aree delle reti filiali.
Sui router di confine è stato creato un router virtuale (VRF-INTERNET), su cui è stato attivato eBGP full view con il rispettivo AS assegnato. Tra i VRF è stato configurato iBGP. L'azienda dispone di un pool di indirizzi pubblici che sono stati pubblicati su questi VRF-INTERNET. Parte degli indirizzi pubblici è instradato direttamente verso il FW-CLUSTER (gli indirizzi su cui operano i servizi aziendali), mentre parte viene instradata attraverso la zona EXCHANGE (servizi interni dell'azienda che richiedono indirizzi IP esterni e indirizzi esterni NAT per gli uffici). Il traffico quindi potrebbe arrivare ai router virtuali creati su L3-CORE con indirizzi pubblici e privati (zone di sicurezza).
Nella rete di management si utilizzano switch dedicati e rappresentano una rete fisicamente separata. La rete di management è anche suddivisa in zone di sicurezza.
Il router EMERGENCY duplica fisicamente e logicamente il FW-CLUSTER. Tutte le interfacce sono disattivate, tranne quelle collegate alla rete di management.
Automazione e sua descrizione
Abbiamo capito come funziona la rete. Ora esaminiamo passo dopo passo cosa faremo per trasferire il traffico dal FW-CLUSTER all'EMERGENCY:
- Disattiviamo le interfacce sullo switch core (L3-CORE) che lo collegano al FW-CLUSTER;
- Disattiviamo le interfacce sullo switch core L2-MGMT che lo collegano al FW-CLUSTER;
- Configuriamo il router EMERGENCY (di default tutte le interfacce sono disattivate, tranne quelle collegate a L2-MGMT):
- Attiviamo le interfacce su EMERGENCY;
- Configuriamo l'indirizzo IP esterno (per NAT) che era su FW-Cluster;
- Generiamo richieste gARP affinché nelle tabelle ARP di L3-CORE si sostituiscano gli indirizzi MAC da FW-Cluster a EMERGENCY;
- Scriviamo il percorso predefinito statico verso BRD-01, BRD-02;
- Creiamo regole NAT;
- Attiviamo OSPF Area 1 su EMERGENCY;
- Attiviamo OSPF Area 2 su EMERGENCY;
- Modifichiamo il costo dei percorsi in Area 1 a 10;
- Modifichiamo il costo del percorso predefinito in Area 1 a 10;
- Modifica indirizzi IP, collegati a L2-MGMT (a quelli che erano su FW-CLUSTER);
- Stiamo generando richieste gARP affinché negli arp-table L2-MGMT cambi gli indirizzi MAC da FW-CLUSTER a EMERGENCY.
Tornando nuovamente all'impostazione iniziale del compito. Sono le tre di notte, un'enorme tensione, un errore in qualsiasi fase può portare a nuovi problemi. Siete pronti a inserire comandi tramite CLI? Sì? Ok, andate almeno a sciacquarvi la faccia, bevete un caffè e raccogliete la vostra determinazione.
Bruce, aiuta per favore i ragazzi.
E noi continuiamo a lavorare sulla nostra automazione.
Di seguito è riportato uno schema del funzionamento del playbook in termini di Ansible. Questo schema riflette ciò che abbiamo descritto poc'anzi, ma ora è una realizzazione concreta in Ansible.
A questo punto abbiamo compreso cosa dobbiamo fare, abbiamo sviluppato il playbook, effettuato test e ora siamo pronti a lanciarlo.
Un'ultima piccola digressione. La facilità di narrazione non deve ingannarvi. Il processo di scrittura dei playbook non è stato semplice e veloce come potrebbe sembrare. I test hanno richiesto abbastanza tempo, è stata creata una piattaforma virtuale, la soluzione è stata ripetutamente testata, e sono stati condotti circa 100 test.
Avviamo... C'è la sensazione che tutto stia accadendo molto lentamente, ci deve essere un errore da qualche parte, qualcosa alla fine non funzionerà. È come saltare con il paracadute e il paracadute non sembra voler aprirsi subito... è normale.
Successivamente leggiamo i risultati delle operazioni eseguite dal playbook Ansible (gli indirizzi IP sono stati sostituiti per motivi di riservatezza):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Emergenza su VCF] ********************************************************
TASK [vcf_junos_emergency_on : Disabilita le interfacce PROD per FW-CLUSTER] *********************
modificato: [vcf]
PLAY [------->Emergenza su MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Disabilita le interfacce MGMT per FW-CLUSTER] ******************
modificato: [m9-03-sw-03-mgmt-core]
PLAY [------->Emergenza su] ****************************************************
TASK [mk_routeros_emergency_on : Abilita l'interfaccia EXT-INTERNET] **************************
modificato: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Genera gARP per l'interfaccia EXT-INTERNET] ****************
modificato: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Abilita la route predefinita statica verso EXT-INTERNET] ****************
modificato: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Modifica la regola NAT per l'interfaccia EXT-INTERNET] ****************
modificato: [m9-04-r-04] => (item=12)
modificato: [m9-04-r-04] => (item=14)
modificato: [m9-04-r-04] => (item=15)
modificato: [m9-04-r-04] => (item=16)
modificato: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : Abilita OSPF Area 1 PROD] ******************************
modificato: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Abilita OSPF Area 2 MGMT] *****************************
modificato: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Modifica i costi delle interfacce OSPF Area 1 a 10] *****************
modificato: [m9-04-r-04] => (item=VLAN-1001)
modificato: [m9-04-r-04] => (item=VLAN-1002)
modificato: [m9-04-r-04] => (item=VLAN-1003)
modificato: [m9-04-r-04] => (item=VLAN-1004)
modificato: [m9-04-r-04] => (item=VLAN-1005)
modificato: [m9-04-r-04] => (item=VLAN-1006)
modificato: [m9-04-r-04] => (item=VLAN-1007)
modificato: [m9-04-r-04] => (item=VLAN-1008)
modificato: [m9-04-r-04] => (item=VLAN-1009)
modificato: [m9-04-r-04] => (item=VLAN-1010)
modificato: [m9-04-r-04] => (item=VLAN-1011)
modificato: [m9-04-r-04] => (item=VLAN-1012)
modificato: [m9-04-r-04] => (item=VLAN-1013)
modificato: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Modifica il costo predefinito dell'OSPF area1 a 10] ******************
modificato: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Cambia gli indirizzi IP delle interfacce MGMT] ********************
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
TASK [mk_routeros_emergency_on : Genera gARPs per le interfacce MGMT] *********************
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
modificato: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY RECAP ************************************************************************Fatto!
In realtà, non è completamente pronto, non dimentichiamo la convergenza dei protocolli di routing dinamico e il caricamento di un gran numero di rotte nel FIB. Su questo non possiamo influire. Aspettiamo. È andato a buon fine. Ora è pronto.
E nel villaggio di Vilabaggio (che non vuole automatizzare la configurazione della rete) continuano a lavare i piatti. Bruce (anche se è un altro, ma non meno straordinario) cerca di capire quanto altro dovrà riconfigurare manualmente l'attrezzatura.
Vorrei soffermarmi su un altro punto importante. Come possiamo riportare tutto indietro? Dopo un po', riporteremo in vita il nostro FW-CLUSTER. Questa è l'attrezzatura principale, non quella di riserva, su di essa deve funzionare la rete.
Sentite come i networker iniziano a scaldarsi? Il direttore tecnico sentirà mille argomentazioni sul perché non si debba fare, perché si possa fare dopo. Purtroppo, il lavoro della rete si compone di una miriade di toppe, pezzi, residui di un tempo di splendore. Risultando in una coperta patchwork. Il nostro obiettivo, in generale, non solo in questa specifica situazione, ma come professionisti IT in generale, è portare il lavoro della rete verso la bella parola inglese "consistency", che racchiude molteplici significati come: coerenza, non contraddittorietà, logica, sinergia, sistematicità, confrontabilità, connettività. Tutto questo è riferito a essa. Solo in tale stato la rete è gestibile, capiamo chiaramente cosa e come funziona, siamo pienamente consapevoli di cosa deve essere cambiato, se necessario, e sappiamo sempre dove guardare in caso di problemi. E solo in una rete del genere è possibile realizzare trucchi, come quelli che abbiamo appena descritto.
In effetti, è stato preparato un ulteriore playbook che ripristinava le impostazioni allo stato originale. La logica del suo funzionamento è la stessa (è importante ricordare che l'ordine dei task è molto importante), per non allungare ulteriormente un articolo già piuttosto lungo, abbiamo deciso di non pubblicare il listing dell'esecuzione del playbook. Dopo aver svolto tali esercitazioni, vi sentirete molto più tranquilli e sicuri per il futuro; inoltre, qualsiasi toppa che avete messo in atto si rivelerà immediatamente.
Tutti coloro che sono interessati possono contattarci e ricevere il codice sorgente di tutto ciò che è stato scritto, insieme a tutti i playbook. I contatti sono nel profilo.
Conclusioni
A nostro avviso, i processi che possono essere automatizzati non si sono ancora cristallizzati. Basandoci su ciò che abbiamo riscontrato e su ciò di cui discutono i nostri colleghi occidentali, le seguenti tematiche sembrano emergere:
- Provisionamento dei dispositivi;
- Raccolta di dati;
- Reporting;
- Risoluzione dei problemi;
- Conformità.
Se c'è interesse, possiamo continuare a discutere su uno dei temi proposti.
Vorremmo riflettere un po' sul tema dell'automazione. Come dovrebbe essere secondo la nostra visione:
- Il sistema deve funzionare senza l'intervento umano, migliorando grazie all'intervento umano. Il sistema non deve dipendere dall'uomo;
- L'operatività deve essere esperta. Non esiste la classe di specialisti che svolgono compiti di routine. Ci sono esperti che hanno automatizzato tutta la routine e si occupano solo di compiti complessi;
- I compiti di routine e standard vengono eseguiti automaticamente "premendo un pulsante", senza utilizzare risorse. Il risultato di tali attività è sempre prevedibile e comprensibile.
E a cosa devono portare questi punti:
- Trasparenza dell'infrastruttura IT (Minori rischi di operatività, modernizzazione, implementazione. Minore downtime annuale);
- Possibilità di pianificare le risorse IT (Sistema di pianificazione della capacità — chiaramente visibile quanto viene consumato e quante risorse sono necessarie in un sistema unico, e non tramite lettere e incontri con i superiori dei reparti);
- Possibilità di ridurre il numero di personale IT di supporto.
Autori dell'articolo: Alexander Chelnokov (CCIE RS, CCIE SP) e Pavel Kirillov. Ci interessa discutere e proporre soluzioni sul tema dell'Automazione dell'infrastruttura IT.
Fonte: habr.com
