Resolva uma atualização de cluster paralisada causada por um nó secundário que para de responder durante a fase de reconstrução do RPMDB. O procedimento envolve dimensionar o cluster para um único nó atualizado e cloná-lo para restaurar o cluster.
Problema
Durante uma atualização de um cluster do Omnissa Access, um nó secundário para de funcionar e permanece sem resposta no estágio successfully rebuilt RPMDB. Não é possível estabelecer novas conexões SSH com o nó afetado. Outros nós do cluster podem ter concluído a atualização com sucesso.
Causa
Um problema de ambiente específico do nó durante o processo de recriação do banco de dados do RPM impede que a atualização seja concluída no nó afetado.
Solução
-
Crie um instantâneo de cada nó do cluster antes de realizar qualquer alteração.
Nota: se sua implantação usa um banco de dados externo, faça um backup do banco de dados antes de prosseguir.
-
Desligue o(s) nó(s) que não responde(m).
-
No nó em funcionamento, verifique se a atualização foi concluída com sucesso e crie um instantâneo do nó atualizado.
-
No vCenter, clone o nó atualizado uma vez para cada nó que você desligou.
-
Para cada nó clonado, abra as configurações da VM no vCenter e atualize o endereço MAC do adaptador de rede para corresponder ao endereço MAC do nó original que está sendo substituído.
-
Ligue o nó clonado e faça login como
root. -
Atualize o arquivo
/etc/hostscom o endereço IP e o nome do host corretos para este nó. -
Execute
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.confpara restaurar a configuração do resolvedor DNS. -
Edite o arquivo
/etc/systemd/network/10-eth0.networke defina o endereço IP para o endereço correto deste nó. -
Edite o arquivo
/etc/hostnamee substitua a entrada existente pelo nome de host correto para este nó. -
Reinicie o nó.
-
Verifique se o nó reconfigurado ingressou no cluster com sucesso e se todos os serviços do Omnissa Access estão em execução.
Nota: repita as etapas 5 a 12 para cada nó clonado adicional.
Esta página foi útil?