Atualização do Virtual Chassis da Série QFX de dois membros
Sobre este exemplo de configuração de rede
Este exemplo de configuração de rede (NCE) mostra como atualizar um Virtual Chassis da Série QFX de dois membros quando o processo de upgrade de software ininterrupto (NSSU) não está disponível ou é indesejável. Esse processo minimiza a interrupção do serviço e tem impacto mínimo nas cargas de trabalho do data center. O recurso NSSU para a Série QFX é suportado entre versões específicas que podem ser encontradas na seção Série QFX das Notas de versão do Junos.
Veja também
Visão geral do caso de uso
Os recursos do Virtual Chassis são aspectos importantes do portfólio da Série QFX. Um caso de uso comum do Virtual Chassis em data centers é agregar vários switches top-of-rack em uma única entidade lógica para simplificar o gerenciamento e as operações de pares de alta disponibilidade. Nesse caso de uso, racks de servidores são multihomed para dois switches da Série QFX top-of-rack. Os switches são configurados em um par de Virtual Chassis e oferecem resiliência ao caminho de rede se um dos dispositivos da Série QFX falhar.
Quando esses dispositivos precisarem de atualizações de software, você geralmente usará os recursos NSSU do Virtual Chassis para atualizar os dispositivos. A atualização do NSSU atualiza seletivamente os dispositivos membros do Virtual Chassis em uma ordem inteligente para minimizar a interrupção do serviço nos servidores conectados.
No entanto, há determinados cenários de atualização em que a versão "de" e a versão "para" não dão suporte ao processo de atualização do NSSU. Ao atualizar nesses cenários, podemos obter um resultado semelhante por meio de uma série de operações manuais. Este caso de uso abrange o caminho de atualização não-NSSU entre duas versões.
Visão geral técnica
O processo de upgrade manual de um Virtual Chassis de dois membros imita de perto as etapas executadas pelo processo NSSU automatizado. A sequência aproveita o design de alta disponibilidade para remover sistematicamente um dispositivo do serviço para realizar a atualização e a reinicialização. Quando os nós do servidor são hospedados em cada um dos dispositivos, a rede pode suportar a remoção de um dos membros do Virtual Chassis durante a janela de atualização. Há uma redução da largura de banda geral da rede durante o processo, mas a rede permanece disponível.
O recurso Virtual Chassis usa um conceito primário/backup para manter o estado do dispositivo sincronizado entre os membros do Virtual Chassis. Enquanto um dispositivo lida com o tráfego, nós colocamos o outro dispositivo offline e o atualizamos. Para atualizar os dois dispositivos, tomamos as seguintes medidas:
Primeiro, transferimos todo o tráfego para o dispositivo principal.
Quando o dispositivo de backup não está mais lidando com o tráfego do servidor, separamos o Virtual Chassis.
Com o dispositivo de backup completamente isolado, atualizamos o software no dispositivo de backup e o reiniciamos. O dispositivo de backup manterá uma cópia da configuração de rede original.
Depois que o backup atualizado fica online, mudamos o tráfego do servidor do dispositivo principal para o dispositivo de backup. Depois que o backup está lidando com a carga da rede, atualizamos e reinicializamos o dispositivo principal.
Depois que o dispositivo principal fica on-line, transferimos o tráfego de volta para o dispositivo principal.
Por fim, reativamos os links do Virtual Chassis entre os dois dispositivos para recriar o par Virtual Chassis executando a nova versão do software.
Exemplo de configuração
Este exemplo de configuração mostra como atualizar um Virtual Chassis de dois membros do Junos OS Release 14.1X53-D49.1 para o Junos OS Release 18.1R2.6. Acontece que essa não é uma combinação compatível com o recurso NSSU, portanto, usaremos o processo manual descrito abaixo.
Este exemplo usa uma configuração básica do Virtual Chassis, mas o processo aqui é adaptável a vários casos de uso diferentes.
Requerimentos
Use este procedimento para atualizar ambos os membros de um Virtual Chassis de dois membros que consiste em switches QFX5100, QFX5110, QFX5220 ou QFX5200 para a mesma versão do Junos OS Release. É altamente recomendável que ambos os membros do Virtual Chassis sejam da mesma plataforma, como neste exemplo.
Antes de começar:
-
Certifique-se de que o Virtual Chassis seja composto por dois membros, onde um é configurado como um membro principal e o outro é configurado como um membro de backup.
-
Configure o Virtual Chassis no modo Virtual Chassis (ou seja, não no modo Virtual Chassis Fabric)
-
Certifique-se de que o Virtual Chassis esteja executando apenas funções de Camada 2 (ou seja, sem IRBs ou protocolos de roteamento)
Este exemplo usa os seguintes componentes de hardware e software:
-
Dois dispositivos QFX5100-48S-6Q executando o Junos OS versão 14.1X53-D49.1
-
Versão do Junos OS 18.1R2.6
-
Servidor de teste executando o Ubuntu Linux 16.04
Visão geral
O upgrade entre versões requer uma sequência específica de etapas coordenadas entre os elementos da rede para garantir um mínimo de tempo de inatividade durante a transição. Conforme indicado no diagrama, o procedimento geral aproveitará as características de alta disponibilidade dos servidores modernos com conexões redundantes com o Virtual Chassis durante a transição.
No início da atualização, começamos com um Virtual Chassis funcional de dois membros. Nosso objetivo é atualizar para uma nova versão do Junos OS com o mínimo de interrupção de tráfego. Para conseguir isso, separaremos o Virtual Chassis e atualizaremos os dispositivos membros como unidades independentes. Após a atualização dos dispositivos, vamos reconectá-los e restabelecer o Virtual Chassis.
Topologia
Configuração
Tramitação processual
Procedimento passo a passo
Para atualizar os dispositivos:
-
Verifique o estado do Virtual Chassis. Verifique os parâmetros do Virtual Chassis e verifique se você está trabalhando com um Virtual Chassis de dois membros que esteja operacional.
{master:0} user@qfx5100-a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 235e.5bda.52ca Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt TA3714120212 qfx5100-48s-6q 129 Master* N Virtual Chassis 1 Virtual Chassisp-255/0/48 1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual Chassis 0 Virtual Chassisp-255/0/48 -
Carregue o novo software para os membros do Virtual Chassis. Copie o novo software para /var/tmp nos dispositivos primários e de backup do Virtual Chassis. Esta etapa prepara o software em ambos os switches para o procedimento de atualização. A operação de cópia levará algum tempo para ser concluída enquanto transfere as imagens do Junos OS.
file copy http://server.example.com/volume/download/software/junos/18.1R2.6/jinstall-host-qfx-5-18.1R2.6-signed.tgz /var/tmp/
-
Recomendamos desabilitar a detecção de divisão sempre que você formar um Virtual Chassis com apenas dois membros. Se você não desabilitar a detecção de divisão, o dispositivo primário poderá assumir uma função de placa de linha e interromper os planos de controle e dados quando você desabilitar o Mecanismo de Roteamento de backup mais adiante neste exemplo.
Como você iniciou este NCE com um Virtual Chassis totalmente configurado, essa opção já deve estar configurada. Se não for por qualquer motivo, configure-o agora.
user@qfx5100-a# set virtual-chassis no-split-detection
-
Desative as portas voltadas para o servidor no Mecanismo de Roteamento de backup para minimizar a interrupção durante a alternância.
user@qfx5100-b# wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
-
Desative as portas VCP em direção ao Mecanismo de Roteamento de backup. Isso quebra o Virtual Chassis.
user@qfx5100-b> request virtual-chassis vc-port delete pic-slot 0 port 48 member 1 request virtual-chassis vc-port delete pic-slot 0 port 48 member 0
Atualize o Mecanismo de Roteamento de backup. Ao atualizar para uma versão 18.2 ou mais recente do Junos, você deve incluir a
force-hostopção. Isso garante que o sistema operacional host e os binários do Junos sejam atualizados e permaneçam correspondentes.{master:1} user@qfx5100-b> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Troque as portas voltadas para o servidor desativando as portas voltadas para o servidor no dispositivo principal e reativando as portas voltadas para o servidor no backup simultaneamente. Implemente a mesma configuração nos dispositivos primários e de backup para modificar qualquer configuração restante de quando os dois dispositivos faziam parte do Virtual Chassis.
No QFX de backup, primeiro desative as portas voltadas para o servidor no dispositivo principal. Não comprometa a configuração:
user@qfx5100-b# wildcard range set interfaces ge-0/0/[0-47] disable wildcard range set interfaces xe-0/0/[0-47] disable
Em seguida, reative as portas voltadas para o servidor no backup excluindo a configuração anterior. Confirme a configuração:
wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
Repita a configuração no QFX principal:
user@qfx5100-a# wildcard range set interfaces ge-0/0/[0-47] disable wildcard range set interfaces xe-0/0/[0-47] disable wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
-
Atualize o Mecanismo de Roteamento principal. Ao atualizar para uma versão 18.2 ou mais recente do Junos, você deve incluir a
force-hostopção. Isso garante que o sistema operacional host e os binários do Junos sejam atualizados e permaneçam correspondentes.{master:0} user@qfx5100-a> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Troque as portas voltadas para o servidor de volta para o dispositivo principal. Reative as portas voltadas para o servidor no dispositivo principal para acelerar a convergência do LACP quando o Virtual Chassis voltar. Implemente a mesma configuração nos dispositivos primários e de backup para modificar qualquer configuração restante de quando os dois dispositivos faziam parte do Virtual Chassis.
No QFX de backup, primeiro reative as portas voltadas para o servidor no dispositivo primário excluindo a configuração anterior. Não comprometa a configuração:
user@qfx5100-b# wildcard range delete interfaces ge-0/0/[0-47] disable wildcard range delete interfaces xe-0/0/[0-47] disable
Em seguida, desative as portas voltadas para o servidor no backup e confirme a configuração:
wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
Repita a configuração no QFX principal:
user@qfx5100-a# wildcard range delete interfaces ge-0/0/[0-47] disable wildcard range delete interfaces xe-0/0/[0-47] disable wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
-
Reative as portas VCP em ambas as caixas para restabelecer o Virtual Chassis.
user@qfx5100-a> request virtual-chassis vc-port set pic-slot 0 port 48 member 0 request virtual-chassis vc-port set pic-slot 0 port 48 member 1
-
Verifique se você restabeleceu o Virtual Chassis.
user@qfx5100-a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 235e.5bda.52ca Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt TA3714120212 qfx5100-48s-6q 129 Master* N Virtual Chassis 1 Virtual Chassisp-255/0/48 1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual Chassis 0 Virtual Chassisp-255/0/48 -
Habilite as portas de acesso em ambos os membros. Agora que o Virtual Chassis foi restabelecido, precisamos restabelecer as portas de acesso para que possamos usar o endereço em0 do Mecanismo de Roteamento primário para nos comunicarmos com o Virtual Chassis recém-atualizado.
No QFX principal:
user@qfx5100-a# wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
Observação:Se você pretende adicionar mais dispositivos ao seu Virtual Chassis de dois membros, reative a detecção de divisão.
Você atualizou seu Virtual Chassis de dois membros.
Conclusão
Virtual Chassis é um projeto de arquitetura importante para alta disponibilidade de data center. Agora você sabe como atualizar manualmente um Virtual Chassis da Série QFX de dois membros com impacto mínimo nas cargas de trabalho do seu data center. Use o procedimento descrito neste documento para atualizar qualquer Virtual Chassis com uma topologia semelhante quando o NSSU não estiver disponível ou não for desejável.