SPARC: Domain administration and autoboot on Sun Fire M6800

Hace unos días acudí a un cliente a levantar un Sun Enterprise M6800 que se había caído (crease o no) debido a un fallo eléctrico. Si bien, el sistema operativo ni los filesystems estaban dañados, había un pequeño tip para que dicho servidor bootee de manera automática que quizás muchos de ustedes deben conocer.

Pero me resulta interesante este post para contarles sobre la arquitectura que disponen estos equipos de la línea enterprise de Sun, y el uso de la XSCF shell, la cual actúa como Service Processor (SP).

Como sabemos, un equipo informático es una colección de distintos recursos de hardware como CPU's, módulos DIMM's, dispositivos de I/O (NIC, discos, slots PCI-E y PCI-X, etc.). Y se suele agrupar en un único conjunto para actuar bajo algún fin preestablecido.

Cuando tratamos con equipos de líneas enterprise estos modelos suelen estar sujetos a algunas modificaciones, por ejemplo, podemos tomar una porción de este hardware para crear una instancia de un sistema operativo ejecutandose, y otra porción de dicho hardware para crear otro equipo.

Esto difiere de la virtualización ya que no existe un hypervisor que actúe como capa de abstracción para la comunicación directa por el hardware, sino que esto es logrado por el SP.

Definimos el término plataforma, como el conjunto de todos los dispositivos de hardware que encontramos en el equipo. El término partición también conocido como segmento, hace referencia a un grupo de repeater boards que son usadas en conjunto para proveer comunicación entre CPU/Memoria, y módulos de I/O en el mismo dominio. Por su parte un dominio es una instancia independiente de un sistema operativo en ejecución y todo su entorno, al cual se le asigno de manera única un Domain ID (valor numérico entero), en el caso de estos equipos Solaris 10, que corre de manera independiente al resto, por lo cual si un dominio se ve dañado no afecta de ninguna manera a los otros dominios en ejecución.


El system controller, es un sistema embebido en el centerplane de estos equipos, y nos va a permitir visualizar y configurar los dominios y algunos otros parámetros de entorno en estos equipos, tales como el encendido, apagado, entre otros. Este system controller es conocido tanto para el entry-point de M3000, mid-ranges como el M4000 y M5000 o high-end server como M8000 y M9000 como SP, y podemos acceder a una shell denominada XSCF (eXtended System Controller Facilities), utilizando cable serial, y un emulador de terminal (por ejemplo Minicom/Hyperterminal), ejecutándose a 9600 baudios, 8 bits de datos, sin paridad, 1 bit de stop y sin control de flujo (9600 8N1), o también mediante una interfaz web denominada por Sun como BUI (Browser User Interface), nosotros utilizaremos la primera.

Entonces, ya tenemos en claro el concepto de que el hardware puede ser dividido en distintas particiones, mediante la utilización repeater boards, y dentro de esas particiones podemos crear dominios asignando más o menos hardware a cada una de ellas. Pero no todo el hardware puede ser compartido, existe hardware de uso común por todos los dominios como es el caso de los fans, power supplies, entre otros.

Para poder definir un dominio necesitamos cumplir con algunos requerimientos mínimos:

• Al menos una CPUM/CMU con memoria. 
• Al menos un módulo I/O.
• Repeater Boards no asignadas a otros dominios.
• Al menos un System Controller.
• Media instalable (imagen DVD/CD, red mediante JumpStart).

En un Sun Fire 3800/3810/4800/6800, podemos crear como máximo dos particiones, y dentro de cada una de estar particiones un máximo de dos dominios (Partición 1: A, B - Partición 2: C, D) en el caso del 6800 y dos (Partición 1: A, B) en el caso de 3800/3810/6800. 

Y estos pueden ser creados mediante las Repeter Boards (RP), en Single-Partition Mode (2 dominios), o Dual-Partition-Mode (4 dominios). 

El termino SB, hace referencia a System Board, esto significa CPU y Memory boards que son conectadas al equipo. Por ejemplo SB0 hace referencia a la primer System Board, SB1 a la segunda y así sucesivamente hasta SB5. IB hace referencia módulos de I/O y se numeran de la misma forma que las System Boards, y el término RP, referencia a las Repeater Boards y también adoptan esta convención de enumeración. 

Veamos un 6800 ejecutándose en Single Partition Mode:

Veamos un 6800 ejecutándose en Dual Partition Mode:

Basta de teoría, vamos a la práctica. 

Existen básicamente dos métodos para conectarnos al SP, el primero, descartado en mi caso, mediante conexión de red, (el System Controller, viene con dos interfaces de red) pero como el equipo estaba caído esto era imposible, y la segunda mediante el clásico puerto serie, del que ya les conté en este post.

Por lo cual, lo primero que hice fue establecer conexión utilizando el puerto serie, y Minicom.

Lo primero es encender los grid, a fin de energizar el equipo y efectuar el POST en el mismo, para ello:

XSFC:> poweron grid0 grid1

Luego de autenticarse y dentro de la XSCF shell, dentro del mismo, seteamos el keyswitch en on así iniciamos el dominio y podemos acceder al Open Boot PROM (OBP) del dominio A.

XSFC:> setkeyswitch on

Podemos examinar el estado de los dominios corriendo en el equipo mediante el comando showplatform.

XSFC:> showplatform -p status
Domain    Solaris Nodename    Domain Status            Keyswitch 
--------  ------------------  -----------------------  -----------
A         nodename-a          Active - Solaris         on
B         -                   Powered Off              off
C         -                   Powered Off              off
D         -                   Powered Off              off 
XSFC:> 

Excelente, nuestro dominio ya está corriendo. Ahora tenemos que acceder a la consola del mismo, para ello utilizamos el comando console. Y dentro del mismo ingresamos a la consola TTY/OBP del dominio:

XSFC:> console -d A
Connect to Domain#00?[y|n] :y
{0} ok

Y nos encontramos con el OBP, por lo cual el equipo no booteo, por lo cual, lo único que hay que ejecutar es el comando boot, si neceistamos bootear en single user, simplemente hacemos boot -s.

{0} boot

En mi caso el equipo booteo a la primera y de manera correcta, en el Open Boot ROM, no esta configurado el autoboot, así que una vez esto, y desde el sistema operativo, podemos cambiar esto mediante el comando eeprom.
#: eeprom autoboot?=true
#: reboot

El ? del paramétro que pasamos mediante eeprom referencia a un valor booleano, donde dos opciones son posibles, true y false. Ahora al reiniciarse el equipo bootea sin intervención del usuario, ahora nos podemos desconectar y estar tranquilos de que ante un posible reboot, el equipo volverá a iniciar.