Valora as conexións na parte central do diagrama. Volveremos a eles a continuación
Nalgún momento, pode descubrir que as redes grandes e complexas baseadas en L2 están enfermas terminales. En primeiro lugar, os problemas asociados ao procesamento do tráfico BUM e ao funcionamento do protocolo STP. En segundo lugar, a arquitectura é xeralmente obsoleta. Isto provoca problemas desagradables en forma de tempo de inactividade e manipulación incómoda.
Tivemos dous proxectos paralelos, nos que os clientes avaliaron con sobriedade todos os pros e contras das opcións e escolleron dúas solucións de superposición diferentes e implementámolas.
Houbo a oportunidade de comparar a implementación. Non de explotación, deberíamos falar diso en dous ou tres anos.
Entón, que é un tecido de rede con redes superpostas e SDN?
Que facer cos problemas acuciantes da arquitectura clásica de rede?
Cada ano aparecen novas tecnoloxías e ideas. Na práctica, a necesidade urxente de reconstruír redes non xurdiu durante moito tempo, porque tamén é posible facer todo manualmente usando os bos métodos anticuados. Entón, e se é o século XXI? Despois de todo, un administrador debería traballar e non sentarse na súa oficina.
Entón comezou un boom na construción de centros de datos a gran escala. Entón quedou claro que se alcanzara o límite de desenvolvemento da arquitectura clásica, non só en termos de rendemento, tolerancia a fallos e escalabilidade. E unha das opcións para resolver estes problemas foi a idea de construír redes de superposición encima dunha columna vertebral encamiñada.
Ademais, co aumento da escala das redes, o problema da xestión deste tipo de fábricas agudizouse, como resultado do cal comezaron a aparecer solucións de rede definidas por software coa capacidade de xestionar toda a infraestrutura de rede como un todo. E cando a rede se xestiona desde un único punto, é máis fácil que outros compoñentes da infraestrutura de TI interactúen con ela, e estes procesos de interacción son máis fáciles de automatizar.
Case todos os principais fabricantes non só de equipos de rede, senón tamén de virtualización, teñen opcións para tales solucións na súa carteira.
Todo o que queda é descubrir o que é axeitado para as necesidades. Por exemplo, para as empresas especialmente grandes cun bo equipo de desenvolvemento e operación, as solucións empaquetadas dos provedores non sempre satisfacen todas as necesidades e recorren a desenvolver as súas propias solucións SD (definidas por software). Por exemplo, estes son provedores de nube que están a ampliar constantemente a gama de servizos que lles proporcionan aos seus clientes, e as solucións empaquetadas simplemente non son capaces de satisfacer as súas necesidades.
Para as empresas medianas, a funcionalidade que ofrece o vendedor en forma de solución en caixa é suficiente no 99 por cento dos casos.
Que son as redes de superposición?
Cal é a idea detrás das redes superpostas? Esencialmente, tomas unha rede enrutada clásica e constrúes outra rede encima para obter máis funcións. Na maioría das veces, estamos a falar de distribuír eficazmente a carga nos equipos e liñas de comunicación, aumentando significativamente o límite de escalabilidade, aumentando a fiabilidade e unha morea de beneficios de seguridade (debido á segmentación). E as solucións SDN, ademais disto, ofrecen a oportunidade dunha administración flexible moi, moi, moi cómoda e fan que a rede sexa máis transparente para os seus consumidores.
En xeral, se as redes locais se inventasen na década de 2010, terían un aspecto moi diferente ao que herdamos dos militares nos anos setenta.
En canto ás tecnoloxías para construír tecidos usando redes superpostas, actualmente hai moitas implementacións de provedores e proxectos de Internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve e outros). Si, hai estándares, pero a implementación destes estándares por diferentes fabricantes pode diferir, polo que ao crear tales fábricas, aínda é posible abandonar completamente o bloqueo do provedor só en teoría en papel.
Cunha solución SD, as cousas son aínda máis confusas; cada vendedor ten a súa propia visión. Hai solucións completamente abertas que, en teoría, podes completar ti mesmo, e as hai completamente pechadas.
Cisco ofrece a súa versión de SDN para centros de datos - ACI. Por suposto, esta é unha solución 100% bloqueada polo provedor en canto á elección de equipos de rede, pero ao mesmo tempo está totalmente integrada cos sistemas de virtualización, contenedores, seguridade, orquestración, equilibradores de carga, etc. Pero, en esencia, segue sendo un tipo de caixa negra, sen posibilidade de acceso total a todos os procesos internos. Non todos os clientes están de acordo con esta opción, xa que dependes completamente da calidade do código da solución escrita e da súa implementación, pero, por outra banda, o fabricante ten un dos mellores soporte técnico do mundo e conta cun equipo dedicado exclusivamente a esta solución. Cisco ACI foi elixida como solución para o primeiro proxecto.
Para o segundo proxecto escolleuse unha solución Juniper. O fabricante tamén ten a súa propia SDN para o centro de datos, pero o cliente decidiu non implementar SDN. Elixiuse un tecido EVPN VXLAN sen o uso de controladores centralizados como tecnoloxía de construción de rede.
Para que serve?
Crear unha fábrica permítelle construír unha rede facilmente escalable, tolerante a fallos e fiable. A arquitectura (leaf-spine) ten en conta as características dos centros de datos (vías de tráfico, minimizando atrasos e embotellamentos na rede). As solucións SD nos centros de datos permítenche xestionar unha fábrica deste tipo de forma moi cómoda, rápida e flexible e integrala no ecosistema do centro de datos.
Ambos os clientes necesitaban construír centros de datos redundantes para garantir a tolerancia a fallos e, ademais, o tráfico entre os centros de datos tiña que ser cifrado.
O primeiro cliente xa estaba considerando solucións sen tecido como un posible estándar para as súas redes, pero nas probas tiveron problemas coa compatibilidade STP entre varios provedores de hardware. Houbo tempos de inactividade que provocaron que os servizos fallasen. E para o cliente isto foi fundamental.
Cisco xa era o estándar corporativo do cliente, miraron ACI e outras opcións e decidiron que pagaba a pena tomar esta solución. Gustoume a automatización do control desde un botón a través dun único controlador. Os servizos configúranse máis rápido e xestionanse máis rápido. Decidimos garantir o cifrado do tráfico executando MACSec entre os interruptores IPN e SPINE. Así, conseguimos evitar o pescozo de botella en forma de pasarela criptográfica, aforrar neles e utilizar o máximo ancho de banda.
O segundo cliente escolleu unha solución sen controlador de Juniper porque o seu centro de datos existente xa tiña unha pequena instalación que implementaba un tecido EVPN VXLAN. Pero alí non foi tolerante a fallos (usouse un interruptor). Decidimos ampliar a infraestrutura do centro de datos principal e construír unha fábrica no centro de datos de copia de seguridade. O EVPN existente non se utilizou completamente: a encapsulación VXLAN non se utilizou realmente, xa que todos os hosts estaban conectados a un interruptor e todos os enderezos MAC e os enderezos de host /32 eran locais, a pasarela para eles era o mesmo interruptor, non había outros dispositivos. , onde foi necesario construír túneles VXLAN. Decidiron garantir o cifrado do tráfico mediante a tecnoloxía IPSEC entre cortalumes (o rendemento do cortalumes era suficiente).
Tamén probaron ACI, pero decidiron que, debido ao bloqueo do vendedor, terían que comprar demasiado hardware, incluíndo a substitución de equipos novos adquiridos recentemente, e simplemente non tiña sentido económico. Si, o tecido de Cisco intégrase con todo, pero só os seus dispositivos son posibles dentro do propio tecido.
Por outra banda, como dixemos anteriormente, non pode mesturar un tecido EVPN VXLAN con calquera provedor veciño, porque as implementacións do protocolo son diferentes. É como cruzar Cisco e Huawei nunha soa rede: parece que os estándares son comúns, pero terás que bailar cunha pandeireta. Dado que este é un banco, e as probas de compatibilidade serían moi longas, decidimos que era mellor mercar agora ao mesmo provedor e non deixarnos levar demasiado polas funcionalidades máis aló das básicas.
Plan migratorio
Dous centros de datos baseados en ACI:
Organización da interacción entre centros de datos. Elixiuse a solución Multi-Pod: cada centro de datos é un pod. Téñense en conta os requisitos de escalado polo número de interruptores e os retardos entre pods (RTT inferior a 50 ms). Decidiuse non construír unha solución Multi-Site para facilitar a xestión (unha solución Multi-Pod usa unha única interface de xestión, un Multi-Site tería dúas interfaces ou requiriría un Multi-Site Orchestrator) foi necesaria a reserva de sitios.
Desde o punto de vista da migración de servizos desde a rede Legacy, optouse pola opción máis transparente, transferindo paulatinamente as VLAN correspondentes a determinados servizos.
Para a migración, creouse un EPG (End-point-group) correspondente para cada VLAN de fábrica. Primeiro, a rede estirouse entre a rede antiga e o tecido a través de L2, despois despois de que todos os hosts foron migrados, a pasarela foi movida ao tecido e a EPG interactuou coa rede existente a través de L3OUT, mentres que a interacción entre L3OUT e EPG. describiuse mediante contratos. Diagrama aproximado:
Na seguinte figura móstrase unha estrutura de mostra da maioría das políticas de fábrica de ACI. Toda a configuración baséase en políticas aniñadas noutras políticas, etc. Ao principio é moi difícil descifralo, pero aos poucos, como mostra a práctica, os administradores de rede acostúmanse a esta estrutura en aproximadamente un mes e despois só comezan a comprender o conveniente que é.
Comparación
Na solución Cisco ACI, cómpre mercar máis equipos (conmutadores separados para a interacción Inter-Pod e os controladores APIC), o que o fai máis caro. A solución de Juniper non requiriu a compra de controladores ou accesorios; Foi posible utilizar parcialmente os equipos existentes do cliente.
Aquí está a arquitectura de tecido EVPN VXLAN para dous centros de datos do segundo proxecto:
Con ACI obtén unha solución preparada, sen necesidade de modificar, sen necesidade de optimizar. Durante o coñecemento inicial do cliente coa fábrica, non se necesitan desenvolvedores, non se necesitan persoas de apoio para o código e a automatización. É bastante sinxelo de usar; pódense facer moitas opcións a través do asistente, o que non sempre é unha vantaxe, especialmente para persoas afeitas á liña de comandos. En calquera caso, leva tempo reconstruír o cerebro en novas pistas, ás peculiaridades da configuración a través de políticas e operar con moitas políticas aniñadas. Ademais disto, é moi desexable ter unha estrutura clara para nomear políticas e obxectos. Se xurde algún problema na lóxica do controlador, só se pode resolver mediante soporte técnico.
En EVPN - consola. Sufrir ou alegrarse. Unha interface familiar para a vella garda. Si, hai unha configuración estándar e guías. Terás que fumar maná. Diferentes deseños, todo é claro e detallado.
Por suposto, en ambos os casos, ao migrar, é mellor migrar primeiro non os servizos máis críticos, por exemplo, os ambientes de proba, e só despois, despois de detectar todos os erros, proceder á produción. E non sintonizar o venres pola noite. Non debes confiar no vendedor de que todo estará ben, sempre é mellor ir seguro.
Pagas máis por ACI, aínda que actualmente Cisco promove activamente esta solución e moitas veces ofrece bos descontos nela, pero aforras no mantemento. A xestión e calquera automatización dunha fábrica de EVPN sen controlador require investimentos e custos regulares: seguimento, automatización, implantación de novos servizos. Ao mesmo tempo, o lanzamento inicial en ACI leva un 30-40 por cento máis. Isto ocorre porque leva máis tempo crear todo o conxunto de perfís e políticas necesarios que despois se utilizarán. Pero a medida que a rede crece, o número de configuracións necesarias diminúe. Usas políticas, perfís e obxectos creados previamente. Pode configurar de forma flexible a segmentación e a seguridade, xestionar de forma centralizada os contratos que se encargan de permitir determinadas interaccións entre os EPG: a cantidade de traballo cae drasticamente.
En EVPN, cómpre configurar cada dispositivo de fábrica, a probabilidade de erros é maior.
Aínda que ACI foi máis lento en implementar, EVPN tardou case o dobre en depurar. Se no caso de Cisco sempre podes chamar a un enxeñeiro de soporte e preguntar pola rede no seu conxunto (porque está cuberta como solución), entón en Juniper Networks só compras hardware, e iso é o que está cuberto. Os paquetes saíron do dispositivo? Ben, vale, entón os teus problemas. Pero podes abrir unha pregunta sobre a elección da solución ou o deseño da rede e, a continuación, aconsellarán que adquiras un servizo profesional por unha tarifa adicional.
O soporte de ACI é moi xenial, porque é separado: un equipo separado só para iso. Tamén hai especialistas de fala rusa. A guía é detallada, as solucións están predeterminadas. Miran e aconsellan. Validan rapidamente o deseño, que moitas veces é importante. Juniper Networks fai o mesmo, pero moito máis lento (tiñamos isto, agora debería ser mellor segundo os rumores), o que che obriga a facer todo ti mesmo onde un enxeñeiro de solucións podería aconsellar.
Cisco ACI admite a integración con sistemas de virtualización e contenedores (VMware, Kubernetes, Hyper-V) e a xestión centralizada. Dispoñible con servizos de rede e seguridade: balance, cortalumes, WAF, IPS, etc... Boa microsegmentación fóra da caixa. Na segunda solución, a integración cos servizos de rede é unha brisa, e é mellor discutir os foros con antelación cos que o fixeron.
Total
Para cada caso concreto, é necesario seleccionar unha solución, non só en función do custo do equipamento, senón que tamén hai que ter en conta os custos operativos adicionais e os principais problemas aos que se enfronta o cliente na actualidade, e que planea alí. son para o desenvolvemento da infraestrutura informática.
ACI, debido ao equipamento adicional, era máis caro, pero a solución está preparada sen necesidade de acabados adicionais; a segunda solución é máis complexa e custosa en termos de operación, pero máis barata.
Se queres discutir canto pode custar implementar un tecido de rede en diferentes provedores e que tipo de arquitectura se necesita, podes reunirte e conversar. Asesorarémosche de forma gratuíta ata conseguir un esbozo aproximado da arquitectura (co que podes calcular os orzamentos), elaboración detallada, por suposto, xa está pagada.
Vladimir Klepche, redes corporativas.
Fonte: www.habr.com