Valutate i collegamenti nella parte centrale dello schema. Torneremo su di essi in seguito
A un certo punto potreste trovarvi di fronte a reti L2 complesse e grandi che sono incurabilmente malate. In primo luogo, a causa di problemi legati alla gestione del traffico BUM e al funzionamento del protocollo STP. In secondo luogo, per un'architettura complessivamente obsoleta. Questo porta a problemi sgradevoli come downtime e difficoltà nella gestione.
Abbiamo avuto due progetti paralleli, dove i clienti hanno valutato con lucidità tutti i pro e i contro delle soluzioni e hanno scelto due diverse soluzioni overlay, e noi le abbiamo implementate.
C'è stata l'opportunità di confrontare proprio l'implementazione. Non l'esercizio, di cui si parlerà tra due o tre anni.
Allora, che cos'è una fabbrica di rete con reti overlay e SDN?
Cosa fare con i problemi irrisolti dell'architettura classica della rete?
Ogni anno compaiono nuove tecnologie e idee. Nella pratica, l'urgente necessità di riprogettare le reti non è emersa per un lungo periodo, perché fare tutto manualmente con i vecchi metodi tradizionali è ancora possibile. E allora, che importa se siamo nel ventunesimo secolo? Alla fine, l'amministratore deve lavorare, non stare chiuso in ufficio.
Poi è cominciato il boom della costruzione di data center su larga scala. Allora è diventato chiaro che era stato raggiunto un limite nello sviluppo dell'architettura classica, non solo in termini di funzionalità, ma anche di tolleranza agli errori e scalabilità. E una delle soluzioni a questi problemi è stata l'idea di costruire reti overlay su un backbone instradabile.
Inoltre, con l'aumento delle dimensioni delle reti, è emersa acutamente la questione della gestione di tali fabbriche, il che ha portato all'emergere di soluzioni di rete definite da software che consentono di gestire l'intera infrastruttura di rete come un'unica entità. Quando la rete è gestita da un unico punto, è più facile per altri componenti dell'infrastruttura IT interagire con essa, e questi processi di interazione sono più facili da automatizzare.
Quasi ogni grande produttore di hardware di rete e di virtualizzazione ha nella propria offerta opzioni di tali soluzioni.
Rimane solo da capire cosa si adatti a quali esigenze. Ad esempio, per le grandi aziende con un buon team di sviluppatori e operativi, le soluzioni standard dei fornitori non soddisfano sempre tutte le necessità, e ricorrono allo sviluppo delle proprie soluzioni SD (software defined). Ad esempio, ci sono fornitori cloud che ampliano continuamente la gamma di servizi offerti ai propri clienti, e le soluzioni standard semplicemente non riescono a star dietro alle loro esigenze.
Per le aziende medie, le funzionalità offerte dal fornitore sotto forma di soluzioni standard sono sufficienti nel 99% dei casi.
Che cosa sono le reti overlay
Qual è l' idea delle reti overlay? In sostanza, si prende una rete classica instradabile e si costruisce sopra di essa un'altra rete, per ottenere più funzionalità. Spesso si parla di un'efficace distribuzione del carico su hardware e linee di comunicazione, di un aumento significativo dei limiti di scalabilità, di miglioramento dell'affidabilità e di una serie di vantaggi in termini di sicurezza (grazie alla segmentazione). Le soluzioni SDN, oltre a questo, offrono la possibilità di amministrazione molto, molto, molto comoda e flessibile, rendendo la rete più trasparente per i suoi utenti.
In generale, se le reti locali fossero state inventate negli anni 2010, non avrebbero affatto avuto l'aspetto di ciò che ci è stato lasciato in eredità dai militari degli anni '70.
Dal punto di vista delle tecnologie per la costruzione di fabbriche utilizzando reti overlay, attualmente esistono molte realizzazioni da parte di produttori e progetti Internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve e altri). Sì, ci sono standard, ma l'implementazione di questi standard da parte di vari produttori può differire, pertanto, nella creazione di tali fabbriche, abbandonare completamente il fornitore è ancora possibile solo in teoria sulla carta.
Con le soluzioni SD la situazione è ancora più complessa, ogni fornitore ha la propria visione. Ci sono soluzioni completamente aperte, che in teoria possono essere modificate autonomamente, e ci sono soluzioni completamente chiuse.
Cisco offre la propria versione di SDN per i data center: ACI. Naturalmente si tratta di una soluzione completamente vendor-lock, dal punto di vista della scelta dell'hardware, ma si integra perfettamente con i sistemi di virtualizzazione, containerizzazione, sicurezza, orchestrazione, bilanciamento del carico e altro. Tuttavia, in sostanza, rimane un tipo di black box, senza possibilità di accesso completo a tutti i processi interni. Non tutti i clienti accettano questa soluzione, poiché si dipende completamente dalla qualità del codice e dalla sua implementazione, ma d'altra parte il produttore vanta uno dei migliori supporti tecnici al mondo ed ha un team dedicato esclusivamente a questa soluzione. Per il primo progetto è stata scelta proprio Cisco ACI.
Per il secondo progetto è stata scelta una soluzione di Juniper. Anche il produttore offre il proprio SDN per i data center, ma il cliente ha deciso di rinunciare all'implementazione dello SDN. Come tecnologia per la costruzione della rete è stata scelta una fabbrica EVPN VXLAN senza l'uso di controller centralizzati.
A cosa serve
La creazione di una fabbrica consente di costruire una rete facilmente scalabile, resiliente e affidabile. L'architettura (leaf-spine) tiene conto delle peculiarità centri di elaborazione dati (percorso del traffico, minimizzazione dei ritardi e dei colli di bottiglia nella rete). Le soluzioni SD nei data center consentono di gestire in modo molto semplice, veloce e flessibile tale fabbrica e di integrarla nell'ecosistema del data center.
Entrambi i clienti avevano bisogno di costruire data center di riserva per garantire la resilienza, inoltre il traffico tra i data center doveva essere crittografato.
Il primo cliente stava già considerando soluzioni senza fabbrica come possibile standard per le proprie reti, ma nei test hanno riscontrato problemi di compatibilità STP tra diversi fornitori di hardware. Si sono verificati downtime che hanno causato interruzioni dei servizi. E per il cliente questo era critico.
Cisco era già lo standard aziendale del cliente, hanno esaminato ACI e altre opzioni e hanno deciso che valeva la pena scegliere proprio questa soluzione. Ha colpito l'automazione della gestione con un solo pulsante tramite un controller unico. I servizi si configurano più rapidamente e sono più facili da gestire. Hanno deciso di garantire la crittografia del traffico avviando MACSec tra gli switch IPN e SPINE. In questo modo, sono riusciti ad evitare il collo di bottiglia del crypto gateway, risparmiando su di esso e utilizzando al massimo la larghezza di banda.
Il secondo cliente ha scelto una soluzione senza controller da Juniper, poiché nel loro attuale Data Center c'era già una piccola installazione con realizzazione della fabbrica EVPN VXLAN. Tuttavia, non era ridondante (era utilizzato un solo switch). Hanno deciso di espandere l'infrastruttura del Data Center principale e costruire la fabbrica nel Data Center secondario. L'EVPN esistente non era utilizzato appieno: l'incapsulamento VXLAN non veniva praticamente applicato, poiché tutti gli host erano collegati a un singolo switch, e tutti gli indirizzi MAC e gli indirizzi /32 degli host erano locali, il gateway per loro era lo stesso switch, non c'erano altri dispositivi a cui era necessario costruire i tunnel VXLAN. Hanno deciso di garantire la crittografia del traffico utilizzando la tecnologia IPSEC tra i firewall (la potenza del firewall era sufficiente).
Hanno anche esaminato ACI, ma hanno concluso che a causa della dipendenza dal fornitore sarebbe stato necessario acquistare troppa gran parte di hardware, compreso il dover sostituire attrezzature nuove di recente acquisto, e questo semplicemente non ha senso economico. Sì, la fabbrica Cisco si integra con tutto, ma all'interno della stessa fabbrica sono possibili solo i suoi dispositivi.
D'altra parte, come detto in precedenza, non si può semplicemente combinare una fabbrica EVPN VXLAN con qualsiasi fornitore vicino, poiché le implementazioni del protocollo differiscono. È come cercare di incrociare Cisco e Huawei in una rete — sembriamo avere standard comuni, solo che ci sarà bisogno di un po' di sforzo. Poiché si tratta di una banca, e i test di compatibilità sarebbero molto lunghi, hanno deciso che era meglio acquistare dallo stesso fornitore ora, e non vagare troppo lontano dalle funzionalità fondamentali.
Piano di migrazione
Due Data Center basati su ACI:
Organizzazione dell'interazione tra i Data Center. È stata scelta una soluzione Multi-Pod, in cui ogni Data Center è considerato un pod. Sono stati presi in considerazione i requisiti di scalabilità in termini di numero di switch e dei ritardi tra i pod (RTT inferiore a 50 ms). È stata presa la decisione di non costruire una soluzione Multi-Site per facilitare la gestione (per la soluzione Multi-Pod viene utilizzata un'unica interfaccia di gestione, mentre per Multi-Site sarebbero state necessarie due interfacce, o un Multi-Site Orchestrator), e poiché non era richiesto un risparmio geografico dei siti.
Dal punto di vista della migrazione dei servizi dalla rete Legacy, è stata scelta l'opzione più trasparente, ovvero trasferire gradualmente i VLAN corrispondenti ai vari servizi.
Per la migrazione, a ciascun VLAN è stato creato un corrispondente EPG (End-point-group) sulla fabbrica. Inizialmente, la rete veniva estesa tra la vecchia rete e la fabbrica su L2, quindi, dopo la migrazione di tutti gli host, il gateway veniva trasferito sulla fabbrica, e l'interazione dell'EPG con la rete esistente avveniva tramite L3OUT, con l'interazione tra L3OUT e EPG descritta utilizzando contratti. Schema indicativo:
Struttura indicativa della maggior parte delle politiche della fabbrica ACI nell'immagine sottostante. Tutta la configurazione si basa su politiche annidate in altre politiche e così via. All'inizio, non è facile comprendere, ma con il tempo, come dimostra l'esperienza, gli amministratori di rete si abitua a questa struttura in circa un mese, e poi giunge la comprensione di quanto possa essere comoda.
Confronto
Nella soluzione Cisco ACI è necessaria l'acquisto di più attrezzature (switch separati per l'interazione Inter-Pod e controller APIC), il che la rende più costosa. La soluzione Juniper non ha richiesto l'acquisto di controller e attrezzature ausiliarie; è stato possibile utilizzare parzialmente l'attrezzatura già esistente del cliente.
Ecco l'architettura EVPN VXLAN della fabbrica per due Data Center del secondo progetto:
In ACI ottieni una soluzione pronta — non c'è bisogno di grattare, non c'è bisogno di ottimizzare. Durante il primo incontro del cliente con la fabbrica non sono necessari sviluppatori, non sono necessarie persone di supporto per il codice e l'automazione. Basta un semplice funzionamento, molte impostazioni possono essere fatte addirittura tramite un wizard, il che non è sempre un vantaggio, specialmente per le persone abituate alla riga di comando. In ogni caso, ci vuole tempo per riorientare la mente su nuovi binari, sulla specificità delle impostazioni tramite policy e sulla gestione di molteplici policy annidate l'una nell'altra. È molto desiderabile, oltre a questo, avere anche una chiara struttura di denominazione delle policy e degli oggetti. In caso di qualche problema nella logica di funzionamento del controller, può essere risolto solo tramite il supporto tecnico.
In EVPN — console. Soffri o gioisci. Interfaccia familiare per la vecchia guardia. Sì, ci sono configurazioni standard e guide. Dovrai leggere i manuali. Diverse costruzioni, tutto chiaro e dettagliato.
Chiaramente, in entrambi i casi è meglio, durante la migrazione, migrare prima i servizi meno critici, ad esempio, gli ambienti di test, e solo dopo aver risolto tutti i bug passare alla produzione. E non configurare il venerdì sera. Non vale la pena credere al fornitore che andrà tutto bene, è sempre meglio proteggersi.
Su ACI paghi di più, anche se attualmente Cisco sta promuovendo attivamente questa soluzione e spesso offre buoni sconti, ma risparmi sui costi di manutenzione e supporto. La gestione e qualsiasi automazione della fabbrica EVPN senza controller richiede investimenti e costi ricorrenti — monitoraggio, automazione, implementazione di nuovi servizi. Inoltre, l'avvio iniziale su ACI richiede il 30-40% di tempo in più. Questo avviene perché ci vuole più tempo per creare l'insieme completo di profili e policy necessarie, che saranno poi utilizzate. Tuttavia, man mano che la rete cresce, il numero di configurazioni necessarie diminuisce. Usando già policy, profili e oggetti precreati. Puoi configurare in modo flessibile segmentazione e sicurezza, gestire centralmente i contratti che regolano le interazioni tra gli EPG, — il volume di lavoro diminuisce drasticamente.
In EVPN è necessario configurare ogni dispositivo nella fabbrica, la possibilità di errore è maggiore.
Se ACI viene implementato più lentamente, allora EVPN ha impiegato quasi il doppio del tempo per essere messo a punto. Se nel caso di Cisco puoi sempre chiamare un ingegnere di supporto e chiedere informazioni sulla rete in generale (poiché viene coperta come soluzione), in Juniper Networks acquisti solo l'hardware, e viene coperto solo quello. I pacchetti sono partiti dal dispositivo? Bene, è un problema vostro. Ma puoi aprire una questione sulla scelta della soluzione o sul design della rete — e in tal caso ti consigliano di acquistare un servizio professionale, a pagamento.
Il supporto ACI è ottimo, perché è separato: un team dedicato si occupa solo di questo. Ci sono anche specialisti di lingua russa. La guida è dettagliata, le soluzioni sono predefinite. Esaminano e consigliano. Validano rapidamente il design, cosa che è spesso importante. Juniper Networks fa lo stesso, ma in modo molto più lento (così è stato per noi, adesso dovrebbe essere meglio secondo le voci), il che ti costringe a fare da solo tutto ciò dove potresti ricevere consigli da un ingegnere di soluzioni.
Cisco ACI supporta l'integrazione con sistemi di virtualizzazione e containerizzazione (VMware, Kubernetes, Hyper-V) e gestione centralizzata. Ci sono con servizi di rete e di sicurezza — bilanciamento, firewall, WAF, IPS e altro… Buona microsegmentazione out of the box. Nella seconda soluzione, l'integrazione con i servizi di rete è complessa, ed è meglio prima consultare i forum con chi lo ha già fatto.
Risultato
Per ogni caso specifico è necessario selezionare una soluzione, non solo in base al costo dell'hardware, ma è necessario considerare anche le spese future per l'esercizio e i principali problemi con cui il cliente si trova ad affrontare ora, e quali sono i piani per lo sviluppo dell'infrastruttura IT.
ACI, grazie all'hardware aggiuntivo, è risultato più costoso, ma la soluzione è pronta senza necessità di modifiche, mentre la seconda soluzione è più complessa e costosa dal punto di vista dell'esercizio, ma è più economica.
Se vuoi discutere di quanto potrebbe costare l'integrazione di una rete su diversi fornitori, e quale architettura è necessaria, possiamo incontrarci e parlarne. Fino alla bozza preliminare dell'architettura (con cui possiamo formulare budget) ti daremo suggerimenti gratuitamente; la lavorazione dettagliata, naturalmente, sarà a pagamento.
Vladimir Klepche, reti aziendali.
Fonte: habr.com
