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
Etapa 2: implantar novo servidor Apstra
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.
Etapa 3: Estado de importação
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.
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.
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.
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.
Etapa 7: desativar o servidor Apstra antigo
- Atualize todas as entradas DNS para usar o novo IP/FQDN do servidor Apstra com base em sua configuração.
- Se você estiver usando um proxy para o servidor Apstra, certifique-se de que ele aponta para o novo servidor Apstra.
- 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ê. - 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.
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 .)