Como migrar o SLES 15 SP5 para o SP6 sem interrupção do sistema

Você pode manter um aplicativo disponível durante a migração de um cluster SLES 15 SP5 para SP6, mas não é possível atualizar e reiniciar uma única instância do sistema operacional sem qualquer interrupção. A SUSE oferece suporte à migração de service packs do SP5 para o SP6, e o processo de migração online ainda requer a reinicialização do sistema. Para evitar tempo de inatividade do serviço, atualize um nó por vez em um cluster SUSE Linux Enterprise High Availability (SLE HA) compatível ou crie um ambiente SP6 substituto e redirecione o tráfego para ele. O serviço deve ter um ambiente íntegro para ser executado enquanto cada host estiver indisponível.

Este guia para iniciantes foca no processo de atualização gradual para um cluster SLE HA. Ele também explica o que fazer se você tiver apenas um servidor, o que verificar antes da alteração e como saber se o serviço permaneceu íntegro. Os comandos exatos e a ordem para migrar as cargas de trabalho dependem dos recursos do seu cluster, do armazenamento e da aplicação.

O que significa “sem tempo de inatividade do sistema”?

A migração de um pacote de serviços substitui os pacotes do sistema enquanto o sistema de origem está em execução. A SUSE chama isso de migração online. Ela reduz a necessidade de inicializar a partir da mídia de instalação, mas o procedimento oficial recomenda reiniciar o sistema após uma migração bem-sucedida. A migração online não é o mesmo que uma atualização em tempo real (live upgrade), que mantém o mesmo host em execução contínua, atendendo às solicitações.

Para um serviço em cluster, uma atualização gradual significa retirar um nó de serviço, migrá-lo e reiniciá-lo, devolvê-lo ao cluster e, em seguida, repetir o processo no próximo nó. O aplicativo pode permanecer disponível a partir de outro nó se o failover funcionar corretamente e a capacidade restante for suficiente. Um failover ainda pode causar uma breve interrupção nas sessões ativas; portanto, meça o serviço voltado para o usuário em vez de presumir que a "alta disponibilidade" garante que todas as conexões permaneçam intactas.

A SUSE lista o SLES 15 SP5 como uma fonte suportada para o SP6, tanto online quanto offline. O caminho suportado está documentado no guia de atualização do SLES 15 SP6 . A documentação do SUSE HA suporta uma atualização contínua do cluster entre service packs dentro da mesma versão principal. Consulte o guia de atualização do cluster SLES HA .

Escolha a abordagem correta antes de mudar qualquer coisa.

• Um servidor independente: agende uma janela de manutenção para a migração e reinicialização do host. Um balanceador de carga não consegue eliminar o tempo de inatividade se não houver uma segunda instância de aplicação íntegra.
• Dois ou mais nós SLE HA: considere o procedimento documentado de atualização gradual, após verificar quórum, isolamento, alocação de recursos, acesso ao armazenamento e capacidade ociosa.
• Aplicação com réplicas fora do SLE HA: atualize um host ou pool SP6 de substituição, valide-o e redirecione o tráfego gradualmente. Trata-se de uma implantação azul-verde ou contínua na camada de aplicação; é um processo distinto de uma migração in-place do SLES.
• Host gerenciado pelo SUSE Manager: siga o fluxo de trabalho de migração do cliente SUSE Manager. A SUSE recomenda não usar a migração online do YaST nem migrar zypper migrationdiretamente pelo cliente SUSE Manager.

Se o seu serviço for um banco de dados ou outro aplicativo com estado, trate a compatibilidade do aplicativo e a replicação de dados como um fluxo de trabalho separado. Um caminho de migração do sistema operacional não atualiza automaticamente o banco de dados nem comprova que seu projeto de replicação e failover é seguro.

Prepare o cluster e o plano de mudança.

1. Confirme as versões, o registro e a elegibilidade para atualização.

Verifique se todos os nós estão executando o SLES 15 SP5, com a extensão SLE HA e outros módulos ou produtos registrados conforme o esperado. A lista de destinos de migração depende dos produtos e extensões instalados. A ausência de um destino SP6 pode indicar um problema de registro, repositório ou disponibilidade de extensão; não tente forçar um caminho de repositório diferente apenas para que o destino apareça.

Para um sistema registrado, as seguintes verificações somente leitura podem ajudar a estabelecer seu estado:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper lr -u

Compare os produtos SLES e SLE HA instalados, os repositórios e a arquitetura em todos os nós. Se o host for gerenciado pelo SUSE Manager, use o procedimento de migração de cliente correspondente em vez das etapas diretas abaixo.

2. Aplique o patch, faça backup e teste.

A SUSE exige que o sistema de origem esteja com o patch mais recente antes da atualização. Aplique as atualizações de manutenção do SP5 e revise as notas de versão do SP6 para verificar alterações em pacotes, módulos e aplicativos. As instruções de preparação para atualização da SUSE também recomendam um backup atualizado e a revisão das notas de versão.

Faça backup da configuração do sistema e dos dados do aplicativo e verifique se o backup pode ser restaurado. Teste todo o procedimento em um cluster de teste que corresponda ao ambiente de produção, incluindo interfaces de rede, armazenamento, recursos do cluster, repositórios de terceiros e verificações de integridade do aplicativo. Registre quanto tempo a migração e a reinicialização levam em cada nó para que você possa estimar a janela de alteração.

3. Comprove que os nós restantes conseguem suportar a carga de trabalho.

Antes de remover um nó, confirme se o cluster está íntegro e se não há falhas de recursos não resolvidas. Verifique se outro nó consegue executar os serviços, montar ou acessar o armazenamento necessário e lidar com o tráfego esperado. Se a perda de um nó sobrecarregar a CPU, a memória, a rede ou o armazenamento, adicione capacidade, reduza a carga ou agende uma janela de manutenção em vez de afirmar que não haverá tempo de inatividade.

Certifique-se de que o isolamento de cluster esteja configurado e funcionando de acordo com o seu projeto de alta disponibilidade (HA) estabelecido. O isolamento protege os recursos compartilhados isolando um nó que não seja confiável; desativá-lo para facilitar uma atualização pode criar um risco de "split-brain" (cérebro dividido). Mantenha o acesso via console ou fora de banda disponível caso um nó não retorne após a reinicialização.

Execute uma atualização gradual, um nó por vez.

Utilize os passos abaixo como um guia de planejamento. Siga o procedimento específico para a sua versão de alta disponibilidade do SLE e configuração de recursos; não copie uma sequência de gerenciamento de recursos para um ambiente de produção sem antes aplicá-la.

1. Confirme a integridade do cluster. Capture o status atual e confirme se todos os nós e recursos estão íntegros. No SLE HA, crm statusessa é uma das maneiras documentadas de inspecionar o status do cluster.
2. Mova ou remova serviços do nó. Utilize o procedimento aprovado do seu cluster para alocar os recursos da aplicação em outro nó íntegro. Verifique o endpoint da aplicação e o armazenamento dependente antes de prosseguir.
3. Interrompa a pilha de cluster no nó que está sendo atualizado. As instruções de atualização contínua da SUSE alertam que manter o gerenciador de recursos do cluster ativo durante uma atualização de software pode causar problemas, como o isolamento de nós ativos. O comando documentado em nível de nó é crm cluster stop.
4. Execute a migração do pacote de serviços do SLES. Em um host registrado e não gerenciado pelo SUSE Manager, use o comando sudo zypper migration. Analise as alterações de destino e repositório do SP6 oferecidas. Leia as ações propostas para os pacotes, especialmente os pacotes a serem removidos ou rebaixados, antes de confirmar. As instruções oficiais de migração online do SLES descrevem esse caminho de linha de comando.
5. Reinicie e verifique o nó. Após a conclusão da migração, reinicie o host conforme as instruções da SUSE. Confirme se ele inicializa o SLES 15 SP6, se os produtos necessários estão registrados, se os repositórios correspondem ao pacote de serviços de destino e se o nó não apresenta erros críticos de sistema.
6. Retorne o nó ao cluster. Inicie a pilha de cluster usando o procedimento aprovado; o guia de alta disponibilidade do SLE mostra como fazer isso crm cluster start. Verifique crm statuscom o Hawk2 e confirme se o nó se reconecta sem falhas de recursos.
7. Repita o procedimento somente após o cluster estar estável. Transfira a carga de trabalho do próximo nó, remova esse nó do cluster, migre, reinicie, valide e reconecte-o. Não inicie o próximo nó enquanto o cluster restante estiver degradado ou executando mais trabalho do que pode suportar com segurança.

A SUSE afirma que nós de cluster com versões mistas são suportados apenas temporariamente durante a atualização gradual e que a atualização deve ser concluída em uma semana. Planeje uma sequência curta e controlada, em vez de deixar um cluster com versões mistas em funcionamento indefinidamente. Finalize confirmando se todos os nós estão executando o SP6, verificando a integridade do cluster e dos aplicativos e revisando os logs e o registro do repositório.

Problemas comuns e o que fazer

• Nenhuma opção de migração para o SP6 foi encontrada: verifique o registro, os repositórios ativos e se cada módulo ou extensão instalado possui uma opção de destino compatível com o SP6. Resolva problemas de repositório ou de direitos antes de começar.
• O solucionador propõe remoções inesperadas: interrompa e investigue as origens dos pacotes, repositórios de terceiros e dependências. A SUSE observa que repositórios locais ou de DVD obsoletos devem ser desativados para a migração. Não aceite um plano de pacotes que você não possa explicar.
• O nó atualizado não será reconectado: mantenha o aplicativo em nós íntegros, inspecione os logs do cluster e do sistema e verifique a rede do nó, o registro do produto, a configuração do repositório e os pacotes SLE HA antes de tentar novamente.
• O serviço está acessível, mas os usuários relatam erros: teste as transações do aplicativo, não apenas a disponibilidade do host. Valide as conexões com o banco de dados, o armazenamento compartilhado, a autenticação, as tarefas agendadas e quaisquer verificações de integridade do balanceador de carga.
• Um sistema de servidor único deve permanecer online: não existe um procedimento de migração de service pack do SLES que evite a reinicialização no mesmo host. Adicione uma segunda instância do aplicativo ou planeje um período de manutenção.

Como avaliar se o tempo de inatividade foi evitado

Defina uma condição de sucesso mensurável antes da alteração. Por exemplo: a verificação de integridade externa do serviço continua sendo aprovada durante a manutenção de cada nó, as taxas de erro permanecem dentro do limite acordado e uma transação de usuário representativa é bem-sucedida enquanto um nó está indisponível. Registre qualquer falha de failover, sessões interrompidas, trabalho em fila ou desempenho degradado. Se o endpoint permaneceu ativo, mas um fluxo de trabalho crítico falhou, a migração não atingiu a meta de nível de serviço.

Uma atualização gradual pode manter um serviço adequadamente projetado disponível enquanto servidores individuais são reinicializados. No entanto, ela não garante sessões ininterruptas, não compensa um cluster com capacidade insuficiente nem elimina a reinicialização de cada host migrado. Para implantações de nó único, aplicações com estado sem replicação testada ou clusters com extensões não suportadas, utilize uma janela de manutenção planejada ou crie e valide um ambiente de substituição antes de migrar o tráfego de produção.

Referências oficiais

• SUSE: Caminhos de atualização e migração suportados para o SLES 15 SP6
• SUSE: Preparando a atualização
• SUSE: Atualizando online com YaST ou Zypper
• SUSE: Atualização contínua do cluster SLE HA
• SUSE: Notas de lançamento do SLES 15 SP6