Actualización del nodo a 3.2

El nodo se actualiza con el script estándar vStack.update.sh. El script se incluye en la distribución y se encuentra en el nodo en /root/bin/. Los nodos se actualizan de uno en uno, y cada uno se reinicia después de la actualización.

Esta página está pensada para los nodos de las líneas 3.0.x y 3.1.x que migran a 3.2.0. La migración desde la línea 2.x cambia la versión mayor de FreeBSD y se realiza junto con el soporte técnico de vStack.

Todos los comandos se ejecutan como root en el propio nodo.

Antes de la ventana

1. Acceso al repositorio. Los paquetes se obtienen del repositorio de vStack, que solo admite direcciones de la lista de autorizadas. Envíe con antelación al soporte técnico las direcciones desde las que los nodos salen al exterior. Sin esto, el script terminará con el código 2.
2. Consola del nodo. Se necesita acceso a IPMI o BMC por si el nodo no vuelve a estar accesible por la red.
3. La carga se ha retirado del nodo. Las VM están apagadas o trasladadas, y los pools del nodo se han cedido a otros nodos del clúster. Cómo hacerlo se describe en la sección «Conmutación de los servicios del pool». Si en el clúster hay VM que se ejecutan en nodos que no tienen su pool, el procedimiento se describe en la sección «Liberación de un nodo con VM ejecutadas remotamente».
4. La hora está sincronizada en todos los nodos. Compruebe ntpq -p: la fuente de tiempo debe estar accesible.
5. Se ha hecho una copia de la configuración del nodo. El procedimiento se describe en la página «Copia de seguridad de la configuración del nodo». El propio script de actualización también hace una copia, pero la guarda en el disco del sistema del nodo, y en una reinstalación se perderá con él.

Orden de recorrido del clúster

Los nodos se actualizan estrictamente de uno en uno. Pase al siguiente nodo cuando el anterior haya vuelto, haya sido aceptado por el clúster y haya terminado el resilver en todos los pools del clúster.

El resilver comienza por sí solo. Mientras el nodo se reinicia, los pools de los demás nodos pierden sus discos, y cuando el nodo vuelve, ZFS pone al día los cambios en ellos. Si reinicia el siguiente nodo antes de tiempo, un pool cuya sincronización aún no haya terminado perderá un segundo disco. Un pool con redundancia N+1 no lo soporta.

Comprobación en cada nodo que tiene pools:

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

Puede continuar cuando todos los pools tengan state: ONLINE y en la línea scan: no aparezca resilver in progress.

Dos reglas más durante el recorrido:

• Un clúster con versiones mixtas es un estado de funcionamiento normal mientras dura el recorrido.
• No devuelva a un nodo sin actualizar un pool que ya ha funcionado en un nodo actualizado. Mantenga los pools en los nodos ya actualizados hasta terminar el recorrido.

precaución

No ejecute zpool upgrade ni durante el recorrido ni después. El script de actualización lo recuerda en el resumen final.

Paso 1. Actualizar el propio script

El script se publica junto con la versión y está firmado con la misma clave que los paquetes. Use la versión de la distribución a la que va a actualizar.

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

La comprobación debe mostrar Verified OK. Si muestra cualquier otra cosa, no inicie la actualización.

Paso 2. Ejecución de prueba

La ejecución de prueba no modifica nada en el nodo. El script escribe una configuración temporal del repositorio y muestra el plan de pkg.

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

Asegúrese de que el repositorio está accesible y de que el plan no incluye eliminaciones inesperadas de paquetes.

Paso 3. Actualización

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

• --controllers actualiza los paquetes del nodo, excepto el sistema base.
• --base actualiza el sistema base y el kernel. Después es obligatorio reiniciar.

No tiene sentido reiniciar los controladores justo después de la actualización si a continuación viene un reinicio. Esto puede desactivarse con la opción --no-restart. La opción --reboot reinicia el nodo al finalizar. La lista completa de opciones está en la referencia.

Antes de la transacción, el script hace una copia de la configuración en /var/backups/etc-<ts>: /etc, /usr/local/etc y, en el subdirectorio boot, los archivos /boot/loader.conf, /boot/loader.conf.local y /boot/device.hints. vstack-env.conf se guarda por separado. Después de la actualización, el script restaura desde la copia las cuentas de usuario, la configuración de ssh, sysctl.conf, syslog.conf, hosts, ntp.conf, vstack-env.conf y los tres archivos de arranque, es decir, el perfil de ajuste del nodo. El resto de los archivos de la copia no se restauran individualmente; si es necesario, se comparan manualmente.

Paso 4. Comprobaciones antes del reinicio

1. El código de salida es 0. Analice cualquier otro código antes de reiniciar; el significado de los códigos se indica más abajo.
2. El shell de root es ejecutable. De lo contrario, después del reinicio sshd no permitirá el acceso de root al nodo.

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

3. La protección de arranque está activada.

   cat /boot/nextboot.conf                         # arranque único del nuevo kernel
   cat /boot/loader.conf.d/zz-vstack-fallback.conf # arranque predeterminado durante la ventana: el kernel anterior

   Revise precisamente los archivos. La línea boot summary del registro muestra los nombres de los kernels con un sufijo _prev sobrante y resulta confusa. En realidad, se arranca una vez el nuevo kernel, y la reversión se hace al anterior.
4. Resumen de la ejecución. Se encuentra en /var/backups/update-summary-<ts>.txt, junto a los archivos versions-before-*.txt y versions-after-*.txt. El registro completo se escribe en /var/log/vstack-os-update-<ts>.log.

El cargador de arranque se actualiza solo en un disco del sistema

El script copia el nuevo loader.efi en la partición EFI desde la que ha arrancado el nodo actualmente. La partición EFI del segundo disco del sistema conserva el cargador antiguo. Si después de la actualización el firmware arranca el nodo desde el segundo disco, el nuevo kernel será cargado por el cargador antiguo.

Por eso, no cambie el orden de arranque en el firmware durante la ventana y téngalo en cuenta al sustituir un disco del sistema.

Paso 5. Reinicio y validación

reboot

Si el nuevo kernel no arranca, el siguiente reinicio levantará el nodo con el anterior. Un nodo que se ha quedado bloqueado en el prompt del cargador no se reiniciará por sí solo: reinícielo desde la consola IPMI o BMC.

Después del arranque:

uname -r                       # base de la línea de destino
cat /etc/os-release            # VERSION_ID = 3.2.0
pkg query '%n %v' | grep -i vstack
pkg check -d -a                # las dependencias están íntegras
ls /boot/nextboot.conf /boot/loader.conf.d/zz-vstack-fallback.conf 2>&1

El último comando debe indicar que los archivos no existen. Tras un arranque correcto, el nodo elimina por sí mismo el arranque único y la reversión temporal. Si los archivos siguen ahí, el nodo no ha arrancado con el kernel de destino. Averigüe la causa antes de devolver la carga.

A continuación, compruebe los servicios del nodo (service <nombre> status) y su estado en el clúster, espere a que termine el resilver en todos los pools y devuelva la carga. Los propios pools no vuelven por sí solos al nodo que ha regresado; se conmutan manualmente.

Conmutación de los servicios del pool

Durante la ventana, la conmutación se necesita dos veces: para retirar los pools del nodo antes de los trabajos y para devolverlos después.

La vía habitual es la interfaz de vStack Center, sección «Servicios del clúster».

La excepción es el pool en el que se ejecuta la VM de gestión (vStack Center). No se puede conmutar desde la interfaz. La conmutación empieza suspendiendo las VM del pool, y entre ellas está la propia VM de gestión: Center se apaga a sí mismo en mitad de la operación, y la conmutación se interrumpe. Ese pool se conmuta con la utilidad del clúster en el nodo.

Normalmente la VM de gestión reside en el primer pool del clúster, z01. Puede comprobarse por la VM con el número 0:

vstack-vm vm list

Conmutación con la utilidad del clúster

Este método es necesario para el pool con la VM de gestión y para los clústeres sin Center. Los comandos se ejecutan desde cualquier nodo del clúster.

En el clúster, el pool está representado por el servicio zpool_<nombre del pool>: al pool z01 le corresponde el servicio zpool_z01. En los comandos se indica el nombre del servicio, no el nombre del pool. Los nombres de los servicios y los números de los nodos los muestra 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]
...

Conmutación del pool z01 al nodo 2:

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

El nodo de destino debe estar en ONLINE y abierto (enabled). El comando se describe en detalle en la referencia.

Mientras el pool se conmuta, las VM del pool se apagan y se interrumpe el aprovisionamiento de sus volúmenes. Es una ventana de mantenimiento, no una operación transparente.

Liberación de un nodo con VM ejecutadas remotamente

Una VM puede ejecutarse en un nodo distinto del propietario de su pool: en ese caso sus discos llegan por NVMe-oF/TCP. En la salida de vstack-vm vm list, estas VM están marcadas con la palabra remote. Antes de la actualización, el nodo se libera de las VM de sus pools y de las VM que se ejecutan en él con discos de pools ajenos.

Detenga e inicie las VM a través de vStack Center.

1. Conmute los pools del nodo como se describe en la sección «Conmutación de los servicios del pool». Las VM de estos pools que se ejecutan en otros nodos deben detenerse antes de la conmutación e iniciarse de nuevo después. Puede encontrarlas en cada nodo del clúster:

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

2. Retire del nodo el resto de las VM. Encuéntrelas en el propio nodo:

   vstack-vm vm list | grep -w remote

   Detenga cada una e iníciela con la acción «Iniciar en el nodo», eligiendo otro nodo. A continuación, asegúrese de que no queda ninguna VM en el nodo:

   ls /dev/vmm

   La respuesta No such file or directory significa que no hay VM en el nodo.

3. Cierre el nodo a la colocación de VM y compruebe que su estado es DISABLED:

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

   Si la utilidad vstack-cluster no está en el nodo, las mismas acciones se realizan con ccrd_cli --node --node_id <N> --command disable y ccrd_cli --node --command status.

   Después del cierre, vuelva a ejecutar ls /dev/vmm. Si han aparecido VM en el nodo, retírelas como en el paso 2.

   precaución

   Durante los trabajos, no inicie ni traslade VM al nodo cerrado. No mantenga cerrado más de un nodo.

4. Actualice el nodo siguiendo los pasos 1–5 de esta página.

5. Abra el nodo después de la validación:

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

   Sin la utilidad vstack-cluster: ccrd_cli --node --node_id <N> --command enable. Después, si es necesario, devuelva los pools. Las VM no vuelven al nodo por sí solas.

Códigos de salida

Código	Significado
0	actualización completada
1	error en los argumentos
2	la fuente o la versión no están disponibles, no se ha obtenido la clave de firma o se ha solicitado un cambio de versión mayor sin --allow-major-upgrade
3	error de pkg o de la comprobación del nuevo kernel
4	no se ha podido guardar o restaurar la configuración (/etc, /usr/local/etc, archivos de arranque)
5	un servicio instalado no se ha reiniciado
6	actualización completada, pero el shell de root no es ejecutable. Corregir antes del reinicio
7	actualización completada, pero la escritura en /boot no se ha confirmado. No reiniciar hasta analizarlo

Con los códigos 6 y 7, el script ignora intencionadamente --reboot.

Reversión

El script no revierte los paquetes. Se puede volver atrás así:

• Arranque. El kernel anterior permanece en el nodo y está disponible en el menú del cargador hasta que la ventana de actualización se cierra con un arranque correcto.
• Configuración. La copia se encuentra en /var/backups/etc-<ts>; se conservan las cinco últimas.
• Sistema completo. Reinstalación desde el medio de la versión de destino o restauración desde una copia de seguridad del nodo hecha antes de los trabajos.

El script no guarda los datos de los pools, los discos de las VM ni la configuración fuera de lo enumerado en el paso 3. Haga usted mismo su copia antes de la ventana; véase «Copia de seguridad de la configuración del nodo».