Avalie as conexões na parte média do esquema. Voltaremos a elas mais adiante.
Em algum momento, você pode se deparar com redes complexas baseadas em L2 que estão irremediavelmente doentes. As principais questões estão relacionadas ao processamento de tráfego BUM e ao funcionamento do protocolo STP. Em segundo lugar, a arquitetura, em geral, está moralmente ultrapassada. Isso causa problemas desagradáveis, como períodos de inatividade e dificuldades na gestão.
Tivemos dois projetos paralelos, onde os clientes avaliaram de forma realista todos os prós e contras das opções e escolheram duas soluções de overlay diferentes, que nós implementamos.
Houve a oportunidade de comparar exatamente a implementação. Não a operação, sobre a qual devemos falar em dois ou três anos.
Então, o que é uma fábrica de redes com overlay e SDN?
O que fazer com os problemas persistentes da arquitetura clássica de rede?
Todo ano surgem novas tecnologias e ideias. Na prática, a necessidade urgente de reestruturar redes não surgiu por um bom tempo, pois ainda é possível fazer tudo manualmente com os velhos métodos tradicionais. E o que importa se agora estamos no século XXI? Afinal, um administrador deve trabalhar, e não ficar sentado em seu escritório.
Depois, começou a onda de construção de grandes data centers. Naquela época, ficou claro que o limite de desenvolvimento da arquitetura clássica havia sido atingido, não apenas em termos de funcionalidade, resiliência e escalabilidade. E uma das soluções para esses problemas foi a ideia de construir redes sobre um backbone roteável.
Além disso, com a crescente escala das redes, a questão da gestão dessas fábricas tornou-se aguda, resultando no surgimento de soluções de redes definidas por software que permitem gerenciar toda a infraestrutura de rede como um todo. Quando a rede é gerida a partir de um único ponto, torna-se mais fácil para aos outros componentes da infraestrutura de TI interagir com ela, e esses processos de interação são mais fáceis de automatizar.
Praticamente todos os grandes fabricantes, não apenas de equipamentos de rede, mas também de virtualização, têm em seu portfólio opções para tais soluções.
Restam apenas determinar o que atende a quais necessidades. Por exemplo, para grandes empresas com uma boa equipe de desenvolvedores e operações, as soluções de prateleira dos fornecedores nem sempre satisfazem todas as necessidades, e elas recorrem ao desenvolvimento de suas próprias soluções SD (software defined). Por exemplo, são provedores de nuvem que estão constantemente ampliando a gama de serviços oferecidos a seus clientes, e as soluções de prateleira simplesmente não conseguem acompanhar suas demandas.
Para empresas de médio porte, a funcionalidade oferecida pelo fornecedor na forma de uma solução de prateleira é suficiente em 99% dos casos.
O que são redes overlay?
Qual é a ideia por trás das redes overlay? Basicamente, você pega uma rede roteável clássica e constrói outra rede sobre ela para obter mais funcionalidades. Na maioria das vezes, trata-se de uma distribuição eficaz da carga no hardware e nas linhas de comunicação, um aumento significativo do limite de escalabilidade, melhoria da confiabilidade e um monte de recursos de segurança (graças à segmentação). E as soluções SDN, além disso, oferecem uma administração muito, muito flexível e tornam a rede mais transparente para seus usuários.
Em geral, se as redes locais tivessem sido inventadas na década de 2010, elas não se pareceriam de forma alguma com aquilo que herdamos dos militares dos anos 1970.
Do ponto de vista das tecnologias para a construção de fábricas utilizando redes overlaid, atualmente existem muitas implementações de fabricantes e projetos da Internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve e outros). Sim, existem padrões, mas a implementação desses padrões por diferentes fabricantes pode variar, portanto, ao criar tais fábricas, desistir completamente da dependência de fornecedores ainda é apenas uma teoria em papel.
Com soluções SD, as coisas estão ainda mais confusas, cada fornecedor tem sua própria visão. Existem soluções totalmente abertas, que em teoria podem ser ajustadas por conta própria, e existem soluções completamente fechadas.
A Cisco oferece sua própria solução SDN para data centers — ACI. Naturalmente, é uma solução totalmente proprietária em termos de escolha de hardware de rede, mas, ao mesmo tempo, se integra completamente com sistemas de virtualização, conteinerização, segurança, orquestração, balanceadores de carga e outros. No entanto, na essência, ainda é uma espécie de caixa preta, sem acesso completo a todos os processos internos. Nem todos os clientes aceitam essa solução, pois você fica totalmente dependente da qualidade do código escritos e de sua implementação, mas, por outro lado, o fabricante possui um dos melhores suportes técnicos do mundo e uma equipe dedicada que se ocupa exclusivamente dessa solução. Para o primeiro projeto, a opção escolhida foi o Cisco ACI.
Para o segundo projeto, foi escolhida a solução da Juniper. O fabricante também possui seu próprio SDN para data centers, mas o cliente decidiu não implementar o SDN. A tecnologia escolhida para a construção da rede foi a fábrica EVPN VXLAN sem o uso de controladores centralizados.
Para que serve
A criação da fábrica permite construir uma rede facilmente escalável, resiliente e confiável. A arquitetura (leaf-spine) leva em consideração as particularidades de data centers (caminhos de tráfego, minimização de latências e gargalos na rede). As soluções SD em data centers permitem gerenciar essa fábrica de forma muito conveniente, rápida e flexível, integrando-a ao ecossistema do data center.
Ambos os clientes precisavam construir data centers de backup para garantir a resiliência; além disso, o tráfego entre os data centers deveria ser criptografado.
O primeiro cliente já considerava soluções sem fábrica como um possível padrão para suas redes, mas durante os testes houve problemas de compatibilidade do STP entre vários fornecedores de hardware. Ocorreram downtimes, que causaram quedas de serviços. E para o cliente, isso era crítico.
A Cisco já era o padrão corporativo do cliente, eles analisaram o ACI e outras opções e decidiram que deveriam adotar essa solução. Gostaram da automação de gerenciamento com um único botão através de um controlador unificado. Os serviços são configurados mais rapidamente e geridos com maior agilidade. Decidiram garantir a criptografia do tráfego implementando MACSec entre os switches IPN e SPINE. Dessa forma, conseguiram evitar o gargalo do gateway criptográfico, economizar nesse aspecto e maximizar a largura de banda.
O segundo cliente optou por uma solução sem controlador da Juniper, pois em seu datacenter existente já havia uma pequena instalação com a implementação da fábrica EVPN VXLAN. Porém, essa instalação não era resiliente (utilizava um único switch). Decidiu-se expandir a infraestrutura do datacenter principal e construir uma fábrica no datacenter de backup. O EVPN existente não era utilizado de forma plena: a encapsulação VXLAN praticamente não era aplicada, já que todos os hosts estavam conectados a um único switch, e todos os endereços MAC e endereços de /32 dos hosts eram locais, sendo que o gateway para eles era o mesmo switch, sem outros dispositivos onde seria necessário construir túneis VXLAN. A criptografia do tráfego foi garantida utilizando a tecnologia IPSEC entre os firewalls (a performance do MSE era suficiente).
Também consideraram o ACI, mas decidiram que devido à dependência de fornecedor, teriam que comprar hardware demais, incluindo a substituição de equipamentos novos comprados recentemente, o que não faz sentido econômico. Sim, a fábrica Cisco se integra com tudo, mas dentro da própria fábrica só é possível utilizar seus dispositivos.
Por outro lado, como mencionado anteriormente, não é possível simplesmente misturar uma fábrica EVPN VXLAN com qualquer fornecedor vizinho, pois as implementações do protocolo diferem. É como tentar cruzar Cisco e Huawei em uma mesma rede — à primeira vista, os padrões são comuns, mas será necessário um trabalho considerável. Como se trata de um banco, e os testes de compatibilidade seriam muito longos, decidiram que era melhor adquirir equipamentos do mesmo fornecedor agora, sem se empolgar muito com funcionalidades além do básico.
Plano de migração
Dois datacenters com base em ACI:
Organização da interação entre os Data Centers. Foi escolhida a solução Multi-Pod — cada Data Center é um pod. As exigências de escalabilidade em relação à quantidade de switches e às latências entre os pods (RTT inferior a 50 ms) foram consideradas. Decidiu-se não construir uma solução Multi-Site para facilitar a gestão (para a solução Multi-Pod é utilizado uma única interface de gestão, enquanto para Multi-Site seriam necessárias duas interfaces ou um Orquestrador Multi-Site), e como não havia necessidade de redundância geográfica dos sites.
Do ponto de vista da migração de serviços da rede Legacy, foi escolhida a opção mais transparente, migrar gradualmente VLANs correspondentes a determinados serviços.
Para a migração, cada VLAN tinha um EPG (End-point-group) correspondente criado na fábrica. Primeiro, a rede era estendida entre a rede antiga e a fábrica via L2, depois que todos os hosts foram migrados, o gateway era transferido para a fábrica e a interação do EPG com a rede existente era feita através do L3OUT, com a interação entre o L3OUT e o EPG descrita usando contratos. Diagrama aproximado:
Estrutura aproximada da maioria das políticas da fábrica ACI na imagem abaixo. Toda a configuração é baseada em políticas, inseridas em outras políticas e assim por diante. Inicialmente, é muito complicado entender, mas aos poucos, como a prática mostra, os administradores de rede se acostumam com essa estrutura em cerca de um mês, e depois vem a compreensão de quão conveniente ela é.
Comparação
Na solução Cisco ACI, é necessário comprar mais equipamentos (switches separados para interação Inter-Pod e controladores APIC), o que a torna mais cara. A solução Juniper não exigiu a compra de controladores e equipamentos auxiliares; foi possível utilizar parcialmente o equipamento já existente do cliente.
Esta é a arquitetura EVPN VXLAN da fábrica para dois Data Centers do segundo projeto:
No ACI, você obtém uma solução pronta — não precisa alterar, não precisa otimizar. Durante a apresentação inicial do cliente à fábrica, não são necessários desenvolvedores, nem pessoas de suporte para o código e automação. Basta a operação, muitas configurações podem ser feitas através de assistentes, o que nem sempre é positivo, especialmente para pessoas acostumadas com a linha de comando. De qualquer forma, é preciso tempo para reprogramar a mente para as novas diretrizes, para a particularidade das configurações através de políticas e a operação de várias políticas aninhadas. É muito desejável, além disso, ter uma estrutura clara de nomenclatura para políticas e objetos. Ao surgir um problema na lógica de operação do controlador, ele só pode ser resolvido através do suporte técnico.
No EVPN — console. Sofra ou alegre-se. Uma interface familiar para a velha guarda. Sim, existe uma configuração padrão e guias. Você terá que estudar os manuais. Diferentes construções, tudo claro e detalhado.
Naturalmente, em ambos os casos, é melhor, na migração, começar migrando os serviços menos críticos, como ambientes de teste, e apenas depois de resolver todos os bugs, partir para a produção. E não configure na sexta-feira à noite. Não vale a pena confiar no fornecedor de que tudo estará bem, sempre é melhor se precaver.
No ACI, você paga mais, embora atualmente a Cisco esteja promovendo ativamente essa solução e muitas vezes ofereça bons descontos, mas economiza em manutenção — acompanhamento. A gestão e qualquer automação da fábrica EVPN sem controlador requer investimentos e custos regulares — monitoramento, automação, implementação de novos serviços. Além disso, o lançamento inicial no ACI leva de 30 a 40% mais tempo. Isso ocorre porque leva mais tempo para criar todo o conjunto de perfis e políticas necessárias, que serão utilizados posteriormente. Mas, à medida que a rede cresce, o número de configurações necessárias diminui. Você já utiliza políticas, perfis e objetos pré-criados. Pode ajustar a segmentação e a segurança de forma flexível, gerenciar centralizadamente os contratos que definem as interações entre EPGs — o volume de trabalho diminui drasticamente.
No EVPN, é necessário configurar cada dispositivo na fábrica, aumentando a probabilidade de erro.
Se a ACI é implantada mais lentamente, então a EVPN foi depurada quase duas vezes mais. No caso da Cisco, sempre é possível chamar um engenheiro de suporte e perguntar sobre a rede como um todo (porque isso é coberto como solução), enquanto na Juniper Networks você compra apenas o hardware, e isso é o que está coberto. Os pacotes saíram do dispositivo? Bem, tudo bem, agora é seu problema. Mas você pode abrir uma questão sobre a escolha da solução ou do design da rede — e então recomendarão adquirir um serviço profissional, por um custo adicional.
O suporte da ACI é realmente impressionante, pois é separado: uma equipe específica trabalha apenas para isso. Também há especialistas que falam russo. O guia é detalhado, as soluções são predefinidas. Eles analisam e recomendam. Validam rapidamente o design, o que muitas vezes é importante. A Juniper Networks faz o mesmo, mas de forma significativamente mais lenta (era assim, agora, segundo rumores, deve estar melhor), o que faz você ter que fazer tudo sozinho, onde poderia perguntar a um engenheiro de soluções.
O Cisco ACI suporta integração com sistemas de virtualização e conteinerização (VMware, Kubernetes, Hyper-V) e gerenciamento centralizado. Há serviços de rede e serviços de segurança — balanceamento, firewalls, WAF, IPS e mais... Boa microsegmentação padrão. No segundo caso, a integração com os serviços de rede é complicada e é melhor consultar fóruns com quem já fez isso.
Resultado
Para cada caso específico, é necessário escolher a solução, não apenas com base no custo do equipamento, mas também levando em consideração os custos futuros de operação e os principais problemas que o cliente enfrenta agora, além dos planos para o desenvolvimento da infraestrutura de TI.
A ACI, devido ao equipamento adicional, custou mais, mas a solução está pronta sem necessidade de ajustes, enquanto a segunda solução é mais complexa e custosa em termos de operação, mas é mais barata.
Se você quiser discutir quanto pode custar a implementação de uma rede de diferentes fornecedores e qual arquitetura é necessária, podemos nos encontrar e conversar. Até um esboço preliminar da arquitetura (com o qual você pode calcular os orçamentos) podemos ajudar gratuitamente; o desenvolvimento detalhado, naturalmente, já será pago.
Vladimir Kleptche, redes corporativas.
Fonte: habr.com
