Atualização do chassi virtual 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 Chassi Virtual da Série QFX de dois membros quando o processo de atualização ininterrupta de software (NSSU) não estiver 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 da Série QFX das Notas de Lançamento 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 está agregando vários switches top-of-rack em uma única entidade lógica para oferecer simplicidade no gerenciamento e operações de pares de alta disponibilidade. Nesse caso de uso, os racks de servidores são multihomed para dois switches top-of-rack da Série QFX. Os switches são configurados em um par Virtual Chassis e fornecem resiliência ao caminho da rede se um dos dispositivos da Série QFX falhar.
Quando esses dispositivos precisam de atualizações de software, você geralmente usará os recursos de NSSU do Virtual Chassis para atualizar os dispositivos. A atualização do NSSU atualiza seletivamente os dispositivos membros do Virtual Chassis de forma inteligente para minimizar a interrupção do serviço nos servidores conectados.
No entanto, existem certos cenários de atualização em que a versão "de" e "para" não suporta o processo de atualização do NSSU. Ao atualizar esses 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 atualização manual de um Virtual Chassis de dois membros imita de perto as medidas tomadas pelo processo automatizado de NSSU. A sequência aproveita o design de alta disponibilidade para remover sistematicamente um dispositivo do serviço para realizar a atualização e reinicialização. Quando os nós do servidor são duplos abrigados 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. Existe 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 principal/backup para manter o estado do dispositivo sincronizado entre os membros do Virtual Chassis. Enquanto um dispositivo lida com o tráfego, tiramos o outro dispositivo e o atualizamos. Para atualizar ambos os dispositivos, tomamos as seguintes medidas:
Primeiro, mudamos todo o tráfego para o dispositivo principal.
Assim que o dispositivo de backup não estiver mais lidando com o tráfego do servidor, nós separamos o Virtual Chassis.
Com o dispositivo de backup completamente isolado, atualizamos o software no dispositivo de backup e o reinicializamos. O dispositivo de backup manterá uma cópia da configuração de rede original.
Depois que o backup atualizado chega on-line, mudamos o tráfego do servidor do dispositivo principal para o dispositivo de backup. Assim que o backup estiver lidando com a carga da rede, atualizamos e reinicializamos o dispositivo principal.
Depois que o dispositivo principal entra em operação, mudamos o tráfego de volta para o dispositivo principal.
Por fim, re-capacitamos os enlaces Virtual Chassis entre os dois dispositivos para recriar o par Virtual Chassis que executa a nova versão de 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. Como acontece, esta não é uma combinação suportada para o recurso NSSU, por isso 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.
Requisitos
Use esse 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 de versão do Junos OS. Recomendamos fortemente que ambos os membros do Virtual Chassis sejam a mesma plataforma, como neste exemplo.
Antes de começar:
-
Se o Virtual Chassis não for pré-provisionado, configure um membro para ser o mecanismo de roteamento principal e o outro como um mecanismo de roteamento de backup
-
Certifique-se de que o Virtual Chassis seja composto por dois membros
-
Configure o Virtual Chassis no modo Virtual Chassis (ou seja, não o 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 que executam o Junos OS Release 14.1X53-D49.1
-
Versão Junos OS 18.1R2.6
-
Servidor de teste executando Ubuntu Linux 16.04
Visão geral
A atualização entre as 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 utilizará as características de alta disponibilidade dos servidores modernos com conexões redundantes ao 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 interrupção mínima do tráfego. Para isso, separaremos o Virtual Chassis e atualizaremos os dispositivos membros como unidades independentes. Depois que os dispositivos forem atualizados, nós os reconectaremos e restabeleceremos o Virtual Chassis.
Topologia
Configuração
Procedimento
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 está 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 -
Envie 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 encena 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 a desativação da detecção de divisão sempre que você formar um Virtual Chassis com apenas dois membros. Se você não desativar a detecção de divisão, o dispositivo principal pode assumir uma função de placa de linha e parar os planos de controle e dados quando desativar o mecanismo de roteamento de backup mais tarde neste exemplo.
Desde que você iniciou este NCE com um Virtual Chassis totalmente configurado, essa opção já deve ser configurada. Se não for por qualquer motivo, configure-o agora.
user@qfx5100-a# set virtual-chassis no-split-detection
-
Desativar portas voltadas para servidor no mecanismo de roteamento de backup para minimizar a interrupção durante a troca.
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
-
Desativar 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 Junos 18.2 ou mais nova, você deve incluir a opção
force-host. Isso acontece porque tanto o sistema operacional de host quanto os binários Junos são atualizados e permanecem compatíveis.{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 simultaneamente as portas voltadas para o servidor no backup. Implemente a mesma configuração nos dispositivos de backup e principal para modificar qualquer configuração deixada de quando os dois dispositivos faziam parte do Virtual Chassis.
No QFX de backup, primeiro desabiibilize 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, re habilite as portas voltadas para o servidor no backup, excluindo a configuração anterior. Confirmar 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 Junos 18.2 ou mais nova, você deve incluir a opção
force-host. Isso acontece porque tanto o sistema operacional de host quanto os binários Junos são atualizados e permanecem compatíveis.{master:0} user@qfx5100-a> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Nota:
Siga esta etapa apenas se o chassi virtual eu não for pré-provisionado. Se o Chassi virtual for pré-provisionado, a eleição de membros é baseada no tempo de atividade do sistema, caso o mecanismo de roteamento primário não esteja pré-configurado.
-
Troque as portas voltadas para o servidor de volta para o dispositivo principal. Retreibilize as portas voltadas para o servidor no dispositivo principal para acelerar a convergência de LACP quando o Virtual Chassis voltar. Implemente a mesma configuração nos dispositivos de backup e principal para modificar qualquer configuração deixada de quando os dois dispositivos faziam parte do Virtual Chassis.
No QFX de backup, primeiro re habilite as portas voltadas para o servidor no dispositivo principal, 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, desativar as portas voltadas para o servidor no backup e comprometer 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
-
Re-habilite 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 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 principal do Mecanismo de Roteamento em0 para comunicar com o recém-atualizado Virtual Chassis.
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
Nota:Se você pretende adicionar mais dispositivos ao seu Virtual Chassis de dois membros, re habilite a detecção dividida.
Você atualizou seu Virtual Chassis de dois membros.
Conclusão
Virtual Chassis é um design de arquitetura importante para alta disponibilidade do data center. Agora você sabe como atualizar manualmente um Chassi Virtual 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 desejável.