SafeChildren Banner

Havoc Oracle Solaris Experts

martes, 2 de abril de 2013

Cómo trabajar con Boot Environments en Solaris - Parte 2

Introducción
En la primera parte de Cómo trabajar con Boot Environments hacíamos una introducción a los comandos de gestión y su funcionamiento básico.

En esta segunda parte, vamos a aplicar lo que hemos aprendido en cuanto a la gestión de Boot Environments y cómo podemos utilizarlo en "un mundo real".

Si no recuerdas las opciones más importantes, te recomiendo hacer un pequeño repaso a la primera parte de Cómo trabajar con boot environments antes de entrar ya en materia.

Instalación de paquetes
Una de las características más interesantes de los Boot Environments es la capacidad de instalar paquetes -o parches- sin tener "downtime" en nuestro sistema principal.

Para ello, deberemos utilizar la opción "-R /punto_montaje" del comando <pkg>, es decir:

havoc@h100:~$ pfexec pkg -R /mnt <acción>

Un Ejemplo Completo
Como siempre, lo mejor es verlo con un ejemplo. Así que vamos a actualizar una versión de OpenIndiana b148 a la última versión utilizando la opción <image-update>

1.- Creamos y Montamos un Boot Environment Nuevo (PreUpdate)

havoc@h100:~$ pfexec mkdir /mnt/preupdate
havoc@h100:~$ pfexec beadm create PreUpdate
havoc@h100:~$ pfexec beadm mount PreUpdate /mnt/preupdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint     Space   Policy Created         
--        ------ ----------     -----   ------ -------         
PreUpdate -      /mnt/preupdate 122.0K  static 2013-03-08 10:28
solaris   -      -              3.06M   static 2011-04-16 04:06
solaris-1 NR     /              103.88G static 2011-04-16 04:41


2.- Actualizamos la distribución completamente utilizando "image-update"

havoc@h100:~$ pfexec pkg -R /mnt/preupdate image-update
                Packages to remove:    71
               Packages to install:   120
                Packages to update:   419
           Create boot environment:    No
               Services to restart:     6
DOWNLOAD                            PKGS       FILES    XFER (MB)
Completed                          610/610 20899/20899  325.4/325.4

PHASE                                        ACTIONS
Removal Phase                             9232/14882
Warning - directory /mnt/usr/share/man/cat1m not empty or not expected during operation - contents preserved in /mnt/var/pkg/lost+found/usr/share/man/cat1m-20130402T001646Z
Removal Phase                            14882/14882
Install Phase                            15359/15359
Update Phase                             12439/23150
Update Phase                             23150/23150

PHASE                                          ITEMS
Package State Update Phase                 1029/1029
Package Cache Update Phase                   490/490
Image State Update Phase                         2/2
------------------------------------------------------------------
NOTE: Please review release notes posted at:

http://docs.sun.com/doc/821-1479
 
------------------------------------------------------------------

3.- Comprobamos que todo se ha actualizado correctamente
Vamos a comprobar, por ejemplo, el paquete PostGreSQL9 que tenemos instalado en el Boot Environment actual y el actualizado (PreUpdate)

havoc@h100:~$ pfexec pkg info postgresql9
          Name: postgresql9
       Summary: PostgreSQL Database Server for OpenIndiana
         State: Installed
     Publisher: havoctec
       Version: 9.0.10
 Build Release: 5.11
        Branch: 0.148
Packaging Date: 25 de octubre de 2012 10:08:03
          Size: 41.04 MB
          FMRI: pkg://havoctec/postgresql9@9.0.10,5.11-0.148:20121025T100803Z
havoc@h100:~$ pfexec pkg -R /mnt/preupdate info postgresql9
          Name: postgresql9
       Summary: PostgreSQL Database Server for OpenIndiana
         State: Installed
     Publisher: havoctec
       Version: 9.0.12
 Build Release: 5.11
        Branch: 0.151
Packaging Date: 12 de febrero de 2013 11:00:46
          Size: 31.16 MB
          FMRI: pkg://havoctec/postgresql9@9.0.12,5.11-0.151:20130212T110046Z


4.- Forzar la reconfiguración.
Aunque este paso no es obligatorio, puede que nos encontremos con algún problema -como en este caso- de drivers que han cambiado y Solaris necesita reconfigurarse.

havoc@h100:~$ pfexec touch /mnt/preupdate/reconfigure

5.- Ciclo completo de boot iniciando con el nuevo Boot Enviroment
Este paso se puede realizar de dos formas (la segura y la rápida), aunque yo voy a centrarme en la más "segura" que requiere de un acceso físico a la consola para poder seleccionar el Boot Environment de forma "manual" en Grub (x86).

a) La más segura
Vamos a realizar un ciclo completo de boot, para ello utilizaremos la opción 6 del comando <init> o si lo preferís "apagar/encender".

havoc@h100:~$ pfexec init 6

Cuando se muestre la opción de arranque del Grub (x86) veremos una nueva entrada que será igual al nombre del Boot Environment que hemos definido, en nuestro caso "PreUpdate".

Seleccionamos ese entorno y comprobamos que todo funciona correctamente haciendo las pruebas necesarias para, finalmente, dejar como "activado" este nuevo entorno.

NOTA: Una vez comprobado que todo el proceso se realiza correctamente, a mí personalmente, me gusta tener el nombre del Boot Environment de una forma correcta, así que renombro el Boot Environment, pero, no es estríctamente necesario.

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space Policy Created
PreUpdate NR     /          141G  static 2013-03-07 23:57
solaris   -      -          3,06M static 2011-04-16 04:06
solaris-1 -      -          5,81G static 2011-04-16 04:41


b) En un sólo paso
Todo el proceso se puede realizar en un sólo paso. Suponiendo que hemos realizado varias pruebas de integración, y el proceso de actualización siempre ha sido correcto, podemos, por ejemplo, activar el nuevo Boot Environment y realizar un ciclo completo de boot, así:

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:~$ pfexec init 6

6.- Actualizar el "zpool" (SOLO CUANDO ESTEMOS SEGUROS)
Por último, una vez comprobado que todo funciona correctamente  -y si me lo permitís, pasados unos días- ya sólo queda actualizar nuestro zpool, si fuese necesario, para comprobarlo, utilizaremos la opción <status> del comando <zpool>, por ejemplo así:

havoc@h100:~$ pfexec zpool status
  pool: rpool
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the pool will no longer be accessible on software that does not support feature flags.
  scan: resilvered 4,10G in 0h1m with 0 errors on Sat Apr 16 13:30:56 2011
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c2d0s0  ONLINE       0     0     0
            c3d1s0  ONLINE       0     0     0

errors: No known data errors


¿Y qué hago si falla?
Esta pregunta tiene una solución sencilla:
"activar el Boot Environment anterior y reiniciar"
El proceso de "rollback" es tan sencillo como volver a iniciar con el Boot Environment que funcionaba correctamente, para ello, tenemos tres escenarios:

a) Nuestro sistema arranca hasta level 3.
En este caso, simplemente activaremos el boot environment anterior utlizando el comando

havoc@h100:/$ pfexec beadm activate <NombreAnteriorBoot>

b) Nuestro sistema no arranca.
Este caso suele ser más problemático porque necesitamos acceso a la consola, e iniciar el sistema en Single Mode y activar el Boot Environment anterior.

c) Nuestro sistema no arranca y hemos actualizado la versión de zpool
Este es un escenario un poco "raro", ya que por algún motivo, hemos certificado que el nuevo Boot Environment era correcto, hemos actualizado la versión del zpool y ahora queremos "echarlo para atrás".

La solución sencilla, pasaría por iniciar desde un CDROM -o similar- una versión de Solaris "compatible" con esa versión de zpool, reparar lo que falle y volver a iniciar.

Conclusiones
Hemos visto en estas dos partes cómo utilizar los Boot Environments para actualizar nuestros equipos Solaris a versiones nuevas, o para hacer experimentos con un "rollback" sencillo.

Hay que decir que en función de lo que queramos actualizar, deberemos realizar más o menos tareas, por ejemplo, si queremos actualizar PostgreSQL y no queremos bajar la base de datos, tendremos que tirar de WAL ... pero eso es otro post.

Espero vuestros comentarios y sugerencias!


<< Cómo trabajar con Boot Environments - Parte 1