Valuta le connessioni nella parte centrale dello schema. Ci torneremo dopo.
Ad un certo punto, potresti trovarti di fronte a reti L2 complesse e insostenibili. In primo luogo, a causa dei problemi legati alla gestione del traffico BUM e al funzionamento del protocollo STP. In secondo luogo, a causa di un'architettura complessivamente obsoleta. Questo provoca fastidiosi problemi come downtime e difficoltà di gestione.
Abbiamo avuto due progetti paralleli, dove i clienti hanno valutato con lucidità tutti i pro e i contro delle opzioni e hanno scelto due diverse soluzioni overlay, che noi abbiamo implementato.
Abbiamo avuto l'opportunità di confrontare specificamente l'implementazione. Non l'operatività, di cui si parlerà tra due o tre anni.
Allora, che cos'è una fabbrica di rete con overlay e SDN?
Cosa fare con i problemi irrisolti dell'architettura di rete classica?
Ogni anno emergono nuove tecnologie e idee. Nella pratica, la necessità urgente di ristrutturare le reti non si è presentata per un lungo periodo, poiché si poteva sempre fare tutto manualmente con metodi tradizionali. E che importa se siamo nel ventunesimo secolo? In fondo, l'amministratore deve lavorare, non rimanere chiuso nel proprio ufficio.
Poi è iniziato il boom nella costruzione di data center di grande scala. È diventato chiaro che era stato raggiunto il limite di sviluppo dell'architettura classica non solo in termini di funzionalità, resilienza e scalabilità. E una delle opzioni per affrontare queste sfide è stata l'idea di costruire reti overlay sopra una backbone instradabile.
Inoltre, con l'aumento delle dimensioni delle reti, è emerso il problema della gestione di tali fabbriche, dando origine a soluzioni di reti programmabili che permettono di gestire l'intera infrastruttura di rete come un'unica entità. Quando la rete è gestita da un unico punto, diventa più facile per gli altri componenti dell'infrastruttura IT interagire con essa, rendendo più semplici i processi di automazione.
Praticamente ogni grande produttore non solo di apparecchiature di rete, ma anche di virtualizzazione, ha nel proprio portafoglio opzioni per tali soluzioni.
Restano solo da comprendere quali si adattino a determinate esigenze. Ad esempio, per le aziende particolarmente grandi che dispongono di un buon team di sviluppatori e gestione, le soluzioni preconfezionate dei fornitori non sempre soddisfano tutte le necessità, spingendole a sviluppare proprie soluzioni SD (software defined). Questo vale per i fornitori di servizi cloud, che ampliano continuamente l'offerta di servizi ai propri clienti, ed è evidente che le soluzioni pronte non riescono a stare al passo con le loro esigenze.
Per le aziende medie, le funzionalità offerte dal fornitore attraverso una soluzione preconfezionata sono sufficienti nel 99% dei casi.
Cosa sono le reti overlay?
Di cosa si tratta nelle idee delle reti overlay? In sostanza, prendi una rete classica instradabile e costruisci un'altra rete sopra di essa per ottenere ulteriori funzionalità. Spesso si parla di un'efficace distribuzione del carico su hardware e linee di connessione, di un notevole aumento dei limiti di scalabilità, di una maggiore affidabilità e una serie di vantaggi in materia di sicurezza (grazie alla segmentazione). Le soluzioni SDN, inoltre, offrono la possibilità di un'amministrazione molto, molto, molto flessibile e rendono la rete più trasparente per i suoi utilizzatori.
In generale, se le reti locali fossero state inventate intorno agli anni 2010, sarebbero apparse molto diverse rispetto a quelle che abbiamo ereditato dai militari degli anni '70.
Dal punto di vista delle tecnologie per la costruzione di fabbriche utilizzando reti overlay, attualmente esistono molte implementazioni da parte di produttori e progetti internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve e altri). Ci sono standard, ma l'implementazione di questi standard da parte di diversi produttori può variare, quindi nella creazione di tali fabbriche, all'idea di eliminare totalmente la dipendenza dai fornitori si può arrivare solo in teoria, sulla carta.
Con le soluzioni SD, la situazione è ancora più complicata, ogni fornitore ha la propria visione. Ci sono soluzioni completamente aperte, che in teoria possono essere personalizzate, e soluzioni completamente chiuse.
Cisco offre la sua versione di SDN per i data center - ACI. Naturalmente, si tratta di una soluzione completamente vendor-lock in termini di scelta dell'hardware di rete, ma è completamente integrata con i sistemi di virtualizzazione, containerizzazione, sicurezza, orchestrazione, bilanciamento del carico, ecc. Tuttavia, essenzialmente rimane un certo tipo di scatola nera, senza possibilità di accesso completo a tutti i processi interni. Non tutti i clienti accettano questa opzione, poiché si è completamente dipendenti dalla qualità del codice dell'applicazione e dalla sua implementazione. D'altra parte, il produttore ha uno dei migliori servizi di assistenza tecnica al mondo e dispone di un team dedicato a questa soluzione. Per il primo progetto è stata scelta proprio Cisco ACI.
Per il secondo progetto è stata scelta una soluzione basata su Juniper. Anche il produttore ha il suo SDN per i data center, ma il cliente ha deciso di rinunciare all'implementazione di SDN. Come tecnologia per la 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 caratteristiche centri di elaborazione dati (dei percorsi di traffico, minimizzazione dei ritardi e dei colli di bottiglia nella rete). Le soluzioni SD nei data center consentono di gestire facilmente, rapidamente e in modo flessibile tale fabbrica, integrandola nell'ecosistema del data center.
Entrambi i clienti avevano bisogno di costruire data center di riserva per garantire la resilienza, oltre a dover criptare il traffico tra i data center.
Il primo cliente stava già considerando soluzioni senza fabbrica come possibile standard per le sue reti, ma durante i test hanno riscontrato problemi di compatibilità STP tra diversi fornitori di hardware. Si sono verificati downtime che causavano il crash 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. Hanno apprezzato l'automazione della gestione con un clic tramite un unico controllore. I servizi vengono configurati più rapidamente e gestiti più agilmente. Hanno deciso di garantire la crittografia del traffico avviando MACSec tra gli switch IPN e SPINE. In questo modo, sono riusciti a evitare un collo di bottiglia rappresentato dal gateway crittografico, risparmiando su di esso e massimizzando la larghezza di banda.
Il secondo cliente ha scelto una soluzione senza controller da Juniper, poiché nel loro data center esistente c'era già una piccola installazione con la realizzazione di una fabbrica EVPN VXLAN. Ma lì non era resiliente (utilizzava uno switch). Hanno deciso di espandere l'infrastruttura del data center principale e costruire una fabbrica nel data center di riserva. L'EVPN esistente non veniva utilizzato appieno: l'incapsulamento VXLAN non veniva praticamente applicato, poiché tutti gli host erano collegati a uno switch e tutti gli indirizzi MAC e indirizzi /32 degli host erano locali, e lo switch stesso fungeva da gateway per loro, non c'erano altri dispositivi per i quali era necessario costruire tunnel VXLAN. Hanno deciso di garantire la crittografia del traffico utilizzando la tecnologia IPSEC tra i firewall (le prestazioni del MSE erano sufficienti).
Hanno anche esaminato ACI, ma hanno deciso che a causa del vendor-lock avrebbero dovuto acquistare troppi dispositivi, inclusa la sostituzione dell'hardware recentemente acquistato, il che non aveva semplicemente senso economico. Sì, la fabbrica Cisco si integra con tutto, ma all'interno della fabbrica stessa possono sostanzialmente esserci solo i suoi dispositivi.
D'altra parte, come detto in precedenza, non è così semplice mescolare una fabbrica EVPN VXLAN con qualsiasi fornitore vicino, perché le implementazioni del protocollo sono diverse. È come provare a mescolare Cisco e Huawei in una rete - in superficie, gli standard sono comuni, solo che bisogna ballare con il tamburo. Poiché questo è una banca e i test di compatibilità sarebbero stati molto lunghi, hanno deciso che era meglio acquistare dallo stesso fornitore ora e non lasciarsi trasportare dalle funzionalità al di là di quelle di base.
Piano di migrazione
Due data center basati su ACI:
Organizzazione dell'interazione tra i data center. È stata scelta una soluzione Multi-Pod - ogni data center è un pod. Sono stati considerati i requisiti per la scalabilità in termini di numero di switch e per i ritardi tra i pod (RTT inferiore a 50 ms). È stata presa la decisione di non costruire una soluzione Multi-Site per comodità di gestione (per la soluzione Multi-Pod viene utilizzata un'interfaccia di gestione unica, per Multi-Site sarebbero state necessarie due interfacce, o sarebbe stato necessario un orchestratore Multi-Site), e poiché non era necessaria la riserva geografica delle sedi.
Dal punto di vista della migrazione dei servizi dalla rete Legacy, è stata scelta l'opzione più trasparente: trasferire gradualmente i VLAN corrispondenti a determinati servizi.
Per ogni VLAN migrata, veniva creato un corrispondente EPG (End-point-group) in fabbrica. Inizialmente, la rete si estendeva tra la rete esistente e la fabbrica in L2, poi, dopo la migrazione di tutti gli host, il gateway veniva spostato in fabbrica, e l'interazione tra EPG e la rete esistente avveniva tramite L3OUT, con l'interazione tra L3OUT ed EPG descritta tramite contratti. Schema esemplificativo:
Struttura esemplificativa della maggior parte delle politiche della fabbrica ACI nell'immagine sottostante. Tutta la configurazione si basa su politiche, incorporate in altre politiche e così via. All'inizio è molto complicato orientarsi, ma pian piano, come dimostra l'esperienza, gli amministratori di rete si abituano a questa struttura in circa un mese, e poi arriva la comprensione di quanto sia comoda.
Confronto
Nella soluzione Cisco ACI è necessario acquistare più hardware (switch separati per l'interazione inter-Pod e controller APIC), il che porta a un costo maggiore. La soluzione Juniper non ha richiesto l'acquisto di controller e hardware di supporto; è stato possibile utilizzare parzialmente l'hardware esistente del cliente.
Ecco l'architettura EVPN VXLAN della fabbrica per due data center del secondo progetto:
In ACI ottieni una soluzione pronta all'uso — non devi modificare, non devi ottimizzare. Durante il primo incontro del cliente con la fabbrica, non sono necessari sviluppatori o personale di supporto per codice e automazione. È sufficiente una normale operazione, molte impostazioni possono essere fatte tramite un wizard, il che non è sempre un vantaggio, soprattutto per chi è abituato alla riga di comando. In ogni caso, è necessario del tempo per riadattare la mente a nuovi processi, alla particolarità delle impostazioni tramite politiche e alla gestione di molte politiche annidate. È molto desiderabile, oltre a questo, avere anche una chiara struttura di denominazione per politiche e oggetti. In caso di problemi nella logica di funzionamento del controller, è possibile risolverli solo attraverso il supporto tecnico.
In EVPN — console. Soffri o godi. Interfaccia familiare per la vecchia guardia. Sì, ci sono configurazioni standard e guide. Dovrai consultare le documentazioni. Diverse strutture, tutto chiaro e dettagliato.
Naturalmente, in entrambi i casi è meglio che durante la migrazione vengano prima migrate le risorse meno critiche, come gli ambienti di test, e poi, dopo aver risolto tutti i bug, passare ai servizi in produzione. E non configurare il venerdì sera. Non vale la pena fidarsi del fornitore, che andrà tutto bene; è sempre meglio prendere precauzioni.
In ACI paghi di più, anche se attualmente Cisco promuove attivamente questa soluzione e spesso concede buoni sconti, ma risparmi sulle spese di manutenzione. La gestione e qualsiasi automazione della fabbrica EVPN senza controller richiede investimenti e costi regolari — monitoraggio, automazione, implementazione di nuovi servizi. Invece, l'avvio iniziale di ACI richiede il 30–40% in più di tempo. Questo perché serve più tempo per creare l'intero set di profili e politiche necessarie che saranno utilizzate successivamente. Tuttavia, con la crescita della rete, il numero di configurazioni necessarie diminuisce. Utilizzi già politiche, profili e oggetti pre-creati. Puoi configurare flessibilmente la segmentazione e la sicurezza, gestire centralmente i contratti che regolano le interazioni tra EPG, e quindi il volume di lavoro diminuisce notevolmente.
In EVPN è necessario configurare ogni dispositivo nella fabbrica, aumentando il rischio di errori.
Se ACI si implementa più lentamente, EVPN richiede quasi il doppio del tempo per la messa a punto. Se nel caso di Cisco si può sempre chiamare un ingegnere di supporto e chiedere informazioni sulla rete in generale (perché è coperta come soluzione), in Juniper Networks acquisti solo hardware, e questo è ciò che viene coperto. I pacchetti sono stati inviati dai dispositivi? Va bene, ora sono problemi tuoi. Ma puoi sollevare una questione sulla scelta della soluzione o del design della rete — e ti consiglia di acquistare servizi professionali a pagamento aggiuntivo.
Il supporto ACI è ottimo, perché è separato: una squadra distinta si occupa solo di questo. Ci sono anche esperti di lingua russa. La guida è dettagliata, le soluzioni sono predefinite. Analizzano e consigliano. Validano rapidamente il design, il che è spesso importante. Juniper Networks fa lo stesso, ma molto più lentamente (è stata così, ora dovrebbe essere meglio a quanto si dice), il che ti costringe a fare tutto da solo dove avresti potuto chiedere consiglio a un ingegnere di soluzione.
Cisco ACI supporta l'integrazione con i sistemi di virtualizzazione e containerizzazione (VMware, Kubernetes, Hyper-V) e la gestione centralizzata. Include servizi di rete e di sicurezza — bilanciamento, firewall, WAF, IPS e altro… Ottima micro-segmentazione out-of-the-box. Nella seconda soluzione, l'integrazione con i servizi di rete richiede una certa attivazione, e sarebbe meglio esplorare in anticipo i forum con chi ha già esperienza in tal senso.
Risultato
Per ogni singolo caso è necessario scegliere una soluzione, non solo in base al costo dell'hardware, ma anche considerando i futuri costi operativi e i principali problemi con cui si confronta attualmente il cliente, oltre ai piani per lo sviluppo dell'infrastruttura IT.
ACI, grazie all'hardware aggiuntivo, risulta più costoso, ma si tratta di una soluzione pronta senza la necessità di ulteriori modifiche. La seconda soluzione è più complessa e costosa dal punto di vista operativo, ma risulta più economica.
Se desideri discutere il costo della implementazione di una rete basata su diversi vendor e quale architettura sia necessaria, possiamo incontrarci e parlarne. Fino alla bozza preliminare dell'architettura (da cui partire per stimare i budget) possiamo offrire supporto gratuito; ovviamente, la pianificazione dettagliata è già a pagamento.
Vladimir Klepche, reti aziendali.
Fonte: habr.com
