Con questo pezzo magico di script Cisco ACI, è possibile configurare rapidamente la rete.
La rete fabricha per i data center Cisco ACI esiste da cinque anni, ma su Habr non si è parlato molto di essa, quindi ho deciso di rimediare un po'. Racconterò dalla mia esperienza cos'è, quali sono i vantaggi e quali sono le insidie.
Cos'è e da dove proviene?
Al momento dell'annuncio di ACI (Application Centric Infrastructure) nel 2013, i concorrenti avanzavano da tre fronti contro gli approcci tradizionali alle reti dei data center.
Da un lato, le soluzioni SDN di "prima generazione" basate su OpenFlow promettevano di rendere le reti più flessibili e economiche allo stesso tempo. L'idea era di spostare le decisioni, tradizionalmente effettuate dal software proprietario degli switch, a un controller centrale.
Questo controller avrebbe avuto una visione unica di tutto ciò che accadeva e, a partire da essa, avrebbe programmato l'hardware di tutti gli switch a livello di regole per il trattamento di flussi specifici.
Dall'altro lato, le soluzioni di rete overlay permettevano di realizzare la connettività desiderata e le politiche di sicurezza senza apportare modifiche alla rete fisica, costruendo tunnel software tra host virtualizzati. Un esempio molto noto di questo approccio era la soluzione di Nicira, che a quel punto era già stata acquisita da VMWare per 1,26 miliardi di dollari e ha dato origine all'attuale VMWare NSX. Aggiungeva un po' di pepe alla situazione il fatto che i cofondatori di Nicira fossero le stesse persone che in precedenza erano state all'origine di OpenFlow, ora affermavano che per costruire la fabbrica di un data center .
Infine, i chip di commutazione disponibili sul mercato aperto (quelli che vengono definiti merchant silicon) hanno raggiunto un livello di maturità tale da rappresentare una reale minaccia per i produttori tradizionali di switch. Se un tempo ogni fornitore sviluppava i propri chip per i suoi switch, nel tempo i chip dei produttori esterni, principalmente da Broadcom, hanno iniziato ad avvicinarsi ai chip dei fornitori in termini di funzionalità e, rispetto al rapporto prezzo/prestazioni, li superavano. Per questo motivo, molti ritenevano che i giorni degli switch basati su chip progettati internamente fossero contati.
ACI è stata una «risposta asimmetrica» di Cisco (piuttosto, della società Insieme entrata a far parte di essa, fondata da ex dipendenti) a tutto ciò che è stato elencato.
Qual è la differenza con OpenFlow?
Dal punto di vista della distribuzione delle funzioni, ACI è di fatto l'opposto di OpenFlow.
Nell'architettura OpenFlow, il controller è responsabile della scrittura di regole dettagliate (flussi)
nell'hardware di tutti gli switch, il che significa che in una rete su larga scala può essere responsabile della gestione e, soprattutto, della modifica di decine di milioni di record in centinaia di punti nella rete; pertanto, le sue prestazioni e affidabilità in una grande implementazione diventano un collo di bottiglia.
In ACI si utilizza un approccio inverso: c'è sicuramente anche un controller, ma gli switch ricevono da esso politiche dichiarative ad alto livello, e la loro traduzione in dettagli specifici delle configurazioni hardware viene eseguita dallo switch stesso. Il controller può essere riavviato o spento del tutto, e non succede nulla di male alla rete, tranne, ovviamente, l'assenza in quel momento della possibilità di gestione. È interessante notare che in ACI ci sono situazioni in cui OpenFlow viene comunque utilizzato, ma in modo locale all'interno dell'host per programmare Open vSwitch.
ACI è interamente costruita su un trasporto overlay basato su VXLAN, ma include anche il trasporto IP sottostante all'interno di una soluzione unica. Cisco ha definito questo termine "overlay integrato". Come punto di terminazione degli overlay, in ACI, si utilizzano per la maggior parte degli switch di fabbrica (lo fanno alla velocità del canale). Gli host non devono sapere nulla sulla fabbrica, sull'incapsulazione, ecc.; tuttavia, in alcuni casi (ad esempio, per la connessione di host OpenStack), il traffico VXLAN può raggiungerli.
Gli overlay in ACI non vengono utilizzati solo per garantire una connettività flessibile attraverso la rete di trasporto, ma anche per la trasmissione di metainformazioni (utilizzate, ad esempio, per l'applicazione delle politiche di sicurezza).
I chip Broadcom erano già utilizzati da Cisco negli switch della serie Nexus 3000. Nella famiglia Nexus 9000, appositamente rilasciata per supportare ACI, è stata inizialmente implementata una modello ibrido chiamato Merchant+. Nello switch sono stati utilizzati contemporaneamente il nuovo chip Broadcom Trident 2 e un chip complementare sviluppato da Cisco, che implementava tutta la magia di ACI. A quanto pare, questo ha consentito di accelerare il lancio del prodotto e di ridurre il prezzo dello switch a un livello vicino ai modelli basati solo su Trident 2. Questo approccio è stato sufficiente per i primi due-tre anni di fornitura di ACI. Durante questo periodo, Cisco ha sviluppato e lanciato sul mercato la generazione successiva di Nexus 9000 già basata su chip proprietari con prestazioni e funzionalità superiori, ma al medesimo livello di prezzo. Le specifiche esterne in termini di interazione all'interno della fabbrica sono rimaste del tutto invariate. Nel contempo, l'hardware interno è stato completamente rivoluzionato: qualcosa di simile a un refactoring, ma per il ferro.
Come è strutturata l'architettura Cisco ACI
Nel caso più semplice, ACI è costruito secondo la topologia di rete Clos, o, come viene spesso chiamata, Spine-Leaf. Ci possono essere da due (o uno, se non ci interessa la resilienza) a sei switch di livello Spine. Di conseguenza, maggiore è il numero, maggiore è la resilienza (minore riduzione della banda e dell'affidabilità in caso di guasto o manutenzione di uno Spine) e la performance complessiva. Tutte le connessioni esterne vanno agli switch di livello Leaf: ci sono server, interfacce con reti esterne via L2 o L3 e connessioni ai controller APIC. In generale, con ACI non solo la configurazione, ma anche la raccolta di statistiche, il monitoraggio dei guasti e altro — tutto avviene tramite l'interfaccia dei controller, che in implementazioni di dimensioni normali sono tre.
Non è mai necessario collegarsi agli switch tramite console, neppure per avviare la rete: il controller rileva automaticamente gli switch e li aggrega in una fabbrica, incluso la configurazione di tutti i protocolli di servizio, quindi, a tal proposito, è molto importante registrare i numeri di serie dell'attrezzatura installata durante il montaggio, per non dover indovinare quale switch si trova in quale rack. Per il troubleshooting, se necessario, ci si può collegare agli switch tramite SSH: su di essi sono state accuratamente riprodotte le comuni show-commands di Cisco.
All'interno, il fabric utilizza trasporto IP, quindi non ci sono Spanning Tree o altre orribili reliquie del passato: tutti i collegamenti sono attivi e la convergenza in caso di guasti è molto rapida. Il traffico nel fabric viene trasmesso attraverso tunnel basati su VXLAN. In effetti, Cisco stessa chiama l'incapsulazione iVXLAN, e si differenzia dal normale VXLAN perché i campi riservati nell'intestazione di rete vengono utilizzati per la trasmissione di informazioni di servizio, soprattutto riguardo al rapporto del traffico con il gruppo EPG. Questo consente di implementare regole di interazione tra i gruppi direttamente nell'hardware, utilizzando i loro numeri proprio come si utilizzano gli indirizzi nelle normali access list.
I tunnel consentono di estendere attraverso il trasporto IP interno sia segmenti L2 che L3 (cioè VRF). In questo caso, il gateway predefinito è distribuito. Ciò significa che ogni switch si occupa dell'instradamento del traffico in entrata nel fabric. Dal punto di vista della logica di trasmissione del traffico, ACI è simile a un fabric basato su VXLAN/EVPN.
Se è così, quali sono le differenze? In tutto il resto!
La prima differenza che si incontra in ACI è il modo in cui i server vengono connessi alla rete. Nelle reti tradizionali, la connessione sia dei server fisici che delle macchine virtuali avviene in VLAN, e tutto il resto dipende da ciò: connettività, sicurezza, ecc. In ACI, invece, si utilizza una struttura che Cisco chiama EPG (End-point Group), dalla quale non si può prescindere. Si può equiparare a VLAN? Sì, ma in questo caso si rischia di perdere gran parte di ciò che offre ACI.
Tutte le regole di accesso vengono formulate rispetto a EPG, e in ACI per impostazione predefinita viene utilizzato il principio della "lista bianca", ovvero è consentito solo il traffico il cui passaggio è esplicitamente autorizzato. Ciò significa che possiamo creare gruppi EPG "Web" e "MySQL" e definire una regola che consente l'interazione tra di essi solo sulla porta 3306. Questo funzionerà senza legami agli indirizzi di rete e persino all'interno della stessa sottorete!
Abbiamo clienti che hanno scelto ACI proprio per questa caratteristica, poiché consente di limitare gli accessi tra i server (virtuali o fisici — non importa), senza spostarli tra le sottoreti, il che significa non modificare l'indirizzamento. Sì, sì, sappiamo che nessuno scrive a mano Indirizzi IP nelle configurazioni delle applicazioni, vero?
Le regole per il passaggio del traffico in ACI sono chiamate contratti. In tale contratto, uno o più gruppi o livelli in un'applicazione multi-tier diventano fornitori di servizi (ad esempio, un servizio di database), mentre altri sono i consumatori. Un contratto può semplicemente consentire il traffico, oppure può fare qualcosa di più complesso, come reindirizzarlo a un firewall o a un bilanciatore di carico, oltre a modificare il valore QoS.
Come vengono inseriti i server in questi gruppi? Se si tratta di server fisici o di qualcosa integrato in una rete esistente in cui abbiamo creato un trunk VLAN, è necessario specificare la porta dello switch e la VLAN utilizzata su di essa per inserirli in EPG. Come possiamo vedere, le VLAN appaiono dove non possono mancare.
Se invece i server sono delle macchine virtuali, è sufficiente riferirsi all'ambiente di virtualizzazione connesso, e poi tutto avverrà da solo: verrà creata un port-group (se parliamo in termini di VMWare) per collegare le VM, verranno assegnate le VLAN o le VXLAN necessarie, e così via. Quindi, anche se ACI è costruito attorno alla rete fisica, per i server virtuali i collegamenti sembrano molto più semplici rispetto a quelli fisici. ACI ha già integrato il collegamento con VMWare e MS Hyper-V, oltre al supporto per OpenStack e RedHat Virtualization. A un certo punto è apparso anche il supporto integrato per le piattaforme container: Kubernetes, OpenShift, Cloud Foundry, e riguarda sia l'applicazione delle politiche che il monitoraggio. Ciò significa che l'amministratore di rete può vedere immediatamente su quali host operano quali pod e in quali gruppi sono stati inseriti.
Oltre all'inclusione in un certo port-group, i server virtuali hanno proprietà aggiuntive: nome, attributi, ecc., che possono essere utilizzate come criteri per il loro trasferimento in un altro gruppo, ad esempio in caso di rinomina di una VM o dell'aggiunta di un'etichetta. Cisco chiama queste microsegmentazioni, anche se, a dire il vero, la stessa struttura che consente di creare molti segmenti di sicurezza sotto forma di EPG nella stessa sottorete è anch'essa una sorta di microsegmentazione. Beh, la casa produttrice sa meglio.
Gli EPG sono puramente costrutti logici, non vincolati a specifici switch, server ecc., quindi con essi e le costruzioni basate su di essi (applicazioni e tenant) si possono fare cose difficili da realizzare nelle reti tradizionali, per esempio, clonare. Di conseguenza, per esempio, è molto facile creare un clone di un ambiente produttivo per ottenere un ambiente di test garantito identico al produttivo. Si può fare manualmente, ma è meglio (e più semplice) farlo tramite API.
In generale, la logica di gestione in ACI è completamente diversa da quella con cui ci si imbatte di solito
nelle reti tradizionali della stessa Cisco: l'interfaccia programmabile è primaria, mentre GUI o CLI sono secondarie, poiché funzionano tramite la stessa API. Pertanto, quasi chiunque lavori con ACI, dopo un certo tempo, inizia a orientarsi nel modello a oggetti utilizzato per la gestione e a automatizzare qualcosa per le proprie esigenze. È più semplice farlo con Python: ci sono strumenti pratici già pronti per lui.
Le trappole promesse
Il problema principale è che molte cose in ACI sono progettate diversamente. Per iniziare a lavorare correttamente con essa, è necessario riprendere l'apprendimento. Questo vale soprattutto per i team di gestione della rete nei grandi clienti, dove gli ingegneri si sono occupati per anni di "stabilire VLAN" su richiesta. Il fatto che ora una VLAN non sia più una VLAN, e che per la creazione di nuove reti su host virtualizzati non sia affatto necessario creare VLAN manualmente, sorprende completamente gli addetti alle reti tradizionali e li costringe a mantenersi aggrappati agli approcci abituali. Va notato che Cisco ha cercato di rendere le cose un po' più facili e ha aggiunto un CLI "simile a NXOS" nel controller, che consente di effettuare configurazioni tramite un'interfaccia simile a quella degli switch tradizionali. Tuttavia, per iniziare a utilizzare ACI in modo corretto, sarà necessario comprendere come funziona.
Dal punto di vista dei costi, le reti ACI su larga e media scala non si differenziano effettivamente dalle reti tradizionali con hardware Cisco, poiché si utilizzano gli stessi switch (i Nexus 9000 possono operare sia in modalità ACI sia in modalità tradizionale e sono attualmente il "cavallo di battaglia" principale per i nuovi progetti nei data center). Tuttavia, per i data center che utilizzano due switch, la presenza di controller e dell'architettura Spine-Leaf si fa sentire. Recentemente è stata introdotta una Mini ACI-factory, in cui due dei tre controller sono stati sostituiti da macchine virtuali. Questo consente di ridurre la differenza di costo, ma essa rimane comunque. Pertanto, per il cliente, la scelta è dettata dall'interesse verso le funzionalità di sicurezza, integrazione con la virtualizzazione, punto di gestione unico e altro ancora.
Fonte: habr.com
