Cù l'aiutu di stu pezzu magicu di script Cisco ACI, pudete stabilisce rapidamente una reta.
A fabbrica di rete per u centru di dati Cisco ACI esiste dapoi cinque anni, ma Habré ùn hà micca dettu veramente nunda, cusì decisu di riparà un pocu. Vi dicu da a mo propria sperienza ciò chì hè, chì hè l'usu di questu è induve hà un rake.
Chì ghjè è da induve vene ?
Quandu l'ACI (Application Centric Infrastructure) hè stata annunziata in 2013, i cuncurrenti avanzavanu nantu à l'approcciu tradiziunale à e rete di centri di dati da trè lati à una volta.
Da una banda, e soluzioni SDN di "prima generazione" basate nantu à OpenFlow anu prumessu di rende e rete più flexible è più prezzu à u stessu tempu. L'idea era di trasfurmà a decisione tradiziunale fatta da un software di switch patentatu à un controller centrale.
Stu controller avissi avutu una visione unica di tuttu ciò chì succede è, basatu annantu à questu, programarà u hardware di tutti i switches à u livellu di e regule per processà i flussi specifichi.
Per d 'altra banda, e soluzioni di rete di sovrapposizione anu permessu di implementà e pulitiche di connettività è di sicurezza necessarie senza alcunu cambiamenti in a reta fisica, custruendu tunnel di software trà l'ospiti virtualizzati. L'esempiu più cunnisciutu di questu approcciu era Nicira, chì da allora era digià acquistatu da VMWare per $ 1,26 miliardi è hà datu l'origine à l'attuale VMWare NSX. Certi piquancy di a situazione hè stata aghjunta da u fattu chì i cofundatori di Nicira eranu i stessi persone chì prima stavanu à l'urighjini di OpenFlow, avà dicendu chì per custruisce una fabbrica di centru di dati. .
È infine, i chips di cambiamentu dispunibuli nantu à u mercatu apertu (ciò chì hè chjamatu siliciu mercante) anu righjuntu un stadiu di maturità induve sò diventati una vera minaccia per i pruduttori tradiziunali di switch. Se prima ogni vinditore hà sviluppatu in modu indipendente chips per i so switches, allora cù u tempu, chips da i pruduttori di terzu, principalmente da Broadcom, cuminciaru à riduce a distanza cù chips di venditore in termini di funzioni, è li superanu in quantu à u rapportu di prezzu / rendiment. Per quessa, assai crede chì i ghjorni di switches in chips di u so propiu disignu eranu numerati.
ACI hè diventata a "risposta asimmetrica" di Cisco (più precisamente, a so cumpagnia Insieme, fundata da i so ex impiegati) à tutte e cose sopra.
Chì ghjè a diffarenza cù OpenFlow?
In quantu à a distribuzione di e funzioni, ACI hè in realtà u cuntrariu di OpenFlow.
In l'architettura OpenFlow, u controller hè rispunsevule per scrive regule dettagliate (flussi)
in l'hardware di tutti i switches, vale à dì, in una grande reta, pò esse rispunsevuli di mantene è, più impurtante, di cambià decine di milioni di registri in centinaie di punti in a rete, cusì u so rendiment è affidabilità diventanu un collu di buttiglia in un grande implementazione.
ACI usa l'approcciu inversu: di sicuru, ci hè ancu un controller, ma i switches ricevenu pulitiche dichjarative d'altu livellu da ellu, è u switch stessu realiza a so rendering in dettagli di paràmetri specifichi in u hardware. U controller pò esse rebooted o disattivatu in tuttu, è nunda di male ùn succederà à a reta, salvu, sicuru, a mancanza di cuntrollu in questu mumentu. Curiosamente, ci sò situazioni in ACI in quale OpenFlow hè sempre utilizatu, ma in u locu in l'ospitu per a prugrammazione Open vSwitch.
ACI hè custruitu interamente nantu à u trasportu overlay basatu in VXLAN, ma include u trasportu IP sottostante cum'è parte di una solu suluzione. Cisco hà chjamatu questu u terminu "superposizione integrata". Cum'è un puntu di terminazione per overlays in ACI, in a maiò parte di i casi, i switches di fabbrica sò usati (fannu questu à a velocità di ligame). L'ospiti ùn anu micca bisognu di sapè qualcosa di a fabbrica, l'incapsulazione, etc., in ogni casu, in certi casi (per esempiu, per cunnette l'ospiti OpenStack), u trafficu VXLAN pò esse purtatu à elli.
Overlays sò usati in ACI micca solu per furnisce una connettività flexible per a reta di trasportu, ma ancu per trasfiriri metainformazioni (hè utilizatu, per esempiu, per applicà e pulitiche di sicurezza).
Chips da Broadcom sò stati utilizati prima da Cisco in i switches di a serie Nexus 3000. In a famiglia Nexus 9000, liberata apposta per sustene l'ACI, un mudellu hibridu hè statu implementatu inizialmente, chì era chjamatu Merchant +. U switch hà utilizatu simultaneamente u novu chip Broadcom Trident 2 è un chip cumplementariu sviluppatu da Cisco, chì implementa tutta a magia di ACI. Apparentemente, questu hà permessu di accelerà a liberazione di u pruduttu è di riduce u prezzu di u cambiamentu à un livellu vicinu à i mudelli simpliciamente basatu in Trident 2. Stu approcciu era abbastanza per i primi dui o trè anni di spedizione ACI. Duranti stu tempu, Cisco hà sviluppatu è lanciatu a prossima generazione Nexus 9000 nantu à i so propii chips cù più prestazioni è funzioni, ma à u listessu livellu di prezzu. E specificazioni esterne in quantu à l'interazzione in a fabbrica sò completamente cunservate. À u listessu tempu, u riempimentu internu hà cambiatu cumplettamente: qualcosa cum'è refactoring, ma per u ferru.
Cumu Funziona l'Architettura Cisco ACI
In u casu più simplice, ACI hè custruitu nantu à a topologia di a reta di Klose, o, cum'è spessu dicenu, Spine-Leaf. L'interruttori di spine-livellu pò esse da dui (o unu, s'ellu ùn ci importa micca a tolleranza di colpa) à sei. In cunsiquenza, più di elli, più altu hè a tolleranza di difetti (più bassa hè a larghezza di banda è a riduzzione di affidabilità in casu d'accidentu o mantenimentu di una Spine) è u rendiment generale. Tutte e cunnessione esterne vanu à i switches à livellu di foglia: questi sò servitori, è docking cù e rete esterne via L2 o L3, è cunnessu cuntrolli APIC. In generale, cù ACI, micca solu a cunfigurazione, ma ancu a cullizzioni di statistiche, u monitoraghju di fallimentu, è cusì - tuttu hè fattu per l'interfaccia di cuntrolli, di quale ci sò trè in implementazioni standard.
Ùn avete mai cunnette cù i switches cù a cunsola, ancu per inizià a rete: u controller stessu detecta i switches è assembla una fabbrica da elli, cumprese i paràmetri di tutti i protokolli di serviziu, per quessa, per via, hè assai impurtante per scrivite i numeri di serie di l'equipaggiu chì hè stallatu durante a stallazione, in modu chì più tardi ùn avete micca à guessà quale switch hè in quale rack hè situatu. Per a risoluzione di i prublemi, se ne necessariu, pudete cunnette cù i switch via SSH: riproducenu i cumandamenti di mostra di Cisco cun cura.
Internamente, a fabbrica usa u trasportu IP, cusì ùn ci hè micca Spanning Tree è altri orrori di u passatu in questu: tutti i ligami sò implicati, è a cunvergenza in casu di fallimenti hè assai veloce. U trafficu in u tessulu hè trasmessu à traversu tunnellati basati in VXLAN. Più precisamente, Cisco stessu chjama l'encapsulazione iVXLAN, è si differenzia da VXLAN regulare in chì i campi riservati in l'intestazione di a rete sò usati per trasmette infurmazione di serviziu, principarmenti nantu à a relazione di u trafficu à u gruppu EPG. Questu permette di implementà e regule di interazzione trà i gruppi in l'equipaggiu, utilizendu i so numeri in u listessu modu chì l'indirizzi sò usati in listi d'accessu ordinariu.
I tunnelli permettenu sia i segmenti L2 sia i segmenti L3 (vale à dì VRF) per esse allungati attraversu u trasportu IP internu. In questu casu, u gateway predeterminatu hè distribuitu. Questu significa chì ogni switch hè rispunsevuli di indirizzà u trafficu chì entra in a tela. In termini di logica di flussu di trafficu, ACI hè simile à un tissu VXLAN / EVPN.
Sì cusì, chì sò e differenzi? Tuttu u restu!
A diferenza numeru unu chì scontru cù ACI hè cumu i servitori sò cunnessi à a reta. In i riti tradiziunali, l'inclusione di i servitori fisichi è di e macchine virtuali va à VLAN, è tuttu u restu balla da elli: cunnessione, sicurità, etc. In ACI, un disignu hè utilizatu chì Cisco chjama EPG (End-point Group), da quale. ùn ci hè nunda di scappà. S'ellu hè pussibule uguali à VLAN? Iè, ma in questu casu ci hè una chance di perde a maiò parte di ciò chì ACI dà.
In quantu à EPG, tutte e regule d'accessu sò formulate, è in ACI, u principiu di "lista bianca" hè utilizatu per difettu, vale à dì, solu u trafficu hè permessu, u passaghju di quale hè esplicitamente permessu. Questu hè, pudemu creà i gruppi EPG "Web" è "MySQL" è definisce una regula chì permette a cumunicazione trà elli solu nantu à u portu 3306. Questu hà da travaglià senza esse ligatu à l'indirizzi di a rete è ancu in a stessa subnet !
Avemu i clienti chì anu sceltu ACI precisamente per via di sta funzione, postu chì permette di limità l'accessu trà i servitori (virtuali o fisichi - ùn importa micca) senza trascinà trà subnets, chì significa senza toccu l'indirizzu. Iè, iè, sapemu chì nimu ùn prescrive l'indirizzi IP in cunfigurazioni di l'applicazione manualmente, nò?
I reguli di trafficu in ACI sò chjamati cuntratti. In un tali cuntrattu, unu o più gruppi o livelli in una applicazione multi-tier diventanu un prestatore di serviziu (per dì, un serviziu di basa di dati), altri diventanu un cunsumadore. U cuntrattu pò simpricimenti passà u trafficu, o pò fà qualcosa di più complicatu, per esempiu, diretta à un firewall o balancer, è ancu cambià u valore QoS.
Cumu i servitori entranu in questi gruppi? Sì questi sò servitori fisici o qualcosa inclusu in una rete esistente in quale avemu creatu un troncu VLAN, allora per mette in l'EPG, avete bisognu di indicà u portu di switch è a VLAN utilizata nantu à questu. Comu pudete vede, i VLAN appariscenu induve ùn pudete micca fà senza elli.
Se i servitori sò macchine virtuali, allora hè abbastanza per riferite à l'ambienti di virtualizazione cunnessu, è allora tuttu succederà da ellu stessu: un gruppu di portu serà creatu (in termini di VMWare) per cunnette a VM, i VLAN o VXLAN necessarii saranu. esse assignati, seranu arregistrati nantu à i porti di switch necessarii, etc. Allora, ancu chì ACI hè custruitu intornu à una reta fisica, e cunnessione per i servitori virtuali parenu assai più simplici chè per quelli fisici. ACI hà digià una cunnessione integrata cù VMWare è MS Hyper-V, è ancu supportu per OpenStack è RedHat Virtualization. Da un certu puntu, hè ancu apparsu un supportu integratu per e plataforme di cuntainer: Kubernetes, OpenShift, Cloud Foundry, mentre chì si tratta sia di l'applicazione di e pulitiche è di u monitoraghju, vale à dì, l'amministratore di a rete pò immediatamente vede quali hosts chì pods travaglianu è in quali gruppi cadenu.
In più di esse inclusi in un gruppu di portu particulari, i servitori virtuali anu proprietà supplementari: nome, attributi, etc., chì ponu esse usatu cum'è criteri per trasfirià à un altru gruppu, per esempiu, quandu una VM hè cambiata o un tag addiziale apparisce. lu. Cisco chjamà i gruppi di micro-segmentazione, ancu s'è, in generale, u disignu stessu cù a capacità di creà parechji segmenti di sicurità in forma di EPG in a listessa subnet hè ancu abbastanza una micro-segmentazione. Ebbè, u venditore sà megliu.
EPG stessi sò custruzzioni puramente lògichi, micca ligati à switches specifichi, servitori, etc., cusì pudete fà e cose cun elli è e custruzzioni basati nantu à elli (applicazioni è inquilini) chì sò difficiuli di fà in rete ordinale, cum'è a clonazione. In u risultatu, dicemu chì hè assai faciule di clonà un ambiente di produzzione per ottene un ambiente di prova chì hè garantitu identicu à l'ambiente di produzzione. Pudete fà manualmente, ma hè megliu (è più faciule) attraversu l'API.
In generale, a logica di cuntrollu in ACI ùn hè micca simile à ciò chì di solitu scontra
in e rete tradiziunali da u stessu Cisco: l'interfaccia di u software hè primaria, è a GUI o CLI sò secondarie, postu chì travaglianu cù a listessa API. Dunque, quasi tutti i implicati in ACI, dopu un pocu tempu, cumincianu à navigà in u mudellu di l'ughjettu utilizatu per a gestione è automatizà qualcosa per adattà à i so bisogni. U modu più faciule per fà questu hè da Python: ci sò strumenti convenienti pronti per questu.
Rake prumessu
U prublema principali hè chì assai cose in ACI sò fatti in modu diversu. Per principià à travaglià cù questu in modu normale, avete bisognu di ricuperà. Questu hè soprattuttu veru per e squadre di operazioni di rete in grandi clienti, induve l'ingegneri sò stati "prescritti VLAN" per anni nantu à dumanda. U fattu chì avà i VLAN ùn sò più VLAN, è ùn avete micca bisognu di creà VLAN a manu per mette e rete novi in ospiti virtualizzati, sguassate cumplettamente u tettu di i networkers tradiziunali è li fa appiccicà à approcci familiari. Hè devi esse nutatu chì Cisco hà pruvatu à addulcirà a pillola un pocu è aghjunghjenu un CLI "NXOS-like" à u controller, chì permette di fà cunfigurazione da una interfaccia simile à i switches tradiziunali. Ma sempre, per cumincià à utilizà l'ACI nurmale, avete da capisce cumu funziona.
In quantu à u prezzu, in scala grande è mediana, e rete ACI ùn sò micca veramente diffirenti da e rete tradiziunale nantu à l'equipaggiu Cisco, postu chì i stessi switches sò usati per custruisce (Nexus 9000 pò travaglià in ACI è in modu tradiziunale è sò diventati avà u principale. "cavaddu di travagliu" per novi prughjetti di centru di dati). Ma per i centri di dati di dui switches, a prisenza di i cuntrolli è l'architettura Spine-Leaf, sicuru, si facenu sente. Ricertamenti, hè apparsu una fabbrica Mini ACI, in quale dui di i trè controller sò rimpiazzati da macchine virtuali. Questu reduce a diferenza in u costu, ma ferma sempre. Allora per u cliente, l'scelta hè dettata da quantu hè interessatu in e funzioni di sicurezza, integrazione cù virtualizazione, un puntu di cuntrollu unicu, etc.
Source: www.habr.com