Avalueu els enllaços de la part central del diagrama. Tornarem a ells a continuació.
En algun moment, és possible que trobeu que les grans xarxes complexes basades en L2 estan malaltes terminals. En primer lloc, problemes relacionats amb el processament del trànsit BUM i el funcionament del protocol STP. En el segon - en general, l'arquitectura moralment obsoleta. Això provoca problemes desagradables en forma de temps d'inactivitat i molèsties de manipulació.
Vam tenir dos projectes paral·lels, on els clients van avaluar amb sobria tots els avantatges i els contres de les opcions i van triar dues solucions de superposició diferents, i les vam implementar.
Va ser possible comparar la implementació. No operació, val la pena parlar-ne d'aquí a dos o tres anys.
Aleshores, què és un teixit de xarxa amb xarxes superposades i SDN?
Què fer amb els problemes dolorosos de l'arquitectura clàssica de xarxa?
Cada any apareixen noves tecnologies i idees. A la pràctica, la necessitat urgent de reconstruir les xarxes no va sorgir durant molt de temps, perquè també es pot fer tot a mà utilitzant els bons mètodes de l'avi. Aleshores què, què és el segle XXI al pati? Al final, l'administrador hauria de treballar i no seure a la seva oficina.
Aleshores va començar un auge en la construcció de centres de dades a gran escala. Aleshores es va fer evident que s'havia assolit el límit del desenvolupament de l'arquitectura clàssica, no només en termes de rendiment, tolerància a errors, escalabilitat. I una de les opcions per resoldre aquests problemes era la idea de construir xarxes superposades a sobre d'una columna vertebral encaminable.
A més, amb l'augment de l'escala de les xarxes, el problema de la gestió d'aquestes fàbriques es va agravar, com a resultat de la qual cosa van començar a aparèixer solucions de xarxa definides per programari amb la capacitat de gestionar tota la infraestructura de xarxa en el seu conjunt. I quan la xarxa es gestiona des d'un únic punt, és més fàcil que altres components de la infraestructura informàtica interactuïn amb ella, i aquests processos d'interacció són més fàcils d'automatitzar.
Gairebé tots els principals fabricants no només d'equips de xarxa, sinó també de virtualització, tenen opcions per a aquestes solucions a la seva cartera.
Només queda esbrinar què és adequat per a quines necessitats. Per exemple, per a empreses especialment grans amb un bon equip de desenvolupament i operació, les solucions prèvies dels venedors no sempre satisfan totes les necessitats, i recorren a desenvolupar les seves pròpies solucions SD (definides per programari). Per exemple, es tracta de proveïdors de núvol que estan ampliant constantment la gamma de serveis que ofereixen als seus clients, i les solucions en caixa simplement no poden mantenir-se al dia amb les seves necessitats.
Per a les empreses mitjanes, la funcionalitat que ofereix el venedor en forma de solució en caixa és suficient en el 99 per cent dels casos.
Què són les xarxes superposades
Quina és la idea de les xarxes de superposició. Bàsicament, agafeu una xarxa encaminada clàssica i creeu una altra xarxa a sobre per obtenir més funcions. Molt sovint, estem parlant de la distribució efectiva de la càrrega en equips i línies de comunicació, un augment significatiu del límit d'escalabilitat, una major fiabilitat i un munt de avantatges de seguretat (a causa de la segmentació). I les solucions SDN, a més d'això, permeten una administració flexible molt, molt, molt còmoda i fan que la xarxa sigui més transparent per als seus consumidors.
En general, si les xarxes locals s'inventessin els anys 2010, es veurien lluny del que vam heretar dels militars dels anys setanta.
Pel que fa a les tecnologies per construir fàbriques mitjançant xarxes de superposició, actualment hi ha moltes implementacions de fabricants i projectes d'Internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve i altres). Sí, hi ha estàndards, però la implementació d'aquests estàndards per diferents fabricants pot ser diferent, de manera que quan es creen aquestes fàbriques, encara és possible abandonar completament el bloqueig del venedor només en teoria en paper.
Amb la solució SD, les coses són encara més complicades, cada venedor té la seva pròpia visió. Hi ha solucions totalment obertes que, en teoria, pots acabar pel teu compte, n'hi ha de totalment tancades.
Cisco ofereix la seva pròpia versió de SDN per a centres de dades: ACI. Naturalment, es tracta d'una solució 100% bloquejada pel proveïdor pel que fa a l'elecció d'equips de xarxa, però alhora està totalment integrada amb virtualització, contenidorització, seguretat, orquestració, equilibradors de càrrega, etc. Però de fet no deixa de ser una mena de caixa negra, sense possibilitat d'accés total a tots els processos interns. No tots els clients estan d'acord amb aquesta opció, ja que depeneu completament de la qualitat del codi de solució escrit i de la seva implementació, però d'altra banda, el fabricant compta amb un dels millors suport tècnic del món i compta amb un equip dedicat que s'ocupa només amb aquesta solució. Es va triar Cisco ACI com a solució per al primer projecte.
Per al segon projecte, es va triar una solució Juniper. El fabricant també té la seva pròpia SDN per al centre de dades, però el client va decidir no implementar SDN. La fàbrica EVPN VXLAN va ser escollida com a tecnologia per construir la xarxa sense l'ús de controladors centralitzats.
Per a què serveix
La creació d'una fàbrica us permet construir una xarxa fàcilment escalable, tolerant a errors i fiable. L'arquitectura (leaf-spine) té en compte les característiques dels centres de dades (camins de trànsit, minimització de retards i colls d'ampolla a la xarxa). Les solucions SD als centres de dades fan que sigui molt còmode, ràpid i flexible gestionar aquesta fàbrica, integrar-la a l'ecosistema del centre de dades.
Tots dos clients havien de construir centres de dades redundants per garantir la tolerància a errors, a més, el trànsit entre centres de dades s'havia de xifrar.
El primer client ja estava considerant solucions sense teixit com un possible estàndard per a les seves xarxes, però en les proves van tenir problemes amb la compatibilitat STP entre diversos venedors de maquinari. Hi va haver temps d'inactivitat que van provocar caigudes del servei. I per al client era crític.
Cisco ja era l'estàndard empresarial del client, van mirar ACI i altres opcions i van decidir que valia la pena prendre aquesta solució en particular. Em va agradar l'automatització del control des d'un botó a través d'un únic controlador. Els serveis es configuren més ràpid, es gestionen més ràpidament. Vam decidir proporcionar xifratge de trànsit executant MACSec entre els commutadors IPN i SPINE. Així, va ser possible evitar un coll d'ampolla en forma de passarel·la criptogràfica, estalviar-hi i utilitzar l'ample de banda al màxim.
El segon client va triar la solució sense controlador de Juniper perquè el seu centre de dades existent ja tenia una petita instal·lació amb una implementació de teixit EVPN VXLAN. Però allà no era tolerant a errors (es va utilitzar un interruptor). Vam decidir ampliar la infraestructura del centre de dades principal i construir una fàbrica al centre de dades de còpia de seguretat. L'EVPN existent no es va utilitzar completament: l'encapsulació VXLAN no es va utilitzar realment, ja que tots els amfitrions estaven connectats al mateix commutador i totes les adreces MAC i les adreces d'amfitrió /32 eren locals, el mateix commutador era la porta d'entrada per a ells, no hi havia cap altre dispositius, on era necessari construir túnels VXLAN. Van decidir proporcionar xifratge de trànsit mitjançant la tecnologia IPSEC entre tallafocs (el rendiment de l'ITU era suficient).
També van provar ACI, però van decidir que, a causa del bloqueig del venedor, haurien de comprar massa maquinari, inclosa la substitució d'equips nous comprats recentment, i simplement no té sentit econòmic. Sí, el teixit Cisco s'integra amb tot, però només els seus dispositius són possibles dins del propi teixit.
D'altra banda, com s'ha esmentat anteriorment, no podeu combinar una fàbrica EVPN VXLAN amb qualsevol proveïdor veí perquè les implementacions del protocol són diferents. És com creuar Cisco i Huawei a la mateixa xarxa: sembla que els estàndards són habituals, només cal ballar amb un tamborí. Com que es tracta d'un banc i les proves de compatibilitat serien molt llargues, vam decidir que ara era millor comprar al mateix venedor i no deixar-nos portar realment amb una funcionalitat més enllà de la base.
Pla de migració
Dos centres de dades basats en ACI:
Organització de la interacció entre centres de dades. S'ha escollit una solució Multi-Pod: cada centre de dades és un pod. Es tenen en compte els requisits d'escala pel nombre d'interruptors i retards entre pods (RTT inferior a 50 ms). Es va decidir no construir una solució multi-lloc per facilitar la gestió (s'utilitza una única interfície de gestió per a una solució multi-pod, per a multi-lloc hi hauria dues interfícies o es necessitaria un orquestrator multi-lloc), i ja que no calia cap reserva geogràfica de llocs.
Des del punt de vista de la migració de serveis des de la xarxa Legacy, es va optar per l'opció més transparent, transferir gradualment les VLAN corresponents a determinats serveis.
Per a la migració, es va crear un EPG (End-point-group) corresponent per a cada VLAN de fàbrica. Primer, la xarxa es va estendre entre l'antiga xarxa i la fàbrica al llarg de L2, després després de la migració de tots els amfitrions, la passarel·la es va transferir a la fàbrica i l'EPG va interactuar amb la xarxa existent mitjançant L3OUT, mentre que la interacció entre L3OUT i EPG. es va descriure mitjançant contractes. Esquema aproximat:
L'estructura aproximada de la majoria de polítiques de fàbrica ACI es mostra a la figura següent. Tota la configuració es basa en polítiques imbricades en altres polítiques, etc. Al principi és molt difícil esbrinar-ho, però a poc a poc, com mostra la pràctica, els administradors de xarxa s'acostumen a aquesta estructura en un mes aproximadament, i després només s'entén com de convenient és.
Comparació
A la solució Cisco ACI, cal comprar més equips (interruptors separats per a la interacció Inter-Pod i controladors APIC), per la qual cosa va resultar més car. La solució de Juniper no va requerir la compra de controladors i accessoris; va resultar utilitzar parcialment l'equip ja existent del client.
Aquí teniu l'arquitectura de teixit EVPN VXLAN per als dos centres de dades del segon projecte:
A ACI, obteniu una solució ja feta: no cal triar, no cal optimitzar. En el coneixement inicial del client amb la fàbrica, no es necessiten desenvolupadors, no calen persones de suport per al codi i l'automatització. N'hi ha prou amb un funcionament senzill, moltes configuracions es poden fer en general mitjançant un assistent, cosa que no sempre és un avantatge, especialment per a persones acostumades a la línia d'ordres. En qualsevol cas, es necessita temps per reconstruir el cervell sobre nous camins, sobre les peculiaritats de la configuració a través de polítiques i operant amb multitud de polítiques imbricades. És molt desitjable, a més d'això, tenir una estructura clara per nomenar polítiques i objectes. Si hi ha algun problema en la lògica del controlador, només es pot resoldre mitjançant suport tècnic.
A EVPN, la consola. Patir o alegrar-se. Interfície familiar per a la vella guàrdia. Sí, hi ha una configuració i guies típics. Has de fumar mana. Diferents dissenys, tot és clar i detallat.
Naturalment, en ambdós casos, és millor migrar no els serveis més crítics primer, per exemple, els entorns de prova, i només després, després de detectar tots els errors, procedir a la producció. I no sintonitzeu divendres a la nit. No hauríeu de confiar en el venedor que tot anirà bé, sempre és millor jugar amb seguretat.
Pagueu més per ACI, tot i que actualment Cisco està promocionant activament aquesta solució i sovint ofereix bons descomptes, però estalvieu en manteniment. La gestió i qualsevol tipus d'automatització d'una fàbrica d'EVPN sense controlador requereix inversions i costos regulars: seguiment, automatització, implantació de nous serveis. Al mateix temps, el llançament inicial d'ACI triga entre un 30 i un 40 per cent més. Això es deu al fet que triga més temps a crear tot el conjunt de perfils i polítiques necessaris, que després s'utilitzaran. Però a mesura que la xarxa creix, el nombre de configuracions necessàries disminueix. Utilitzeu polítiques, perfils i objectes ja creats prèviament. Podeu configurar de manera flexible la segmentació i la seguretat, gestionar de manera centralitzada els contractes que s'encarreguen de resoldre determinades interaccions entre EPG: la quantitat de treball disminueix dràsticament.
A EVPN, heu de configurar cada dispositiu de fàbrica, la probabilitat d'error és més gran.
Si l'ACI és més lent d'implementar, llavors EVPN va trigar gairebé el doble a depurar-se. Si en el cas de Cisco sempre podeu trucar a un enginyer de suport i preguntar sobre la xarxa en el seu conjunt (perquè està coberta com a solució), llavors només compreu maquinari de Juniper Networks, i això és el que cobreix. Els paquets van sortir del dispositiu? D'acord, llavors els teus problemes. Però podeu obrir una pregunta sobre l'elecció d'una solució o un disseny de xarxa i, a continuació, us aconsellaran que adquireu un servei professional per una tarifa addicional.
El suport de l'ACI és molt interessant, perquè és separat: un equip separat només s'asseu per això. N'hi ha, inclosos especialistes de parla russa. La guia està detallada, les decisions estan predeterminades. Observa i aconsella. Validen ràpidament el disseny, que sovint és important. Juniper Networks fa el mateix, però moltes vegades més lent (és que ho fèiem, ara hauria de ser millor segons els rumors), cosa que t'obliga a fer-ho tu mateix allà on un enginyer de solucions podria aconsellar.
Cisco ACI admet la integració amb sistemes de virtualització i contenidors (VMware, Kubernetes, Hyper-V) i la gestió centralitzada. Hi ha serveis de xarxa i serveis de seguretat: equilibri, tallafocs, WAF, IPS i més... Bona micro-segmentació fora de la caixa. En la segona solució, la integració amb serveis de xarxa es fa amb un tamborí, i és millor fumar fòrums amb els que ho van fer amb antelació.
Total
Per a cada cas concret, cal seleccionar una solució, no només en funció del cost de l'equip, sinó que també cal tenir en compte els costos operatius addicionals i els principals problemes als quals s'enfronta ara el client, i quins són els plans. per al desenvolupament de la infraestructura informàtica.
ACI a causa d'equips addicionals va sortir més car, però la solució està preparada sense necessitat de serres addicionals, la segona solució és més complicada i costosa en termes d'operació, però més barata.
Si voleu discutir quant pot costar implementar una fàbrica de xarxa en diferents proveïdors i quin tipus d'arquitectura es necessita, podeu reunir-vos i xerrar. Abans de l'esbós aproximat de l'arquitectura (amb el qual podeu calcular els pressupostos), us donarem una pista gratuïta, un estudi detallat, per descomptat, ja està pagat.
Vladimir Klepche, xarxes corporatives.
Font: www.habr.com