Con l'aiuto di questo magico pezzo di script Cisco ACI, puoi configurare rapidamente una rete.
La fabbrica di rete per il data center Cisco ACI esiste da cinque anni, ma Habré non ha detto nulla al riguardo, quindi ho deciso di aggiustarla un po'. Ti dirò per esperienza personale cos'è, a cosa serve e dove ha un rastrello.
Che cos'è e da dove viene?
Quando ACI (Application Centric Infrastructure) è stato annunciato nel 2013, i concorrenti stavano avanzando sugli approcci tradizionali alle reti di data center da tre lati contemporaneamente.
Da un lato, le soluzioni SDN di "prima generazione" basate su OpenFlow promettevano di rendere le reti più flessibili e allo stesso tempo più economiche. L'idea era di spostare il processo decisionale tradizionalmente svolto dal software switch proprietario a un controller centrale.
Questo controller avrebbe una visione unica di tutto ciò che accade e, in base a ciò, programmerebbe l'hardware di tutti gli switch a livello di regole per l'elaborazione di flussi specifici.
Le soluzioni di overlay network, invece, hanno permesso di implementare le necessarie policy di connettività e sicurezza senza alcuna modifica della rete fisica, costruendo tunnel software tra host virtualizzati. L'esempio più noto di questo approccio è stata Nicira, che a quel tempo era già stata acquisita da VMWare per 1,26 miliardi di dollari e ha dato origine all'attuale VMWare NSX. Un po' di piccantezza della situazione è stata aggiunta dal fatto che i co-fondatori di Nicira erano le stesse persone che in precedenza erano alle origini di OpenFlow, ora dicendo che per costruire una fabbrica di data center .
Infine, i chip di commutazione disponibili sul mercato aperto (il cosiddetto silicio mercantile) hanno raggiunto uno stadio di maturità in cui sono diventati una vera minaccia per i produttori di switch tradizionali. Se prima ogni fornitore sviluppava autonomamente chip per i propri switch, nel tempo i chip di produttori di terze parti, principalmente Broadcom, hanno iniziato a ridurre la distanza con i chip del fornitore in termini di funzioni e li hanno superati in termini di rapporto prezzo / prestazioni. Pertanto, molti credevano che i giorni degli switch su chip di loro progettazione fossero contati.
ACI è diventata la "risposta asimmetrica" di Cisco (più precisamente, la sua società Insieme, fondata dai suoi ex dipendenti) a tutto quanto sopra.
Qual è la differenza con OpenFlow?
In termini di distribuzione delle funzioni, ACI è in realtà l'opposto di OpenFlow.
Nell'architettura OpenFlow, il controllore è responsabile della scrittura di regole dettagliate (flussi)
nell'hardware di tutti gli switch, ovvero in una rete di grandi dimensioni, può essere responsabile del mantenimento e, soprattutto, della modifica di decine di milioni di record in centinaia di punti della rete, quindi le sue prestazioni e affidabilità diventano un collo di bottiglia in un grande implementazione.
ACI utilizza l'approccio inverso: ovviamente esiste anche un controller, ma gli switch ricevono policy dichiarative di alto livello da esso e lo switch stesso esegue il loro rendering nei dettagli di impostazioni specifiche nell'hardware. Il controller può essere riavviato o spento del tutto e non accadrà nulla di male alla rete, tranne, ovviamente, la mancanza di controllo in questo momento. È interessante notare che ci sono situazioni in ACI in cui OpenFlow è ancora utilizzato, ma localmente all'interno dell'host per la programmazione Open vSwitch.
ACI si basa interamente sul trasporto overlay basato su VXLAN, ma include il trasporto IP sottostante come parte di un'unica soluzione. Cisco ha chiamato questo termine "overlay integrato". Come punto di terminazione per gli overlay in ACI, nella maggior parte dei casi vengono utilizzati gli switch di fabbrica (lo fanno alla velocità del collegamento). Agli host non è richiesto di sapere nulla sulla fabbrica, l'incapsulamento, ecc., tuttavia, in alcuni casi (ad esempio, per connettere gli host OpenStack), è possibile portare loro il traffico VXLAN.
Gli overlay vengono utilizzati in ACI non solo per fornire connettività flessibile attraverso la rete di trasporto, ma anche per trasferire metainformazioni (viene utilizzato, ad esempio, per applicare criteri di sicurezza).
I chip di Broadcom erano stati precedentemente utilizzati da Cisco negli switch della serie Nexus 3000. Nella famiglia Nexus 9000, rilasciata appositamente per supportare ACI, è stato originariamente implementato un modello ibrido, chiamato Merchant +. Lo switch utilizzava contemporaneamente sia il nuovo chip Broadcom Trident 2 sia un chip complementare sviluppato da Cisco, che implementa tutta la magia di ACI. Apparentemente, ciò ha permesso di accelerare il rilascio del prodotto e ridurre il prezzo del passaggio a un livello vicino ai modelli basati semplicemente su Trident 2. Questo approccio è stato sufficiente per i primi due o tre anni di consegne ACI. Durante questo periodo, Cisco ha sviluppato e lanciato la nuova generazione di Nexus 9000 sui propri chip con maggiori prestazioni e set di funzionalità, ma allo stesso livello di prezzo. Le specifiche esterne in termini di interazione in fabbrica sono completamente mantenute. Allo stesso tempo, il riempimento interno è completamente cambiato: qualcosa come il refactoring, ma per il ferro.
Come funziona l'architettura Cisco ACI
Nel caso più semplice, ACI è costruito sulla topologia della rete Klose o, come spesso si dice, Spine-Leaf. Gli switch a livello di spine possono essere da due (o uno, se non ci interessa la tolleranza ai guasti) a sei. Di conseguenza, maggiore è il numero, maggiore è la tolleranza ai guasti (minore è la larghezza di banda e la riduzione dell'affidabilità in caso di incidente o manutenzione di una Spina) e le prestazioni complessive. Tutte le connessioni esterne vanno agli switch a livello foglia: si tratta di server e docking con reti esterne tramite L2 o L3 e connessione di controller APIC. In generale, con ACI, non solo la configurazione, ma anche la raccolta di statistiche, il monitoraggio dei guasti e così via: tutto viene eseguito tramite l'interfaccia dei controller, di cui ce ne sono tre in implementazioni di dimensioni standard.
Non devi mai connetterti agli switch con la console, nemmeno per avviare la rete: il controller stesso rileva gli switch e da essi assembla una fabbrica, comprese le impostazioni di tutti i protocolli di servizio, quindi, a proposito, è molto importante annotare i numeri di serie dell'apparecchiatura da installare durante l'installazione, in modo che in seguito non sia necessario indovinare quale interruttore si trova in quale rack si trova. Per la risoluzione dei problemi, se necessario, è possibile connettersi agli switch tramite SSH: riproducono abbastanza attentamente i soliti comandi show di Cisco.
Internamente, la fabbrica utilizza il trasporto IP, quindi non contiene Spanning Tree e altri orrori del passato: tutti i collegamenti sono coinvolti e la convergenza in caso di guasti è molto rapida. Il traffico nel tessuto viene trasmesso attraverso tunnel basati su VXLAN. Più precisamente, la stessa Cisco chiama incapsulamento iVXLAN e differisce dalla normale VXLAN in quanto i campi riservati nell'intestazione di rete vengono utilizzati per trasmettere informazioni di servizio, principalmente sulla relazione del traffico con il gruppo EPG. Ciò consente di implementare le regole di interazione tra i gruppi nelle apparecchiature, utilizzando i loro numeri allo stesso modo in cui vengono utilizzati gli indirizzi nelle normali liste di accesso.
I tunnel consentono di estendere sia i segmenti L2 che i segmenti L3 (ovvero VRF) attraverso il trasporto IP interno. In questo caso, viene distribuito il gateway predefinito. Ciò significa che ogni switch è responsabile dell'instradamento del traffico che entra nel fabric. In termini di logica del flusso di traffico, ACI è simile a un tessuto VXLAN/EVPN.
Se sì, quali sono le differenze? Tutto il resto!
La differenza numero uno che incontri con ACI è il modo in cui i server sono connessi alla rete. Nelle reti tradizionali, l'inclusione sia di server fisici che di macchine virtuali va alle VLAN, e tutto il resto balla da loro: connettività, sicurezza, ecc. In ACI, viene utilizzato un design che Cisco chiama EPG (End-point Group), da cui non c'è nessun posto dove scappare. Se è possibile equipararlo a VLAN? Sì, ma in questo caso c'è la possibilità di perdere la maggior parte di ciò che dà ACI.
Per quanto riguarda EPG, vengono formulate tutte le regole di accesso e in ACI viene utilizzato di default il principio della "lista bianca", ovvero è consentito solo il traffico il cui passaggio è esplicitamente consentito. Cioè, possiamo creare i gruppi EPG "Web" e "MySQL" e definire una regola che consenta la comunicazione tra di loro solo sulla porta 3306. Questo funzionerà senza essere legato agli indirizzi di rete e anche all'interno della stessa sottorete!
Abbiamo clienti che hanno scelto ACI proprio per questa caratteristica, visto che permette di restringere l'accesso tra i server (virtuali o fisici - non importa) senza trascinarli tra le sottoreti, cioè senza toccare l'indirizzamento. Sì, sì, sappiamo che nessuno prescrive manualmente gli indirizzi IP nelle configurazioni dell'applicazione, giusto?
Le regole del traffico in ACI sono chiamate contratti. In un tale contratto, uno o più gruppi o livelli in un'applicazione multilivello diventano un fornitore di servizi (ad esempio, un servizio di database), altri diventano un consumatore. Il contratto può semplicemente passare il traffico o può fare qualcosa di più complicato, ad esempio indirizzarlo a un firewall o bilanciatore e anche modificare il valore QoS.
In che modo i server entrano in questi gruppi? Se si tratta di server fisici o qualcosa incluso in una rete esistente in cui abbiamo creato un trunk VLAN, per inserirli nell'EPG sarà necessario puntare alla porta dello switch e alla VLAN utilizzata su di essa. Come puoi vedere, le VLAN appaiono dove non puoi farne a meno.
Se i server sono macchine virtuali, allora è sufficiente fare riferimento all'ambiente di virtualizzazione connesso, e poi tutto avverrà da solo: verrà creato un gruppo di porte (in termini di VMWare) per connettere la VM, le necessarie VLAN o VXLAN essere assegnati, verranno registrati sulle porte switch necessarie, ecc. Quindi, sebbene ACI sia costruito attorno a una rete fisica, le connessioni per i server virtuali sembrano molto più semplici rispetto a quelle fisiche. ACI dispone già di connettività integrata con VMWare e MS Hyper-V, oltre al supporto per OpenStack e RedHat Virtualization. Da un certo momento è apparso anche il supporto integrato per piattaforme container: Kubernetes, OpenShift, Cloud Foundry, mentre riguarda sia l'applicazione delle policy che il monitoraggio, ovvero l'amministratore di rete può vedere immediatamente su quali host lavorano quali pod e in quali gruppi rientrano.
Oltre ad essere inclusi in un determinato gruppo di porte, i server virtuali hanno proprietà aggiuntive: nome, attributi, ecc., che possono essere utilizzati come criteri per trasferirli a un altro gruppo, ad esempio quando una VM viene rinominata o appare un tag aggiuntivo in Esso. Cisco chiama questi gruppi di microsegmentazione, sebbene, in generale, anche il design stesso con la possibilità di creare molti segmenti di sicurezza sotto forma di EPG sulla stessa sottorete sia piuttosto una microsegmentazione. Bene, il venditore lo sa meglio.
Gli stessi EPG sono costrutti puramente logici, non legati a specifici switch, server, ecc., quindi puoi fare cose con loro e costrutti basati su di essi (applicazioni e tenant) che sono difficili da fare nelle reti ordinarie, come la clonazione. Di conseguenza, diciamo che è molto facile clonare un ambiente di produzione per ottenere un ambiente di test che sia garantito identico all'ambiente di produzione. Puoi farlo manualmente, ma è meglio (e più facile) tramite l'API.
In generale, la logica di controllo in ACI non è affatto simile a quella che si incontra di solito
nelle reti tradizionali dallo stesso Cisco: l'interfaccia software è primaria e la GUI o la CLI sono secondarie, poiché funzionano tramite la stessa API. Pertanto, quasi tutte le persone coinvolte in ACI, dopo un po', iniziano a navigare nel modello a oggetti utilizzato per la gestione e ad automatizzare qualcosa per soddisfare le proprie esigenze. Il modo più semplice per farlo è da Python: ci sono comodi strumenti già pronti per questo.
Rastrello promesso
Il problema principale è che molte cose in ACI vengono fatte in modo diverso. Per iniziare a lavorarci normalmente, devi riqualificarti. Ciò è particolarmente vero per i team operativi di rete nei grandi clienti, dove gli ingegneri "prescrivono VLAN" da anni su richiesta. Il fatto che ora le VLAN non siano più VLAN e non sia necessario creare VLAN a mano per creare nuove reti in host virtualizzati, fa saltare completamente il tetto ai networker tradizionali e li fa aggrapparsi ad approcci familiari. Va notato che Cisco ha provato ad addolcire un po' la pillola e ha aggiunto una CLI "simile a NXOS" al controller, che consente di eseguire la configurazione da un'interfaccia simile agli switch tradizionali. Tuttavia, per iniziare a utilizzare normalmente ACI, devi capire come funziona.
In termini di prezzo, su larga e media scala, le reti ACI non differiscono in realtà dalle reti tradizionali su apparati Cisco, in quanto per realizzarle vengono utilizzati gli stessi switch (i Nexus 9000 possono lavorare in modalità ACI e tradizionale e sono diventati ormai i principali "cavallo di battaglia" per i nuovi progetti di data center). Ma per i data center di due switch, la presenza di controller e l'architettura Spine-Leaf, ovviamente, si fanno sentire. Di recente è apparsa una fabbrica Mini ACI, in cui due dei tre controller sono sostituiti da macchine virtuali. Ciò riduce la differenza di costo, ma rimane comunque. Quindi, per il cliente, la scelta è dettata da quanto è interessato alle funzionalità di sicurezza, all'integrazione con la virtualizzazione, a un unico punto di controllo e così via.
Fonte: habr.com