Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Atualize o Apstra em Novo VM (VM-VM) (Recomendado)

Recomendamos que você atualize o Apstra em um novo VM (em vez de colocar no mesmo VM) para que você receba correções do Ubuntu Linux OS, incluindo atualizações de vulnerabilidades de segurança. Para atualizar o servidor Apstra, você precisa de privilégios de usuário administrador do Apstra OS e permissões de grupo de usuários administradores do Apstra.

Etapa 1: Validação pré-upgrade

  1. Consulte caminhos de atualização para confirmar que você está atualizando para uma versão suportada. (Você pode encontrar sua versão apstra atual navegando para a Plataforma > Sobre na GUI do Apstra. A partir da versão 4.2.1 do Apstra, a versão Apstra também é mostrada no menu de navegação à esquerda da GUI sob o logotipo do Juniper Apstra.)
  2. Faça login no servidor Apstra como administrador (por exemplo, se o seu endereço IP do servidor Apstra fosse 10.28.105.3, o comando seria ssh admin@10.28.105.3).
  3. Execute o comando service aos status para verificar se o servidor está ativo e não tem problemas.
  4. Verifique as novas notas de versão da versão do Apstra para obter mudanças na renderização de configuração que possam afetar o plano de dados.
  5. Analise cada blueprint para confirmar que toda a Configuração de Serviços está no estado BEM SUCEDIDO. Se necessário, inimplante e remova dispositivos do blueprint para resolver qualquer configuração de serviço pendente ou falha.
  6. Analise cada blueprint para obter anomalias de sondagem e resolva-as o máximo possível. Tome notas de quaisquer anomalias restantes.
  7. Consulte o Guia do usuário do Apstra (referências > dispositivos > dispositivos qualificados e versões NOS) para verificar se os modelos de dispositivo e as versões NOS estão qualificados na nova versão do Apstra. Atualize ou rebaixe conforme necessário para uma das versões suportadas. (A partir da versão 4.2.0 do Apstra, o Apstra depreciou o EX4300s. A partir da versão 4.2.1 do Apstra, se o EX4300s estiver presente em blueprints ativos, a atualização será bloqueada.)
  8. Se você estiver usando dispositivos Junos e atualizando para a versão 4.2.1 do Apstra, a configuração perfeita deve incluir o essencial mgmt_junos VRF. Consulte o artigo da Base de conhecimento de suporte da Juniper KB77094 para obter mais informações.
    CUIDADO:

    Se a configuração intocada não incluir o mgmt_junos VRF, a implantação falhará.
  9. Remova qualquer configuração AAA do dispositivo. Durante a atualização do dispositivo, as credenciais do agente de dispositivo configurado são necessárias para o acesso ao SSH.
  10. Remova quaisquer configlets usados para configurar firewalls. Se você usar os filtros do mecanismo de roteamento da FW em dispositivos, você precisará atualizá-los para incluir o endereço IP do novo controlador e VMs do trabalhador.
  11. Para atualizar os agentes do sistema de dispositivos, o Apstra deve ser capaz de SSH para todos os dispositivos usando as credenciais que foram configuradas ao criar os agentes. Para verificar isso na GUI do Apstra, navegar até dispositivos > Agentes, selecionar a caixa de verificação (es) para verificar o(s) dispositivo(s) para verificar e, em seguida, clicar no botão Verificar no menu Agente. Verifique se os estados de todos os empregos são SUCESSO. Se algum trabalho de verificação falhar, resolva o problema antes de prosseguir com a atualização do Apstra.
  12. Como usuário raiz, execute o comando sudo aos_backup para fazer backup do servidor Apstra.
    CUIDADO:

    O servidor Apstra atualizado não inclui revisões de time voyager, portanto, se você precisar reverter para um estado passado, esse backup é necessário. Os estados anteriores não estão incluídos devido ao acoplamento apertado com os designs de referência que podem mudar entre as versões do Apstra.
  13. Copie os arquivos de backup de /var/lib/aos/snapshot/<shapshot_name> um local externo.
  14. Certifique-se de que o novo VM tenha os recursos de servidor necessários para o servidor Apstra.

Etapa 2: implantar novo servidor Apstra

Nota:

Se você personalizou o /etc/aos/aos.conf arquivo no servidor Apstra antigo (por exemplo, se você atualizou o metadb campo para usar uma interface de rede diferente), você deve novamente aplicar as alterações no mesmo arquivo no novo VM do servidor Apstra. Ela não é migrada automaticamente.
  1. Como usuário de suporte registrado, baixe a imagem de VM do Apstra dos Downloads de suporte da Juniper (for example, aos_server_4.1.2-269) e transfira-a para o novo servidor Apstra.
  2. Instale e configure a nova imagem de VM do Apstra com o novo endereço IP (o mesmo ou novo FQDN pode ser usado).
  3. Se você estiver usando um cluster Apstra (agentes de offbox, sondas IBA) e reutilizar suas VMs profissionais, instale o novo software em execuçãosudo bash aos_<aos_version>.run. Se você estiver usando novas VMs de trabalhadores, pule essa etapa.
    Nota:

    Exemplo de substituição de todos os VMs: se você tiver um controlador e 2 nós de trabalhador e quiser atualizar todos eles para novos VMs, você criaria 3 VMs com a nova versão do Apstra e designaria um deles para ser o controlador.
  4. Verifique se o novo servidor Apstra tem acesso SSH ao antigo servidor Apstra.
  5. Verifique se o novo servidor Apstra pode alcançar agentes do sistema. (Veja portas de comminicação necessárias.)
  6. Verifique se o novo servidor Apstra pode alcançar sistemas externos aplicáveis (como NTP, DNS, servidor vSphere, servidor LDAP/TACACs+ e assim por diante).

Etapa 3: Estado de importação

CUIDADO:

Se você realizar alguma operação de gravação de API/GUI no antigo servidor Apstra depois de começar a importar o novo VM, essas alterações não serão copiadas para o novo servidor Apstra.
  1. Faça login no novo servidor Apstra como administrador do usuário.
  2. Execute o sudo aos_import_state comando para importar SysDB do servidor antigo, aplicar as tradução necessárias e a configuração de importação. Inclua os seguintes argumentos, conforme aplicável:
    • --ip-address <old-apstra-server-ip>
    • --username <admin-username>
    • Para clusters Apstra com novos endereços IP de nós do trabalhador, inclua o seguinte: --cluster-node-address-mapping <old-node-ip> <new-node-ip>

    • Para executar as verificações de pré-condições de atualização sem executar a atualização real, use o seguinte:--dry-run-connectivity-validation

    • Para não verificar a validação da conectividade, inclua o seguinte: --skip-connectivity-validation

    • Se as credenciais de SSH em sua versão apstra mais antiga não forem tão rigorosas quanto os requisitos para a nova versão do Apstra, então você precisa adicionar o --override-cluster-node-credentials argumento ao comando ao aos_import_state importar seu banco de dados para a nova versão do Apstra. Caso contrário, a atualização falhará.

    Comando de exemplo: Cluster único de VM ou Apstra com nós do mesmo trabalhador

    Comando de exemplo: Cluster Apstra com novos nós trabalhadores

    No exemplo acima, 10.28.105.4 e 10.28.105.7 são endereços IP de nós do trabalhador antigos; 10.28.105.6 e 10.28.105.8 são novos endereços IP de nós do trabalhador.

    O Root é necessário para a importação do banco de dados, para que você seja solicitado a senha SSH e a senha raiz para o Apstra VM remoto.

    Nota:

    Quando você atualiza um cluster Apstra, a senha SSH para controlador antigo, trabalhador antigo e novo trabalhador deve ser idêntica, caso contrário a atualização falha na autenticação. No exemplo acima, a senha que você digita para 'senha SSH para VM remoto' é usada para controlador remoto, trabalhador antigo e VMs novos trabalhadores. (AOS-27351)

    Se você alterar a senha SSH dos VMs do trabalhador após a atualização, você também precisa atualizar a senha do trabalhador na GUI do Apstra (Plataforma > Cluster Apstra > Nós).
    Nota:

    O tamanho do blueprint e os recursos de VM do servidor Apstra determinam quanto tempo leva para concluir a importação. Se a importação do banco de dados exceder o valor padrão, a operação pode "perder tempo". (O valor padrão do Apstra 4.1.2 é de 40 minutos ou 2400 segundos). Se isso acontecer, você pode aumentar o valor de tempo limite com o AOS_UPGRADE_DOCKER_EXEC_TIMEOUT comando.

    Por exemplo, o comando a seguir aumenta o tempo antes do intervalo para 2 horas (7200 segundos).

    admin@aos-server:~$ sudo AOS_UPGRADE_DOCKER_EXEC_TIMEOUT=7200 aos_import_state --ip-address 10.10.10.10 --username admin

    O script de atualização apresenta uma visão resumida dos dispositivos dentro da malha que receberão mudanças de configuração durante a atualização. A partir da versão 4.1.2 do Apstra, um aviso aparece na tela recomendando que você leia Notas de versão e documentação dos caminhos de atualização antes de prosseguir. As notas de versão incluem uma categoria para mudanças de renderização de configuração, a partir da versão 4.1.2 do Apstra. As mudanças de renderização de configuração estão claramente documentadas no topo explicando o impacto de cada mudança na rede.

    A partir da versão 4.0.1 do Apstra, o Resumo de atualização do Apstra mostra informações separadas por funções de dispositivo (superspina, spine, leaf, par leaf e switch de acesso, por exemplo). Se uma configuração incremental foi aplicada em vez de uma configuração completa, mais detalhes serão exibidos sobre as mudanças.

  3. Depois de revisar o resumo, entre q para sair do resumo. A atualização do AOS: o menu interativo aparece onde você pode revisar a mudança exata de configuração em cada dispositivo. Se você estiver usando configurações, verifique se a nova configuração empurrada pela atualização não entra em conflito com nenhuma configuração existente.
    CUIDADO:

    O design de referência do Apstra na nova versão do Apstra pode ter mudado de uma maneira que invalida configlets. Para evitar resultados inesperados, verifique se suas configurações não estão em conflito com a configuração recém-renderizada. Se você precisar atualizar suas configurações, deixar a atualização, atualizar suas configurações e então executar o upgrade novamente.
  4. Se você quiser continuar com a atualização após revisar as alterações pendentes, entre em .c
  5. Se você quiser interromper a atualização, entre q para interromper o processo. Se você desistir neste momento e depois decidir atualizar, você deve iniciar o processo desde o início.
    Nota:

    Se a atualização do Apstra falhar (ou no caso de algum outro mau funcionamento) você poderá desligar graciosamente o novo servidor Apstra e reiniciá-lo novamente no servidor Apstra antigo para continuar as operações.

Passo 4: Mantenha o endereço IP do antigo VM (opcional)

Se você quiser manter o endereço IP do VM antigo, você deve executar as seguintes etapas extras antes de alterar o Modo de Operação e atualizar o agente dos dispositivos.

  1. Encerre o VM antigo ou altere seu endereço IP para um endereço diferente para liberar o endereço IP. Isso é necessário para evitar qualquer problema de endereço IP duplicado.
  2. Acesse o novo menu interativo apstra da VM da CLI.
  3. Clique em Rede para atualizar o endereço IP e confirmar os outros parâmetros.
  4. Para que o novo endereço IP entre em vigor, reinicie o serviço de rede, seja do mesmo menu antes de sair ou da CLI após deixar o menu.

Etapa 5: mude o modo de operação para normal

Quando você inicia uma atualização do servidor Apstra, o modo de operação muda do normal para a manutenção automaticamente. O modo de manutenção impede que qualquer agente offbox entre em operação prematuramente. Nenhuma configuração é empurrada e nenhuma telemetria é puxada. Neste ponto, se você decidir continuar usando a versão anterior do Apstra em vez de atualizar, você pode simplesmente desligar o novo servidor Apstra. Se você decidir concluir a atualização, altere o modo de volta ao Normal.

  1. Faça login na GUI do Apstra.
  2. Se você quiser ver alterações pendentes na configuração do serviço, navegue até o painel do blueprint e clique em PENDING para ver os dispositivos afetados.
  3. Do menu de navegação à esquerda, navegue até a plataforma > Cluster Apstra > gerenciamento de clusters.
  4. Clique no botão Alterar o modo de operação, selecionar Normal e clicar em Atualizar. Quaisquer agentes de offbox, sejam eles no controlador ou VMs do trabalhador, automaticamente ficam on-line e reconectam dispositivos e empurram quaisquer mudanças de configuração pendentes. Após alguns momentos, as anomalias temporárias na resolução do painel e a seção de configuração de serviços mostram que a operação teve sucesso.

    Você também pode acessar a página de gerenciamento de clusters na seção inferior esquerda de qualquer página. Você também tem visibilidade contínua de integridade da plataforma a partir daqui, com base nas cores.

    Na parte inferior do menu de navegação esquerdo, clique em um dos ponto e clique no Modo de operação para acessar o gerenciamento de clusters. Clique no botão Alterar o modo de operação , selecionar Normal e clicar em Atualizar.

Etapa 6: atualize agentes onbox

O servidor Apstra e os agentes onbox devem estar executando a mesma versão do Apstra. Se as versões forem diferentes, os agentes não se conectarão ao servidor Apstra.

Se você estiver executando um blueprint de vários estados, especialmente de 5 estágios, recomendamos que você atualize agentes em etapas: primeiro atualize superespínias, depois spines e leafs. Recomendamos essa ordem por causa da caça ao caminho. Em vez de rotear tudo até uma spine, ou de uma spine para uma supersseba, é possível que o roteamento vá temporariamente de leaf para spine de volta para outra folha e de volta para outra spine. Para minimizar as chances disso acontecer, recomendamos atualizar dispositivos em etapas.

  1. Faça login na GUI do Apstra como administrador do usuário.
  2. Do menu de navegação à esquerda, navegue até dispositivos > dispositivos gerenciados e selecione as caixas de verificação para o(s) dispositivo(s) para atualizar (até 100 dispositivos de cada vez). Você pode atualizar vários agentes de caixa ao mesmo tempo, mas a ordem de atualização do dispositivo é importante.
    • Atualize os agentes para superspinos primeiro.
    • Atualize agentes para spines em segundo lugar.
    • Atualize agentes para o leafs em terceiro lugar.
    Ao selecionar um ou mais dispositivos, os menus de Dispositivo e Agente aparecem acima da tabela.
  3. Clique no botão Instalar para iniciar o processo de instalação.
    O estado do trabalho muda para IN PROGRESS. Se os agentes estiverem usando uma versão anterior do software Apstra, eles serão atualizados automaticamente para a nova versão. Em seguida, eles se conectam ao servidor e empurram qualquer alteração de configuração pendente para os dispositivos. A telemetria também é reiniciada, e os estados de trabalho mudam para O SUCESSO.
  4. Na seção Liveness do painel de modelos, confirme que não há anomalias no dispositivo.
    Nota:

    Se você precisar voltar para a versão anterior do Apstra após iniciar a atualização do agente, você deve construir uma nova VM com a versão anterior do Apstra e restaurar a configuração dessa VM. Para obter assistência, entre em contato com o Suporte Técnico da Juniper.

Etapa 7: desativar o servidor Apstra antigo

  1. Atualize todas as entradas DNS para usar o novo IP/FQDN do servidor Apstra com base em sua configuração.
  2. Se você estiver usando um proxy para o servidor Apstra, certifique-se de que ele aponta para o novo servidor Apstra.
  3. Desativar graciosamente o antigo servidor Apstra. A partir da versão 4.2.1 do Apstra, você terá sido perguntado se deseja que o servidor Apstra antigo seja desativado; se você respondeu que sim, o service aos stop comando é executado automaticamente para desligar o servidor Apstra antigo para você.
  4. Se você estiver atualizando um cluster Apstra e substituindo seus nós de trabalhador por novas VMs, desativar também as VMs antigas do trabalhador.
Próximas etapas:

Se as versões NOS de seus dispositivos não forem qualificadas na nova versão do Apstra, atualize-as para uma versão qualificada. (Veja detalhes no Guia do usuário do Juniper Apstra .)