Amb l'ajuda d'aquesta peça màgica de l'script Cisco ACI, podeu configurar ràpidament una xarxa.
La fàbrica de xarxa del centre de dades Cisco ACI fa cinc anys que existeix, però Habré no va dir res al respecte, així que vaig decidir arreglar-ho una mica. Us explicaré per experiència pròpia què és, quin ús en té i on té un rastell.
Què és i d'on ha sortit?
Quan es va anunciar l'ACI (Application Centric Infrastructure) el 2013, els competidors estaven avançant en els enfocaments tradicionals de les xarxes de centres de dades des de tres costats alhora.
D'una banda, les solucions SDN de "primera generació" basades en OpenFlow prometien fer les xarxes més flexibles i més barates alhora. La idea era traslladar la presa de decisions tradicionalment feta per programari de commutació propietari a un controlador central.
Aquest controlador tindria una visió única de tot el que passa i, a partir d'això, programaria el maquinari de tots els commutadors a nivell de regles per processar fluxos concrets.
D'altra banda, les solucions de xarxa superposades van permetre implementar les polítiques de connectivitat i seguretat necessàries sense cap canvi a la xarxa física, construint túnels de programari entre hosts virtualitzats. L'exemple més conegut d'aquest enfocament va ser Nicira, que aleshores ja havia estat adquirit per VMWare per 1,26 milions de dòlars i va donar lloc a l'actual VMWare NSX. Una mica de picant a la situació es va afegir pel fet que els cofundadors de Nicira eren les mateixes persones que abans estaven en els orígens d'OpenFlow, ara dient que per construir una fàbrica de centres de dades .
I, finalment, els xips de canvi disponibles al mercat obert (el que s'anomena silici comercial) han arribat a una etapa de maduresa on s'han convertit en una amenaça real per als fabricants de commutadors tradicionals. Si abans cada venedor desenvolupava xips de manera independent per als seus interruptors, aleshores, amb el temps, els xips de fabricants de tercers, principalment de Broadcom, van començar a reduir la distància amb els xips de proveïdors en termes de funcions i els van superar en termes de relació preu / rendiment. Per tant, molts creien que els dies dels interruptors dels xips de disseny propi estaven comptats.
ACI s'ha convertit en la "resposta asimètrica" de Cisco (més precisament, la seva empresa Insieme, fundada pels seus antics empleats) a tot l'anterior.
Quina diferència hi ha amb OpenFlow?
Pel que fa a la distribució de funcions, ACI és en realitat el contrari d'OpenFlow.
A l'arquitectura OpenFlow, el controlador és responsable d'escriure regles detallades (flujos)
en el maquinari de tots els commutadors, és a dir, en una xarxa gran, pot ser responsable de mantenir i, sobretot, canviar desenes de milions de registres en centenars de punts de la xarxa, de manera que el seu rendiment i fiabilitat es converteixen en un coll d'ampolla en un gran implementació.
L'ACI utilitza l'enfocament invers: per descomptat, també hi ha un controlador, però els commutadors en reben polítiques declaratives d'alt nivell i el mateix commutador realitza la seva representació en detalls de configuracions específiques del maquinari. El controlador es pot reiniciar o apagar completament, i no passarà res dolent a la xarxa, excepte, per descomptat, la manca de control en aquest moment. Curiosament, hi ha situacions a ACI en què encara s'utilitza OpenFlow, però localment dins de l'amfitrió per a la programació Open vSwitch.
L'ACI es basa completament en el transport de superposició basat en VXLAN, però inclou el transport IP subjacent com a part d'una solució única. Cisco va anomenar això el terme "superposició integrada". Com a punt de terminació de les superposicions en ACI, en la majoria dels casos, s'utilitzen commutadors de fàbrica (ho fan a velocitat d'enllaç). Els amfitrions no han de saber res sobre la fàbrica, l'encapsulació, etc., però, en alguns casos (per exemple, per connectar els amfitrions d'OpenStack), el trànsit VXLAN se'ls pot portar.
Les superposicions s'utilitzen a l'ACI no només per proporcionar connectivitat flexible a través de la xarxa de transport, sinó també per transferir metainformació (s'utilitza, per exemple, per aplicar polítiques de seguretat).
Els xips de Broadcom eren utilitzats anteriorment per Cisco als commutadors de la sèrie Nexus 3000. A la família Nexus 9000, llançada especialment per admetre ACI, es va implementar originalment un model híbrid, que es deia Merchant +. L'interruptor va utilitzar simultàniament tant el nou xip Broadcom Trident 2 com un xip complementari desenvolupat per Cisco, que implementa tota la màgia de l'ACI. Pel que sembla, això va permetre accelerar el llançament del producte i reduir el preu de l'interruptor a un nivell proper als models basats simplement en Trident 2. Aquest enfocament va ser suficient per als primers dos o tres anys de lliurament d'ACI. Durant aquest temps, Cisco va desenvolupar i llançar la propera generació Nexus 9000 amb els seus propis xips amb més rendiment i conjunt de funcions, però al mateix nivell de preu. Es conserven completament les especificacions externes pel que fa a la interacció a la fàbrica. Al mateix temps, el farciment intern ha canviat completament: una cosa així com la refactorització, però per al maquinari.
Com funciona l'arquitectura Cisco ACI
En el cas més senzill, ACI es basa en la topologia de la xarxa Klose, o, com sol dir, Spine-Leaf. Els interruptors de nivell de la columna vertebral poden ser de dos (o un, si no ens importa la tolerància a fallades) a sis. En conseqüència, com més d'ells, més gran és la tolerància a fallades (menor és l'ample de banda i la reducció de la fiabilitat en cas d'accident o manteniment d'una columna) i el rendiment global. Totes les connexions externes van a commutadors de nivell de fulla: aquests són servidors, i acoblament amb xarxes externes a través de L2 o L3, i connectant controladors APIC. En general, amb ACI, no només la configuració, sinó també la recopilació d'estadístiques, el seguiment de fallades, etc., tot es fa a través de la interfície dels controladors, dels quals n'hi ha tres en implementacions de mida estàndard.
Mai no us heu de connectar als interruptors amb la consola, fins i tot per iniciar la xarxa: el mateix controlador detecta els interruptors i en munta una fàbrica, inclosa la configuració de tots els protocols de servei, per tant, per cert, és molt important anoteu els números de sèrie de l'equip que s'instal·la durant la instal·lació, de manera que més endavant no haureu d'endevinar quin interruptor és en quin bastidor es troba. Per solucionar problemes, si cal, podeu connectar-vos als commutadors mitjançant SSH: reprodueixen les ordres habituals de Cisco show amb molta cura.
Internament, la fàbrica utilitza transport IP, de manera que no hi ha Spanning Tree i altres horrors del passat: tots els enllaços estan implicats, i la convergència en cas de fallades és molt ràpida. El trànsit en el teixit es transmet a través de túnels basats en VXLAN. Més precisament, el mateix Cisco crida a l'encapsulació iVXLAN, i es diferencia del VXLAN normal perquè els camps reservats de la capçalera de la xarxa s'utilitzen per transmetre informació de servei, principalment sobre la relació del trànsit amb el grup EPG. Això permet implementar les regles d'interacció entre grups de l'equip, utilitzant els seus números de la mateixa manera que les adreces s'utilitzen a les llistes d'accés ordinàries.
Els túnels permeten estirar tant els segments L2 com els segments L3 (és a dir, VRF) a través del transport IP intern. En aquest cas, es distribueix la passarel·la per defecte. Això vol dir que cada commutador és responsable d'encaminar el trànsit que entra al teixit. En termes de lògica de flux de trànsit, ACI és similar a un teixit VXLAN/EVPN.
Si és així, quines són les diferències? Qualsevol altra cosa!
La diferència número u que trobeu amb ACI és com es connecten els servidors a la xarxa. A les xarxes tradicionals, la inclusió tant de servidors físics com de màquines virtuals va a les VLAN, i d'elles balla tota la resta: connectivitat, seguretat, etc. A ACI s'utilitza un disseny que Cisco anomena EPG (End-point Group), des del qual no hi ha enlloc escapar. Si és possible equiparar-lo a VLAN? Sí, però en aquest cas hi ha la possibilitat de perdre la major part del que ofereix l'ACI.
Pel que fa a l'EPG, es formulen totes les regles d'accés, i a l'ACI s'utilitza per defecte el principi de “llista blanca”, és a dir, només es permet el trànsit, el pas del qual està explícitament permès. És a dir, podem crear els grups EPG "Web" i "MySQL" i definir una regla que permeti la comunicació entre ells només al port 3306. Això funcionarà sense estar lligat a adreces de xarxa i fins i tot dins de la mateixa subxarxa!
Tenim clients que han escollit ACI precisament per aquesta característica, ja que permet restringir l'accés entre servidors (virtuals o físics, no importa) sense arrossegar-los entre subxarxes, és a dir, sense tocar l'adreçament. Sí, sí, sabem que ningú prescriu les adreces IP a les configuracions d'aplicacions a mà, oi?
Les normes de trànsit a l'ACI s'anomenen contractes. En aquest contracte, un o més grups o nivells d'una aplicació multinivell es converteixen en un proveïdor de serveis (per exemple, un servei de base de dades), els altres es converteixen en consumidors. El contracte només pot passar trànsit, o pot fer alguna cosa més complicada, per exemple, dirigir-lo a un tallafoc o equilibrador i també canviar el valor de QoS.
Com entren els servidors en aquests grups? Si es tracta de servidors físics o alguna cosa inclosa en una xarxa existent en la qual hem creat un tronc de VLAN, per col·locar-los a l'EPG, haureu d'apuntar al port del commutador i a la VLAN que s'utilitza. Com podeu veure, les VLAN apareixen on no podeu prescindir d'elles.
Si els servidors són màquines virtuals, n'hi ha prou amb referir-se a l'entorn de virtualització connectat, i llavors tot passarà per si mateix: es crearà un grup de ports (en termes de VMWare) per connectar la VM, les VLAN o VXLAN necessàries. Per tant, encara que l'ACI es construeix al voltant d'una xarxa física, les connexions per als servidors virtuals semblen molt més senzilles que per als físics. ACI ja té connectivitat integrada amb VMWare i MS Hyper-V, així com suport per a OpenStack i RedHat Virtualization. A partir d'algun moment, també ha aparegut el suport integrat per a plataformes de contenidors: Kubernetes, OpenShift, Cloud Foundry, tot i que es refereix tant a l'aplicació de polítiques com a la supervisió, és a dir, l'administrador de xarxa pot veure immediatament en quins amfitrions funcionen quins pods i en quins grups pertanyen.
A més d'estar inclosos en un grup de ports concret, els servidors virtuals tenen propietats addicionals: nom, atributs, etc., que es poden utilitzar com a criteri per transferir-los a un altre grup, per exemple, quan es canvia el nom d'una màquina virtual o apareix una etiqueta addicional a això. Cisco anomena a això grups de microsegmentació, tot i que, en general, el disseny en si amb la capacitat de crear molts segments de seguretat en forma d'EPG a la mateixa subxarxa també és una microsegmentació. Bé, el venedor ho sap millor.
Els propis EPG són construccions purament lògiques, no lligades a commutadors, servidors, etc. específics, de manera que podeu fer coses amb elles i construccions basades en elles (aplicacions i inquilins) que són difícils de fer en xarxes normals, com ara la clonació. Com a resultat, diguem que és molt fàcil clonar un entorn de producció per tal d'aconseguir un entorn de prova que es garanteixi que sigui idèntic a l'entorn de producció. Podeu fer-ho manualment, però és millor (i més fàcil) mitjançant l'API.
En general, la lògica de control en ACI no és gens semblant a la que normalment coneixeu
en xarxes tradicionals del mateix Cisco: la interfície del programari és primària, i la GUI o CLI són secundàries, ja que funcionen mitjançant la mateixa API. Per tant, gairebé tots els implicats en ACI, al cap d'un temps, comencen a navegar pel model d'objectes utilitzat per a la gestió i automatitzar alguna cosa per adaptar-se a les seves necessitats. La manera més senzilla de fer-ho és des de Python: hi ha eines pràctiques ja fetes per a això.
Rastrell promès
El principal problema és que moltes coses a ACI es fan de manera diferent. Per començar a treballar-hi amb normalitat, cal que us torneu a formar. Això és especialment cert per als equips d'operacions de xarxa de clients grans, on els enginyers han estat "prescrivint VLAN" durant anys a petició. El fet que ara les VLAN ja no siguin VLAN, i que no necessiteu crear VLAN a mà per establir noves xarxes en amfitrions virtualitzats, fa volar completament el sostre dels usuaris de xarxa tradicionals i els fa aferrar-se a enfocaments familiars. Cal tenir en compte que Cisco va intentar endolcir una mica la píndola i va afegir una CLI "com NXOS" al controlador, que us permet fer la configuració des d'una interfície similar als interruptors tradicionals. Però tot i així, per començar a utilitzar ACI amb normalitat, heu d'entendre com funciona.
Pel que fa al preu, a gran i mitjana escala, les xarxes ACI en realitat no es diferencien de les xarxes tradicionals dels equips Cisco, ja que s'utilitzen els mateixos commutadors per construir-les (el Nexus 9000 pot funcionar en ACI i en mode tradicional i ara s'han convertit en el principal "cava de batalla" per a nous projectes de centres de dades). Però per als centres de dades de dos commutadors, la presència de controladors i l'arquitectura Spine-Leaf, per descomptat, es fan notar. Recentment, ha aparegut una fàbrica Mini ACI, en la qual dos dels tres controladors són substituïts per màquines virtuals. Això redueix la diferència de cost, però encara es manté. Per tant, per al client, l'elecció ve dictada per quant està interessat en les funcions de seguretat, la integració amb la virtualització, un únic punt de control, etc.
Font: www.habr.com