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.

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.

Solaris: Connecting to iSCSI targets

iSCSI es un protocolo que permite enviar comandos SCSI mediante tramas ethernet, el cual se utiliza en Storage Area Networks a fin de flexibilizar las soluciones de storage que existen hoy en día.

iSCSI, se compone básicamente de dos tipos de tecnologías, iniciadores (clientes), y targets, los cuales son aquellos equipos que están sirviendo unidades de disco (LUN's), para que los iniciadores las monten como si se trataran de discos físicamente conectados al equipo cliente.
iSCSI suele utilizarse por regla general en redes separadas a las de datos, por cuestiones de performance sobre todas las cosas, pero como bien sabemos, iSCSI hace uso del stack TCP/IP, y este tiene una limitación bastante común, el MTU que por default es 1500 bytes, a fin de sobrellevar este primer inconveniente, muchas redes iSCSI utilizan Jumbro frames, estos son paquetes especiales en los cuales el MTU a sido alterado, incrementando el tamaño de su payload, por ejemplo 9000 bytes, que es el tamaño más común para un Jumbo frame.
La utilización de Jumbo frames, requiere que las interfaces de red de ambos lados, tanto el iniciador, como el cliente, tengan con mismo valor de MTU configurados.

Solaris: Adaptative Replacement Cache and ZFS memory leak

Hace unos días acudí a un cliente el cual decía que sus servidores con Solaris 10 08/11 estaban consumiendo memoria de una manera excesiva (un total de 8 GB. de RAM física). La situación se producía en un grupo de dos servidores que utilizaban ZFS para montar unos Containers, mientras que en aquellos que cumplían la misma función pero no utilizaban ZFS, esto no se producía. Así que comenzando a destripar el alien, hice uso de unas de las fantásticas herramientas que Solaris provee para esto, mdb.

POSIX: System-V Executable and Linkeable Format (ELF) and the Linux ABI

ELF son las siglas en inglés de Executable and Linkeable Format, y es el formato de archivo utilizado por los file objects (.o), binarios, librerías y coredumps en Linux y en Unix en general.
El principio de todo proceso, define al mismo como un archivo en un dispositivo de almacenamiento, que una vez compilado y al ser ejecutado, es cargado en memoria para que el scheduler (mediante el sistema operativo), le asigne tiempo de CPU y recursos a fin de poder ejecutar las rutinas definidas en el.
Este archivo, ya convertido en binario, se encuentra escrito en algunos de los cientos lenguajes de programación que existen actualmente, por ejemplo ANSI C o Fortran. Cuando fue compilado, el compilador en un momento determinado ejecuto el linker, y definió en un header todas aquellas librerías que el programa necesita para poder ejecutarse y que estás les provean aquellas funciones y procedimientos que utilice.
Un binario, puede ser compilado de dos formas, una es estática y la otra dinámica. Compilar un binario de manera estática (parámetro -Bstatic en gcc(2)), significa que se incluirán en el mismo binario todas aquellas librerías que el programa requiera. Por su parte, la principal idea de las librerías compartidas, es tener una sola copia de las mismas instaladas en el sistema operativo y que todo aquel programa que las necesite, haga uso de ellas, y las cargue en memoria para ejecución, en segmentos que pueden ser mapeados de manera privada para el proceso, o compartido entre varios procesos/threads.

Los procesos en Unix, nacen de alguna de las variantes de la syscall fork(2). fork(2), bifurca el proceso padre en una nueva imagen del proceso (una nueva entrada en la estructura proc_t), y mediante exec(2) desplaza esta imagen para crear el mapeo y la estructuras en memoria para el nuevo proceso ejecutado.
Una vez realizado el exec del proceso, y si este está compilado de manera dinámica, en invocado el runtime linker, en este caso ld.so.1,

POSIX: INT_MAX, INT_MIN and SIGFPE

En sistemas operativos modernos, los límites de direccionamiento de memoria y cantidad de procesos/threads está estipulada de dos formas: la primera acorde al hardware específico con que cuenta el equipo, y la segunda, mediante configuración específica del sistema operativo.

A modo de ejemplo, y para dejar las cosas más en claro, vamos a hablar un poco sobre los límites de los procesos: Cada proceso en el sistema operativo ocupa un slot en una estructura de datos denominada kernel process table. Esta tabla contiene toda la información necesaria que el kernel mantiene a fin de poder manejar los procesos, schedulear las distintas tareas (acorde a sus prioridades) y estados de los mismos. Cuando el OS bootea, el kernel inicializa una estructura de datos denominada process_cache, donde comenzará a direccionar la estructura de procesos que luego serán empleada por el kernel y el userspace. Esta tabla es una lista doblemente enlazada con dos punteros, uno a su elemento anterior y otro a su elemento posterior, la cual tiene una capacidad máxima que se define acorde a la cantidad de memoria física instalada en el equipo. El sistema operativo, para esto asigna la cantidad de memoria instalada a una variable MAX_MAXUSERS (que no tiene nada que ver con el número máximo de usuarios que el sistema soporta), que luego será utilizada por dos variables más del propio kernel max_nprocs y maxuprc. max_nprocs define el número máximo de procesos del sistema operativo, y maxuprc determina el número máximo de procesos que usuarios no privilegiados (que no sean root), puedan crear y ocupar slots en la kernel process table. Y basándose en el valor de MAX_MAXUSERS, poder definir el tamaño en memoria de cada segmento del proceso (región .text, .stack, .heap, .bss, etc.).

Performance analysis: A study case (bottleneck)

Como una manera de seguir ilustrando el post anterior "Performance analysis: Understanding the vmstat comand output", vamos a realizar un rápido análisis de un bottleneck producido en un equipo debido a la baja lentitud de la controladora de disco. Si bien en este caso el equipo no es más que una laptop, ejemplifica bien lo que es el estudio de performance que puede aplicarse a una gran variedad de equipos. Como en esta serie de post, solo hemos tratado con vmstat(1), utilizaremos tal herramienta para realizar el análisis.

Síntomas
El equipo, en momentos en los que se sometía a alta carga de trabajo de I/O se volvía extremadamente lento, dejando de responder por momentos, no habiendo otra solución que apagarlo, o esperar un buen rato. Si bien es entendible que el mismo se "quede" sin memoria y swapee, esto no se hacía de una manera tan agresiva, por lo cual se analizara la existencia de otro problema.

Descripción del equipo
El equipo es una laptop HP 420, con una CPU Pentium(R) Dual-Core CPU T4500 @ 2.30GHz, en cuanto a su memoría RAM se encuentra conectado un módulo DDR2 de 2 Gb. además cuenta con un disco rígido Western Digital WDC WD5000BPVT-00HXZT3 utilizando la interfaz SATAII. El sistema operativo que corre en el mismo es Linux (Fedora 16), x86_64, utilizando el kernel 3.3.1-5.fc16.x86_64. Sin entrar en más detalles vemos que dice lspci(1), sobre los dispositivos conectados al mismo:

Performance analysis: Understanding the vmstat command output

Todo sysadmin que se digne de tal, tiene la capacidad de optimizar sus equipos para soportar las distintas situaciones de carga a las que se puede ver sometido o resolver bottlenecks que puedan llegar a producirse. Existen varias situaciones que pueden sobrecargar un equipo, y siempre es útil comprender cuando se producen y los procedimientos para remediarlas.
La performance es un área difícil de comprender, pero fundamental a la hora de administrar sistemas.
Durante este post vamos a intentar comprender la salida de vmstat(8), un comando disponible en la mayoría de los sistemas Unix, en nuestro caso vamos a enfocarnos en Linux, y analizaremos algunas situaciones las cuales pueden llevar a una sobrecarga de performance.
Existen numerosas herramientas para analizar esto, pero muchas de ellas dan su punto de partida en vmstat(8), para luego enfocar en herramientas más específicas como iostat(8), mpstat(1), o sar(1). Para un mayor entendimiento de performance y las herramientas utilizadas les recomiendo el blog de Brendan Gregg, o también leer el libro "Solaris™ Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris" por Richard McDougall, Jim Mauro y Brendan Gregg

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.

Unix: Stateful firewalls vs. Non-Stateful firewalls

Hace unos días tuve una interesante discusión en Twitter sobre las ventajas de utilizar como firewall Packet Filter contra Netfilter (IPTables). Cabe destacar que tengo mas conocimientos de PF que de IPTables, por lo cual conozco más las ventajas prácticas del primero que del último.

En teoría de firewalls, encontramos los denominados stateful firewalls, son firewalls que actúan en layer 3 del modelo OSI/ISO (network) donde su punto fuerte es el poder de inspeccionar estados, y saber si los mismos corresponden a una conexión ya existente o no. Esto es posible lograrlo en Linux mediante connectrion tracking utilizando los módulos conntrack, y  así mantener un record de los estados existentes en el sistema operativo.

Tanto Packet Filter como IP Filter utilizan una estructura denominada tabla de estados (o status table), para mantener dicha información. Si un paquete IP ingresa al firewall, se va a buscar mediante una previa inspección del header si el mismo forma parte de una conexión ya existente, y si esto es cierto no se van a inspeccionar reglas de filtrado, sino que el paquete va a pasar directamente. Si un paquete llega por primera vez al firewall, el mismo si matchea con alguna regla, entonces va a crear una entrada en la tabla de estados del firewall, y ya, mientras la conexión siga viva no va a pasar por dicha inspección de reglas.

Linux: Determine if a program is using TCPWrappers

TCP Wrappers es un sistema de ACL's basado en hosts y redes, multiplataforma; Que permite o deniega la acceso a un demonio en un sistema a ciertos hosts o redes, Su configuración se realiza editando los archivos /etc/hosts.allow y /etc/hosts.deny mediante el host o las redes que queremos permitir o denegar y las claves ALL, LOCAL, UNKNOW, KNOW y PARANOID.


Que un demonio utilice TCP Wrappers significa que el mismo fue compilado y linkeado contra libwrap.so y podemos determinarlo simplemente haciendo uso de ldd. Por ejemplo, podemos ver que SSH utiliza TCP Wrappers:

# ldd $(which sshd) | grep libwrap
 libwrap.so.0 => /lib64/libwrap.so.0 (0x00002aae2628b000)

PoC: Playing with the ZFS compression

Como muchos sabrán, ZFS o ZettaByte filesystem es un sistema de 128 bits archivos diseñado por los ingenieros de Sun Microsystems para ser realmente grande, Jeff Bonwick, el arquitecto jefe de Sun para ZFS, dijo "Llenar un sistema de archivos de 128 bits excedería los límites cuánticos de almacenamiento de la Tierra. No puedes rellenarlo sin hervir los océanos". Una de las ventajas prácticas de ZFS es que integra el volume manager y el filesystem en un solo toolkit.

En este post, trataré de hacer una prueba de conceptos sobre uno de los features más interesantes que tiene ZFS, que es la compresión. Actualmente vivimos en una época en que el storage es un recurso barato, y el sentido de usar esta es mejorar de manera considerable el I/O del dataset, el dato al estar compreso ocupa menos, por lo cual se tienen que leer y escribir datos mas pequeños en el disco lo cual reduce la taza de I/O pero aumenta gradualmente la carga de las CPU's del equipo.

Para este ejemplo sobre FreeBSD 8.2 64 bits vamos a crear filedisks, iniciando un pool de discos con mdadm.
Vamos manos a la obra:

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.