Con questo straordinario pezzo di script Cisco ACI puoi configurare rapidamente la rete.
Il Network Fabric per il Data Center con Cisco ACI esiste già da cinque anni, ma su Habr non se n'è parlato molto, quindi ho deciso di rimediare. Condividerò la mia esperienza su cos'è, quali vantaggi offre e dove si trovano le insidie.
Cos'è e da dove proviene?
Al momento dell'annuncio dell'ACI (Application Centric Infrastructure) nel 2013, approcci tradizionali per le reti Data Center erano attaccati da concorrenti su tre fronti.
Da un lato, le soluzioni SDN di 'prima generazione' basate su OpenFlow promettevano di rendere le reti più flessibili e convenienti 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 complessiva di tutto ciò che accadeva e, sulla base di ciò, avrebbe programmato l'hardware di tutti gli switch a livello di regole di elaborazione per specifici flussi.
D'altra parte, le soluzioni di rete overlay consentivano di realizzare la connettività necessaria e le politiche di sicurezza senza apportare modifiche alla rete fisica, creando tunnel software tra gli host virtualizzati. Un esempio noto di questo approccio è stata la soluzione di Nicira, che a quel tempo era già stata acquisita da VMWare per 1,26 miliardi di dollari e ha dato vita all'attuale VMWare NSX. Aggiungeva un po' di pepe alla situazione il fatto che i co-fondatori di Nicira fossero le stesse persone che in precedenza avevano contribuito alle origini di OpenFlow, ora affermando che per costruire una fabbrica di data center. .
Infine, i chip di switching disponibili sul mercato (quelli noti come merchant silicon) hanno raggiunto un livello di maturità tale da costituire una vera minaccia per i produttori tradizionali di switch. Se in passato ogni vendor sviluppava autonomamente i chip per i propri switch, col passare del tempo i chip dei produttori terzi, in particolare quelli di Broadcom, hanno iniziato a ridurre il divario con i chip dei vendor in termini di funzionalità, e li hanno superati in termini di rapporto prezzo/performance. Pertanto, molti ritenevano che i giorni degli switch basati su chip di sviluppo proprietario fossero contati.
ACI è stata la "risposta asimmetrica" di Cisco (più precisamente, della società Insieme, fondata dai suoi ex dipendenti) a tutto ciò che è stato elencato.
Qual è la differenza rispetto a 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 grande rete potrebbe essere responsabile del mantenimento 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'è anche il controller, ma gli switch ricevono da esso politiche dichiarative ad alto livello, e il loro rendering nei dettagli delle impostazioni specifiche nell'hardware viene eseguito dallo switch stesso. Il controller può essere riavviato o persino spento, e con la rete non succede nulla di negativo, tranne, naturalmente, l'assenza in quel momento della possibilità di gestione. È interessante notare che in ACI ci sono situazioni in cui OpenFlow viene ancora utilizzato, ma localmente all'interno dell'host per programmare Open vSwitch.
ACI è interamente basata sul trasporto overlay basato su VXLAN, ma include anche, all'interno di una soluzione unica, il trasporto IP sottostante. Cisco ha definito questo termine "overlay integrato". Per la terminazione degli overlay in ACI, si utilizzano nella maggior parte dei casi gli switch di fabbrica (realizzando questa operazione alla velocità di banda). Gli host non devono necessariamente sapere nulla sulla fabbrica, l'incapsulamento, ecc., tuttavia in alcuni casi (ad esempio, per il collegamento degli host OpenStack) il traffico VXLAN può essere indirizzato anche a loro.
Gli overlay sono utilizzati in ACI non solo per garantire una connettività flessibile attraverso la rete di trasporto, ma anche per la trasmissione di metainformazioni (che vengono 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, progettata specificamente per supportare ACI, è stata inizialmente implementata un modello ibrido chiamato Merchant+. Nello switch erano presenti contemporaneamente il nuovo chip Broadcom Trident 2 e un chip complementare progettato da Cisco, che realizzava tutta la magia di ACI. Questo ha apparentemente consentito di accelerare il lancio del prodotto e di ridurre il prezzo dello switch a un livello vicino ai modelli con Trident 2. Questo approccio è durato i primi due o tre anni di distribuzione di ACI. Durante questo periodo, Cisco ha sviluppato e lanciato sul mercato la successiva generazione di Nexus 9000 basata sui propri chip, con prestazioni superiori e un migliore set di funzionalità, ma mantenendo lo stesso livello di prezzo. Le specifiche esterne in termini di interazione nella fabbrica sono rimaste completamente invariate. Tuttavia, l'hardware interno è cambiato completamente: qualcosa di simile a un refactoring, ma per il ferro.
Come è strutturata l'architettura Cisco ACI
Nel caso più semplice, l’ACI viene costruito secondo la topologia della rete Clos, o come spesso viene chiamata, Spine-Leaf. Ci possono essere da due (o uno, se non ci preoccupa la tolleranza agli errori) a sei switch di livello Spine. Pertanto, più switch ci sono, maggiore è la tolleranza agli errori (minore è la riduzione della capacità e dell'affidabilità in caso di guasti o manutenzione di uno switch Spine) e le prestazioni complessive. Tutte le connessioni esterne sono collegati agli switch di livello Leaf: includono sia i server che l’interfacciamento con reti esterne tramite L2 o L3, e il collegamento ai controller APIC. Con l’ACI, non solo la configurazione ma anche la raccolta delle statistiche, il monitoraggio dei guasti e altro — tutto avviene tramite l'interfaccia dei controller, che in implementazioni di dimensioni normali sono tre.
Non è necessario collegarsi ai comutatori tramite console, nemmeno per avviare la rete: il controller rileva autonomamente i comutatori e li aggrega in una rete, includendo le configurazioni di tutti i protocolli di servizio. Per questo motivo, è molto importante annotare i numeri di serie dell'attrezzatura installata durante il montaggio, così da non dover indovinare quali comutatori si trovano in quali rack. Per il troubleshooting, è possibile collegarsi ai comutatori tramite SSH, dove sono state riprodotte con precisione le comuni comandi show di Cisco.
All'interno, la fabbrica utilizza il trasporto IP, quindi non ci sono Spanning Tree e altre atrocità del passato: tutti i link sono attivi e la convergenza in caso di guasti è molto rapida. Il traffico nella fabbrica viene trasmesso tramite tunnel basati su VXLAN. Per essere più precisi, Cisco stessa chiama l'incapsulamento iVXLAN, che si differenzia dal normale VXLAN in quanto i campi riservati nell'intestazione di rete sono utilizzati per trasmettere informazioni di servizi, soprattutto riguardo alla relazione del traffico con il gruppo EPG. Questo consente di implementare regole di interazione tra i gruppi nell'hardware, utilizzando i loro numeri esattamente come negli access-list normali si usano gli indirizzi.
I tunnel consentono di estendere sia segmenti L2 che L3 (cioè VRF) tramite il trasporto IP interno. Inoltre, il gateway predefinito è distribuito. Ciò significa che ogni switch gestisce la routing del traffico in entrata nella fabbrica. In termini di logica di trasmissione del traffico, ACI assomiglia a una fabbrica basata su VXLAN/EVPN.
Se è così, quali sono le differenze? In tutto il resto!
La principale differenza con cui ci si scontra in ACI è come i server vengono connessi alla rete. Nelle reti tradizionali, l'inclusione sia dei server fisici che delle macchine virtuali avviene in VLAN, da cui tutto il resto deriva: connettività, sicurezza, ecc. In ACI, invece, si utilizza una struttura chiamata EPG (End-point Group) da cui non si può prescindere. Si può equiparare questo concetto a una VLAN? Sì, ma in questo caso si rischia di perdere gran parte dei vantaggi offerti da ACI.
Riguardo all'EPG, vengono formulate tutte le regole di accesso, e in ACI per impostazione predefinita viene utilizzato il principio della «lista bianca», cioè è consentito solo il traffico per il quale è esplicitamente autorizzato il passaggio. Ciò significa che possiamo creare gruppi EPG «Web» e «MySQL» e definire una regola che consente l'interazione tra di loro solo sulla porta 3306. Questo funzionerà senza vincoli agli indirizzi di rete e anche all'interno della stessa sottorete!
Abbiamo clienti che hanno scelto ACI proprio per questa funzionalità, in quanto permette di limitare gli accessi tra i server (virtuali o fisici, non importa), senza doverli spostare tra le sottoreti e, quindi, senza toccare l'indirizzamento. Sì, sappiamo, nessuno scrive manualmente. Indirizzi IP nelle configurazioni delle applicazioni, giusto?
Le regole per il passaggio del traffico in ACI sono chiamate contratti. In questo contratto, uno o più gruppi o livelli in un'applicazione multi-tier diventano fornitori di servizi (ad esempio, un servizio DB), mentre altri diventano consumatori. Un contratto può semplicemente far passare il traffico oppure fare qualcosa di più complesso, come indirizzarlo a un firewall o a un bilanciatore di carico, e anche cambiare il valore di QoS.
Come arrivano i server in questi gruppi? Se sono server fisici o qualcosa di integrato in una rete esistente, in cui abbiamo creato un trunk VLAN, sarà necessario specificare il port del switch e la VLAN usata su di esso per inserirli nell'EPG. Come possiamo vedere, le VLAN appaiono dove sono indispensabili.
Se i server sono macchine virtuali, è sufficiente fare riferimento all'ambiente di virtualizzazione collegato, e il resto avverrà automaticamente: si creerà un gruppo di porte (parlando in termini di VMWare) per connettere le VM, verranno assegnati i VLAN o VXLAN necessari, e saranno configurati sulle porte appropriate degli switch, e così via. Pertanto, mentre ACI è costruita attorno a una rete fisica, le connessioni per i server virtuali appaiono molto più semplici rispetto a quelle per i fisici. ACI integra già il collegamento con VMWare e MS Hyper-V, oltre a supportare OpenStack e RedHat Virtualization. A un certo punto è stata introdotta anche la supporto integrata per le piattaforme di containerizzazione: Kubernetes, OpenShift, Cloud Foundry, che include l'applicazione delle politiche e il monitoraggio, permettendo così all'amministratore di rete di vedere immediatamente su quali host sono attivi i pod e in quali gruppi sono stati assegnati.
Oltre all'inclusione in uno o nell'altro gruppo di porte, i server virtuali hanno proprietà aggiuntive: nome, attributi, ecc., che possono essere utilizzate come criteri per il loro spostamento in un altro gruppo, per esempio, durante la rinomina della VM o quando ottiene un tag aggiuntivo. Cisco chiama questo gruppi di microsegmentazione, anche se, in senso lato, la struttura stessa che consente di creare più segmenti di sicurezza sotto forma di EPG nella stessa sottorete è anch'essa microsegmentazione. Beh, sarà il fornitore a saperlo meglio.
Le EPG stesse sono pure costruzioni logiche, non legate a specifici switch, server, ecc., quindi con esse e le strutture basate su di esse (applicazioni e tenant) si possono fare cose che sono difficili da realizzare nelle reti tradizionali, come clonare. Di conseguenza, è molto semplice creare un clone di un ambiente produttivo per ottenere un ambiente di test garantito identico a quello di produzione. 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 si ha solitamente a che fare.
nelle reti tradizionali dello stesso Cisco: l'interfaccia programmativa è primaria, mentre l'interfaccia grafica (GUI) o la linea di comando (CLI) sono secondarie, poiché funzionano attraverso la stessa API. Pertanto, quasi tutti coloro che si occupano di ACI, con il tempo, iniziano a orientarsi nel modello degli oggetti utilizzato per la gestione e a automatizzare qualcosa in base alle proprie esigenze. È più facile farlo con Python: per questo ci sono strumenti pronti e comodi.
Le trappole promesse
Il problema principale è che molte cose in ACI sono fatte in modo diverso. Per iniziare a lavorarci normalmente, è necessario riprendere l'apprendimento. Questo è particolarmente vero per i team di operazioni di rete nei grandi clienti, dove gli ingegneri si occupano da anni di "configurare VLAN" su richiesta. Il fatto che ora la VLAN non sia più una VLAN e che per creare nuove reti su host virtualizzati non sia affatto necessario creare VLAN manualmente, sconvolge completamente i tradizionali professionisti di rete, costringendoli a rimanere ancorati a metodi familiari. Va notato che Cisco ha cercato di ammorbidirne un po' l'impatto, aggiungendo nel controller un'interfaccia CLI "simile a NXOS" che consente di configurare attraverso un'interfaccia simile a quella dei tradizionali switch. Tuttavia, per iniziare a utilizzare ACI in modo efficace, sarà necessario comprendere come funziona.
Dal punto di vista dei costi, le reti ACI non si differenziano sostanzialmente dalle reti tradizionali basate su hardware Cisco a grande e media scala, poiché utilizzano gli stessi switch (Nexus 9000 possono operare sia in ACI che in modalità tradizionale e sono diventati il "cavallo di battaglia" principale per i nuovi progetti di data center). Tuttavia, per i data center con due switch, la presenza di controller e dell'architettura Spine-Leaf si fa sentire. Recentemente è stata introdotta una Mini ACI-fabbrica, in cui due dei tre controller sono stati sostituiti da macchine virtuali. Questo riduce la differenza di costo, ma essa rimane comunque. Quindi, per il cliente, la scelta è dettata da quanto è interessato a funzionalità di sicurezza, integrazione con la virtualizzazione, un'unica interfaccia di gestione e altro ancora.
Fonte: habr.com
