
Na nossa agregação de rede local, havia seis pares de switches Arista DCS-7050CX3-32S e um par de switches Brocade VDX 6940-36Q. Não é que os switches Brocade nos preocupassem muito nesta rede, eles funcionam e cumprindo suas funções, mas estávamos preparando a automação completa de algumas ações, e essas capacidades não tínhamos nesses switches. Além disso, queríamos passar de interfaces de 40GE para a possibilidade de usar 100GE, para ter margem para os próximos 2-3 anos. Assim, decidimos trocar os Brocade por Arista.
Estes switches são switches de agregação de rede local para cada data center. Eles se conectam diretamente aos switches de distribuição (segundo nível de agregação), que já reúnem os switches Top-of-Rack na racks com servidores.
Cada servidor está conectado a um ou dois switches de acesso. Os switches de acesso estão conectados a um par de switches de distribuição (dois switches de distribuição e duas conexões físicas do switch de acesso para diferentes switches de distribuição são utilizadas para redundância).
Cada servidor pode ser utilizado por seu cliente, então um VLAN separado é atribuído ao cliente. Essa mesma VLAN é depois configurada em outro servidor desse cliente em qualquer rack. O data center consiste em várias dessas fileiras (PODs), para cada fileira de racks existem seus próprios switches de distribuição. Então, esses switches de distribuição são conectados aos switches de agregação.
Os clientes podem solicitar servidores em qualquer fileira, não é possível prever com antecedência que um servidor será alocado ou instalado em uma fileira específica em um rack específico, portanto, nos switches de agregação há cerca de 2500 VLAN em cada data center.
O equipamento para DCI (Data-Center Interconnect) é conectado aos switches de agregação. Ele pode ser destinado à conectividade L2 (um par de switches formando um túnel VXLAN para outro data center), assim como para conectividade L3 (dois roteadores MPLS).
Como já mencionei, para unificar os processos de automação da configuração dos serviços em um único data center, precisávamos substituir os switches centrais de agregação. Instalamos novos switches próximos aos existentes, formamos um par MLAG e começamos a nos preparar para os trabalhos. Eles foram conectados imediatamente aos switches de agregação existentes, criando assim um domínio L2 comum para todas as VLANs de clientes.
Detalhes do esquema
Para ser mais específico, vamos chamar os antigos switches de agregação de A1 e A2, os novos — N1 e N2. Suponhamos que em POD 1 e POD 4 estão localizados os servidores de um cliente C1, a VLAN do cliente é indicada na cor azul. Este cliente utiliza o serviço de conectividade L2 com outro data center, portanto sua VLAN está encaminhada para um par de switches VXLAN.
Cliente C2 aloca servidores em POD 2 e POD 3, a VLAN do cliente é indicada na cor verde-escuro. Este cliente também utiliza o serviço de conectividade com outro data center, mas L3, então sua VLAN é encaminhada para um par de roteadores L3VPN.
As VLANs dos clientes são necessárias para entender em quais etapas do trabalho de substituição ocorrem eventos, onde há interrupções na conexão e qual pode ser sua duração. O protocolo STP não é utilizado neste esquema, pois a largura da árvore seria grande e a convergência do protocolo aumentaria geometricamente com o número de dispositivos e links entre eles.
Todos os dispositivos conectados por links duplos formam um stack, um par MLAG ou uma fábrica Ethernet VCS. Para um par de roteadores L3VPN, essas tecnologias não são utilizadas, pois não há necessidade de redundância L2; é suficiente que haja conectividade L2 entre eles através dos switches de agregação.
Opções de implementação
Ao analisar as opções para os eventos futuros, percebemos que existem várias maneiras de realizar esses trabalhos. Desde uma interrupção global em toda a rede local até pequenas interrupções de apenas 1-2 segundos em partes da rede.
Rede, parar! Switches, troquem-se!
A maneira mais simples é, claro, declarar uma interrupção global de conexão em todos os PODs e em todos os serviços DCI e redirecionar todos os links dos switches A nos switches N.
Além da interrupção, cujo tempo não podemos prever com certeza (sim, sabemos a quantidade de links, mas não sabemos quantas vezes algo pode dar errado — desde um cabo de patch quebrado ou um conector danificado até uma falha na porta ou no transceptor), não conseguimos prever antecipadamente se o comprimento dos cabos de patch, DAC, AOC conectados aos antigos switches A será suficiente para alcançarem os novos switches N, que, embora estejam próximos, estão ainda assim um pouco afastados, e se os mesmos transceptores/DAC/AOC dos switches Brocade funcionarão nos switches Arista.
E tudo isso sob a forte pressão dos clientes e do suporte técnico ("Natasha, levante-se! Natasha, está tudo fora do ar! Natasha, já contatamos o suporte, honestamente! Natasha, já derrubaram tudo! Natasha, quanto tempo ainda ficará fora? Natasha, quando voltará a funcionar?!"). Mesmo com a interrupção previamente anunciada e a notificação feita aos clientes, o aumento de solicitações nesse período é garantido.
Pare, 1-2-3-4!
E se não anunciarmos uma interrupção global, mas sim uma série de pequenas interrupções de conexão por POD e serviços DCI. Na primeira interrupção, alternar para os switches N apenas POD 1, na segunda — em alguns dias — POD 2, depois mais alguns dias POD 3, em seguida POD 4…[N], depois os switches VXLAN e depois os roteadores L3VPN.
Com essa organização do trabalho de comutação, diminuímos a complexidade das operações simultâneas e aumentamos nosso tempo para solucionar problemas, caso algo saia errado. A conectividade do POD 1 após a comutação com outros PODs e DCI não se perde. No entanto, as atividades se prolongam por muito tempo; durante esses trabalhos, é necessário designar um engenheiro físico para realizar as comutações, e durante as operações (que, como regra, são realizadas à noite, entre 2 e 5 da manhã) é necessário ter um engenheiro de rede online de alta qualificação. Mas, em compensação, obtemos interrupções de conexão curtas, geralmente as operações podem ser realizadas em intervalos de meia hora com uma pausa de até 2 minutos (na prática, muitas vezes 20-30 segundos com o comportamento esperado dos equipamentos).
No exemplo dado do cliente C1 ou do cliente C2 será necessário avisar sobre os trabalhos com interrupção na conexão pelo menos três vezes — a primeira para realizar trabalhos em um POD que contém um de seus servidores, a segunda vez — para o segundo, e a terceira vez — ao alternar o equipamento para serviços DCI.
Alternância de canais de comunicação agregados
Por que falamos sobre o comportamento esperado do equipamento e como os canais agregados podem ser alternados com uma interrupção mínima na conexão. Vamos imaginar a seguinte situação:
De um lado do link — os switches de distribuição POD — D1 e D2, eles formam entre si um par MLAG (stack, fábrica VCS, par vPC), do outro lado dois links — Link 1 e Link 2 — estão conectados ao par MLAG de switches de agregação antigos A. Do lado dos switches D é formado um interface agregada com o nome Port-channel A, do lado dos switches de agregação A — interface agregada com o nome Port-channel D.
As interfaces agregadas em seu funcionamento utilizam LACP, ou seja, os switches de ambos os lados trocam regularmente pacotes LACPDU por ambos os links para garantir que os links:
- estão operacionais;
- estão conectados a um par de dispositivos do lado remoto.
Ao trocar pacotes, o pacote transmite o valor system-id, que indica o dispositivo ao qual esses links estão conectados. Para o par MLAG (stack, fábrica, etc.) o valor do system-id para os dispositivos que formam a interface agregada é o mesmo. O switch D1 envia para Link 1 valor system-id D, e o switch D2 envia para Link 2 valor system-id D.
Os switches A1 e A2 analisam os pacotes LACPDU recebidos por uma interface Po D e verificam a correspondência do system-id neles. Se o system-id recebido por algum link difere do valor de trabalho atual, o link é removido da interface agregada até que a situação seja corrigida. Atualmente, do lado dos switches D o valor atual do system-id do parceiro LACP é — A, e do lado dos switches A — o valor atual do system-id do parceiro LACP é — D.
Se for necessário alternar a interface agregada, podemos proceder de duas maneiras diferentes:
Método 1 — Simples
Desconectar ambos os links dos switches A. Nesse caso, o canal agregado não funciona.
Conectar ambos os links em sequência aos switches N, então ocorrerá uma nova negociação dos parâmetros de operação do LACP, formação da interface Po D nos switches N e transmissão dos links do valor system-id N.
Método 2 — Minimização da interrupção
Desconectar do switch A2 o link Link 2. A partir disso, o tráfego entre A e D continuará a ser transmitido simplesmente por um dos links que permanecerá na interface agregada.
Conectar o Link 2 no switch N2. No switch N já está configurada a interface agregada Po DN, e o switch N2 começará a transmitir em LACPDU system-id N. Neste estágio, já podemos verificar se o switch N2 funciona corretamente com o transceptor utilizado para Link 2, se a porta de conexão passou para o estado Up, e se durante a transmissão de LACPDU não ocorrem erros na porta de conexão.
Mas o fato de que o switch D2 para a interface agregada Po A do lado Link 2 está recebendo o valor de system-id N, diferente do valor atual de trabalho system-id A, não permite que os switches D introduzam Link 2 na interface agregada. Po AO switch N não pode introduzir Link 2 em operação, pois não recebe confirmação de operação do parceiro LACP do switch D2. O tráfego, no final, não é transmitido por Link 2 .
Agora, desligamos o Link 1 do switch A1, desta forma, privando os switches A e D da interface agregada em funcionamento. Assim, do lado do switch D perde-se o valor atual de trabalho do system-id da interface Po A.
Isso permite que os switches D e N negociem a troca do system-id A-N nas interfaces Po A e Po DN, de modo que o tráfego começa a ser transmitido pelo link Link 2. A interrupção, neste caso, é de até 2 segundos na prática.
Agora, podemos tranquilamente alternar o Link 1 para o switch N1, restaurando a capacidade e o nível de redundância das interfaces. Po A e Po DN. Como, ao conectar este link, o valor atual do system-id não muda de nenhum lado, não ocorre interrupção.
Links adicionais
Mas a alternância pode ser realizada sem a presença de um engenheiro no momento da troca. Para isso, precisamos previamente instalar links adicionais entre os switches de distribuição D e os novos switches de agregação N.
Estabelecemos novos links entre switches de agregação N e switches de distribuição de todos os POD. Isso requer a solicitação e a instalação de cabos patch adicionais e a instalação de transceptores adicionais tanto em N, quanto em D. Podemos fazer isso, pois em nossos switches D de cada POD existem portas livres (ou as liberamos previamente). No final, cada POD está fisicamente conectado por duas links aos switches antigos A e aos novos switches N.
No switch D foram formados dois interfaces agregados — Po A com links Link 1 e Link 2, quanto Po N — com links Link N1 e Link N2. Neste estágio, verificamos a correção da conexão dos interfaces e links, os níveis dos sinais ópticos em ambas as extremidades dos links (por meio de informações DDM dos switches), podemos até verificar a funcionalidade do link sob carga ou monitorar os estados dos sinais ópticos e a temperatura dos transceptores durante alguns dias.
O tráfego continua a ser transmitido através do interface Po A, enquanto o interface Po N permanecem sem tráfego. As configurações nos interfaces são aproximadamente as seguintes:
Interface Port-channel A
Modo de switchport trunk
Vlan permitidas switchport C1, C2
Interface Port-channel N
Modo de switchport trunk
Vlan permitidas switchport noneOs switches D, em geral, suportam a alteração de configuração de sessão, utilizando modelos de switches que possuem essa funcionalidade. Assim, a alteração das configurações dos interfaces Po A e Po N pode ser feita em um único passo:
Configure session
Interface Port-channel A
switchport allowed vlan none
Interface Port-channel N
switchport allowed vlan C1, C2
CommitDessa forma, a alteração da configuração ocorrerá rapidamente, e a interrupção será, na prática, de não mais que 5 segundos.
Esse método nos permite realizar todos os trabalhos preparatórios com antecedência, realizar todas as verificações necessárias, coordenar as atividades com os participantes do processo, prever detalhadamente as ações para a execução dos trabalhos, sem voos criativos, quando "tudo deu errado", e ter em mãos um plano de retorno à configuração anterior. Os trabalhos conforme esse plano são realizados pelo engenheiro de redes sem a presença no local do engenheiro do data center, que fisicamente realiza as comutações.
Outra coisa importante nesse tipo de comutações — todos os novos links já estão previamente configurados para monitoramento. Erros, inclusão de links no agregado, carregamento de links — todas as informações necessárias já estão no sistema de monitoramento, e isso já foi desenhado nos mapas.
D-Day
POD
Escolhemos o caminho menos doloroso para os clientes e menos suscetível a opções de "algo deu errado" para as comutações com links adicionais. Assim, em algumas noites, mudamos todos os PODs para novos switches de agregação.
Mas falta mudar o equipamento que fornece os serviços DCI.
L2
No caso de equipamentos que fornecem conectividade L2, não conseguimos realizar trabalhos semelhantes com links adicionais. Existem pelo menos duas razões para isso:
- Falta de portas livres na velocidade necessária nos switches VXLAN.
- Falta de funcionalidade de alteração de configuração de sessão nos switches VXLAN.
Não realizamos a troca dos links 'um a um' com intervalo apenas durante a sincronização do novo par system-id, pois não tínhamos 100% de certeza de que o procedimento ocorreria corretamente. Um teste em laboratório mostrou que, se 'algo der errado', ainda teremos uma interrupção na conexão, e o mais grave — não apenas para os clientes que possuem conectividade L2 com outros data centers, mas para todos os clientes deste data center.
Antes, realizamos um trabalho de sensibilização para a migração dos canais L2, portanto, o número de clientes afetados pelos trabalhos nos switches VXLAN já era várias vezes menor do que há um ano. Como resultado, decidimos pela interrupção da conexão em relação ao serviço de conectividade L2, sob a condição de que mantivéssemos o funcionamento normal dos serviços de rede local em um data center. Além disso, o SLA para esse serviço prevê a possibilidade de realização de trabalhos programados com interrupção.
L3
Por que recomendamos a todos que migrassem para o uso de L3VPN na organização de serviços DCI? Uma das razões é a possibilidade de realizar trabalhos em um dos roteadores que fornecem esse serviço, simplesmente diminuindo o nível de redundância para N+0, sem interrupção na conexão.
Vamos considerar o esquema de fornecimento do serviço mais de perto. Neste serviço, o segmento L2 vai dos servidores dos clientes apenas até os roteadores L3VPN da Selectel. Nos roteadores, a rede do cliente é terminada.
Cada servidor do cliente, por exemplo, S2 e S3 no esquema apresentado, tem seu privado endereços IP — 10.0.0.2/24 no servidor S2 e 10.0.0.3/24 no servidor S3. Os endereços 10.0.0.252/24 e 10.0.0.253/24 são atribuídos do lado da Selectel aos roteadores L3VPN-1 e L3VPN-2, respectivamente. O endereço IP 10.0.0.254/24 é o endereço VIP do VRRP nos roteadores da Selectel.
Mais informações sobre o serviço L3VPN podem ser encontradas em nosso blog.
Até o momento da mudança, tudo parecia aproximadamente como no esquema:
Dois roteadores L3VPN-1 e L3VPN-2 estavam conectados ao antigo switch de agregação A. O mestre para o endereço VIP do VRRP 10.0.0.254 é o roteador L3VPN-1Ele tem prioridade para este endereço maior do que o do roteador L3VPN-2.
unit 1006 {
description C2;
vlan-id 1006;
family inet {
address 10.0.0.252/24 {
vrrp-group 1 {
priority 200;
virtual-address 10.100.0.254;
preempt {
hold-time 120;
}
accept-data;
}
}
}
}O servidor S2 utiliza o gateway 10.0.0.254 para se comunicar com servidores em outras localizações. Assim, a desconexão da rede do roteador L3VPN-2 (naturalmente, após sua desconexão do domínio MPLS) não afeta a conectividade dos servidores do cliente. Neste momento, apenas o nível de redundância do esquema é reduzido.
Depois disso, podemos reconectar o roteador com tranquilidade L3VPN-2 a um par de switches N. Estabelecer os links, trocar os transceivers. As interfaces lógicas do roteador, das quais dependem os serviços do cliente, permanecem desativadas até que tenhamos a confirmação de que tudo está funcionando corretamente.
Após as verificações dos links, transceivers, níveis de sinal, níveis de erro nas interfaces, o roteador é ativado novamente, mas já conectado ao novo par de switches.
Em seguida, reduzimos a prioridade do VRRP no roteador L3VPN-1, e o endereço VIP 10.0.0.254 é transferido para o roteador L3VPN-2. Esses trabalhos também são realizados sem interrupção da conexão.
A transferência do endereço VIP 10.0.0.254 para o roteador L3VPN-2 permite desligar o roteador L3VPN-1 sem interrupção da conexão para o cliente e conectá-lo já ao novo par de switches de agregação N.
Se devemos ou não retornar o VIP do VRRP para o roteador L3VPN-1 — essa é uma outra questão, e mesmo que retornemos, isso é feito sem interrupção da conexão.
Total
Após todas essas ações, realmente substituímos os switches de agregação em um de nossos data centers, minimizando assim as interrupções para nossos clientes.
Depois disso, resta apenas a desmontagem. A desmontagem dos switches antigos, a desmontagem dos links antigos entre os switches A e D, a desmontagem dos transceivers desses links, a correção da monitoria, a correção do diagrama de rede na documentação e monitoramento.
Os switches, transceivers, patch cords, AOC, DAC restantes após as comutações, podemos usar em outros projetos ou em outras comutações semelhantes.
«Natasha, nós tudo comutamos!»
Fonte: habr.com
