Ciao, Habr!
In questo articolo vorremmo parlare dell'automazione dell'infrastruttura di rete. Verrà presentato uno schema funzionale di rete che opera in una piccola, ma molto orgogliosa azienda. Eventuali somiglianze con attrezzature di rete reali sono puramente casuali. Analizzeremo un caso che si è verificato all'interno di questa rete, il quale avrebbe potuto causare un'interruzione delle attività per un lungo periodo e significative perdite finanziarie. La soluzione di questo caso si integra perfettamente nel concetto di "Automazione dell'infrastruttura di rete". Utilizzando strumenti di automazione, dimostreremo come sia possibile affrontare in modo efficace compiti complessi in tempi ridotti, e rifletteremo su perché sia preferibile risolvere queste problematiche in questo modo piuttosto che in un altro (tramite console).
Avvertenza
I principali strumenti per l'automazione che utilizziamo sono Ansible (come strumento di automazione) e Git (come repository per i playbook di Ansible). È importante chiarire che non si tratta di un articolo introduttivo in cui parliamo della logica di funzionamento di Ansible o Git, né di spiegare i concetti di base (come cosa siano i moduli, i file di inventario o le variabili in Ansible, o cosa accade quando vengono eseguiti i comandi git push o git commit). Non stiamo parlando di come esercitarsi con Ansible, configurare NTP o SMTP sull'hardware. Questa è una storia su come risolvere rapidamente, e idealmente senza errori, un problema di rete. È inoltre utile avere una buona comprensione di come funziona una rete, in particolare conoscere lo stack dei protocolli TCP/IP, OSPF e BGP. Anche la scelta di Ansible e Git la rimanderemo. Se sei ancora indeciso su quale soluzione specifica adottare, ti consigliamo vivamente 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 sodo.
Definizione del compito
Immagina la situazione: sono le 3 del mattino, stai dormendo profondamente e sognando. Ricevi una telefonata. Chiama il direttore tecnico:
— Pronto?
— ###, ####, #####, il cluster dei firewall è caduto e non si riavvia!!!
Ti strofini gli occhi, cercando di comprendere cosa stia succedendo e di immaginare come possa essere accaduto. Nella cornetta si sente il suono dei capelli che si strappano dalla testa del direttore, che chiede di richiamare, perché sulla seconda linea sta chiamando il CEO.
Dopo mezz'ora hai raccolto i primi dettagli dall'operatore di turno, svegliando tutti quelli che potevi. Alla fine, il direttore tecnico non aveva mentito: è tutto vero, il cluster principale dei firewall è caduto e nessuna delle operazioni di base riesce a farlo riprendere. Tutti i servizi offerti dall'azienda non funzionano.
Scegli tu il problema, ognuno ricorderà qualcosa di personale. Ad esempio, dopo l'aggiornamento notturno, in assenza di un grande carico, tutto funzionava bene e tutti, soddisfatti, se ne andarono a dormire. È arrivato il traffico e i buffer delle interfacce hanno iniziato a sovraccaricarsi a causa di un bug nel driver della scheda di rete.
La situazione potrebbe essere ben descritta da Jackie Chan.
Grazie, Jackie.
Non è una situazione molto gradevole, vero?
Lasciamo per un momento il nostro amico della rete con i suoi pensieri tristi.
Discussiamo come si svilupperanno gli eventi.
Proponiamo il seguente ordine di presentazione del materiale.
- Esaminiamo lo schema di rete e vediamo come funziona;
- Descriviamo come trasferiamo le impostazioni da un router a un altro utilizzando Ansible;
- Parliamo dell'automazione dell'infrastruttura IT in generale.
Schema di rete e sua descrizione
Schema
Esaminiamo lo schema logico della nostra organizzazione. Non citeremo produttori specifici di apparecchiature, poiché non è rilevante per questo articolo. (Il lettore attento capirà da solo che tipo di apparecchiature viene utilizzato). Questo è uno dei grandi vantaggi di lavorare con Ansible; durante la configurazione, in generale, non ci importa quale sia l'apparecchiatura. Solo per capirlo, queste sono apparecchiature di fornitori noti, come Cisco, Juniper, Check Point, Fortinet, Palo Alto... potete inserire la vostra opzione.
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), oltre all'accesso di queste filiali a Internet tramite l'ufficio centrale.
Iniziamo con gli elementi fondamentali:
- Due router di confine (BRD-01, BRD-02);
- Cluster di firewall (FW-CLUSTER);
- Switch di core (L3-CORE);
- Un router che agirà da salvagente (durante la risoluzione 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 testare e sviluppare playbook per Ansible (Laptop-Automation).
In 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 del funzionamento 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 border sono stati creati dei router virtuali (VRF-INTERNET), che gestiscono una vista completa di eBGP con il rispettivo AS assegnato. Tra i VRF è configurato iBGP. L'azienda possiede un pool di indirizzi IP pubblici, che sono pubblicati su questi VRF-INTERNET. Parte degli indirizzi pubblici è instradata direttamente verso FW-CLUSTER (gli indirizzi sui quali operano i servizi dell'azienda), mentre un'altra parte è instradata attraverso la zona EXCHANGE (servizi interni dell'azienda che richiedono indirizzi IP esterni e indirizzi pubblici NAT per gli uffici). Il traffico quindi passa ai router virtuali creati su L3-CORE con indirizzi bianchi e grigi (zone di sicurezza).
Nella rete di gestione si utilizzano switch dedicati, costituendo una rete fisicamente separata. La rete di gestione è anche suddivisa in zone di sicurezza.
Il router EMERGENCY duplica fisicamente e logicamente FW-CLUSTER. Sono disabilitati tutti gli interfaccia tranne quelle che puntano verso la rete di management.
Automazione e sua descrizione
Abbiamo compreso come funziona la rete. Ora esaminiamo passo dopo passo cosa faremo per trasferire il traffico da FW-CLUSTER a EMERGENCY:
- Disattiviamo le interfacce dello switch core (L3-CORE) che lo collegano a FW-CLUSTER;
- Disattiviamo le interfacce sullo switch del 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 vengano sostituiti gli indirizzi MAC da FW-Cluster a EMERGENCY;
- Impostiamo 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 delle rotte in Area 1 a 10;
- Modifichiamo il costo della rotta predefinita in Area 1 a 10;
- Modifichiamo indirizzi ip, collegati a L2-MGMT (ovvero quelli che erano su FW-CLUSTER);
- Generiamo richieste gARP affinché nelle tabelle arp di L2-MGMT vengano sostituiti gli indirizzi MAC da FW-CLUSTER a EMERGENCY.
Torniamo quindi alla richiesta originale. Sono le tre di notte, grande stress, un errore in qualsiasi fase può portare a nuovi problemi. Siete pronti a digitare i comandi tramite CLI? Sì? Bene, andate a sciacquarvi il viso, prendete un caffè e raccogliete la vostra forza.
Bruce, per favore aiutali.
E noi continuiamo a sviluppare la nostra automazione.
Di seguito è riportato uno schema di funzionamento del playbook in termini di Ansible. Questo schema riflette ciò che abbiamo descritto in precedenza, ma già come implementazione concreta in Ansible.
A questo punto abbiamo compreso cosa fare, sviluppato il playbook, effettuato i test e ora siamo pronti a lanciarlo.
Un'altra piccola digressione. La semplicità del racconto non deve portarvi a fraintendimenti. Il processo di scrittura dei playbook non è stato semplice e veloce come potrebbe sembrare. I test hanno richiesto un bel po' di tempo, è stato creato un ambiente virtuale e la soluzione è stata testata più volte, con circa 100 test effettuati.
Stiamo avviando... C'è la sensazione che tutto stia avvenendo molto lentamente, c'è qualche errore da qualche parte, qualcosa alla fine non funzionerà. È come saltare con il paracadute, e il paracadute sembra non aprirsi subito... è normale.
Successivamente, leggiamo il risultato 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 [------->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 ************************************************************************Fatto!
In realtà, non è del tutto pronto, non dimentichiamo la convergenza dei protocolli di routing dinamico e il caricamento di un gran numero di percorsi nel FIB. Su questo non possiamo influire. Stiamo aspettando. Si è allineato. Ecco, 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 comunque altrettanto fantastico) cerca di capire quanto altro dovrà riconfigurare l'attrezzatura manualmente.
Vorrei anche soffermarmi su un altro punto importante. Come possiamo riportare tutto indietro? Dopo un po' di tempo, riporteremo in vita il nostro FW-CLUSTER. Questa è l'attrezzatura principale, non di riserva, sulla quale deve funzionare la rete.
Hai la sensazione che la pressione dei fornitori di rete stia aumentando? Il direttore tecnico ascolterà mille argomentazioni sul perché non dovresti farlo e perché sia meglio rimandarlo. Purtroppo, il lavoro di una rete si riduce a una serie di rattoppi, pezzi e frammenti di un tempo di grandezza. Risultando in un mosaico. Il nostro obiettivo, non solo in questa situazione specifica, ma in generale come professionisti IT, è riportare l'operatività della rete a una bella parola inglese: "consistency", che ha molteplici sfaccettature e può essere tradotta come: coerenza, non contraddittorietà, logica, armonia, sistematicità, comparabilità, connessione. Tutto questo le appartiene. Solo in questo stato la rete è gestibile; comprendiamo chiaramente cosa e come funziona, siamo pienamente consapevoli di cosa deve essere cambiato, se necessario, e sappiamo esattamente dove guardare in caso di problemi. E solo in una rete del genere è possibile eseguire magie simili a quelle che abbiamo descritto ora.
In effetti, è stato preparato un altro playbook che ripristinava le impostazioni allo stato originale. La logica di 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 sostenuto tali esercitazioni, ti sentirai molto più tranquillo e sicuro per il futuro; inoltre, eventuali soluzioni temporanee che hai implementato si riveleranno immediatamente.
Tutti coloro che lo desiderano 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 sono ancora concretizzati. Dalle esperienze che abbiamo avuto e da ciò che discutono i nostri colleghi occidentali, attualmente si vedono i seguenti temi:
- Provisioning dei dispositivi;
- Raccolta dei dati;
- Reporting;
- Risoluzione dei problemi;
- Compliance.
Se ci sarà interesse, potremo continuare la discussione su uno dei temi proposti.
Vogliamo anche riflettere un po' sull'automazione. Come dovrebbe essere, secondo noi:
- Il sistema dovrebbe funzionare senza l'intervento umano, migliorando però grazie all'interazione dell'uomo. Il sistema non dovrebbe dipendere dall'uomo;
- L'operazione deve essere esperta. Non ci sono personale qualificato che esegue compiti di routine. Ci sono esperti che hanno automatizzato tutte le attività di routine e si occupano solo di compiti complessi;
- Le attività standard di routine vengono eseguite automaticamente con un "click", senza risorse sprecate. Il risultato di queste attività è sempre prevedibile e chiaro.
E a cosa dovrebbero portare questi punti:
- Trasparenza dell'infrastruttura IT (minori rischi di operazione, modernizzazione, implementazione. Meno downtime in un anno);
- Possibilità di pianificare le risorse IT (sistema di capacity-planning — visibile quanto viene consumato, visibile quante risorse sono necessarie in un unico sistema, e non attraverso email e visite ai responsabili dei reparti);
- Possibilità di ridurre il numero di personale IT di supporto.
Autori dell'articolo: Alexander Chelyakov (CCIE RS, CCIE SP) e Pavel Kirilov. Siamo interessati a discutere e proporre soluzioni sul tema Automazione dell'infrastruttura IT.
Fonte: habr.com
