L’SDSM è finito, ma resta la voglia irrefrenabile di scrivere.
Per molti anni, nostro fratello ha sofferto svolgendo lavori di routine, incrociando le dita prima di impegnarsi e non avendo sonno a causa dei rallentamenti notturni.
Ma i tempi bui stanno per finire.
Con questo articolo inizierò una serie su come me appare l'automazione.
Lungo il percorso, comprenderemo le fasi dell'automazione, della memorizzazione delle variabili, della formalizzazione del design, RestAPI, NETCONF, YANG, YDK e faremo molta programmazione.
Me significa che a) non è una verità oggettiva, b) non è incondizionatamente l'approccio migliore, c) la mia opinione, anche nel passaggio dal primo all'ultimo articolo, può cambiare - a dire il vero, dalla fase di bozza all'ultima pubblicazione, ho riscritto tutto completamente due volte.
contenuto
- Obiettivi
- La rete è come un unico organismo
- Test di configurazione
- Versionamento
- Monitoraggio e autoguarigione dei servizi
- Fondi
- sistema di inventario
- Sistema di gestione dello spazio IP
- Sistema di descrizione dei servizi di rete
- Meccanismo di inizializzazione del dispositivo
- Modello di configurazione indipendente dal fornitore
- Interfaccia del driver specifica del fornitore
- Meccanismo per fornire la configurazione al dispositivo
- CI / CD
- Meccanismo di backup e ricerca di deviazioni
- Sistema di monitoraggio
- conclusione
Cercherò di condurre l'ADSM in un formato leggermente diverso dall'SDSM. Continueranno ad apparire articoli grandi, dettagliati e numerati, e tra questi pubblicherò piccole note tratte dall'esperienza quotidiana. Cercherò di combattere il perfezionismo qui e di non leccarli tutti.
Com'è divertente che la seconda volta devi percorrere lo stesso percorso.
All'inizio ho dovuto scrivere io stesso articoli sulle reti perché non erano su RuNet.
Ora non sono riuscito a trovare un documento completo che sistematizzi gli approcci all'automazione e analizzi le tecnologie di cui sopra utilizzando semplici esempi pratici.
Potrei sbagliarmi, quindi fornisci collegamenti a risorse utili. Tuttavia, questo non cambierà la mia determinazione a scrivere, perché l'obiettivo principale è imparare qualcosa da solo, e rendere la vita più facile agli altri è un piacevole bonus che accarezza il gene della condivisione delle esperienze.
Cercheremo di prendere un data center LAN DC di medie dimensioni e di elaborare l'intero schema di automazione.
Farò alcune cose quasi per la prima volta con te.
Non sarò originale nelle idee e negli strumenti qui descritti. Dmitry Figol ha un eccellente .
Gli articoli si sovrapporranno ad essi sotto molti aspetti.
Il LAN DC ha 4 DC, circa 250 switch, una mezza dozzina di router e un paio di firewall.
Non Facebook, ma abbastanza per farti riflettere profondamente sull’automazione.
Tuttavia, si ritiene che se si dispone di più di 1 dispositivo, l'automazione è già necessaria.
In effetti, è difficile immaginare che qualcuno possa ora vivere senza almeno un pacchetto di copioni per il ginocchio.
Anche se ho sentito che ci sono uffici in cui gli indirizzi IP sono conservati in Excel e ciascuno delle migliaia di dispositivi di rete è configurato manualmente e ha la propria configurazione unica. Questo, ovviamente, può essere spacciato per arte moderna, ma i sentimenti dell’ingegnere saranno sicuramente offesi.
Obiettivi
Ora fisseremo gli obiettivi più astratti:
- La rete è come un unico organismo
- Test di configurazione
- Controllo delle versioni dello stato della rete
- Monitoraggio e autoguarigione dei servizi
Più avanti in questo articolo vedremo quali mezzi utilizzeremo e, di seguito, esamineremo gli obiettivi e i mezzi in dettaglio.
La rete è come un unico organismo
La frase che definisce la serie, anche se a prima vista potrebbe non sembrare così significativa: configureremo la rete, non i singoli dispositivi.
Negli ultimi anni abbiamo assistito a uno spostamento dell’enfasi verso il trattamento della rete come un’unica entità, da qui il principio Software Defined Network, Reti guidate dagli intenti и Reti autonome.
Dopotutto, di cosa hanno bisogno le applicazioni a livello globale dalla rete: connettività tra i punti A e B (beh, a volte +B-Z) e isolamento da altre applicazioni e utenti.
E quindi il nostro compito in questa serie è costruire un sistema, mantenendo la configurazione attuale l'intera rete, che è già scomposto nella configurazione effettiva su ciascun dispositivo in base al suo ruolo e alla sua posizione.
Sistema la gestione della rete implica che per apportare modifiche lo contattiamo e lui, a sua volta, calcola lo stato desiderato per ciascun dispositivo e lo configura.
In questo modo riduciamo al minimo l'accesso manuale alla CLI (qualsiasi modifica alle impostazioni del dispositivo o alla progettazione della rete deve essere formalizzata e documentata) e solo successivamente la distribuiamo agli elementi di rete necessari.
Cioè, ad esempio, se decidessimo che d'ora in poi gli switch rack a Kazan dovessero annunciare due reti invece di una, noi
- Per prima cosa documentiamo i cambiamenti nei sistemi
- Generazione della configurazione di destinazione di tutti i dispositivi di rete
- Lanciamo il programma di aggiornamento della configurazione di rete, che calcola cosa deve essere rimosso su ciascun nodo, cosa aggiungere e porta i nodi allo stato desiderato.
Allo stesso tempo, apportiamo modifiche manualmente solo nel primo passaggio.
Test di configurazione
che l'80% dei problemi si verifica durante le modifiche alla configurazione: una prova indiretta di ciò è che durante le vacanze di Capodanno di solito tutto è calmo.
Personalmente ho assistito a decine di downtime globali dovuti a errori umani: comando sbagliato, configurazione eseguita nel ramo sbagliato, comunità dimenticata, MPLS è stato demolito globalmente sul router, cinque componenti hardware sono stati configurati, ma l'errore non è stato notato il sesto, sono state commesse vecchie modifiche apportate da un'altra persona. Ci sono un sacco di scenari.
L’automazione ci consentirà di commettere meno errori, ma su scala più ampia. In questo modo puoi murare non solo un dispositivo, ma l'intera rete contemporaneamente.
Da tempo immemorabile, i nostri nonni hanno controllato con occhio attento la correttezza delle modifiche apportate, le sfere d'acciaio e la funzionalità della rete dopo averle stese.
Quei nonni il cui lavoro ha portato a tempi di inattività e perdite catastrofiche hanno lasciato meno prole e dovrebbero estinguersi nel tempo, ma l'evoluzione è un processo lento, e quindi non tutti stanno ancora testando prima i cambiamenti in laboratorio.
Tuttavia, in prima linea nel progresso ci sono coloro che hanno automatizzato il processo di test della configurazione e la sua ulteriore applicazione alla rete. In altre parole, ho preso in prestito la procedura CI/CD () dagli sviluppatori.
In una delle parti vedremo come implementarlo utilizzando un sistema di controllo della versione, probabilmente Github.
Una volta che ti sarai abituato all'idea della rete CI/CD, da un giorno all'altro il metodo di controllare una configurazione applicandola a una rete di produzione sembrerà un'ignoranza altomedievale. Un po' come colpire una testata con un martello.
Una continuazione organica di idee su sistema la gestione della rete e CI/CD diventa un versioning completo della configurazione.
Versionamento
Assumeremo che con qualsiasi cambiamento, anche il più lieve, anche su un dispositivo impercettibile, l'intera rete si sposta da uno stato all'altro.
E non eseguiamo sempre alcun comando sul dispositivo, cambiamo lo stato della rete.
Quindi chiamiamo versioni di questi stati?
Diciamo che la versione attuale è 1.0.0.
L'indirizzo IP dell'interfaccia Loopback su uno dei ToR è cambiato? Questa è una versione minore e sarà numerata 1.0.1.
Abbiamo rivisto le politiche per l'importazione di rotte in BGP - un po' più seriamente - già nella versione 1.1.0
Abbiamo deciso di eliminare IGP e passare solo a BGP - questo è già un cambiamento radicale nel design - 2.0.0.
Allo stesso tempo, diversi DC possono avere versioni diverse: la rete si sta sviluppando, vengono installate nuove apparecchiature, nuovi livelli di spine vengono aggiunti da qualche parte e non in altri, ecc.
Про ne parleremo in un articolo a parte.
Ripeto: qualsiasi modifica (ad eccezione dei comandi di debug) è un aggiornamento della versione. Gli amministratori devono essere informati di eventuali deviazioni dalla versione attuale.
Lo stesso vale per il rollback delle modifiche - non si tratta di annullare gli ultimi comandi, non si tratta di un rollback utilizzando il sistema operativo del dispositivo - si tratta di portare l'intera rete a una nuova (vecchia) versione.
Monitoraggio e autoguarigione dei servizi
Questo compito evidente ha raggiunto un nuovo livello nelle reti moderne.
Spesso, i grandi fornitori di servizi adottano l'approccio secondo cui un servizio guasto deve essere risolto molto rapidamente e crearne uno nuovo, invece di capire cosa è successo.
"Molto" significa che è necessario essere generosamente rivestiti su tutti i lati con un monitoraggio, che in pochi secondi rileverà le minime deviazioni dalla norma.
E qui le solite metriche, come il caricamento dell’interfaccia o la disponibilità dei nodi, non bastano più. Nemmeno il loro monitoraggio manuale da parte dell’ufficiale di turno è sufficiente.
Per molte cose dovrebbe esserci - le luci di monitoraggio sono diventate rosse e siamo andati ad applicare noi stessi il platano dove faceva male.
E qui monitoriamo anche non solo i singoli dispositivi, ma anche lo stato dell'intera rete, sia whitebox, che è relativamente comprensibile, sia blackbox, che è più complicato.
Di cosa avremo bisogno per attuare piani così ambiziosi?
- Avere un elenco di tutti i dispositivi sulla rete, la loro posizione, ruoli, modelli, versioni del software.
kazan-leaf-1.lmu.net, Kazan, foglia, Ginepro QFX 5120, R18.3. - Avere un sistema per descrivere i servizi di rete.
IGP, BGP, L2/3VPN, policy, ACL, NTP, SSH. - Essere in grado di inizializzare il dispositivo.
Nome host, IP di gestione, Route di gestione, Utenti, Chiavi RSA, LLDP, NETCONF - Configura il dispositivo e porta la configurazione alla versione desiderata (inclusa quella vecchia).
- Provare la configurazione
- Controlla periodicamente lo stato di tutti i dispositivi per eventuali deviazioni da quelli attuali e segnala a chi dovrebbe essere.
Durante la notte, qualcuno ha aggiunto silenziosamente una regola all'ACL. - Monitorare le prestazioni.
Fondi
Sembra abbastanza complicato iniziare a scomporre il progetto in componenti.
E saranno dieci:
- sistema di inventario
- Sistema di gestione dello spazio IP
- Sistema di descrizione dei servizi di rete
- Meccanismo di inizializzazione del dispositivo
- Modello di configurazione indipendente dal fornitore
- Interfaccia del driver specifica del fornitore
- Meccanismo per fornire la configurazione al dispositivo
- CI / CD
- Meccanismo di backup e ricerca di deviazioni
- Sistema di monitoraggio
Questo, tra l'altro, è un esempio di come è cambiata la visione degli obiettivi del ciclo: nella bozza c'erano 4 componenti.
Nell'illustrazione ho raffigurato tutti i componenti e il dispositivo stesso.
I componenti che si intersecano interagiscono tra loro.
Più grande è il blocco, maggiore è l'attenzione da prestare a questo componente.
Componente 1: sistema di inventario
Ovviamente vogliamo sapere quali apparecchiature si trovano, dove e a cosa sono collegate.
Il sistema di inventario è parte integrante di qualsiasi impresa.
Molto spesso, un'azienda dispone di un sistema di inventario separato per i dispositivi di rete, che risolve problemi più specifici.
Nell'ambito di questa serie di articoli lo chiameremo DCIM - Data Center Infrastructure Management. Sebbene il termine stesso DCIM, in senso stretto, includa molto di più.
Per i nostri scopi, memorizzeremo le seguenti informazioni sul dispositivo:
- Numero di inventario
- Descrizione del titolo
- Modello (Huawei CE12800, Juniper QFX5120, ecc.)
- Parametri caratteristici (schede, interfacce, ecc.)
- Ruolo (Foglia, dorso, fresa per bordi, ecc.)
- Posizione (regione, città, data center, rack, unità)
- Interconnessioni tra dispositivi
- Topologia di rete
È perfettamente chiaro che noi stessi vogliamo sapere tutto questo.
Ma questo aiuterà ai fini dell’automazione?
Certamente.
Ad esempio, sappiamo che in un dato data center sugli switch Leaf, se si tratta di Huawei, gli ACL per filtrare determinato traffico dovrebbero essere applicati sulla VLAN e, se si tratta di Juniper, sull'unità 0 dell'interfaccia fisica.
Oppure è necessario implementare un nuovo server Syslog su tutti i confini della regione.
In esso memorizzeremo i dispositivi di rete virtuale, ad esempio router virtuali o riflettori root. Possiamo aggiungere server DNS, NTP, Syslog e in generale tutto ciò che in un modo o nell'altro riguarda la rete.
Componente 2: sistema di gestione dello spazio IP
Sì, e oggigiorno esistono team di persone che tengono traccia dei prefissi e degli indirizzi IP in un file Excel. Ma l’approccio moderno è ancora un database, con un front-end su nginx/apache, API e ampie funzioni per la registrazione di indirizzi IP e reti suddivise in VRF.
IPAM - Gestione degli indirizzi IP.
Per i nostri scopi, memorizzeremo al suo interno le seguenti informazioni:
- VLAN
- VRF
- Reti/sottoreti
- Indirizzi IP
- Associazione degli indirizzi ai dispositivi, delle reti alle posizioni e ai numeri VLAN
Ancora una volta, è chiaro che vogliamo essere sicuri che quando assegniamo un nuovo indirizzo IP per il loopback ToR, non ci imbatteremo nel fatto che è già stato assegnato a qualcuno. O che abbiamo usato lo stesso prefisso due volte a estremità diverse della rete.
Ma in che modo questo aiuta con l’automazione?
Facilmente.
Richiediamo un prefisso nel sistema con il ruolo Loopbacks, che contiene gli indirizzi IP disponibili per l'allocazione: se viene trovato, assegniamo l'indirizzo, in caso contrario richiediamo la creazione di un nuovo prefisso.
Oppure, quando creiamo la configurazione di un dispositivo, possiamo scoprire dallo stesso sistema in cui VRF dovrebbe trovarsi l'interfaccia.
E quando si avvia un nuovo server, lo script accede al sistema, scopre in quale switch si trova il server, quale porta e quale sottorete è assegnata all'interfaccia e assegnerà da essa l'indirizzo del server.
Ciò suggerisce il desiderio di combinare DCIM e IPAM in un unico sistema in modo da non duplicare le funzioni e non servire due entità simili.
Questo è quello che faremo.
Componente 3. Sistema per descrivere i servizi di rete
Se i primi due sistemi memorizzano variabili che devono ancora essere utilizzate in qualche modo, il terzo descrive per ciascun ruolo del dispositivo come dovrebbe essere configurato.
È opportuno distinguere due diverse tipologie di servizi di rete:
- Infrastruttura
- Cliente.
I primi sono progettati per fornire connettività di base e controllo del dispositivo. Questi includono VTY, SNMP, NTP, Syslog, AAA, protocolli di routing, CoPP, ecc.
Questi ultimi organizzano il servizio per il cliente: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, ecc.
Naturalmente, ci sono anche casi limite: dove includere MPLS LDP, BGP? Sì, ed è possibile utilizzare protocolli di routing per i client. Ma questo non è importante.
Entrambi i tipi di servizi sono scomposti in primitive di configurazione:
- interfacce fisiche e logiche (tag/anteg, mtu)
- Indirizzi IP e VRF (IP, IPv6, VRF)
- ACL e policy di elaborazione del traffico
- Protocolli (IGP, BGP, MPLS)
- Politiche di instradamento (elenchi di prefissi, comunità, filtri ASN).
- Servizi di utilità (SSH, NTP, LLDP, Syslog...)
- Eccetera.
Come lo faremo esattamente, non ne ho ancora idea. Lo esamineremo in un articolo separato.
Se fosse un po' più vicino alla vita, allora potremmo descriverlo
Lo switch Leaf deve avere sessioni BGP con tutti gli switch Spine connessi, importare le reti connesse nel processo e accettare solo reti da un determinato prefisso dagli switch Spine. Limita CoPP IPv6 ND a 10 pps, ecc.
A loro volta, le spine tengono sessioni con tutti i cavi collegati, agendo come riflettori delle radici, e accettano da loro solo percorsi di una certa lunghezza e con una certa comunità.
Componente 4: meccanismo di inizializzazione del dispositivo
Sotto questa voce unisco molte delle azioni che devono verificarsi affinché un dispositivo appaia sul radar e sia possibile accedervi da remoto.
- Inserisci il dispositivo nel sistema di inventario.
- Seleziona un indirizzo IP di gestione.
- Configura l'accesso di base ad esso:
Nome host, indirizzo IP di gestione, instradamento alla rete di gestione, utenti, chiavi SSH, protocolli: telnet/SSH/NETCONF
Esistono tre approcci:
- Tutto è completamente manuale. Il dispositivo viene portato allo stand, dove una normale persona organica lo inserirà nei sistemi, si collegherà alla console e lo configurerà. Può funzionare su piccole reti statiche.
- ZTP – Provisioning Zero Touch. L'hardware è arrivato, si è alzato, ha ricevuto un indirizzo tramite DHCP, è andato su un server speciale e si è configurato.
- L'infrastruttura dei server console, dove la configurazione iniziale avviene tramite la porta console in modalità automatica.
Parleremo di tutti e tre in un articolo separato.
Componente 5: modello di configurazione indipendente dal fornitore
Fino ad ora, tutti i sistemi erano patch disparate che forniscono variabili e una descrizione dichiarativa di ciò che vorremmo vedere sulla rete. Ma prima o poi dovrai affrontare i dettagli.
In questa fase, per ogni dispositivo specifico, le primitive, i servizi e le variabili vengono combinati in un modello di configurazione che descrive effettivamente la configurazione completa di un dispositivo specifico, solo in modo indipendente dal fornitore.
Cosa fa questo passaggio? Perché non creare subito una configurazione del dispositivo che puoi semplicemente caricare?
In realtà, questo risolve tre problemi:
- Non adattarsi a un'interfaccia specifica per interagire con il dispositivo. Che si tratti di CLI, NETCONF, RESTCONF, SNMP, il modello sarà lo stesso.
- Non mantenere il numero di modelli/script in base al numero di fornitori sulla rete e, se il design cambia, modificare la stessa cosa in più punti.
- Carica la configurazione dal dispositivo (backup), inseriscila esattamente nello stesso modello e confronta direttamente la configurazione target con quella esistente per calcolare il delta e preparare una patch di configurazione che cambierà solo le parti necessarie o per identificare le deviazioni.
Come risultato di questa fase, otteniamo una configurazione indipendente dal fornitore.
Componente 6. Interfaccia del driver specifica del fornitore
Non bisogna illudersi che un giorno sarà possibile configurare un ciska esattamente come un Juniper, semplicemente inviandogli esattamente le stesse chiamate. Nonostante la crescente popolarità delle whitebox e l’emergere del supporto per NETCONF, RESTCONF, OpenConfig, il contenuto specifico fornito da questi protocolli differisce da fornitore a fornitore, e questa è una delle differenze competitive a cui non rinunceranno così facilmente.
Questo è più o meno lo stesso di OpenContrail e OpenStack, che hanno RestAPI come interfaccia NorthBound, si aspettano chiamate completamente diverse.
Quindi, nella quinta fase, il modello indipendente dal fornitore deve assumere la forma in cui verrà adottato per l’hardware.
E qui tutti i mezzi sono buoni (non): CLI, NETCONF, RESTCONF, SNMP semplicemente.
Pertanto, avremo bisogno di un driver che trasferisca il risultato del passaggio precedente nel formato richiesto da un fornitore specifico: un insieme di comandi CLI, una struttura XML.
Componente 7. Meccanismo per fornire la configurazione al dispositivo
Abbiamo generato la configurazione, ma deve ancora essere consegnata ai dispositivi e, ovviamente, non a mano.
In primo luogo, ci troviamo di fronte alla domanda: quali mezzi di trasporto utilizzeremo? E oggi la scelta non è più piccola:
- CLI (telnet, ssh)
- SNMP
- CONF.NET
- CONF.REST
- API REST
- OpenFlow (anche se è un valore anomalo perché è un modo per fornire FIB, non impostazioni)
Mettiamo il punto sulla t qui. La CLI è legacy. SNMP... tosse tosse.
RESTCONF è ancora un animale sconosciuto; l'API REST non è supportata quasi da nessuno. Pertanto, nella serie ci concentreremo su NETCONF.
Infatti, come il lettore avrà già capito, a questo punto abbiamo già deciso l'interfaccia: il risultato del passaggio precedente è già presentato nel formato dell'interfaccia scelta.
In secondo luogoe con quali strumenti lo faremo?
Anche qui c'è un'ampia scelta:
- Script o piattaforma autoprodotti. Armiamoci di ncclient e asyncIO e facciamo tutto da soli. Quanto ci costa costruire un sistema di distribuzione da zero?
- Ansible con la sua ricca libreria di moduli di rete.
- Sale con il suo magro lavoro con la rete e connessione con Napalm.
- Anzi Napalm, che conosce un paio di venditori e basta, arrivederci.
- Nornir è un altro animale che analizzeremo in futuro.
Qui il preferito non è stato ancora scelto: lo cercheremo.
Cos'altro è importante qui? Conseguenze dell'applicazione della configurazione.
Riuscito o no. C'è ancora accesso all'hardware o no?
Sembra che commit aiuterà qui con la conferma e la convalida di ciò che è stato scaricato sul dispositivo.
Questo, combinato con la corretta implementazione di NETCONF, restringe notevolmente la gamma di dispositivi adatti: non molti produttori supportano i commit normali. Ma questo è solo uno dei prerequisiti . Alla fine, nessuno si preoccupa che nemmeno un singolo fornitore russo rispetterà le condizioni dell'interfaccia 32*100GE. Oppure è preoccupato?
Componente 8. CI/CD
A questo punto abbiamo già pronta la configurazione per tutti i dispositivi di rete.
Scrivo “per tutto” perché stiamo parlando del controllo delle versioni dello stato della rete. E anche se è necessario modificare le impostazioni di un solo switch, le modifiche vengono calcolate per l'intera rete. Ovviamente, possono essere zero per la maggior parte dei nodi.
Ma, come già detto sopra, non siamo una specie di barbari che vogliono mettere tutto direttamente in produzione.
La configurazione generata deve prima passare attraverso la pipeline CI/CD.
CI/CD sta per Integrazione Continua, Distribuzione Continua. Si tratta di un approccio in cui il team non solo rilascia una nuova versione principale ogni sei mesi, sostituendo completamente quella vecchia, ma implementa regolarmente in modo incrementale (distribuzione) nuove funzionalità in piccole porzioni, ciascuna delle quali è completamente testata per compatibilità, sicurezza e prestazioni (Integrazione).
Per fare ciò, disponiamo di un sistema di controllo della versione che monitora le modifiche alla configurazione, un laboratorio che verifica se il servizio client è interrotto, un sistema di monitoraggio che verifica questo fatto e l'ultimo passaggio è l'implementazione delle modifiche nella rete di produzione.
Ad eccezione dei comandi di debug, tutte le modifiche sulla rete devono assolutamente passare attraverso la pipeline CI/CD: questa è la nostra garanzia di una vita tranquilla e di una carriera lunga e felice.
Componente 9. Sistema di backup e rilevamento anomalie
Bene, non è necessario parlare ancora di backup.
Li aggiungeremo semplicemente alla corona o in caso di modifica della configurazione in git.
Ma la seconda parte è più interessante: qualcuno dovrebbe tenere d'occhio questi backup. E in alcuni casi, questo qualcuno deve andare a rimettere tutto com'era, e in altri, miagolare a qualcuno che qualcosa non va.
Ad esempio, se è apparso un nuovo utente che non è registrato nelle variabili, è necessario rimuoverlo dall'hack. E se è meglio non toccare una nuova regola del firewall, forse qualcuno ha appena attivato il debug, o forse il nuovo servizio, un pasticcione, non è stato registrato secondo le norme, ma le persone vi hanno già aderito.
Non riusciremo comunque a sfuggire a qualche piccola differenza sulla scala dell’intera rete, nonostante i sistemi di automazione e la mano d’acciaio del management. Per eseguire il debug dei problemi, nessuno aggiungerà comunque la configurazione ai sistemi. Inoltre, potrebbero anche non essere inclusi nel modello di configurazione.
Ad esempio, una regola del firewall per contare il numero di pacchetti per IP specifico per localizzare un problema è una configurazione temporanea del tutto normale.
Componente 10. Sistema di monitoraggio
All'inizio non avrei trattato l'argomento del monitoraggio: è ancora un argomento voluminoso, controverso e complesso. Ma col progredire delle cose, si è scoperto che questa era parte integrante dell’automazione. Ed è impossibile aggirarlo, anche senza pratica.
Il pensiero in evoluzione è una parte organica del processo CI/CD. Dopo aver distribuito la configurazione alla rete, dobbiamo essere in grado di determinare se ora va tutto bene.
E stiamo parlando non solo e non tanto dei programmi di utilizzo dell'interfaccia o della disponibilità dei nodi, ma di cose più sottili: la presenza dei percorsi necessari, gli attributi su di essi, il numero di sessioni BGP, i vicini OSPF, le prestazioni end-to-end dei servizi sovrastanti.
I syslog sul server esterno hanno smesso di sommarsi, o l'agente Sflow si è rotto, o i cali nelle code hanno iniziato a crescere, o la connettività tra alcune coppie di prefissi si è interrotta?
Rifletteremo su questo in un articolo separato.
conclusione
Come base, ho scelto uno dei moderni progetti di rete di data center: L3 Clos Fabric con BGP come protocollo di routing.
Questa volta costruiremo la rete su Juniper, perché ora l'interfaccia di JunOs è un vanlove.
Rendiamoci la vita più difficile utilizzando solo strumenti Open Source e una rete multi-vendor, quindi oltre a Juniper, sceglierò un'altra persona fortunata lungo il percorso.
Il piano per le prossime pubblicazioni è più o meno questo:
Per prima cosa parlerò delle reti virtuali. Innanzitutto perché lo voglio, e in secondo luogo perché senza questo il disegno della rete infrastrutturale non sarà molto chiaro.
Poi parliamo della progettazione della rete stessa: topologia, routing, politiche.
Montiamo un supporto da laboratorio.
Pensiamoci e magari esercitiamoci a inizializzare il dispositivo sulla rete.
E poi su ogni componente in dettaglio intimo.
E sì, non prometto di concludere con grazia questo ciclo con una soluzione già pronta. 🙂
Link utili
- Prima di approfondire la serie, vale la pena leggere il libro di Natasha Samoilenko . E magari passare .
- Sarà utile anche leggere sulla progettazione delle fabbriche di data center di Facebook di Peter Lapukhov.
- La documentazione dell'architettura ti darà un'idea di come funziona Overlay SDN. (precedentemente Open Contrail).
Grazie
Gola Romana. Per commenti e modifiche.
Artyom Chernobay. Per KDPV.
Fonte: habr.com