P2V migration: from Solaris 9 server to Solaris 10 branded zone.

Hace poco tiempo atrás, participe en un proyecto en el cual se me asigno la tarea de migrar un obsoleto equipo en Solaris 9, junto a sus aplicaciones, a un nuevo Sun Enterprise M3000 con Solaris 10.
El proceso es en si sencillo y brinda una flexibilidad enorme al hacer este tipo de migraciones que cada vez se vuelven mas frecuentes en datacenters del mundo.
La idea principal es disminuir la cantidad de hardware necesario y el espacio ocupado por este en los datacenters, como así también aprovechar las ventajas que provee la posibilidad de utilizar zonas para disminuir costos, como así también reducir el punto de falla de equipos, debido a que tarde o temprano, esto debería ser migrado ya que en estos tiempos Solaris 9 a quedado obsoleto en el mercado.

Antes de meter leña al fuego, debemos comprender algunos conceptos generalizados sobre las tecnologías con las que vamos a trabajar.

Sun Enterprise M3000
El M3000 es el Entry Level de la familia de servidores MX000 desarrollados conjuntamente entre Sun (ahora Oracle) y Fujitsu utilizando la familia de procesadores SPARC 64 VII y el nuevo bus de interconexiones Jupiter. Este equipo es el más pequeño de este conjunto, ocupando solo 2RU (unidades de rack), pero cuenta con características más que interesantes que lo convierten en una buena elección para este tipo de migración. Si bien otros equipos de la familia tales como el M4000, M8000 y M9000 superan enormemente al M3000, debido a la posibilidad de poder crear mas de un dominio en el, se convierte, como dije anteriormente en una excelente elección para esa migración.

Virtualización en Solaris:

Solaris ofrece principalmente tres métodos para virtualizar (si puede llamarse así), ellos son LDOM (Logical Domains), esto es quizás lo más parecido a un hypervisor (director en este caso), que podemos encontrar. Hardware Domains, en los cuales, en equipos de gama alta (M4000, M8000, M9000), el hardware es dividido a nivel eléctrico, conformando distintos subconjuntos y donde uno o varios dominios son creados y configurados y el último Solaris Containers, que describiré a continuación.

Solaris Containers and Zones:
Parecido al concepto de las Jails en FreeBSD o Workload Partitioning (WPAR) de AIX, es el concepto de Zonas en Solaris. Introducidas originalmente en el año 2005, una zona no es otra cosa que una instacia del sistema operativo corriendo sobre este, de manera totalmente aislada con única dependencia de un Container, esto es, la zona global.
Definimos como zona global a la instancia original del sistema operativo, quien administra y hace uso de la memoria, CPU, I/O, devices, filesystem y el resto de recursos de hardware y distribuye esto a las zonas no globales creadas en el.

Teóricamente es posible crear mas de 8.000 zonas por dominio, aunque siempre este limite se encuentra limitado por el propio hardware del equipo, cabe destacar que una zona es muy liviana, de hecho una zona sparse-root ocupa menos de 40 mb. Son rápidas y fáciles de crear ademas de tener la capacidad de compartir el kernel, y algunos directorios de uso común (como /usr, /opt, /bin, /sbin, /lib, entre otros) con la zona no global, a la que también se le suele denominar zona nativa.

Es posible compartir una interfaz de red con la zona global, o dedicar completamente una de ellas a fin de lograr una mejor gestión de networking del equipo.
A fin de lograr performance en cuanto a I/O se pueden dedicar devices exclusivos a una zona, como así también crear zpools, o filesystems utilizando ZFS para que sea utilizado unicamente por una zona no global.
Podemos concluir con que una zona nos provee básicamente dos cosas: flexibilidad, debido a la amplia gama de configuraciones posibles que podemos lograr. Y aislamiento (isolation), esto significa que desde una zona no global es teóricamente y prácticamente imposible escapar de ella, por lo cual garantiza seguridad, aunque con un usuario suficientemente privilegiado, desde la zona global podrán ser vistos y manejados los procesos de las zonas no globales, como así también los devices y filesystems a los que la zona accede.

En lo que respecta a gestión de recursos, podemos priorizar zonas utilizando FSS (Fair Share Scheduler), esto significa dividiendo el tiempo total de CPU de formas definidas previamente (a las que denominaremos shares), y asignandole a cada miembro del conjunto una cantidad determinada de esos shares, por ejemplo si tenes cinco zonas las cuales tienen 500 shares, y a una zona le asignamos 100 shares, FSS se asegurará de asignarle a esa zona 1/5 parte del tiempo total de CPU asignado al conjunto como mínimo. Esto evita gastar tiempo de CPU de manera inútil, problema que puede impactar en la performance de la zona. CPU Caps el cual asigna una cantidad especifica del tiempo total de CPU a una zona durante un tiempo de muestra, por ejemplo podemos decir que el proceso X de la zona Y, puede consumir solo el 4.33 de Z CPU. Y el último método disponible es crear CPU pools y dedicar CPU's de manera exclusiva a una zona o conjunto de ellas (Dynamic Resource Pools). Por su parte, si necesitaramos limitar la memoría (swap, share memory, real, etc.) que utiliza una zona podemos darle una mirada a Resource Capping Daemon (rcapd), además de siempre proveernos la capacidad de hacer estos cambios de manera dinámica sin la necesidad de reiniciar la zona.

La migración de antiguos equipos con Solaris 8 o 9 a zonas en Solaris 10, puede proveernos algunas características interesantes de las que podemos hacer uso y abuso, como por ejemplo utilizar FMA (Fault Managment Agent), Dtrace para examinar los procesos de la zona, utilizar ZFS o Zvols, ejecutar antiguas versiones en hardware hasta el momento no soportado, poder mover zonas de un equipo a otro sin mayores dificultades y beneficiarse de las mejoras de performance de Solaris 10.

El costo de hacer negocios es el crecimiento exponencial de la carga del equipo, pero ¿cuanta carga añade una zona?. Veamos este ejemplo extraido del documento "Zones and Containters FAQ":

40 zones, each running five copies of the Apache web service, on an E250 with two 300MHz CPUs, 512MB RAM, and three hard disk drives totalling 40GB. With all zones running and a load consisting of multiple simultaneous HTTP requests to each zone, the overhead of using zones was so small it wasn’t measurable (<5%). 

Básicamente podemos categorizar las zonas de tres formas:

• Sparse-root zone:
  Una zona Sparse-root es una pequeña instancia del mismo sistema operativo ejecutandose en un entorno aislado, comparte el mismo kernel que la zona global, como así también binarios, directorios, los cuales se montan para la zona como solo lectura.
  Una zona Sparse-root completamente configurada y en ejecución, pesa aproximadamente unos 100 mb. Es la opción más liviana a ser usada y nos brinda una enorme flexibilidad.
• Whole-root zone:
  Por su parte una zona Whole-root, es mas grande que una Sparse-root y consume más recursos, se basa en una instancia independiente del sistema operativo (1 gb. aproximadamente), utilizando su propio kernel, binarios y directorios.
• Branded-zone:
  Una zona brand, ejecuta otro sistema operativo dentro del container, por lo cual es posible ejecutar mediante un framework (BrandZ) algunas versiones de Linux (RHEL), o antiguas versiones de Sun Solaris. Actualmente se encuentra soportados Solaris 8 y Solaris 9, y sobre esto nos focalizaremos para realizar nuestra migración. 

Ya con el marco teórico suficiente comenzaremos a realizar nuestras tareas de migración, la cual dividiremos en tres partes:

1. Creación de FLAR en Solaris 9.
2. Creación del brand Solaris 9 sobre la zona global.
3. Restore del FLAR creado anteriormente.

Un archivo FLAR (Flash Archive), es una imagen de un sistema operativo, la cual puede se replicada a lo largo de un sin número de equipos a fin de lograr sistemas iguales y puede ser utilizada para diversos motivos como por ejemplo JumpStarts, o como la utilizaremos nosotros para restaurar nuestro antiguo Solaris 9 en una zona Brand.

Manos a la obra:
Lo primero a realizar es generar el FLAR en el equipo con Solaris 9, y copiarlo al equipo de destino, en mi caso, por una cuestión de practicidad elegí hacerlo mediante NFS, para ello compartí el directorio /flar en el equipo de destino:

GZ# share -F nfs -o rw /flar

Y lo monte en /net/Solaris9/ un filesystem del equipo de origen:

# mount -F nfs solaris10:/flar /net/Solaris9/

para ello con el equipo lo más inactivo posible y excluyendo algunos directorios y archivos ejecutamos:

# flarcreate -S -n S9-`hostname`-`date +%Y-%m-%d` /net/Solaris9/S9-`hostname`-`date +%Y-%m-%d`.flar
Determining which filesystems will be included in the archive...
Creating the archive...
cpio: File size of "etc/mnttab" has
increased by 156
716678910 blocks
1 error(s)
Archive creation complete.

Para poder realizar nuestra migración P2V necesitamos tener instalados algunos paquetes: SUNWs9brandr SUNWs9brandu SUNWs9brandk para ello utilizando pkgadd y sobre nuestro spool de paquetes local (media de instalación o similar), realizamos:

GZ# pkgadd -d /var/spool/pkg/ SUNWs9brandr SUNWs9brandu SUNWs9brandk

El paquete SUNWs9brandk, no se encuentra en la media de instalación, sino que debe ser provisto por Oracle de manera especial (según mi experiencia personal).
Una vez listo esto, con los paquetes instalados y el flar en el servidor de destino comenzamos a crear nuestro contrainer brandZ, al que llamaremos S9Zone:

GZ# zonecfg -z S9Zone
S9Zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:S9Zone> create -t SUNWsolaris9
zonecfg:S9Zone> set autoboot=true
zonecfg:S9Zone> set zonepath=/zones/S9Zone

Mediante el comando zonecfg, entramos en modo configuración de nuestra zona, a fin de crearla, lo primero que hacemos, mediante el comando create es crear la zona especificándole que el brand que utilizaremos sera Solaris 9, en este caso: SUNWsolaris9. Luego permitimos mediante el valor booleano true, el autoboot de la zona, y especificamos el path donde se copiaran los archivos de la misma, el cual previamente debe estar creado.

Ahora procedemos con la configuración de networking, compartiendo la interfaz e1000g0 para ser utilizada tanto por la zona global como por nuestra brandZ:

zonecfg:S9Zone> add net
zonecfg:S9Zone:net> set physical=e1000g0
zonecfg:S9Zone:net> set address=172.16.1.200/24
zonecfg:S9Zone:net> end

Luego verificamos que todo este correctamente, e imprimimos como quedo nuestra configuración, para luego hacer el commit.

zonecfg:S9Zone> verify
zonecfg:S9Zone> info
zonename: S9Zone
zonepath: /zones/S9Zone
brand: solaris9
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
net:
 address: 172.16.1.200/24
 physical: e1000g1
zonecfg:S9Zone> commit
zonecfg:S9Zone> exit

Bien, ya con la zona creada solo nos resta restaurar el flar, este es un procedimiento que puede llevar su tiempo, aproximadamente en mi caso, restaurando un flar de unos 120 gb, demoro estimadamente 20 minutos, así que con un poco de paciencia debemos ejecutar:

GZ# zoneadm -z S9Zone install -p -s /flar/S9-foobar-2012-05-23.flar
   Source: /flar/S9-foobar-2012-05-23.flar
   Installing: This may take several minutes...
   Postprocessing: This may take several minutes...
...
   Result: Installation completed successfully.

Una vez listo, bootearemos nuestra zona:

GZ# zoneadm -z S9Zone boot

Verificamos que todo este bien y que la zona haya booteado correctamente (generalmente tarda unos 2 segundos):

GZ# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP
   0 global           running    /                              native   shared
   5 S9Zone           running    /zones/S9Zone                  solaris9 shared

Y procedemos a configurar la zona:

GZ# zlogin -C S9Zone
[Connected to zone 'S9Zone' console]

SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2006 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.

Hostname: foo
The system is comming up.
NIS domainname is bar.net
starting rpc services: rpcbind keyserv ypbind done.
syslog services starting.
Print services started.
The system is ready.

foobar console login:

Ahora ya estamos en condiciones de loguearnos en nuestra zona, y trabajar con ella. ¿Fácil verdad?.