Solaris: SVM deployment and ZFS migration with minimun downtime

Hace muy pocos días, compré un viejo, pero en excelente estado, servidor Sun Fire 280R. El equipo cuenta con algunos features más que interesantes, equipado con dos procesadores UltraSPARC64 III, 2 Gb. de RAM, RSC card, fuentes de alimentación redundantes, lector de DVD-R y dos discos SCSI de 36 Gb cada uno.
Al momento de bootearlo por primera vez, me encontré con Solaris 10 5/08 instalado, y prácticamente sin uso. Por lo cual no hacía reinstalar el sistema operativo. Había un solo tema negativo en esta configuración por default, el layout de particionamiento de los discos y asignación filesystems no me gustaba. En uno de los discos estaba el sistema operativo, el /export/home, en otro utilizando ZFS cree un zpool donde instalé una zona que no quería volver a reinstalar.

Solaris 10 Link Aggregation (NIC Bonding) and switch side Trunking configuration

Link Aggregation también llamado NIC Bonding o NIC Teaming. Es un conjunto de técnicas utilizado combinar múltiples conexiones de red en un solo link a fin de brindar mayor throughput, y proveer redundancia en caso de que el link falle. Es común su utilización en switches o routers y puede ser utilizada también en equipos. Acorde al sistema operativo se pueden configurar varios métodos o políticas para realizar bonding (Round Robin, Active/Backup, XOR, Brodcast) , y en este post específicamente nos vamos a basar en Active/Backup a fin de proveer una mayor rebundancia en la conexión de red del servidor.

Vamos a estructurar el post en tres partes: En la primera comprenderemos como se organiza la configuración de networking en Oracle Solaris 10, de esta manera sabremos donde tenemos que tocar al momento de lograr esta configuración. Luego nos enfocaremos a realizar la configuración del lado del switch suponiendo que el mismo corre Cisco IOS, y donde generaremos un Channel Group en el cual se encontrará conectado nuestro servidor con Solaris 10 y configuraremos Spanning Tree para evitar loops de red.
Durante el post utilizaremos dos interfaces de red, pero cabe notar que esto puede realizarse con varias interfaces, es común encontrar Link Aggregations con tres o más links.

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.

The Sun OpenBoot architecture - Part I

Todos los sistemas Sun tienen un firmware denominado PROM que le provee a los mismos las funciones básicas de testeo e inicialización del hardware del equipo. También desde el OpenBoot se puede identificar hardware de terceras partes y cargar drivers genéricos para hacer uso de estos dentro del sistema.
OpenBoot, se encuentra incluido en un chip denominado PROM, en el motherboard, y es la interfaz que se utiliza tanto para bootear un sistema, como para establecer parámetros sobre el funcionamiento del equipo, siendo especialmente útil durante el proceso de booteo, ya que el será el encargado de inicializar en SPARC, los distintos slides para inicializar el sistema.