"Live Upgrade" problemático con zonas y "/var" en un "dataset" separado
Última Actualización:
03 de enero de 2010 - Domingo
Los problemas documentados con "Live Upgrade" y las zonas Solaris
(cuando tenemos "var" en un "dataset" separado) son graves, pero
tras la publicación del parche 121431-44
pensamos que estaba todo solucionado... y no es así.
En este documento describiré los problemas que tengo usando "Live Upgrade" en una máquina Solaris 10
Update 7 (con todos los parches públicos instalados, incluyendo el 121431-44) para actualizarla a
Solaris 10 Update 8. La máquina usa ZFS boot/root, tiene "/var" en un "dataset" separado, y tiene un par
de zonas Solaris montadas en sus respectivos "datasets".
Para los antecedentes, recomiendo leer los siguientes artículos:
Vistas las experiencias previas, antes de hacer la actualización a Solaris 10 Update 8 hacemos un backup de todo, snapshots
ZFS, y creamos un BE de "backup" por si las moscas. Todas las precauciones son pocas.
La creación del BE nuevo funciona ahora correctamente, gracias al parche 121431-44. Activamos el nuevo BE y reiniciamos
la máquina. Ésta arranca correctamente... pero las zonas Solaris no funcionan.
Como primer paso pensamos en volver al BE anterior, para asegurarnos de que funciona correctamente. Si el BE anterior funciona
correctamente, y podemos arrancar libremente entre uno y otro, podemos permitirnos "toquetear" el BE nuevo sabiendo que en caso de
"cagarla" podemos volver al BE anterior. A las malas, arrancamos el BE antiguo, borramos el nuevo y volvemos a empezar desde el
principio.
Así que hacemos lo siguiente:
[root@stargate-host /]# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
Solaris10u7 yes no no yes -
Solaris10u7BACKUP yes yes yes no -
[root@stargate-host /]# lumount Solaris10u7
ERROR: cannot mount '/var': directory is not empty
ERROR: cannot mount mount point </.alt.Solaris10u7/var> device <datos/ROOT/Solaris10u7/var>
ERROR: failed to mount file system <datos/ROOT/Solaris10u7/var> on </.alt.Solaris10u7/var>
ERROR: unmounting partially mounted boot environment file systems
ERROR: No such file or directory: error unmounting <datos/ROOT/Solaris10u7>
ERROR: cannot mount boot environment by name <Solaris10u7>
[root@stargate-host /]# zfs mount datos/ROOT/Solaris10u7
[root@stargate-host /]# ls -la /.alt.Solaris10u7/var/
total 13
drwx------ 2 root root 2 Jan 3 17:28 .
drwxr-xr-x 36 root root 49 Jan 3 17:28 ..
[root@stargate-host /]# rmdir /.alt.Solaris10u7/var/
[root@stargate-host /]# ls -la /.alt.Solaris10u7/var/
ls: cannot access /.alt.Solaris10u7/var/: No such file or directory
[root@stargate-host /]# zfs umount datos/ROOT/Solaris10u7
[root@stargate-host /]#
ERROR: cannot mount '/var': directory is not empty
ERROR: cannot mount mount point </.alt.Solaris10u7/var> device <datos/ROOT/Solaris10u7/var>
ERROR: failed to mount file system <datos/ROOT/Solaris10u7/var> on </.alt.Solaris10u7/var>
ERROR: unmounting partially mounted boot environment file systems
ERROR: No such file or directory: error unmounting <datos/ROOT/Solaris10u7>
ERROR: cannot mount boot environment by name <Solaris10u7>
[root@stargate-host /]# ls -la /.alt.Solaris10u7/var/
ls: cannot access /.alt.Solaris10u7/var/: No such file or directory
[root@stargate-host /]# zfs mount datos/ROOT/Solaris10u7
[root@stargate-host /]# ls -la /.alt.Solaris10u7/var/
total 13
drwx------ 2 root root 2 Jan 3 17:57 .
drwxr-xr-x 36 root root 49 Jan 3 17:57 ..
Como podemos ver claramente, volvemos a tener problemas con el hecho de tener "/var" en un "dataset"
separado. Lo que ocurre es que al montar el BE viejo las herramientas "Live Upgrade" crean un directorio
vacío "/var" en el BE, sin darse cuenta de que es innecesario porque ese lugar lo va a ocupar un "dataset".
Osea, el parche 121431-44 es incompleto. Soluciona la creación de BEs, pero no su uso rutinario posterior.
Este bug está reportado a SUN. Veremos...
En una situación así, ¿cómo podemos volver al BE anterior?. Si tenemos acceso físico a la máquina (o un KVM),
en teoría podemos seleccionar su entrada en el arranque GRUB (ojo, hay que asegurarse de haber borrado el directorio
vacío espurio "/var" antes de intentarlo). Pero ésto deja un montón de cabos sueltos, como el árbol de
snapshots y clones ZFS (que se pueden resolver fácilmente a mano con "zfs promote", si sabemos las implicaciones).
De hecho ésto fue lo que hice el día de fin de año, porque la cena de navidad es inaplazable y no podía permitirme
intentar solucionar el problema con el nuevo BE sin saber si ello me iba a llevar media hora o dos días. Ante esa incertidumbre,
preferí "tirar para atrás" a mano.
Hilo comentando estos
problemas en la lista "zones-discuss" del proyecto OpenSolaris.
Con menos agobio y aprovechando el fin de semana, que tiene menos movimiento (aunque la máquina debería estar activa 24x7,
en un mundo perfecto...), lo intento de nuevo. Este documento es la experiencia de ese segundo intento (no tengo registro del
primer intento, por las prisas para resolver el entuerto con urgencia).
Volviendo al grano, tenemos un nuevo BE llamado "Solaris10u7BACKUP" que arranca correctamente, pero cuyas
zonas no se lanzan automáticamente. Toqueteo mil cosas, pero no funciona correctamente. El hecho es que los "datasets"
de las zonas no se montan automáticamente al lanzar la máquina. Si las montamos a mano, podemos arrancar las zonas. Pero
es algo a hacer a mano.
Tras pegarme un par de horas con este tema, sin suerte, decido dejar de fastidiar a mis usuarios, así que tengo que
volver al BE anterior que, como ya hemos visto, no es tarea simple debido al bug ya señalado. Aprovecho para documentarlo todo.
ATENCIÓN ATENCIÓN ATENCIÓN ATENCIÓN ATENCIÓN ATENCIÓN: Lo que sigue supone la manipulación directa del sistema
operativo. Cualquier error puede suponer la destrucción del sistema. AVISADOS ESTÁIS. Por lo tanto, el primer y mejor consejo
que puedo daros es que hagáis backup/snapshot del estado actual. El segundo es que ni se os ocurra hacer lo que documento
a continuación a menos que seáis expertos en el tema y podáis salir del agujero en el que os vais a meter.
[root@stargate-host /]# zfs mount datos/ROOT/Solaris10u7
[root@stargate-host /]# rmdir /.alt.tmp.b-Zl.mnt/var
[root@stargate-host /]# zpool get bootfs datos
NAME PROPERTY VALUE SOURCE
datos bootfs datos/ROOT/Solaris10u7BACKUP local
[root@stargate-host /]# zpool set bootfs=datos/ROOT/Solaris10u7 datos
[root@stargate-host /]# zfs promote datos/ROOT/Solaris10u7
[root@stargate-host /]#
Editamos "/datos/boot/grub/menu.lst" para arrancar el BE antiguo. Hay que hacerlo correctamente, porque si cometemos
un error aquí necesitaremos acceso físico a la máquina, o un KVM, para solucionarlo.
Una vez arrancado eliminamos los restos del BE saliente, para dejar todo como estaba al principio:
[root@stargate-host /]# zfs get mountpoint datos/zones/babylon5
NAME PROPERTY VALUE SOURCE
datos/zones/babylon5 mountpoint /datos/zones/babylon5-Solaris10u7-Solaris10u7-Solaris10u7-Solaris10u7-Solaris10u7-Solaris10u7-Solaris10u7-Solaris10u7 local
[root@stargate-host /]# zfs inherit mountpoint datos/zones/babylon5
[root@stargate-host /]# zfs get mountpoint datos/zones/babylon5
NAME PROPERTY VALUE SOURCE
datos/zones/babylon5 mountpoint /datos/zones/babylon5 inherited from datos
[root@stargate-host /]# zfs inherit mountpoint datos/zones/stargate
[root@stargate-host /]# zfs get mountpoint datos/zones/stargate
NAME PROPERTY VALUE SOURCE
datos/zones/stargate mountpoint /datos/zones/stargate inherited from datos
[root@stargate-host /]# zfs set canmount=on datos/zones/babylon5
[root@stargate-host /]# zfs set canmount=on datos/zones/stargate
[root@stargate-host /]# vi /etc/lutab <- Aquí eliminamos los detalles del BE actual. Tomamos nota de su número
[root@stargate-host /]# rm /etc/lu/ICF.2 <- Eliminamos el ICF con el número que hemos visto en el punto anterior
[root@stargate-host /]# zfs list|grep -i Solaris10u7BACKUP
datos/ROOT/Solaris10u7@Solaris10u7BACKUP 2.32M - 4.12G -
datos/ROOT/Solaris10u7/var@Solaris10u7BACKUP 591K - 2.54G -
datos/ROOT/Solaris10u7BACKUP 60.9M 581G 4.12G /
datos/ROOT/Solaris10u7BACKUP/var 1.33M 581G 2.54G /var
datos/zones/babylon5@Solaris10u7BACKUP 962K - 637M -
datos/zones/babylon5-Solaris10u7BACKUP 1.32M 453G 637M /datos/zones/babylon5-Solaris10u7BACKUP
datos/zones/stargate@Solaris10u7BACKUP 9.07M - 1.51G -
datos/zones/stargate-Solaris10u7BACKUP 28.7M 453G 1.50G /datos/zones/stargate-Solaris10u7BACKUP
[root@stargate-host /]# zfs destroy datos/ROOT/Solaris10u7@Solaris10u7BACKUP
cannot destroy 'datos/ROOT/Solaris10u7@Solaris10u7BACKUP': snapshot has dependent clones
use '-R' to destroy the following datasets:
datos/ROOT/Solaris10u7BACKUP/var
datos/ROOT/Solaris10u7BACKUP
[root@stargate-host /]# zfs destroy -R datos/ROOT/Solaris10u7@Solaris10u7BACKUP
[root@stargate-host /]# zfs destroy -R datos/zones/babylon5@Solaris10u7BACKUP
[root@stargate-host /]# zfs destroy -R datos/zones/stargate@Solaris10u7BACKUP
[root@stargate-host /]# zfs list|grep -i Solaris10u7BACKUP
[root@stargate-host /]# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
Solaris10u7 yes yes yes no -
Reiniciamos y nos aseguramos de que todo está correcto, incluyendo las zonas.
Una opción inexplorada es usar "update on attach" par actualizar. Es decir:
- Creamos un nuevo BE. Esta operación es casi instantanea.
- Montamos el BE (si no podemos por el problema del "/var", montamos solo su "dataset" raíz) y eliminamos las referencias
a las zonas. Eliminamos también sus datasets (ésto puede requerir hacer un "zfs promote" si queremos conservar snapshots
antiguos, etc).
- Actualizamos el BE en cuestión. Ésto puede ser lento, pero nos da igual.
- Obsérvese que hasta este momento, hemos hecho los cambios en el BE nuevo, pero seguimos ejecutando el BE antiguo. Es decir,
la máquina sigue en producción e inalterada en todo momento.
- Ahora exportamos las zonas ("detach"). Esta operación supone la pérdida de los servicios que presten, obviamente.
- Probamos a hacer un "attach" de las zonas en el BE en funcionamiento, para asegurarnos de que podemos dar marcha atrás si
no funciona. Si todo va bien, volvemos a hacer el "detach". Hacemos copia de seguridad de las zonas, por si acaso.
- Reiniciamos la máquina, arrancando el nuevo BE actualizado.
- Nos aseguramos de que el BE funcione correctamente.
- Seguidamente hacemos un "attach" de las zonas, con la opción de "update on attach". Esta operación, teóricamente, debería
parchear las zonas "al vuelo".
- Las zonas así transferidas las tenemos que gestionar nosotros. Es decir, si volvemos a un BE anterior, debemos hacer un
"attach" de la versión VIEJA de la zona (lo inteligente es que el "dataset" en juego sólo contenga el sistema operativo de la
zona; los datos, configuraciones, etc., deben estar en OTRO "dataset", compartido por todos los BE). Si estamos con ZFS, lo suyo sería
hacer un snapshot+clon.
- De hecho, trabajando con ZFS podríamos:
- Hacer el "detach" de las zonas
- Hacer un "snapshot" de las zonas
- Volver a hacer un "attach" de las zonas
- Arrancar el nuevo BE
- Clonar los "snapshots" de las zonas
- Hacer "update on attach" de las zonas clonadas en el nuevo BE
En teoría estos pasos deberían tener éxito, pero no tengo prisa por migrar aún. Tendré un poco de paciencia, a ver si SUN se pone
las pilas...
El mensaje que
he enviado a la lista zones-discuss de OpenSolaris.
Historia
- 03/ene/10: Primera versión de esta página.
©2010
jcea@jcea.es
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
Blog personal: El hilo del laberinto
