Atualização do nó para a 3.2

Um nó é atualizado com o script padrão vStack.update.sh. O script acompanha a distribuição e fica no nó em /root/bin/. Os nós são atualizados um de cada vez, e cada um é reinicializado após a atualização.

Esta página se destina aos nós das linhas 3.0.x e 3.1.x que estão passando para a 3.2.0. A passagem a partir da linha 2.x muda a versão principal do FreeBSD e é feita junto com o suporte técnico da vStack.

Execute todos os comandos como root no próprio nó.

Antes da janela

1. Acesso ao repositório. Os pacotes são obtidos do repositório da vStack, que aceita somente endereços da lista de permissões. Envie ao suporte técnico, com antecedência, os endereços a partir dos quais os nós acessam a rede externa. Sem isso, o script termina com o código 2.
2. Console do nó. Você precisa de acesso ao IPMI ou ao BMC caso o nó não volte pela rede.
3. A carga de trabalho foi retirada do nó. As VMs foram desligadas ou movidas, e os pools do nó foram passados para outros nós do cluster. Como fazer isso está descrito na seção "Mover os serviços de pool". Se no cluster houver VMs que também são executadas em nós que não detêm seu pool, o procedimento está descrito na seção "Liberar um nó com VMs iniciadas remotamente".
4. O horário está sincronizado em todos os nós. Verifique com ntpq -p: a fonte de horário deve estar acessível.
5. Foi feito um backup da configuração do nó. O procedimento está descrito na página "Backup da configuração do nó". O próprio script de atualização também faz uma cópia, mas a mantém no disco de sistema do nó e, em uma reinstalação, ela se perde junto com o disco.

Ordem de passagem pelo cluster

Atualize os nós estritamente um de cada vez. Passe para o próximo nó quando o anterior tiver voltado, tiver sido aceito pelo cluster e o resilver tiver terminado em todos os pools do cluster.

O resilver começa sozinho. Enquanto um nó reinicializa, os pools dos outros nós perdem os discos dele e, quando o nó volta, o ZFS atualiza as alterações neles. Se você reinicializar o próximo nó antes, um pool cuja sincronização ainda não terminou perderá um segundo disco. Um pool com redundância N+1 não sobrevive a isso.

Verifique em cada nó que detém pools:

zpool status | grep -E 'pool:|state:|scan:'

Você pode prosseguir quando todos os pools tiverem state: ONLINE e a linha scan: não contiver resilver in progress.

Mais duas regras durante a passagem:

• Um cluster com versões mistas é um estado de operação normal enquanto a passagem estiver em andamento.
• Não devolva um pool que já foi executado em um nó atualizado a um nó que não foi atualizado. Mantenha os pools nos nós atualizados até concluir a passagem.

cuidado

Não execute zpool upgrade nem durante a passagem nem depois dela. O script de atualização lembra disso no resumo final.

Passo 1. Atualize o próprio script

O script é lançado junto com o release e é assinado com a mesma chave dos pacotes. Pegue a versão da distribuição para a qual você está atualizando.

fetch -o /root/bin/vStack.update.sh https://repo.vstack.com/os/3.2.0/update.sh
fetch -o /tmp/update.sh.sig        https://repo.vstack.com/os/3.2.0/update.sh.sig
openssl dgst -sha256 \
  -verify /usr/share/keys/vstack/vstackos.pub \
  -signature /tmp/update.sh.sig /root/bin/vStack.update.sh
chmod 0755 /root/bin/vStack.update.sh

A verificação deve imprimir Verified OK. Se imprimir qualquer outra coisa, não inicie a atualização.

Passo 2. Execução de teste

Uma execução de teste não altera nada no nó. O script grava uma configuração temporária de repositório e mostra o plano do pkg.

/root/bin/vStack.update.sh --controllers --base \
  --source release --version 3.2.0 --dry-run

Certifique-se de que o repositório está acessível e de que o plano não tem remoções inesperadas de pacotes.

Passo 3. Atualização

/root/bin/vStack.update.sh --controllers --base \
  --source release --version 3.2.0

• --controllers atualiza os pacotes do nó, exceto o sistema base.
• --base atualiza o sistema base e o kernel. Uma reinicialização é obrigatória depois disso.

Não faz sentido reiniciar os controladores logo após a atualização se uma reinicialização vier em seguida. Você pode desativar isso com a opção --no-restart. A opção --reboot reinicializa o nó ao concluir. A lista completa de opções está na referência.

Antes da transação, o script faz uma cópia da configuração em /var/backups/etc-<ts>: /etc, /usr/local/etc e, no subdiretório boot, os arquivos /boot/loader.conf, /boot/loader.conf.local e /boot/device.hints. O vstack-env.conf é salvo separadamente. Após a atualização, o script restaura a partir da cópia as contas, as configurações de ssh, sysctl.conf, syslog.conf, hosts, ntp.conf, vstack-env.conf e os três arquivos de inicialização, ou seja, o perfil de ajuste do nó. Os outros arquivos da cópia não são restaurados por nome; compare-os manualmente, se necessário.

Passo 4. Verificações antes da reinicialização

1. O código de saída é 0. Investigue qualquer outro código antes de reinicializar; o significado dos códigos é dado abaixo.
2. O shell do root é executável. Caso contrário, após a reinicialização o sshd não deixará o root entrar no nó.

   pw usershow root | awk -F: '{ print $NF }'   # shell path
   ls -l $(pw usershow root | awk -F: '{ print $NF }')

3. A proteção de inicialização está armada.

   cat /boot/nextboot.conf                         # one-time boot of the new kernel
   cat /boot/loader.conf.d/zz-vstack-fallback.conf # default boot for the duration of the window: the previous kernel

   Olhe especificamente os arquivos. A linha boot summary no log imprime os nomes dos kernels com um sufixo _prev a mais e induz ao erro. Na realidade, o novo kernel inicializa uma única vez, e a reversão vai para o anterior.
4. Resumo da execução. Ele fica armazenado em /var/backups/update-summary-<ts>.txt, ao lado dos arquivos versions-before-*.txt e versions-after-*.txt. O log completo é gravado em /var/log/vstack-os-update-<ts>.log.

O bootloader é atualizado em apenas um disco de sistema

O script copia o novo loader.efi para a partição EFI a partir da qual o nó está inicializado no momento. A partição EFI do segundo disco de sistema mantém o bootloader antigo. Se, após a atualização, o firmware inicializar o nó a partir do segundo disco, o novo kernel será carregado pelo bootloader antigo.

Por isso, não altere a ordem de inicialização no firmware durante a janela e leve isso em conta ao substituir um disco de sistema.

Passo 5. Reinicialização e aceitação

reboot

Se o novo kernel não conseguir inicializar, a próxima reinicialização sobe o nó com o anterior. Um nó que trava no prompt do bootloader não reinicializa sozinho: reinicie-o pelo console do IPMI ou do BMC.

Depois que o nó subir:

uname -r                       # base of the target line
cat /etc/os-release            # VERSION_ID = 3.2.0
pkg query '%n %v' | grep -i vstack
pkg check -d -a                # dependencies are consistent
ls /boot/nextboot.conf /boot/loader.conf.d/zz-vstack-fallback.conf 2>&1

O último comando deve informar que os arquivos não existem. Após uma inicialização bem-sucedida, o próprio nó remove a inicialização única e a reversão temporária. Se os arquivos permanecerem, o nó não subiu com o kernel de destino. Encontre a causa antes de devolver a carga de trabalho.

Em seguida, verifique os serviços do nó (service <name> status) e o estado do nó no cluster, aguarde o resilver terminar em todos os pools e devolva a carga de trabalho. Os próprios pools não voltam para o nó que retornou; mova-os manualmente.

Mover os serviços de pool

Durante a janela, você precisa mover pools duas vezes: retirar os pools do nó antes do trabalho e devolvê-los depois.

A forma usual é a interface do vStack Center, a seção "Serviços do cluster".

A exceção é o pool no qual a VM de gerenciamento (vStack Center) é executada. Ele não pode ser movido pela interface. Uma movimentação começa suspendendo as VMs do pool, e a própria VM de gerenciamento está entre elas: o Center se desliga no meio da operação, e a movimentação é interrompida. Esse pool é movido com o utilitário do cluster em um nó.

A VM de gerenciamento geralmente fica no primeiro pool do cluster, z01. Você pode verificar isso pela VM com o número 0:

vstack-vm vm list

Mover com o utilitário do cluster

Este método é necessário para o pool com a VM de gerenciamento e para clusters sem Center. Os comandos são executados a partir de qualquer nó do cluster.

No cluster, um pool é representado pelo serviço zpool_<pool name>: o pool z01 corresponde ao serviço zpool_z01. Os comandos recebem o nome do serviço, não o nome do pool. Os nomes dos serviços e os números dos nós são exibidos por vstack-cluster status:

vstack-cluster status

Node ID:  1; name:   q100u001.example.com; state:       ONLINE; [     enabled]
	Service name:       cluster-management; state:    STARTED; [     enabled]
	Service name:                zpool_z01; state:    STARTED; [     enabled]

Node ID:  2; name:   q100u002.example.com; state:       ONLINE; [     enabled]
	Service name:                zpool_z02; state:    STARTED; [     enabled]
...

Mover o pool z01 para o nó 2:

vstack-cluster service move -s zpool_z01 --dst-id=2

O nó de destino deve estar ONLINE e aberto (enabled). O comando é descrito em detalhes na referência.

Enquanto o pool é movido, as VMs do pool são desligadas, e o fornecimento dos seus volumes é interrompido. Trata-se de uma janela de manutenção, não de uma operação transparente.

Liberar um nó com VMs iniciadas remotamente

Uma VM pode ser executada em um nó diferente do dono do seu pool: nesse caso, seus discos são entregues por NVMe-oF/TCP. Na saída de vstack-vm vm list, essas VMs são marcadas com a palavra remote. Antes de uma atualização, o nó é liberado das VMs dos seus pools e das VMs que são executadas nele com discos de pools de outros nós.

Pare e inicie as VMs pelo vStack Center.

1. Mova os pools do nó conforme descrito na seção "Mover os serviços de pool". Pare as VMs desses pools que são executadas em outros nós antes da movimentação e inicie-as novamente depois da movimentação. Você pode encontrá-las em qualquer nó do cluster:

   vstack-vm vm list | grep -w remote | grep -w <pool>

2. Retire as VMs restantes do nó. Encontre-as no próprio nó:

   vstack-vm vm list | grep -w remote

   Pare cada uma e inicie-a com a ação "Start on node", selecionando um nó diferente. Depois certifique-se de que não restaram VMs no nó:

   ls /dev/vmm

   A resposta No such file or directory significa que não há VMs no nó.

3. Feche o nó para o posicionamento de VMs e verifique se o seu status é DISABLED:

   vstack-cluster node disable --id=<N>
   vstack-cluster node status

   Se o utilitário vstack-cluster não estiver no nó, as mesmas ações são realizadas por ccrd_cli --node --node_id <N> --command disable e ccrd_cli --node --command status.

   Após fechar o nó, execute ls /dev/vmm novamente. Se VMs tiverem aparecido no nó, retire-as como no passo 2.

   cuidado

   Durante o trabalho, não inicie nem mova VMs para o nó fechado. Mantenha no máximo um nó fechado.

4. Atualize o nó seguindo os passos 1–5 desta página.

5. Abra o nó após a aceitação:

   vstack-cluster node enable --id=<N>

   Sem o utilitário vstack-cluster: ccrd_cli --node --node_id <N> --command enable. Depois devolva os pools, se necessário. As VMs não voltam para o nó sozinhas.

Códigos de saída

Código	Significado
0	a atualização foi concluída
1	um erro nos argumentos
2	a origem ou a versão não está disponível, a chave de assinatura não foi obtida, ou foi solicitada uma passagem entre versões principais sem --allow-major-upgrade
3	um erro do pkg ou um erro na verificação do novo kernel
4	falha ao salvar ou restaurar a configuração (/etc, /usr/local/etc, arquivos de inicialização)
5	um serviço instalado não reiniciou
6	a atualização foi concluída, mas o shell do root não é executável. Corrija antes de reinicializar
7	a atualização foi concluída, mas a gravação em /boot não foi confirmada. Não reinicialize até investigar

Com os códigos 6 e 7, o script ignora --reboot intencionalmente.

Reversão

O script não reverte pacotes. Você pode voltar da seguinte forma:

• Inicialização. O kernel anterior permanece no nó e fica disponível no menu do bootloader até que a janela de atualização seja fechada por uma inicialização bem-sucedida.
• Configuração. A cópia fica armazenada em /var/backups/etc-<ts>; as cinco mais recentes são mantidas.
• O sistema inteiro. Reinstale a partir da mídia da versão de destino ou restaure a partir de um backup do nó feito antes do trabalho.

O script não salva dados dos pools, discos de VMs nem configurações além do que está listado no passo 3. Faça você mesmo uma cópia deles antes da janela; consulte "Backup da configuração do nó".