Neste artigo, examinaremos por que a abordagem tradicional de combinar redes locais no nível L2 é ineficaz com um aumento significativo no número de equipamentos, além de mostrar quais problemas conseguimos resolver no processo de combinar projetos localizados em locais diferentes.
Circuito L2 normal
À medida que a infraestrutura de TI cresce no data center, os clientes precisam combinar servidores, armazenamento e firewalls em uma única rede. Para isso, a Selectel sugere inicialmente o uso de uma rede local.
A rede local é organizada como uma rede clássica "campus" dentro do mesmo data center, apenas os switches de acesso estão localizados diretamente nos racks com os servidores. Os switches de acesso são ainda combinados em um único switch de camada de agregação. Cada cliente pode
solicitar uma conexão com a rede local para qualquer dispositivo que ele alugue ou coloque conosco no data center.
Para organizar uma rede local, são usados comutadores de acesso e agregação dedicados, para que problemas na rede da Internet não afetem a rede local.
Não importa em qual rack o próximo servidor está localizado - o Selectel combina os servidores em uma única rede local, e você não precisa pensar em switches nem na localização do servidor. Você pode
solicitar um servidor quando necessário e ele será conectado à rede local.
L2 funciona muito bem enquanto o tamanho do data center é pequeno, quando nem todos os racks estão cheios. Porém, à medida que o número de racks, servidores em racks, comutadores e clientes aumenta, o circuito se torna muito mais difícil de manter.
Os servidores de um cliente podem estar localizados em vários
data centers para garantir a tolerância a desastres ou se for impossível colocar o servidor em um data center existente (por exemplo, todos os racks e todos os locais estão ocupados). Entre vários data centers, a conectividade também é necessária - entre servidores em uma rede local.
À medida que o número de data centers, racks e servidores aumenta, o circuito se torna mais complicado. Inicialmente, a conectividade entre os servidores de diferentes data centers era realizada simplesmente no nível dos switches de agregação usando a tecnologia VLAN.
Mas o espaço de identificação da VLAN é muito limitado (4095 IDs da VLAN). Portanto, para cada data center, você deve usar seu próprio conjunto de VLANs, o que reduz o número de identificadores possíveis que podem ser usados entre os data centers.
Problemas L2
Ao usar um esquema no nível L2 usando VLAN, a operação incorreta de um dos servidores no datacenter pode levar a interrupções no fornecimento de serviços em outros servidores. Os problemas mais comuns incluem:
- Problemas com STP (Spanning-Tree Protocol)
- Problemas com tempestades de transmissão
- Problemas com o processamento multicast incorreto
- Fator humano (transferência de link, transferência de VLAN)
- Problemas com a organização da reserva para L2
- Problemas com tráfego de unicast desconhecido
- Problemas com o número de endereços MAC
Os problemas com o STP geralmente estão relacionados às configurações dos servidores ou equipamentos do cliente. Ao contrário dos pontos populares de troca de tráfego, não podemos filtrar completamente o STP nas portas de acesso e fechar as portas quando um STP PDU chega. Na STP, vários fabricantes de equipamentos de rede implementam funcionalidades básicas de switches de data center, como a detecção de loops na rede.
Se o STP não funcionar corretamente no lado do cliente, todo o domínio STP de pelo menos um comutador de acesso poderá ser afetado. O uso de extensões STP, como o MSTP, também não é uma solução, porque o número de portas, VLANs, comutadores geralmente excede a escalabilidade arquitetural do protocolo STP.
Difusão
A rede no centro de dados pode ser construída em dispositivos de diferentes fabricantes. Às vezes, até as diferenças na versão do software do switch são suficientes para que os switches lidem com o STP de maneira diferente. Assim, por exemplo, no data center de
Dubrovka 3 , existem 280 racks, o que excede o número máximo possível de comutadores em um domínio STP.
Com o amplo uso do STP em uma rede assim, o tempo de resposta a quaisquer alterações, em particular, simplesmente ligar ou desligar a porta, excederá todos os limites de espera. Você não deseja que, quando um dos clientes ligue a porta, sua conectividade de rede desapareça por alguns minutos?
Os problemas com o tráfego de transmissão geralmente surgem devido a ações incorretas no servidor (por exemplo, criando uma ponte entre várias portas do servidor), bem como devido à configuração incorreta do software nos servidores. Tentamos nivelar possíveis problemas com a quantidade de tráfego de broadcast que chega à nossa rede. Mas podemos fazer isso em uma porta de conexão do servidor e, se 5 servidores estiverem incluídos em um comutador, cada um dos quais não excede os limites definidos, juntos eles podem gerar tráfego suficiente para acionar o controle no comutador de agregação. De nossa própria prática, os problemas com uma tempestade de transmissão do lado do servidor podem ser causados por uma falha específica da placa de rede do servidor.
Ao proteger toda a rede, o switch de agregação “colocará” a porta na qual ocorreu a anomalia na rede. Infelizmente, isso levará à inoperabilidade dos cinco servidores que causaram esse incidente, bem como à inoperabilidade de outros servidores (até vários racks no data center).
Multicast
Problemas com o processamento incorreto do tráfego multicast são problemas muito específicos que surgem no complexo devido à operação incorreta do software no servidor e do switch. Por exemplo, o Corosync é configurado no modo multicast entre vários servidores. Regularmente, a troca de pacotes Hello é realizada em pequenos volumes. Mas, em alguns casos, os servidores com o Corosync instalado podem encaminhar muitos pacotes. Esse volume já requer uma configuração especial dos comutadores ou o uso dos mecanismos de processamento corretos (junção IGMP e outros). No caso de operação incorreta dos mecanismos ou quando os limites são acionados, pode haver interrupções no serviço que afetam outros clientes. Obviamente, quanto menos clientes no switch, menor a probabilidade de ocorrerem problemas de outro cliente.
O fator humano é um tipo de problema bastante imprevisto que pode surgir ao trabalhar com equipamentos de rede. Quando o administrador da rede está sozinho e ele constrói seu trabalho com competência, documenta as ações e pondera as consequências de suas ações, a probabilidade de um erro é muito pequena. Mas quando a quantidade de equipamentos em operação do data center está aumentando, quando há muitos funcionários, quando há muitas tarefas, é necessária uma abordagem completamente diferente para organizar o trabalho.
Alguns tipos de ações típicas são automatizados para evitar erros humanos, mas muitos tipos de ações não podem ser automatizados no momento, ou o preço da automação de tais ações é excessivamente alto. Por exemplo, a alternância física de patch cords em um painel de conexões, conectando novos links, substituindo os existentes. Tudo relacionado ao contato físico com o SCS. Sim, existem painéis de correção que permitem alternar remotamente, mas são muito caros, exigem muito trabalho preparatório e são muito limitados em suas capacidades.
Nenhum patch panel automático instalará um novo cabo, se necessário. Você pode cometer um erro ao configurar um switch ou roteador. Indique que o número da porta incorreto, número da VLAN, seja selado ao inserir um valor numérico. Ao especificar configurações adicionais, não leve em consideração sua influência na configuração existente. Com a complexidade crescente do esquema, complicando o esquema de redundância (por exemplo, devido ao esquema atual atingir o limite de escala), a probabilidade de erros humanos aumenta. Qualquer pessoa pode ter um erro humano, independentemente de o dispositivo estar no estágio de configuração, em um servidor, em um switch, em um roteador ou em algum tipo de dispositivo de trânsito.
A organização da redundância em L2, à primeira vista, parece uma tarefa simples para pequenas redes. O curso Cisco ICND aborda os conceitos básicos do uso do STP como um protocolo que foi originalmente projetado para fornecer redundância L2. O STP possui muitas restrições chamadas "por design" neste protocolo. Não devemos esquecer que qualquer domínio STP tem uma "largura" muito limitada, ou seja, o número de dispositivos em um domínio STP é bastante pequeno comparado ao número de racks no data center. O protocolo STP em sua versão original divide os links em usados e de backup, o que não fornece a utilização completa dos uplinks durante a operação normal.
O uso de outros protocolos de reserva L2 impõe suas limitações. Por exemplo, ERPS (Ethernet Ring Protection Switching) - para a topologia física usada, para o número de toques em um dispositivo, para a utilização de todos os links. O uso de outros protocolos, via de regra, está associado a alterações proprietárias de diferentes fabricantes ou limita a construção da rede a uma tecnologia selecionada (por exemplo, a fábrica TRILL / SPBm usando equipamentos Avaya).
Unicast desconhecido
Gostaria especialmente de destacar o subtipo de problemas com o tráfego unicast desconhecido. O que é isso O tráfego destinado a um endereço IP específico via L3, mas é transmitido na rede via L2, ou seja, é transmitido a todas as portas pertencentes a esta VLAN. Essa situação pode surgir por vários motivos, por exemplo, ao receber DDoS em um endereço IP não ocupado. Ou se, durante um erro de digitação na configuração do servidor, um endereço que não existe na rede foi especificado como backup, e no servidor historicamente houver um registro ARP estático nesse endereço. O unicast desconhecido aparece quando todas as entradas nas tabelas ARP estão presentes, mas na ausência do endereço MAC do receptor nas tabelas de comutação dos comutadores de trânsito.
Por exemplo, a porta atrás da qual o host da rede com o endereço fornecido está frequentemente entra no estado desligado. Esse tipo de tráfego é limitado por comutadores de trânsito e geralmente é servido da mesma maneira que difusão ou multicast. Mas, diferentemente deles, o tráfego unicast desconhecido pode ser iniciado "pela Internet" e não apenas pela rede do cliente. O risco de tráfego unicast desconhecido é especialmente alto quando as regras de filtragem nos roteadores de borda permitem a falsificação de endereços IP de fora.
Mesmo o grande número de endereços MAC às vezes pode ser um problema. Parece que, com um tamanho de data center de 200 racks, 40 servidores por rack, é improvável que o número de endereços MAC exceda muito o número de servidores no data center. Mas isso não é mais uma afirmação verdadeira, já que um dos sistemas de virtualização pode ser iniciado nos servidores e cada máquina virtual pode ser representada por seu endereço MAC ou até vários (ao emular várias placas de rede em uma máquina virtual, por exemplo). No total, podemos obter mais de vários milhares de endereços MAC legítimos de um rack em 40 servidores.
Esse número de endereços MAC pode afetar a plenitude da tabela de comutação em alguns modelos de comutador. Além disso, para determinados modelos de comutador, ao preencher a tabela de comutação, o hash é usado e alguns endereços MAC podem causar colisões de hash, levando ao aparecimento de tráfego unicast desconhecido. A pesquisa aleatória de endereços MAC em um servidor alugado a uma velocidade de, digamos, 4.000 endereços por segundo, pode causar um estouro na tabela de comutação no comutador de acesso. Naturalmente, os comutadores aplicam restrições ao número de endereços MAC que podem ser aprendidos nas portas do comutador, mas, dependendo da implementação específica desse mecanismo, os dados podem ser interpretados de diferentes maneiras.
Novamente, o envio de tráfego para o endereço MAC filtrado por esse mecanismo leva ao aparecimento de tráfego unicast desconhecido. A coisa mais desagradável nessa situação é que os interruptores raramente são testados pelo fabricante para autocorreção após casos com excesso da tabela de comutação. Um único estouro da tabela, causado, digamos, por um erro de um cliente nos parâmetros hping ou na escrita de um script que monitora sua infraestrutura, pode levar à reinicialização do switch e à interrupção da comunicação de todos os servidores localizados no rack. Se esse estouro ocorrer no comutador de nível de agregação, a reinicialização do comutador poderá resultar em um tempo de inatividade de 15 minutos em toda a rede local do datacenter.
Gostaria de dizer que o uso de L2 é justificado apenas em casos limitados e impõe muitas restrições. O tamanho do segmento, o número de segmentos L2 - esses são todos os parâmetros que devem ser avaliados toda vez que você adiciona uma nova VLAN com conectividade L2. E quanto menores os segmentos L2, mais simples e, como resultado, mais confiável a rede estará em serviço.
Casos de uso típicos de L2
Como já mencionado, com o desenvolvimento gradual da infraestrutura em um data center, uma rede local L2 é usada. Infelizmente, esse uso também está implícito no desenvolvimento de projetos em outro data center ou em outra tecnologia (por exemplo, máquinas virtuais na nuvem).
Vincular frente e verso, backup
Como regra, o uso de uma rede local começa com a separação da funcionalidade dos serviços de front-end e back-end, alocando o DBMS a um servidor separado (para melhorar o desempenho, separar o tipo de SO no servidor de aplicativos e no DBMS). Inicialmente, o uso de L2 para esses fins parece justificado, no segmento existem poucos servidores, muitas vezes eles estão localizados no mesmo rack.
Os servidores estão incluídos em uma VLAN, em um ou vários comutadores. À medida que a quantidade de equipamentos aumenta, mais e mais novos servidores são incluídos nos comutadores de novos racks no data center, a partir dos quais o domínio L2 começa a crescer em largura.
Novos servidores aparecem, incluindo servidores de banco de dados de backup, servidores de backup e similares. Enquanto o projeto residir em um data center, geralmente não ocorrem problemas de dimensionamento. Os desenvolvedores de aplicativos acostumam-se ao fato de que, no próximo servidor da rede local, o endereço IP muda apenas no último octeto, e você não precisa escrever nenhuma regra de roteamento separada.
Os desenvolvedores devem aplicar um esquema semelhante quando o projeto crescer, quando os seguintes servidores já estiverem alugados em outro data center ou quando parte do projeto for transferida para as máquinas virtuais
na nuvem . Na foto, tudo parece muito simples e bonito:
Parece que você só precisa conectar dois comutadores de agregação no DC1 e DC2 com uma VLAN. Mas o que está por trás dessa ação simples?
Reserva de Recursos
Primeiro, aumentamos a largura do domínio L2, para que todos os possíveis problemas da rede local do DC1 possam surgir no DC2. Quem gostaria que seus servidores estivessem localizados no DC2 e o incidente relacionado à inacessibilidade da rede local ocorrerá devido a ações incorretas no DC1?
Em segundo lugar, você precisa fazer o backup dessa VLAN. A opção de agregação em cada data center é o ponto de falha. O cabo entre os data centers é outro ponto de falha. Cada ponto de falha deve ser reservado. Dois comutadores de agregação, dois cabos de comutadores de agregação para acessar comutadores, dois cabos entre data centers ... Cada vez que o número de componentes aumenta e o circuito se torna mais complicado.
A complexidade do esquema é causada pela necessidade de reservar cada elemento no sistema. Para um backup completo de dispositivos e links, você precisa duplicar quase todos os elementos. Em uma rede tão grande, não é mais possível usar o STP para organizar backups. Seria possível apresentar todos os elementos de rede, em particular os comutadores de acesso, como componentes da nuvem MPLS, e a redundância seria obtida devido à funcionalidade do protocolo MPLS.
Mas os dispositivos MPLS geralmente são duas vezes mais caros que os dispositivos não MPLS. E deve-se notar que a opção MPU em 1U, que possui um bom grau de escalabilidade, a implementação da funcionalidade MPLS completa no plano de controle, na prática, não existia até recentemente. Como resultado, quero me livrar ou minimizar o impacto dos problemas de L2 na rede existente, mas, ao mesmo tempo, manter a capacidade de reservar recursos.
Transição para L3
Se cada link na rede é representado como um segmento IP separado e cada dispositivo como um roteador separado, não precisamos de redundância no nível L2. A redundância de link e roteador é garantida por protocolos de roteamento dinâmico e redundância de roteamento na rede.
Dentro do datacenter, podemos salvar os esquemas de interação do servidor existentes via L2, e o acesso aos servidores em outro datacenter será via L3.
Assim, os data centers são interconectados pela conectividade L3. Ou seja, emula-se que um roteador esteja instalado entre os datacenters (na verdade, vários, para backup). Isso permite que você divida os domínios L2 entre os data centers, use sua própria VLAN em cada data center e se comunique entre eles. Para cada cliente, você pode usar intervalos repetidos de endereços IP, as redes são completamente isoladas umas das outras e não pode entrar na rede de outro cliente a partir da rede de um cliente (exceto quando os dois clientes concordam com essa conexão).
Recomendamos que você use segmentos IP de 10.0.0.0/8 para redes locais. Para o primeiro datacenter, a rede será, por exemplo, 10.0.1.0/24, para o segundo - 10.0.2.0/24. Selectel no roteador prescreve o endereço IP desta sub-rede. Normalmente, os endereços .250-.254 são reservados para dispositivos de rede Selectel, e um endereço .254 serve como gateway para outras LANs. A rota é atribuída a todos os dispositivos em todos os datacenters:
route add 10.0.0.0 mask 255.0.0.0 gw 10.0.x.254Onde x é o número do datacenter. Devido a essa rota, os servidores nos datacenters “se veem” roteando.
A presença dessa rota simplifica o dimensionamento do esquema no caso, por exemplo, da aparência de um terceiro data center. Em seguida, para servidores no terceiro data center, os endereços IP do próximo intervalo, 10.0.3.0/24, são registrados no roteador - o endereço 10.0.3.254.
Uma característica distintiva da implementação de um esquema desse tipo é que ele não requer reserva adicional em caso de falha do datacenter ou dos canais de comunicação externos. Portanto, por exemplo, se o datacenter 1 falhar, a conexão entre o datacenter 2 e o datacenter 3 será completamente preservada e, ao implementar o esquema com o feed L2 entre os datacenters por um deles, como na figura:
A conexão entre o data center 2 e o data center 3 depende da eficiência do data center 1. Ou, a organização de links adicionais e o uso de esquemas complexos de reserva L2 são necessários. E, ao salvar o esquema L2, toda a rede ainda é muito sensível à comutação incorreta, à formação de loops de comutação, várias tempestades de tráfego e outros problemas.
Segmentos L3 nos projetos
Além de usar diferentes segmentos L3 em diferentes datacenters, faz sentido alocar uma rede L3 separada para servidores em diferentes projetos, geralmente criados com diferentes tecnologias. Por exemplo, servidores de hardware no datacenter em uma sub-rede IP, servidores virtuais no mesmo datacenter, mas na nuvem VMware, em outra sub-rede IP, alguns servidores relacionados à preparação na terceira sub-rede IP . Portanto, erros aleatórios em um dos segmentos não levam a uma falha completa de todos os servidores incluídos na rede local.
Reserva de roteador
Tudo isso é impressionante, mas há um único ponto de falha entre os projetos - este é o roteador. O que fazer neste caso? De fato, o roteador não está sozinho. Dois roteadores são alocados para cada datacenter e, para cada cliente, eles formam o IP virtual .254 usando o protocolo VRRP.
O uso de VRRP entre dois dispositivos adjacentes com um segmento L2 comum é justificado. Para data centers geograficamente distribuídos, roteadores diferentes são usados e o MPLS é organizado entre eles. Assim, cada cliente que se conecta à rede local dessa maneira é conectado a um L3VPN separado criado para esses roteadores MPLS. E o esquema, em aproximação à realidade, fica assim:
O endereço do gateway para cada segmento .254 é reservado pelo VRRP entre os dois roteadores.
Conclusão
Resumindo tudo isso, alterar o tipo de rede local de L2 para L3 nos permitiu manter a capacidade de escalar, aumentou o nível de confiabilidade e tolerância a falhas e também nos permitiu implementar esquemas de redundância adicionais. Além disso, isso contornou as restrições e “armadilhas” existentes de L2.
À medida que os projetos e os data centers crescem, as soluções padrão existentes atingem seu limite de escalabilidade. Isso significa que eles não são mais adequados para a solução eficaz de problemas. Os requisitos de confiabilidade e estabilidade do sistema como um todo estão aumentando constantemente, o que, por sua vez, afeta o processo de planejamento. É importante levar em consideração o fato de que previsões de crescimento otimistas devem ser consideradas para que, no futuro, não exista um sistema que não possa ser escalado.
Diga-nos - você já está usando o L3VPN? Vejo você nos comentários.