De AIX 5.3-07 a 5.3-11

Ayer, intentando actualizar un AIX 5.3-07 a 5.3-11, me fundí una máquina. Bueno, no del todo. La aplicación de los parches que había funcionado en otras máquinas que estaban en 5.3-08 y las había subido a 5.3-11, en ésta no funcionaba. Parece ser que dar un salto tan grande no le gustaba.

Así que me decidó por hacer una migración con los discos de instalación de la 5.3-08. Cuál fue mi sorpresa cuando, habiendo arrancado de CD, las únicas opciones que me daba eran ‘Complete installation” o ‘Preserved installation’ total, que ‘preserved’.

Me tocó instalar de nuevo el SSH pero eso fue lo de menos.

Me encontré con que había hecho una instalación prácticamente nueva, el /etc/passwd limpito, igual que los grupos… y los FS que habían en rootvg del motor de Oracle, por el aire.

Éstos los pude salvar finalmente, pues el FS estaba, pero no su punto de montaje, una cosa muy rara. Los fui creando uno a uno y montando sin problemas. Abuff!! Luego creamos los usuarios necesarios y todo solucionado. Ya están trabajando sobre ella con versiópn 5.3-11.

La experiencia es un grado (muy alto)

Anuncios

Y volvió a caer

Ésta mañana al llegar al curro me he encontrado un bonito correo.

La compañera que está en BBDD nos envía un mail diciendo que a las 0.15 la máquina volvió a caer. La misma máquina que cayó hace unos días por problemas con los snapshots ahora, sin snaps, ha vuelto a caer con exactamente los mismos errores.

La salida del errpt nos dice ésto:

A6DF45AA   1110001009 I O RMCdaemon      El daemon se ha iniciado.
67145A39   1110000709 U S SYSDUMP        VUELCO DEL SISTEMA
F48137AC   1110000609 U O minidump       COMPRESSED MINIMAL DUMP
9AA1914A   1110000609 P S SYSVMM         REFERENCIA A MEMORIA NO VÁLIDA
9DBCFDEE   1110000709 T O errdemon       ACTIVADO REG. CRONOL. DE ERRORES

La teoría que teníamos basada en que los snaps tenían la culpa de ésta asignación a memoria no válida se nos ha ido al garete. Ahora estamos preparando un snap (de otro tipo, jejeje) para enviarlo a IBM.

Algunos cambios

Estoy pensando en añadir algo de redundancia y seguridad al server de casa ya que tengo varias máquinas virtuales y varios gigas de datos que si se perdieran sé de una que me cortaba algo…

He consultado precios y tal en un par de tiendas, sólo me falta ver si en server me permite montarlo.

La idea sería comprar 4 o 5 discos duros. 2 no muy grandes, 160GB más que suficiente, no hay más pequeños, y montar ahí el SO en mirror por software. Si tengo 5 puertos SATA que no lo sé…, lo siguiente sería pillar 3 discos de 1TB y hacer un RAID 5, con lo que se me queda un espacio de 2TB sobradísimo teniendo en cuenta que tengo ahora unos 400GB de datos. Si no me quedasen SATA’s libres, ésto es, que tenga sólamente 4 que es lo que me temo, compro sólamente 2 discos de tera y hago otro mirror, con lo que tengo igualmenete los 2 TB  pero pierdo redundancia y seguridad.

Además de ésto, quiero cambiar el SO. Voy a probar CentOS, la rama gratuíta de RHEL, así me familiarizo con el entorno del curro y con la futura certificación…

Snapshots problemáticos

Actualización 18/11/09

Como bien me apuntó mi compañero (que debe ser el único que ha entrado al blog) tengo que decir que los snapshots no tienen nada que ver con las caídas de máquina que hemos estado sufriendo.  Sólo fueron una fatídica concurrencia de tareas que se nos presentó.

Lo único que pasa si se nos llenan los LV donde están hechos los snapshots es que la copia no será consistente, de hecho, al hacer un simple ls del directorio donde los tenemos montados nos devuelve un error de E/S, pero nada más.

#################################

El otro día y más concretamente ayer, nos tocó tirar de  snapshot de la BBDD para hacer una copia y replicar el entorno productivo en el entorno de pruebas.  La cosa se nos fue de las manos la última semana, parecía que la caída de la máquina algo tenía que ver con el snap que habíamos hecho pero no había nada demostrado.

Para los que no sepan de qué va ésto de los snapshots, una breve explicación:

Lo primero que hay que saber es que sólo se pueden hacer snapshots de filesystems, si tenemos volúmenes lógicos de tipo RAW como hace tiempo se hacía para aumentar el rendimiento, no nos dejará hacerlo.

Al crear un snapshot de un filesystem, estamos creando punteros al contenido del filesystem en un determinado momento. Ésto tiene sus ventajas e inconvenientes. La ventaja principal que se nos presenta es la rapidez con la que lo hacemos. Ésto nos permite parar la BBDD, lanzar el snapshot de todos los FS de la BBDD y volver a levantarla, todo ésto en 5 minutos escasos. Una vez que tenemos el snap, arrancamos de nuevo la BBDD. El snapshot apuntará a los ficheros tal cual estaban cuando se hizo, teniendo los FS consistentes para hacer la copia. Podemos entonces montar los snaps y hacer la copia a otro FS.

En condiciones normales, ésta teoría se convierte en práctica satisfactoria. Pero éstas últimas veces….. no se ha dado tan bien como esperábamos.

En éste entorno, con una BBDD de 800GB con mucho, mucho, mucho trasiego de datos, los volúmenes lógicos que albergan los snapshots se empiezan a saturar. Y aquí viene la desventaja del snapshot: los punteros de los snaps apuntan a los ficheros tal cual estaban cuando se lanzó, pero si hay modificaciones y mucha entrada/salida, los datos nuevos necesitan ser copiados o mirroreados a la ubicación donde está el snapshot, para mantenerlo consistente. Y aquí nos vino el problema: los volúmenes lógicos de los snaps se llenaron, la máquina no podía satisfacer los requerimientos de espacio y, para asombro de todos, volcado de memoria, system dump y máquina caída. Es algo que no me explico. En vez de llenarse el LV y decir que no puede serguir copiando en él, como si fuera un LV cualquiera, pues no, se cuelga la máquina entera! Increíble. Estamos en nivel de versión 5.3.00-11 y ésto todavía no lo han arreglado… en la versión 6.1 ya no hay referencias a éste error, espero que lo solucionen.

De momento, ésta mañana me ha tocado arrancar la BBDD a mí, menos mal que hasta las 9 no empieza la gente a trabajar…

Trasteando con NMON

En el curro me han pedido alguna herramienta para monitorizar los servidores AIX y Linux y tener un histórico para poder consultar y ver la evolución y tal.

Lo que he encontrado para ambos sistemas es NMON y la verdad es que va de narices.

Como mejor explicación no escuentro otra mejor que la que nos trae el man:

“Displays local system statistics in interactive mode and records system
statistics in recording mode.”

Hay bastante información y enlaces de descarga en:

http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon

Una vez que tenemos el fichero .nmon con los datos estadísticos en “bruto” necesitamos algo para poder leerlos. Hay una hoja de cálculo hecha en Excel con unas macros las cuales te procesan todo el fichero .nmon y te crean hojas con los datos. Ésta podría ser una solución pero nos obligaba a pasar por un Windows así que siempre que podamos evitarlo, mejor.

Hay otra herramienta: nmon2rrd

Ésta nos coje el mismo fichero .nmon y nos genera gráficas al estilo del MTRG todo dentro de un HTML que podemos colgar en cualquier servidor web. Así que ya tenemos la solución.

En el crontab de cada máquina ponemos una tarea que a las 0:05 empiece a recoger información, hasta las 23:55 del mismo día. Acto seguido se pasa éste ficherito por scp o como se quiera a la máquina Linux que va a generar los html. En ésta máquina destino ponemos otra tarea que sea ejecutar un script que recoge todos los .nmon, los procesa y según el día crea un directorio nuevo para tener los html ordenaditos por carpetas y poder navegar por días.

El script, un poco rudimentario quizá pero efectivo, lo teneis aquí:

#!/bin/bash

cd /var/log/nmon
ls | grep -v auto | grep -v temp | grep -v old > temp
export ruta=/var/www/nmon

cat temp | while read k
do
nmon=$k
export maq=`echo $nmon | cut -d “_” -f 1`
export dia=`echo $nmon | cut -d “_” -f 2 | cut -d “-” -f 1`
export mes=`echo $nmon | cut -d “_” -f 2 | cut -d “-” -f 2`
export anyo=20`echo $nmon | cut -d “_” -f 2 | cut -d “-” -f 3 | cut -d “.” -f 1`
if [ ! -d $ruta/$maq ]
then
mkdir $ruta/$maq
fi
if [ ! -d $ruta/$maq/$anyo ]
then
mkdir $ruta/$maq/$anyo
fi
if [ ! -d $ruta/$maq/$anyo/$mes ]
then
mkdir $ruta/$maq/$anyo/$mes
fi
if [ ! -d $ruta/$maq/$anyo/$mes/$dia ]
then
mkdir $ruta/$maq/$anyo/$mes/$dia
fi
nmon2rrd -f $nmon -d $ruta/$maq/$anyo/$mes/$dia -x
mv $nmon $nmon.old
sleep 3
done

Aquí tenemos un ejemplo:

nomn1nmon2

 

 

Por último sólo decir que el nmon2rrd está para AIX pero se distribuye el fiuente en C, así que sólo hay que compilarlo con un gcc desde el Linux y ponerlo en una ruta accesible.

Buenas sensaciones

La verdad que hacía tiempo que no le había dado ninguna oportunidad a otra distro de escritorio que no fuera Ubuntu ya que estaba bastante contento con el funcionamiento, la facilidad de configuración y facilidad de administración por estar basado en Debian.  Una vez desinstalado el NetworkManager e instalado el Wicd la cosa empezaba a ir bastante bien.

Pero no hace mucho, tras una actualización el touchpad me deja de funcionar.  Para flipar. Leyendo por ahí veo cosas como que el kernel tiene alguno que otro bug en lo referente a éste hardware, pero era para una versión anterior, se supone que en las siguiente revisiones ya deberían haberlo solucionado. Bueno, pues tras 3 revisiones más, no me funciona ni el touchpad ni la sintonizadora de tv que antes funcionaba a las mil maravillas.

Total que SuSE/OpenSuSE ni de coña, Fedora ya lo probé y me pegada unas petadas importantes, CentOS podría ser un candidato pero me decidí por probar primero Mandriva.  La comunidad de usuarios es bastante grande tb y un compañero del curro está bastante contento con ella así que adelante.

Me he instalado la 2009 para 64bits y la verdad es que hasta el momento todo son facilidades.  Lo único que no funcionó es la tarjeta inalámbrica, lo cual no es de extrañar, ya sabemos todos lo que pasa con las Broadcom. Bastó con descargar el firmware, dejarlo en /lib/firmware descargar el bt43 cutter y reiniciar.

wifi

wifi

Por otra parte trae de serie configurados todos los repos que de momento me han hecho falta y, al igual que apt-get, tenemos urpmi para instalar, urpme para desinstalar, urpmf para buscar, etc.

Tambien trae un entorno de administración de la máquina mucho más liviano que YaST, aunque muy parecido, el cual con 1 par de clics me permitió activar los efectos de escritorio, además de decirme que me hacían falta unos cuántos paquetes que se descargó e instaló sin ningún problema.

En definitiva, aunque el servidor corre Ubuntu Server y las máquinas virtuales Debian Etch, Mandriva me está dando muy buenas sensaciones para entornos de escritorio.

Problemas con SNMP

Actualización 18/11/09

Finalmente, he averiguado por qué fallaban tantos servicios en el arranque, no fallaban, sencillamente no arrancaban. Resulta que el /etc/rc.tcpip estaba vacío, no preguntéis el por qué, ni yo lo sé. Lo he cogido y modificado de otra máquina. En próximos reinicios se probará.

Tras la cagarsis del último día y numerosos reinicios, innecesarios por otra parte, el SNMP de una de las máquinas AIX no respondía correctamente.  Desde la máquina de monitorización sólo contestaba a:

snmpwalk -v 1 -c public x.x.x.x system

El chequeo de los FS que es para lo que principalmente gastamos la monitorización, nada de nada, era como si hubiera perdido las MIB’s.

El refresh del servicio tampoco fue satisfactorio y las demás máquinas tenían los mismos servicios, aparentemente.

Resulta que hay por ahí un par de servicios que deben estar tb levantados, a saber: aixmibd y hostmibd

startsrc -s aixmibd

startsrc -s hostmibd

# snmpwalk -v1 -c public x.x.x.x  HOST-RESOURCES-MIB::hrStorageDescr

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: /dev/hd4
HOST-RESOURCES-MIB::hrStorageDescr.2 = STRING: /dev/hd2
HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: /dev/hd9var
HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: /dev/hd3
HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: /dev/hd1
HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: /dev/hd10opt
HOST-RESOURCES-MIB::hrStorageDescr.7 = STRING: /dev/fslv00
HOST-RESOURCES-MIB::hrStorageDescr.8 = STRING: /dev/fslv01
HOST-RESOURCES-MIB::hrStorageDescr.9 = STRING: /dev/fslv07
HOST-RESOURCES-MIB::hrStorageDescr.10 = STRING: /dev/localsislv
HOST-RESOURCES-MIB::hrStorageDescr.11 = STRING: /dev/localtsmlv

[…]

No sigo porque la lista es bastante grande. Ahora queda la cuestión de por qué no se levantaron al encender la máquina.