Mantenha os serviços disponíveis durante uma atualização do SLES 15 SP5 para SP6.

É difícil agendar uma janela de manutenção curta quando um servidor SLES executa um serviço voltado para o cliente. A SUSE oferece suporte à migração online de service packs do SLES 15 SP5 para o SP6, mas a máquina atualizada ainda precisa ser reinicializada; "online" não significa sem reinicialização. Para manter um aplicativo acessível, atualize os nós redundantes um de cada vez ou crie um substituto para o SP6 e redirecione o tráfego para ele. Um único servidor não consegue manter seu próprio sistema operacional disponível durante a reinicialização.

Cenário ilustrativo: Uma equipe fictícia executa um aplicativo web em três nós SLES 15 SP5 por trás de um balanceador de carga. O aplicativo pode atender solicitações dos outros dois nós enquanto um deles estiver em manutenção. A sequência abaixo mostra como essa equipe poderia migrar o cluster; trata-se de um exemplo, não de uma afirmação de que um teste foi realizado ou de que todos os clusters podem tolerar a indisponibilidade de um nó.

1. Escolha um caminho que corresponda ao serviço.

Para migrar do SLES 15 SP5 para o SP6, a SUSE documenta métodos de atualização online e offline. O método online utiliza a migração pelo YaST ou realiza a migração zypper migrationcom o sistema operacional em execução, exigindo, em seguida, a reinicialização do sistema após a migração. Alterações em pacotes também podem reiniciar serviços, portanto, a migração online por si só não garante a continuidade dos aplicativos.

Use o procedimento de atualização contínua de alta disponibilidade do SLE somente se sua carga de trabalho já estiver protegida por um cluster íntegro e com suporte. O cluster deve manter o quorum e capacidade suficiente para executar o serviço mesmo com um nó offline. Um balanceador de carga comum sem redundância de aplicação, ou um cluster de dois nós que perde o quorum quando um nó para, não é suficiente. Se o servidor for independente, use um host SP6 paralelo e uma migração de carga de trabalho/dados testada para manter a acessibilidade; caso contrário, agende um período de inatividade para a reinicialização.

2. Verifique o alvo e prepare um plano de recuperação.

Antes de acessar o cluster, verifique a versão inicial, o registro, os repositórios e as extensões suportadas. A SUSE lista o SLES 15 SP5 para SP6 como um caminho suportado. A migração online exige que a máquina esteja registrada no SUSE Customer Center ou em um servidor RMT local; os clientes do SUSE Manager devem usar o procedimento de migração do cliente Manager em vez de executá-lo zypper migrationdiretamente. O destino disponível pode depender dos produtos e extensões registrados.

A partir de 1º de janeiro de 2026, as informações de lançamento da SUSE indicam que o SLES 15 SP6 migrou para o LTSS. Confirme se sua assinatura e fonte de registro atualmente oferecem suporte ao SP6 antes de agendar essa migração específica. Caso não ofereçam, não force uma alteração no repositório para simular uma migração suportada.

Faça backup dos dados e da configuração do aplicativo usando o método compatível com o aplicativo e confirme se é possível restaurá-los. Consulte o guia de atualização de alta disponibilidade do SLE e as notas de versão do SP6 para suas extensões, bancos de dados, armazenamento e hardware. No cluster fictício, o operador também verifica o quorum, o isolamento de tráfego (fencing), a integridade da replicação, a capacidade ociosa, a integridade do balanceador de carga e uma maneira testada de redirecionar o tráfego de cada nó. Um snapshot pode auxiliar na reversão em configurações de raiz Btrfs compatíveis, mas não substitui os backups de aplicativos ou bancos de dados.

3. Atualize um nó drenado por vez.

Para cada nó, siga o procedimento de atualização gradual de alta disponibilidade do SLE e o manual de execução do seu cluster. Nunca atualize vários nós simultaneamente, a menos que o procedimento específico do produto permita isso explicitamente.

1. Confirme se os nós restantes conseguem atender à carga de trabalho. Verifique a integridade do aplicativo e o status do cluster. Mova ou direcione o tráfego do nó usando os controles documentados para seu balanceador de carga e recursos do cluster. Não prossiga se os nós restantes não conseguirem manter o quorum ou atender à capacidade mínima do serviço.
2. Pare o cluster nesse nó. A SUSE alerta que manter o gerenciador de recursos do cluster ativo durante a atualização do software pode causar o isolamento de nós ativos. No nó selecionado para manutenção, execute:

sudo crm cluster stop

3. Inicie a migração do pacote de serviços e inspecione a proposta. Execute o comando de migração Zypper documentado:

sudo zypper migration

Selecione o SLES 15 SP6 somente se ele aparecer como um destino disponível. Leia o repositório e o plano de pacotes, especialmente os pacotes propostos para remoção ou downgrade, e interrompa o processo se as alterações forem inesperadas. Não aceite um plano que você não tenha revisado. A lista exata de pacotes varia de acordo com o software instalado e as extensões registradas.

4. Reinicie o nó atualizado. Após o Zypper reportar uma migração bem-sucedida, reinicie a máquina para que ela inicialize o kernel e os serviços do SP6:

sudo reboot

5. Reconecte-se e verifique antes de passar para o próximo nó. Após o nó retornar, inicie sua pilha de cluster:

sudo crm cluster start
sudo crm status

Aguarde até que o cluster reporte que o nó foi adicionado e que os recursos estão íntegros. Em seguida, restaure-o para o serviço de acordo com o seu manual de procedimentos. Verifique o aplicativo de fora do cluster. Somente então repita o processo para o próximo nó. O SUSE permite versões mistas apenas brevemente durante uma atualização contínua e instrui os administradores a concluírem a atualização do cluster em até uma semana.

4. Verifique o serviço, não apenas o rótulo do sistema operacional.

Após a atualização de todos os nós, confirme a versão com `systemctl status` cat /etc/os-release, inspecione a integridade do cluster com ` crm statussystemctl status` e verifique as unidades systemd com falha com `systemctl status` systemctl --failed. Em seguida, teste o aplicativo em si por meio do endereço normal voltado para o cliente, incluindo as verificações de integridade, o acesso ao banco de dados ou armazenamento e quaisquer tarefas agendadas importantes para os usuários. Analise os logs de migração e confirme se os repositórios e extensões esperados estão ativos em todos os nós.

Uma migração bem-sucedida do sistema operacional não garante a compatibilidade de todas as dependências do aplicativo nem que nenhuma requisição tenha sido interrompida. Se o aplicativo não tolerar uma falha de nó, utilize uma implantação azul-verde com replicação de dados validada e troca controlada de endpoints, ou planeje uma janela de manutenção. Para obter informações precisas sobre as opções de comando e as condições de suporte, consulte o guia de atualização online do SLES 15 SP6 da SUSE , os caminhos de atualização suportados , o procedimento de atualização contínua de alta disponibilidade do SLES e as notas de versão do SUSE Multi-Linux Manager 5.1 para a nota de transição do ciclo de vida do SP6.