Hoje vou contar como surgiu e foi implementada a ideia de criar uma nova rede interna para nossa empresa. A posição da administração é que você precisa fazer o mesmo projeto completo para você e para o cliente. Se fizermos bem para nós mesmos, podemos convidar o cliente e mostrar como o que oferecemos a ele funciona e funciona bem. Por isso, abordamos de forma muito aprofundada o desenvolvimento do conceito de uma nova rede para o escritório de Moscou, utilizando todo o ciclo de produção: análise das necessidades departamentais → seleção de uma solução técnica → projeto → implementação → testes. Então vamos começar.
Selecionando uma solução técnica: Santuário Mutante
O procedimento para trabalhar em um sistema automatizado complexo é atualmente melhor descrito em GOST 34.601-90 “Sistemas automatizados. Estágios da Criação”, então trabalhamos de acordo com isso. E já nas fases de formação de requisitos e desenvolvimento de conceitos, encontramos as primeiras dificuldades. Organizações de diversos perfis - bancos, seguradoras, desenvolvedores de software, etc. - para suas tarefas e padrões, necessitam de determinados tipos de redes, cujas especificidades sejam claras e padronizadas. No entanto, isso não funcionará conosco.
Por quê?
Jet Infosystems é uma grande empresa de TI diversificada. Ao mesmo tempo, o nosso departamento de suporte interno é pequeno (mas orgulhoso), garantindo a funcionalidade dos serviços e sistemas básicos. A empresa contém muitas divisões que desempenham funções diferentes: são várias equipes poderosas de terceirização e desenvolvedores internos de sistemas de negócios, segurança da informação e arquitetos de sistemas de computação - em geral, quem quer que seja. Assim, as suas tarefas, sistemas e políticas de segurança também são diferentes. O que, como era de se esperar, criou dificuldades no processo de análise de necessidades e padronização.
Aqui, por exemplo, está o departamento de desenvolvimento: seus funcionários escrevem e testam códigos para um grande número de clientes. Muitas vezes é necessário organizar rapidamente os ambientes de teste e, francamente, nem sempre é possível formular requisitos para cada projeto, solicitar recursos e construir um ambiente de teste separado de acordo com todos os regulamentos internos. Isso dá origem a situações curiosas: um dia seu humilde servo olhou para a sala dos desenvolvedores e encontrou debaixo da mesa um cluster Hadoop de 20 desktops funcionando corretamente, que estava inexplicavelmente conectado a uma rede comum. Não creio que valha a pena esclarecer que o departamento de TI da empresa não sabia da sua existência. Esta circunstância, como muitas outras, foi responsável pelo facto de durante o desenvolvimento do projecto ter nascido o termo “reserva mutante”, que descreve o estado da sofrida infra-estrutura de escritórios.
Ou aqui está outro exemplo. Periodicamente, uma bancada de testes é montada dentro de um departamento. Foi o caso do Jira e do Confluence, que foram utilizados de forma limitada pelo Centro de Desenvolvimento de Software em alguns projetos. Depois de algum tempo, outros departamentos aprenderam sobre esses recursos úteis, avaliaram-nos e, no final de 2018, Jira e Confluence passaram do status de “brinquedo dos programadores locais” para o status de “recursos da empresa”. Agora um proprietário deve ser atribuído a esses sistemas, SLAs, políticas de segurança de acesso/informação, políticas de backup, monitoramento, regras para roteamento de solicitações para correção de problemas devem ser definidas - em geral, todos os atributos de um sistema de informação completo devem estar presentes .
Cada uma de nossas divisões também é uma incubadora que cultiva seus próprios produtos. Alguns deles morrem na fase de desenvolvimento, alguns usamos enquanto trabalhamos em projetos, enquanto outros criam raízes e se tornam soluções replicadas que começamos a usar e vender aos clientes. Para cada um desses sistemas, é desejável ter um ambiente de rede próprio, onde se desenvolva sem interferir em outros sistemas, e em algum momento possa ser integrado à infraestrutura da empresa.
Além do desenvolvimento, temos um grande com mais de 500 funcionários, formados em equipes para cada cliente. Eles estão envolvidos na manutenção de redes e outros sistemas, monitoramento remoto, resolução de reclamações e assim por diante. Ou seja, a infraestrutura do SC é, na verdade, a infraestrutura do cliente com quem trabalha atualmente. A peculiaridade de trabalhar com este trecho da rede é que suas estações de trabalho para nossa empresa são parte externas e parte internas. Assim, para o SC implementámos a seguinte abordagem - a empresa disponibiliza ao departamento correspondente rede e outros recursos, considerando os postos de trabalho destes departamentos como ligações externas (por analogia com filiais e utilizadores remotos).
Projeto de rodovia: nós somos o operador (surpresa)
Depois de avaliar todas as armadilhas, percebemos que estávamos colocando a rede de uma operadora de telecomunicações dentro de um escritório e começamos a agir de acordo.
Criamos uma rede central com a qual qualquer consumidor interno, e no futuro também externo, recebe o serviço necessário: VPN L2, VPN L3 ou roteamento L3 regular. Alguns departamentos precisam de acesso seguro à Internet, enquanto outros precisam de acesso limpo, sem firewalls, mas ao mesmo tempo protegendo os nossos recursos corporativos e a rede principal do seu tráfego.
“Concluímos informalmente um SLA” com cada divisão. De acordo com ele, todos os incidentes que surgirem devem ser eliminados dentro de um determinado período de tempo pré-acordado. Os requisitos da empresa para a sua rede revelaram-se rigorosos. O tempo máximo de resposta a um incidente em caso de falhas telefónicas e de e-mail foi de 5 minutos. O tempo para restaurar a funcionalidade da rede durante falhas típicas não passa de um minuto.
Como temos uma rede de operadora, você só pode se conectar a ela estritamente de acordo com as regras. As unidades de serviço definem políticas e fornecem serviços. Eles nem precisam de informações sobre conexões de servidores, máquinas virtuais e estações de trabalho específicas. Mas, ao mesmo tempo, são necessários mecanismos de proteção, porque nem uma única conexão deve desabilitar a rede. Se um loop for criado acidentalmente, outros usuários não deverão perceber, ou seja, é necessária uma resposta adequada da rede. Qualquer operadora de telecomunicações resolve constantemente problemas semelhantes e aparentemente complexos em sua rede principal. Oferece atendimento a diversos clientes com diferentes necessidades e tráfego. Ao mesmo tempo, diferentes assinantes não devem sofrer inconvenientes com o tráfego de terceiros.
Em casa, resolvemos esse problema da seguinte forma: construímos uma rede backbone L3 com redundância total, utilizando o protocolo IS-IS. Uma rede de sobreposição foi construída no topo do núcleo com base na tecnologia /, usando um protocolo de roteamento . Para acelerar a convergência dos protocolos de roteamento, foi utilizada a tecnologia BFD.
estrutura de rede
Nos testes, esse esquema mostrou-se excelente - quando qualquer canal ou switch é desconectado, o tempo de convergência não é superior a 0.1-0.2 s, um mínimo de pacotes são perdidos (geralmente nenhum), as sessões TCP não são interrompidas, conversas telefônicas não são interrompidos.
Camada Underlay - Roteamento
Camada de sobreposição - roteamento
Switches Huawei CE6870 com licenças VXLAN foram usados como switches de distribuição. Este dispositivo tem uma ótima relação preço/qualidade, permitindo conectar assinantes a uma velocidade de 10 Gbit/s e conectar-se ao backbone a velocidades de 40–100 Gbit/s, dependendo dos transceptores usados.
Interruptores Huawei CE6870
Os switches Huawei CE8850 foram usados como switches principais. O objetivo é transmitir o tráfego de forma rápida e confiável. Nenhum dispositivo está conectado a eles exceto switches de distribuição, eles não sabem nada sobre VXLAN, então foi escolhido um modelo com 32 portas 40/100 Gbps, com licença básica que fornece roteamento L3 e suporte para IS-IS e MP-BGP protocolos.
O inferior é o switch principal Huawei CE8850
Na fase de projeto, surgiu uma discussão dentro da equipe sobre tecnologias que poderiam ser usadas para implementar uma conexão tolerante a falhas aos nós principais da rede. Nosso escritório em Moscou está localizado em três edifícios, temos 7 salas de distribuição, em cada uma das quais foram instalados dois switches de distribuição Huawei CE6870 (apenas switches de acesso foram instalados em várias salas de distribuição). Ao desenvolver o conceito de rede, foram consideradas duas opções de redundância:
- Consolidação de switches de distribuição em uma pilha tolerante a falhas em cada sala de conexão cruzada. Prós: simplicidade e facilidade de configuração. Desvantagens: há maior probabilidade de falha de toda a pilha quando ocorrem erros no firmware dos dispositivos de rede (“vazamentos de memória” e similares).
- Aplique tecnologias de gateway M-LAG e Anycast para conectar dispositivos a switches de distribuição.
No final, optamos pela segunda opção. É um pouco mais difícil de configurar, mas tem demonstrado na prática seu desempenho e alta confiabilidade.
Vamos primeiro considerar a conexão de dispositivos finais a switches de distribuição:
Cruzar
Um switch de acesso, servidor ou qualquer outro dispositivo que exija uma conexão tolerante a falhas está incluído em dois switches de distribuição. A tecnologia M-LAG fornece redundância no nível do link de dados. Supõe-se que dois interruptores de distribuição aparecem para o equipamento conectado como um único dispositivo. A redundância e o balanceamento de carga são realizados utilizando o protocolo LACP.
A tecnologia de gateway Anycast fornece redundância no nível da rede. Um número bastante grande de VRFs é configurado em cada um dos switches de distribuição (cada VRF é projetado para seus próprios propósitos - separadamente para usuários “regulares”, separadamente para telefonia, separadamente para vários ambientes de teste e desenvolvimento, etc.), e em cada O VRF possui diversas VLANs configuradas. Em nossa rede, os switches de distribuição são os gateways padrão para todos os dispositivos conectados a eles. Os endereços IP correspondentes às interfaces VLAN são iguais para ambos os switches de distribuição. O tráfego é roteado através do switch mais próximo.
Agora vamos ver como conectar os switches de distribuição ao kernel:
A tolerância a falhas é fornecida no nível da rede usando o protocolo IS-IS. Observe que uma linha de comunicação L3 separada é fornecida entre os switches, a uma velocidade de 100G. Fisicamente, esta linha de comunicação é um cabo de acesso direto que pode ser visto à direita na foto dos switches Huawei CE6870;
Uma alternativa seria organizar uma topologia de estrela dupla “honesta” e totalmente conectada, mas, como mencionado acima, temos 7 salas de conexão cruzada em três edifícios. Assim, se tivéssemos escolhido a topologia “estrela dupla”, precisaríamos exatamente do dobro de transceptores 40G de “longo alcance”. A economia aqui é muito significativa.
Algumas palavras precisam ser ditas sobre como as tecnologias de gateway VXLAN e Anycast funcionam juntas. VXLAN, sem entrar em detalhes, é um túnel para transporte de frames Ethernet dentro de pacotes UDP. As interfaces de loopback dos switches de distribuição são usadas como endereço IP de destino do túnel VXLAN. Cada crossover possui dois switches com os mesmos endereços de interface de loopback, de modo que um pacote pode chegar a qualquer um deles e um quadro Ethernet pode ser extraído dele.
Se o switch souber o endereço MAC de destino do quadro recuperado, o quadro será entregue corretamente ao seu destino. Para garantir que ambos os switches de distribuição instalados no mesmo cross-connect tenham informações atualizadas sobre todos os endereços MAC “chegados” dos switches de acesso, o mecanismo M-LAG é responsável por sincronizar as tabelas de endereços MAC (bem como ARP tabelas) em ambos os pares de switches M-LAG.
O balanceamento de tráfego é alcançado devido à presença na rede subjacente de diversas rotas para as interfaces de loopback dos switches de distribuição.
Em vez de uma conclusão
Conforme mencionado acima, durante os testes e operação a rede mostrou alta confiabilidade (o tempo de recuperação para falhas típicas não passa de centenas de milissegundos) e bom desempenho - cada conexão cruzada é conectada ao núcleo por dois canais de 40 Gbit/s. Os switches de acesso em nossa rede são empilhados e conectados aos switches de distribuição via LACP/M-LAG com dois canais de 10 Gbit/s. Uma pilha geralmente contém 5 switches com 48 portas cada, e até 10 pilhas de acesso são conectadas à distribuição em cada conexão cruzada. Assim, o backbone fornece cerca de 30 Mbit/s por usuário mesmo na carga teórica máxima, o que no momento em que este artigo foi escrito é suficiente para todas as nossas aplicações práticas.
A rede permite organizar perfeitamente o emparelhamento de quaisquer dispositivos conectados arbitrariamente via L2 e L3, fornecendo isolamento completo de tráfego (que o serviço de segurança da informação gosta) e domínios de falha (que a equipe de operações gosta).
Na próxima parte contaremos como migramos para a nova rede. Fique atento!
Máximo Klochkov
Consultor sênior do grupo de auditoria de redes e projetos complexos
Centro de soluções de rede
"Infosistemas a Jato"
Fonte: habr.com