Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

"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:

  1. Creamos un nuevo BE. Esta operación es casi instantanea.

  2. 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).

  3. Actualizamos el BE en cuestión. Ésto puede ser lento, pero nos da igual.

  4. 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.

  5. Ahora exportamos las zonas ("detach"). Esta operación supone la pérdida de los servicios que presten, obviamente.

  6. 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.

  7. Reiniciamos la máquina, arrancando el nuevo BE actualizado.

  8. Nos aseguramos de que el BE funcione correctamente.

  9. 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".

  10. 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.

  11. De hecho, trabajando con ZFS podríamos:

    1. Hacer el "detach" de las zonas

    2. Hacer un "snapshot" de las zonas

    3. Volver a hacer un "attach" de las zonas

    4. Arrancar el nuevo BE

    5. Clonar los "snapshots" de las zonas

    6. 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.



Python Zope ©2010 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS