SyntaxHighlighter

Mostrando entradas con la etiqueta hp. Mostrar todas las entradas
Mostrando entradas con la etiqueta hp. Mostrar todas las entradas

viernes, 31 de octubre de 2014

Cambio de disco en una cabina de discos HP Modular Smart Array (MSA 2000)

No es la primera vez, ni será la última. Puedes gastarte un dineral en comprar los dispositivos más fiables del mercado, intentar que las condiciones de funcionamiento sean las mejores (UPS, refrigeración, etc) pero al final sabes que se romperán.

Los administradores de sistemas tenemos la obligación de ser paranoicos dentro de las posibilidades económicas de la empresa y las de que nuestra salud mental, por eso en cada intervención delicada en uno de nuestros sistemas debemos, al menos:

  1. Ponernos al día sobre la actuación leyendo el material recomendado por el fabricante, foros explicando procedimientos similares
  2. Documentar el estado actual del sistema, para poder reproducirlo después del cambio: versiones del software, opciones de configuración más importantes, etc
  3. Ensayar la actuación en un sistema de pre-producción
  4. Hacer copias de seguridad
  5. Si es posible tener un sistema "gemelo" montado aunque sea en máquinas menos potentes o virtuales para usar como "plan B" en caso de que las cosas se compliquen
  6. Hacer copias de seguridad... ¿Lo he puesto antes? Da igual, no está de más decirlo otra vez
Presento el sistema. Matriz de discos HP MSA Modular:


Los sistemas de gama empresarial normalmente sintonizan con nuestra paranoia. Algo tan aparentemente leve como que uno de los discos tarde un poco más en girar (spin-up time) o se detecte alguna anomalía eléctrica hace que se disparen las alarmas y el disco pase a ser "no confiable". Ahora entran en juego dos conceptos muy importantes en sistemas de este tipo.

RAID y SPARE

  • RAID. Algunas configuraciones de RAID son tolerantes a fallos, de manera que aunque perdemos espacio de almacenamiento ganamos seguridad. Por ejemplo, un conjunto de discos configurados en RAID 5 utiliza el espacio de almacenamiento de un disco como espacio de redundancia, de manera que si perdemos un disco, no se pierden datos. Se puede sustituir por otro disco y el sistema reconstruirá el conjunto.
  • Discos SPARE (hotspare) o "discos reserva". Además podemos definir dentro de la cabina discos que no se utilizan, pero están preparados para sustituir a otro que falle inmediatamente, sin intervención nuestra.
En sistemas de este nivel SIEMPRE se utiliza algún sistema de redundancia que variará para maximizar la seguridad, la velocidad de escritura, la velocidad de lectura, etc.,  y, por supuesto, discos spare.

Por ejemplo, los sistemas RAID 1 (mirror) acelera las lecturas ya que se puede leer de dos discos al mismo tiempo, en cambio, la escritura lleva un tiempo similar a sistemas de disco único. Usamos la mitad de la capacidad total en datos de redundancia. Aquí somos tolerantes a fallos siempre que el disco o discos se encuentren en el mismo conjunto del espejo.

Otros niveles de RAID, como RAID5, hacen que se pierda menos espacio. Si tenemos n discos, el espacio total será el de n-1 discos ya que uno se usa como disco redundante. Aquí no se gana tanto rendimiento de lectura como en RAID1 pero aún así, bajo ciertas circunstancias, se acelera la lectura respecto a sistemas de disco único. La escritura se ve penalizada al tener que calcular el contenido del bloque de paridad, que ya no es un proceso tan inmediato como hacer una copia del bloque en otro disco. Este nivel RAID tolera fallos en un sólo disco. RAID6, es similar a RAID5, pero usa dos discos para redundancia, por lo que se tiene tolerancia a fallos en dos discos.

Las combinaciones de niveles RAID están permitidas. Es decir, se puede hacer RAID5+0.

Frío y Calor

Hay sistemas capaces de implementar RAID en software, pero lo interesante es tener una controladora de discos que lo soporte en hardware y así hacerlo menos dependiente del sistema operativo. Éste es el caso de las controladoras de discos que estamos viendo.

Suponiendo una configuración RAID5 con spare, en el momento que falle un disco, la cabina lo detecta, lo tacha como "no confiable" y usa el disco spare como nuevo disco en el conjunto RAID. Este proceso puede hacerse en frío, si necesitamos reiniciar el sistema o dar la orden de resconstrucción y esperar el tiempo necesario para que se reconstruya; o en caliente, si la controladora es capaz de seguir dando servicio mientras el disco spare se reconstruye y además no necesita que intervengamos en el proceso.

Rompiendo un disco

Lo que voy a hacer es reproducir el proceso de sustitución de un disco en fallo en una cabina en la que todos los discos están bien. Extraeré uno de los discos del array para simular en fallo. 
Primero vamos a ver el estado de la cabina:


En la imagen vemos que hay ocho discos, siete forman un conjunto RAID6 y uno de ellos configurado como SPARE. Podrían romperse dos discos del conjunto RAID6 y aún no perderíamos datos. Además, como veremos, en el momento que falle uno de ellos el disco SPARE intentará sustituirlo.

Otra vista, pero esta vez voy a insertar un disco nuevo en la cabina. Como no hemos dicho para qué debe utilizar ese nuevo disco lo define como "disponible". Este disco no se utilizará para nada hasta que no se defina su función de forma explícita. Vemos el disco spare (VDISKSP).


Sacamos un disco y a ver que pasa.


Reconstrucción de un VDISK (RAID 6)

Si pinchamos en el estado de la MSA vemos que ha empezado a reconstruir el RAID6 inmediatamente. El proceso tardará unas horas dependiendo del tamaño del VDISK, la configuración RAID y el grado de utilización de los datos de la cabina mientras se hace la reconstrucción ya que la cabina seguirá activa para lectura y escritura.

En la figura anterior tenemos varios campos relacionados con la salud (health). Vemos que la cabina está degradada aunque aún es tolerante a fallos. En la parte inferior vemos en current job que el disco se está reconstruyendo.


En el esquema gráfico de la cabina se puede ver que hemos vuelto "pinchar" el disco en su lugar. La MSA sabe qué disco es, sabe que ha estado pinchado con anterioridad y por algún motivo ha fallado, así que lo marca como LEFTOVR (descartado). No usará este disco más a no ser que la "hagamos olvidar".

Una vez reconstruido el disco tenemos esta estructura.


El disco 1.8 que antes estaba como SPARE pasa a formar parte del VDISK.

Ahora para recuperar el disco que hemos sacado debemos borrar sus metadatos. Esto se puede hacer desde la opción clear disk metadata, como vemos en la imagen siguiente.


Borrando los metadatos el disco volverá a estar disponible (AVAIL). Por último modificamos los discos SPARE de la MSA para incluir estos discos disponibles no usados.


En el menú provisioning la opción Manage Global Spares donde podemos definir los discos que se podrán usar como SPARE en cualquier VDISK de la MSA. También podríamos definir discos SPARE reservados para un VDISK determinado.

Este sería el estado final donde se ve el primer disco que retiramos de la cabina como Global Spare. Y el VDISK totalmente reconstruido.


Todo correcto :D



viernes, 21 de marzo de 2014

Data Protector. Recuperación usando la directiva POST-EXEC y SCRIPTING

Con Data Protector podemos programar una agenda de copias de seguridad fácilmente usando la GUI Java, lo que no es tan simple es planificar una calendario de restauración que, por ejemplo, recupere la última copia de seguridad realizada en otra localización.

La primera aproximación sería intentar ejecutar esta restauración llamando al programa omnir con los argumentos necesarios e incluir la llamada en el cron del servidor para que se ejecute periódicamente. Lo que a priori parece algo sencillo se complica con sólo mirar la la página de manual de omnir (o buscar "data protector cli reference" en cualquier buscador). El Backend de comandos de Data Protector da toda la funcionalidad que necesitamos para restaurar una copia de seguridad, pero es necesario la ejecución de varias órdenes para "montar" los argumentos que necesita omnir.

Hay otro problema en cuanto a la inclusión en cron de esta orden podría dar lugar a solapamientos en el uso de la unidad sobre la que estemos haciendo la copia de seguridad.

Imaginad que la copia de seguridad programada comienza a las 2:00 am, y nuestra orden de restauración se ejecuta vía cron a las 4:00 am. Si la copia de seguridad tarda más de 2h, la restauración se podrá en cola. Pasado cierto tiempo de espera configurable en Data Protector, si aún no ha comenzado el trabajo de restauración, se procederá a su cancelación. Esto se puede evitar usando las opciones POST-EXEC y PRE-EXEC del trabajo de copia de seguridad.

Estas dos opciones se encargan de ejecutar un script en el cliente de data protector que indiquemos antes (PRE-EXEC) o después (POST-EXEC) de que se realice el trabajo de backup. El uso más extendido de estas dos opciones es el de parar un servicio antes de realizar el trabajo de copia y levantarlo después.

Para conseguir el comportamiento que necesitamos lo ideal sería ejecutar un script en POST-EXEC que llame a omnir con los datos de la última copia de seguridad. Para conseguir los datos necesarios de la última sesión de copia de seguridad hay que ejecutar la orden onmidb, que consulta la BD de Data Protector para extraer la información que requiere omnir:

/opt/omni/bin/omnir -filesystem [datalist] [label] -session [session] -tree [path] -as [target_path] -target [target_client]

Pasos del script:
  1. Considera un número de días hacia atrás desde la fecha actual para buscar la última sesión de la agenda especificada.
  2. Determinar sesión más reciente que se terminó satisfactoriamente en el intervalo definido en el paso anterior.
  3. Buscar el árbol de directorios que queremos restaurar y extraer el datalist y label, argumentos necesarios para ejecutar omnir.
  4. Ejecutar omnir con los parámetros adecuados.
El código del script (un poco sucio):

#!/bin/bash
OMNI_PATH=/opt/omni/bin/

if [ $# -ne 5 ]; then
  echo "Ilegal number of arguments" >&2
  echo "Use: $0 [dataList] [label] [targetClient] [targetDir] [RestoreOnlyIfFull 0/1]" >&2
  exit 1
fi

ARG_DATALIST=$1
ARG_LABEL=$2
ARG_TARGETCLIENT=$3
ARG_TARGETDIR=$4
ARG_ONLYFULL=$5
DAYSTOINSPECT=30

INITIALDATE=$(date '+%Y/%m/%d' --date="${DAYSTOINSPECT} days ago")
LASTSESSION=$(${OMNI_PATH}omnidb -session -datalist $ARG_DATALIST -since $INITIALDATE | grep -i backup | grep -i completed | tail -n1 | cut -f 1 -d " ")
FILESYSTEM=$(${OMNI_PATH}omnidb -session $LASTSESSION | grep \'${ARG_LABEL}\' | cut -f1 -d " ")
LABEL=$(${OMNI_PATH}omnidb -session $LASTSESSION | grep \'${ARG_LABEL}\' | cut -f2 -d " ")
BACKUP_LEVEL=$(${OMNI_PATH}omnidb -filesystem $FILESYSTEM ${ARG_LABEL} -session $LASTSESSION | egrep -o "Incremental|Full")

if [ -z "$LASTSESSION" ]; then
 echo "Session not found: $ARG_DATALIST. Available schedules:"
 ls /etc/opt/omni/server/schedules >&2
 exit 1
fi

if [[ $ARG_ONLYFULL -eq 1 && $BACKUP_LEVEL != "Full" ]]; then
 echo "Mode is set to full but cannot find full backup" >&2
 exit 1
fi

if [ -z "$LABEL" ]; then 
 echo "Label not found: $ARG_LABEL. Backed up filesystems and labels:"
 omnidb -filesystem >&2
 exit 1
fi

#Print command options
echo "Restoring label: ${LABEL}, filesystem: < $FILESYSTEM > from Session: $LASTSESSION into ${ARG_TARGETCLIENT}:${ARG_TARGETDIR}, backup_level: $BACKUP_LEVEL"
#Print omnir command used to perform the restore job. Debug.
echo ${OMNI_PATH}omnir -filesystem ${FILESYSTEM} ${LABEL} -session ${LASTSESSION} -tree ${ARG_LABEL} -as ${ARG_TARGETDIR} -target ${ARG_TARGETCLIENT}
OMNI_COMMAND="${OMNI_PATH}omnir -filesystem ${FILESYSTEM} ${LABEL} -session ${LASTSESSION} -tree ${ARG_LABEL} -as ${ARG_TARGETDIR} -target ${ARG_TARGETCLIENT}"
eval $OMNI_COMMAND

Si a la orden omnir que se llama al final del script añadimos -full antes del argumento -filesystem se restaurará una copia completa del árbol de directorios usando la última copia completa que se realizó y todas las incrementales hasta la sesión que estamos restaurando. De otra manera sólo se restaurarán los ficheros que se respaldaron en la sesión en cuestión.  El último argumento del script controla los problemas que se puedan derivar de esto: sólo se ejecutará la restauración si la última copia ha sido full.

No está de más ejecutar el script comentando la última línea (eval ...), para comprobar que todo es correcto antes de empezar a utilizarlo. Si alguno de los parámetros no es correcto imprimirá posibles soluciones.

Por último, el directorio en el que tenemos que incluir el script para que no haya problemas es /opt/omni/lbin y así podremos llamarlo sin usar path completo, algo que parece que no funciona bien si configuramos el POST-EXEC desde la GUI Java.

NOTA. Si la restauración toma demasiado tiempo, Data Protector puede abortar el Script. Para evitarlo se puede modificar la opción ScriptOutputTimeout en el fichero /etc/opt/omni/server/options/global

viernes, 2 de agosto de 2013

Amanda Backup I: Instalación y Configuración

Amanda es una de las soluciones OpenSource (BSD License) de tipo empresarial que puedes utilizar para realizar copias de seguridad de tus servidores.

Una de las características que me hicieron elegir este software frente a otros a la hora de hacer backup de los datos más importantes de mi empresa es que no utilizar ningún tipo de formato propio para almacenar esas copias, es decir, puedes recuperar las copias de seguridad desde otra máquina sin la necesidad de tener instalado/configurado el software, puedes manejar todo el proceso con órdenes estándar del sistema operativo, como tar, mt, cron, etc.
Es un software muy potente comparable a Bacula, por ejemplo, y que tiene una estructura similar: habrá una máquina que hará de servidor de copias de seguridad que atenderá a varios clientes siguiendo una agenda determinada. La instalación y configuración es bastante sencilla, quizás más que la de Bacula, la herramienta

En esta entrada haré un repaso de la instalación y configuración del software en un equipo HP Proliant con una unidad de cinta Ultrium 232 (LTO1) algo antigua, en la que se ejecuta un sistema CentOS 6.

Backup en cintas

Para ejecutar Amanda usando la unidad Ultrium como dispositivo de copia de seguridad  debemos tener instaladas todas las herramientas de sistema que trabajarán de forma subyacente, especialmente mt-st:
yum install mt-st

Comprobamos la unidad de cinta:

[root@host ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: HL-DT-ST Model: CD-ROM GCR-8486B Rev: 2.00
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi3 Channel: 00 Id: 03 Lun: 00
  Vendor: HP       Model: Ultrium 1-SCSI   Rev: P61D
  Type:   Sequential-Access                ANSI  SCSI revision: 03
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: BENQ     Model: DVD DD EW162I    Rev: 47F9
  Type:   CD-ROM 
[root@host ~]# dmesg | grep -i tape
st 3:0:3:0: Attached scsi tape st0
osst :I: Tape driver with OnStream support version 0.99.4


Tenemos la unidad ultrium en st0. Aquí tenemos una de las primeras curiosidades con respecto a la gestión de dispositivos secuenciales: las interfaces /dev/st0 y /dev/nst0 ser refieren al mismo dispositivo, la diferencia es que si usamos st0 el sistema considerará el dispositivo como "rebobinable" en cambio si usamos nst0 accederemos a un dispositivo "no rebobinable". La diferencia es que después de cualquier operación sobre st0 la cinta se rebobinará, por lo tanto toda operación sobre la cinta comenzará en el bloque 0 lista para una operación de "rewrite". En el dispositivo nst0, después de una operación la cinta estará lista para una operación de "append" sin destruir los datos grabados hasta el momento.

Comprobaré que la cinta funciona correctamente, por ejemplo, extrayendo información sobre la misma o extrayendo la unidad:

mt -f /dev/nst0 offline # Extrae la cinta

[amandabackup@host root]$ mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=1, partition=0.
Tape block size 0 bytes. Density code 0x40 (DLT1 40 GB, or Ultrium).
Soft error count since last status=0
General status bits on (1010000):
 ONLINE IM_REP_EN


Al intentar ejecutar otras órdenes en las que si se accede a la cinta como mt -f /dev/nst0 tell, que dice el bloque en que se encuentra la cinta, da un error de entrada salida. Para solucionarlo se han de ejecutar estas dos órdenes: Más información sobre la configuración de las cintas Ultrium en los manuales de HP.

mt -f /dev/nst0 stsetoptions scsi2logical # Hace que el driver st use direccionamiento lógico
mt -f /dev/nst0 setblk 0                  # Establece la lectura de bloques de tamaño variable. Ver enlace de Info anterior.

Instalación y configuración de Amanda

Server: Instalación


Una vez comprobado el funcionamiento de la unidad de cinta continuamos con la instalación y configuración de Amanda en CentOS. Vamos a configurar Amanda para que realice copias de seguridad del mismo servidor (local), así que necesitamos instalar el software de cliente y de servidor. 

yum install amanda amanda-server amanda-client

La instalación en CentOS crea el usuario amandabackup que será desde el que realizaremos la mayoría de las interacciones con Amanda. También crea los grupos disk y tape en los que incluirá al usuario amandabackup, estos grupos tendrán permisos para acceder a varios directorios, dispositivos y ficheros de configuración necesarios. También crea archivos de configuración que tendremos que modificar. En el directorio /etc/amanda y /etc/amanda/DailySet1 tenemos también plantillas de archivos de configuración.
Amanda se ejecuta vía xinetd, así que tendremos que configurar el servicio. Aunque la instalación ha creado el archivo en /etc/xinetd.d/amanda sustituimos por el archivo xinetd.amandaserver que encontramos en el directorio /etc/amanda/DailySet1/. Este archivo define los servicios de Amanda que estarán activos en el servidor, estos servicios vienen determinados por el parámetro server_args.

  • amdump. Es el servicio (máquina cliente y servidor) que se encarga de realizar las copias de seguridad.
  • amindexd. Es el servicio (servidor) que mantiene el catálogo de Amanda. Muchas herramientas de Amanda se comunican con este servicio. Es necesario para ejecutar amrecover, la herramienta interactiva de recuperación de datos, es muy similar a un servicio de FTP que es accedido por la herramienta amrecover.
  • amidxtaped. Servicio (servidor) que se comunica con la unidad de cinta.
Archivo /etc/xinetd.d/amanda

# default: on
#
# description: Amanda services for Amanda server and client.
#
service amanda
{
        disable         = no
        flags           = IPv6
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = amandabackup
        group           = disk
        groups          = yes
        server          = /usr/lib64/amanda/amandad
        server_args     = -auth=bsdtcp amdump amindexd amidxtaped
}

Siempre que hagamos algún cambio en este archivo debemos recargar xinetd con la orden service xinetd reload.

Server: Configuración de los trabajos de copia

La configuración de los trabajos de copia de seguridad se hace desde los subdirectorios dentro de /etc/amanda. Por ejemplo, hemos copiado la configuración por defecto que incluye la instalación al directorio DailySet1. Dentro de este directorio establecemos todos los parámetros para realizar las copias de seguridad. Hay que tener en cuenta que para casi cualquier operación que hagamos con Amanda tendremos que especificar este identificador.
El fichero principal es el fichero amanda.conf dentro del directorio de configuración. Los cambios más importantes son:
mailto= "admin@email.es"     # Email que recibirá las notificaciones. Hay que modificar .mailrc en /var/lib/amanda/ para que funcione. Después se explica.
dumpuser="amandabackup"     # Usuario que se utiliza para ejecutar dump en el cliente.

dumpcycle 1 weeks           # Asegura al menos haya una copia completa cada 1 semana
runspercycle 4              # Cuantas veces se lanza el dump cada dumpcycle
tapecycle 4 tapes           # Número de cintas que se conservan antes de empezar a reciclar.

runtapes 1                  # Número de cintas que se permiten para un trabajo de copia. Si una copia no cabe en una cinta debemos subirlo. Sólo se usan las necesarias.
#tpchanger "scrtip"         # Script que se encarga de cambiar cintas. Como cambiaremos las cintas manualmente comentamos.
tapedev "tape:/dev/nts0"    # Dispositivo que se usa para realizar las copias.
tapetype HP-ULTRIUM-LTO1    # Tipo de cinta. HP-ULTRIUM-LTO1 debe estar definido como tipo de cinta en la sección ''define tapetype''. Ver más adelante.
labelstr "^DailySet1-[0-9][0-9]*$"     # Expresión regular que restringe la etiqueta de las cintas que se aceptan. Todas las cintas ser etiquetadas según este patrón.

#holdingdisk  hd1 {         # Discos buffer en los que se hará un dump previo, después se copiará a la cinta. Desactivado (comentado) por problemas de espacio en el servidor.
#...
#}

infofile "/etc/amanda/DailySet1/curinfo"    # database DIRECTORY
logdir   "/etc/amanda/DailySet1"            # log directory
indexdir "/etc/amanda/DailySet1/index"              # index directory
tapelist "/etc/amanda/DailySet1/tapelist"   # list of used tapes

define tapetype HP-ULTRIUM-LTO1 {          # Definición de la cinta. Extraída del enlace http://tirpitz.iat.sfu.ca/wiki/index.php?title=Backups_with_AMANDA
    comment "LTO-1. Añadido por Emilio"    # Amanda puede examinar la cinta para obtener su definición usando la orden 'amtapetype -f /dev/nst0'
    length 96512 mbytes
    filemark 0 kbytes
    speed 13611 kps
}

# A continuación vienen las definiciones de los tipos de dumps estándares. En el fichero se comentan todas las opciones posibles y se pueden crear nuevos o modificar existentes, 
# que después habrá que especificar en el fichero disklist. Estas definiciones se pueden anidar, como se ve en el ejemplo. Estamos usando comp-user-tar, cuya definición es:
define dumptype global {
    comment "Global definitions"
    # This is quite useful for setting global parameters, so you don't have
    # to type them everywhere.  All dumptype definitions in this sample file
    # do include these definitions, either directly or indirectly.
    # There's nothing special about the name `global'; if you create any
    # dumptype that does not contain the word `global' or the name of any
    # other dumptype that contains it, these definitions won't apply.
    # Note that these definitions may be overridden in other
    # dumptypes, if the redefinitions appear *after* the `global'
    # dumptype name.
    # You may want to use this for globally enabling or disabling
    # indexing, recording, etc.  Some examples:
    # index yes
    # record no
    # split_diskbuffer "/raid/amanda"
    # fallback_splitsize 64m
    auth "bsdtcp" # Añadido para forzar la autenticación bsdtcp
}


define dumptype root-tar {
    global
    program "GNUTAR"
    comment "root partitions dumped with tar"
    compress none
    index
#   exclude list "/etc/amanda/exclude.gtar"
    priority low
}
define dumptype user-tar {
    root-tar
    comment "user partitions dumped with tar"
    priority medium
}
define dumptype comp-user-tar {
    user-tar
    compress client fast
}

...
...
Puede que al hacer un amcheck <ID> no se pueda conectar al cliente dando este error:

[amandabackup@host root]$ amcheck DailySet1
Amanda Tape Server Host Check
-----------------------------
read label `DailySet1-04', date `20130314070502'.
Tape with label DailySet1-04 is still active and cannot be overwritten.
       (expecting tape DailySet1-01 or a new tape)
Server check took 0.096 seconds

Amanda Backup Client Hosts Check
--------------------------------
WARNING: host: selfcheck request failed: timeout waiting for ACK
Client check: 1 host checked in 30.036 seconds.  1 problem found.

(brought to you by Amanda 2.6.1p2)
Se soluciona especificando en amanda.conf el tipo de autenticación en la definición dumptype. Yo lo he añadido en la definición de dumptype global, como aparece en el enlace.

Ahora debemos indicar a Amanda las máquinas a las que tendrá que acceder, los datos que deberá respaldar y el tipo de dump que realizará para cada uno. Esto se hace mediante el archivo disklist dentro del directorio /etc/amanda/DailySet1:

host  /var/backups comp-user-tar
host  /etc   comp-user-tar

Antes de poder hacer copias de seguridad debemos etiquetar las cintas para que sean reconocidas por amanda. Para ello introducimos una por una las cintas y las etiquetamos de la siguiente forma, donde XX es el número de cinta:
amlabel DailySet1 DailySet1-XX

Cada vez que etiquetemos una cinta se añadirá al archivo /etc/amanda/[id]/tapelist. Se puede listar este fichero para ver las cintas.
Para comprobar que funciona podemos ejecutar:
[amandabackup@host root]$ amcheck DailySet1
Amanda Tape Server Host Check
-----------------------------
read label `DailySet1-02', date `20130312070502'.
Tape with label DailySet1-02 is still active and cannot be overwritten.
       (expecting a new tape)
WARNING: tapecycle (4) <= runspercycle (4).
Server check took 0.097 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 2.135 seconds.  0 problems found.

OJO! Esta salida se obtiene una vez configurado todo, la salida real en esta etapa de configuración debería ser similar, lo importante es que no aparezcan problemas en el resultado.

Server: Cron

En el directorio /etc/amanda/ hay un ejemplo de cron. Se puede modificar el cron del usuario amandabackup para programar las copias. Cambiarse al usuario amandabackup y hacer un crontab -e. El contenido actual (pruebas) es el siguiente:

#Amanda Backup
00 07 * * 1-5    /usr/sbin/amcheck -m DailySet1
05 07 * * 1-4    /usr/sbin/amdump DailySet1

Server: Notificaciones por email

Para que funcionen las notificaciones de las copias de seguridad hay que configurar los parámetros de envío creando el archivo /var/lib/amanda/.mailrc:

set smtp=[smtp server]
set from=[admin@email.es]

Client

Primero debemos configurar el servicio amanda en xinetd. Esto ya lo hemos hecho ya que el servidor también es el cliente. Permitir al servidor que acceda al servicio amanda. Para esto se modifica el fichero /var/lib/amanda/.amandahosts:

# host user services. 
# root en el cliente accederá a los servicios amindexdx y amidxtaped para recuperar ficheros.
# amandabackup accederá al servicio amdump
server1 root amindexd amidxtaped
server1 amandabackup amdump

En un segundo post haré un repaso por las órdenes más útiles para hacer copias de seguridad, restauraciones, extraer información del catálogo... Además del manejo de las copias realizadas con herramientas del sistema como mt o tar.

lunes, 7 de mayo de 2012

Configuración rápida de Zabbix + SNMP + HP Insight en un HP Proliant

En el último post estuve cambiando un disco de un HP Proliant. Tengo que decir que enterarte de que un disco falla gracias al led de estado que hay en su carcasa no es lo más adecuado (mea culpa!!). En los servidores Proliant tenemos varios sistemas que nos mantienen informados de cualquier incidencia hardware, entre otros: Las herramientas de configuración-diagnóstico en línea de órdenes (hpacucli, hpasmcli, etc.), la web de monitorización "HP System Manager Homepage" (si la hemos instalado), o el sistema de notificación vía SNMP.

La interfaz de monitorización normalmente se activa al instalar el HP PSP en el puerto 2831. Nos da acceso a gran cantidad de información de estado del servidor con una interfaz gráfica muy cómoda.


En la figura tenemos información del sistema, de las controladoras de discos, del estado de los adaptadores de red, de la interfaz ILO, etc. Es una herramienta muy potente ya que, además, dispone de un log donde se registran todos los cambios en los parámetros monitorizados. Pero falta algo, que nos avise cuando algo falle.

Como vemos en la parte superior derecha de la ventana, en la sección "Data Source", todo el mecanismo de monitorización se hace a través de SNMP, entonces, ¿por qué no ir al origen y consultar directamente estos sensores?

SNMP

La verdad es que tan sólo he leído un poco sobre SNMP, lo justo para poder consultar algunos valores desde Zabbix (aunque también es posible con NAGIOS).

Debemos tener en cuenta que SNMP es un servicio que viene en cualquier distribución de Linux. Con este servicio estándar podemos consultar una serie de monitores básicos de nuestro servidor definidos en una colección MIB (Management Information Base), que no es más que un conjunto de valores organizados jerárquicamente que describen el estado de muchos parámetros del servidor.
No quiero entrar en el tema mucho porque es bastante complejo y no le he dedicado mucho tiempo, así que vamos al grano.

Lo primero que he hecho ha sido comprobar que el servicio está funcionando con, por ejemplo service snmpd status o chkconfig --list | grep snmp con el que además podemos ver si los agentes snmp de HP están funcionando. Si se ha instalado el servicio SNMP y el Proliant Support Pack todo debería estar funcionando. Comprobamos la salida que nos da snmpwalk, que imprime todos los valores en una rama del árbol de indicadores, en este caso system.

[root@localhost ~]# snmpwalk -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:21:01 EDT 2011 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3655739) 10:09:17.39
SNMPv2-MIB::sysContact.0 = STRING: Root  (configure /etc/snmp/snmp.local.conf)
SNMPv2-MIB::sysName.0 = STRING: localhost
SNMPv2-MIB::sysLocation.0 = STRING: Unknown (edit /etc/snmp/snmpd.conf)
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.2 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.3 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.4 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.5 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORID.6 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.7 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.8 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB module for managing TCP implementations
SNMPv2-MIB::sysORDescr.3 = STRING: The MIB module for managing IP and ICMP implementations
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for managing UDP implementations
SNMPv2-MIB::sysORDescr.5 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORDescr.6 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.7 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.8 = STRING: The management information definitions for the SNMP User-based Security Model.
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.6 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.7 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.8 = Timeticks: (0) 0:00:00.00

Si tenemos respuesta de la orden snmpwalk todo está listo para comenzar con la configuración.

La información que podemos extraer con las consultas a SNMP pueden ser bastante sensible y, por defecto en la configuración de SNMP, se bloquean ciertas ramas. En el fichero /etc/snmp/snmp.conf se pueden definir las ramas que se mostrarán y a qué grupos. Yo lo que he hecho es añadir a la lista systemview la rama MIB correspondiente a los monitores de HP Proliant con la siguiente directiva:


# Make at least  snmpwalk -v 1 localhost -c public system fast again.
#       name           incl/excl     subtree         mask(optional)
view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1
# Emilio: Linea de abajo añadida para poder consultar monitores de hp insight
view    systemview    included   .1.3.6.1.4.1.232

La rama .1.3.6.1.4.1.232 contiene la información asociada a la rama enterprises. Podéis ver un listado con todos los OIDs en el archivo /opt/hp/hp-snmp-agents/mibs/cmaobjects.mibdef. Reiniciamos snmpd y consultamos la rama enterprises con snmpwalk. La orden debería mostrar un listado bastante largo con todos los valores del árbol MIB.

Con esto ya podríamos consultar los monitores de forma periódica con un script en bash por ejemplo que envíe un correo en caso de encontrar un valor no deseado. Pero podemos ir un paso más allá usando ZABBIX.

SNMP + ZABBIX

Zabbix tiene la capacidad de hacer consultas a SNMP, es más, uno de los usuarios de Zabbix ya se ha molestado en hacer una plantilla que consulta algunos de los monitores más importantes de los servidores Proliant. Tan sólo hay que asociar la plantilla a nuestro servidor dentro de Zabbix, abrir el puerto 161 Udp del servidor a monitorizar y reiniciar zabbix_server.

Sensores Insight Manager
Y aquí tenemos los sensores que añade la plantilla. Algunos aparecerán como "no soportados" según la configuración de nuestro equipo. Por ejemplo, en este equipo sólo tenemos una controladora de discos, por lo que diskController2 aparece como no soportado. Ya disponemos de información tan importante como el estado de las controladoras de disco, de las fuentes de alimentación, de los ventiladores, de la memoria, temperaturas...

La plantilla define estos monitores como críticos, por lo que cualquier cambio en alguno de ellos será considerado como tal en Zabbix y desencadenará la acción que nosotros hemos configurado para eventos críticos: email, sms, etc.

Una buena página para acceder al significado de cada monitor con un enorme listado de MIBs, enlazo directamente los monitores de HP Health:
http://www.mibdepot.com/cgi-bin/getmib3.cgi?win=mib_a&n=CPQHLTH-MIB&r=compaq&f=Compaq-Health.mib&t=tree&v=v1&i=0#compaq



viernes, 4 de mayo de 2012

Cambiando un Disco Duro en un HP Proliant

Shit happens!! Si, solo es cuestión de tiempo. Tarde o temprano todo aparato electrónico acaba fallando, incluso si es de buena calidad. Ayer, cuando me disponía a cambiar la cinta de copia de seguridad de uno de nuestros servidores me di cuenta de que uno de los discos duros tenía iluminado el led de fallo.

Recuerdo la primera vez que nos falló un disco en el trabajo. Fue en un servidor clónico, muy potente, poco después de comprarlo. Entonces todas nuestras aplicaciones estaban alojadas en este servidor. Aprendimos mucho aquella vez: es mejor invertir en un servidor que te dé garantías y en un buen servicio técnico que en uno tipo "hacendado" por muy potente que sea, lo importante que es poder confiar en tu sistema de copias de seguridad, que debes prever situaciones de emergencia, que andar con pies de plomo y tener todo medianamente bien atado es imprescindible si quieres ahorrarte muchos dolores de cabeza porque LA GENTE SOLO SE ACUERDA DE " EL INFORMÁTICO" CUANDO ALGO FALLA. Por eso sustituimos esa máquina por nuestro primer HP Proliant, ahora tenemos 15.

Lavadora o servidor??

No quiero hacer de comercial de HP, seguro que Dell, Sun o cualquier marca de renombre tienen buen hardware, proveen de herramientas software adecuadas y disponen de un servicio técnico de calidad.

Bueno, voy al grano. Se nos ha roto uno de los discos que, junto con otros 3, formaba parte de un conjunto RAID 1+0. Como con esta configuración RAID podemos "perder" un disco, todo el sistema sigue funcionando. Los discos para estos sistemas vienen incrustados en una especie de chasis que facilita su manejo y además da información del estado de los mismos por medio de una serie de leds.

Disco defectuoso
Podemos confirmar esta información usando una de las herramientas del paquete Proliant Support Pack hpacucli. La sintaxis es la siguiente:


[root@localhost hpacucli]# hpacucli ctrl all show config

Smart Array 641 in Slot 3     (sn: XXXXX)

   array A (Parallel SCSI, Unused Space: 0 MB)

      logicaldrive 1 (273.5 GB, RAID 1+0, Interim Recovery Mode)

      physicaldrive 1:2   (port 1:id 2 , Parallel SCSI, 146 GB, Failed)
      physicaldrive 1:3   (port 1:id 3 , Parallel SCSI, 146.8 GB, OK)
      physicaldrive 1:4   (port 1:id 4 , Parallel SCSI, 146.8 GB, OK)
      physicaldrive 1:5   (port 1:id 5 , Parallel SCSI, 146.8 GB, OK)

Como vemos en la salida de hpacucli el disco en el slot 2 está defectuoso.

Si contamos con un contrato de mantenimiento con HP el proceso de pedido se facilita mucho. Solo tienes que dar el número de serie del servidor y el modelo del disco. Podemos verlo usando también las herramientas de HP PSP. En pocas horas recibes el disco e incluso te pueden enviar un técnico para que lo reemplace sin coste adicional. Usando hpasmcli podemos ver toda la información del servidor.

HP management CLI for Linux (v1.0)
Copyright 2004 Hewlett-Packard Development Group, L.P.

--------------------------------------------------------------------------
NOTE: Some hpasmcli commands may not be supported on all Proliant servers.
      Type 'help' to get a list of all top level commands.
--------------------------------------------------------------------------
hpasmcli> show server
System        : ProLiant ML350 G4p
Serial No.    : CZJ6XXXXX      
ROM version   : D19 02/15/2006
iLo present   : Yes
Embedded NICs : 1
 NIC1 MAC: XX:XX:XX:XX:XX:XX

Processor: 0
 Name         : Intel Xeon
 Stepping     : 10
 Speed        : 3000 MHz
 Bus          : 800 MHz
 Socket       : 1
 Level2 Cache : 2048 KBytes
 Status       : Ok

Processor: 1
 Name         : Intel Xeon
 Stepping     : 10
 Speed        : 3000 MHz
 Bus          : 800 MHz
 Socket       : 2
 Level2 Cache : 2048 KBytes
 Status       : Ok

Processor total  : 2

Memory installed : 4096 MBytes
ECC supported    : Yes

Arriba tenemos el número de serie del servidor. Y para ver la información del disco podemos utilizar de nuevo hpacucli:

[root@localhost hpacucli]# hpacucli ctrl slot=3 pd all show detail

Smart Array 641 in Slot 3

   array A (Failed)

      physicaldrive 1:2
         SCSI Bus: 1
         SCSI ID: 2
         Status: Failed
         Drive Type: Data Drive
         Interface Type: Parallel SCSI
         Transfer Mode: Sync Narrow
         Size: 146 GB
         Transfer Speed: 10 MB/Sec
         Rotational Speed: 10000
         Firmware Revision: HPB1
         Serial Number: XXXXXX
         Model: COMPAQ  BD14689BB9      
      physicaldrive 1:3
         SCSI Bus: 1
         SCSI ID: 3
         Status: OK
         Drive Type: Data Drive
         Interface Type: Parallel SCSI
         Transfer Mode: Ultra Narrow
         Size: 146.8 GB
         Transfer Speed: 20 MB/Sec
         Rotational Speed: 10000
         Firmware Revision: HPB1
         Serial Number: XXXXXX
         Model: COMPAQ  BD14689BB9      
      physicaldrive 1:4
         SCSI Bus: 1
         SCSI ID: 4
         Status: OK
         Drive Type: Data Drive
         Interface Type: Parallel SCSI
         Transfer Mode: Ultra Wide
         Size: 146.8 GB
         Transfer Speed: 40 MB/Sec
         Rotational Speed: 10000
         Firmware Revision: HPB4
         Serial Number: XXXXXX
         Model: COMPAQ  BD1468A4C5      
      physicaldrive 1:5
         SCSI Bus: 1
         SCSI ID: 5
         Status: OK
         Drive Type: Data Drive
         Interface Type: Parallel SCSI
         Transfer Mode: Ultra Wide
         Size: 146.8 GB
         Transfer Speed: 40 MB/Sec
         Rotational Speed: 15000
         Firmware Revision: HPB1
         Serial Number: XXXXXX
         Model: COMPAQ  BF1468AFEB

Si alguna vez habéis visto el precio de una buena controladora de discos os habréis dado cuenta que hay un gran salto entre las las controladoras de "andar por casa" y las de gama empresarial. La respuesta es muy sencilla "hacen magia": Hot Swap de discos, reconstrucción de conjuntos RAID de varios tipos de forma rápida y transparente... Tan fácil como extraer el disco defectuoso e introducir el nuevo, la controladora se encarga de todo.

Cambiando el disco

Si consultamos otra vez el estado de la controladora de discos podemos ver que se ha detectado correctamente el cambio y que el proceso de reconstrucción del RAID ha comenzado, cosa que ya notábamos en los indicadores led de los discos duros asociados al conjunto RAID.

[root@localhost hpacucli]# hpacucli ctrl all show config

Smart Array 641 in Slot 3     (sn: XXXX)

   array A (Parallel SCSI, Unused Space: 0 MB)

      logicaldrive 1 (273.5 GB, RAID 1+0, Recovering 1.6% complete)

      physicaldrive 1:2   (port 1:id 2 , Parallel SCSI, 146.8 GB, Rebuilding)
      physicaldrive 1:3   (port 1:id 3 , Parallel SCSI, 146.8 GB, OK)
      physicaldrive 1:4   (port 1:id 4 , Parallel SCSI, 146.8 GB, OK)
      physicaldrive 1:5   (port 1:id 5 , Parallel SCSI, 146.8 GB, OK)

Según la rapidez del disco y la controladora la reconstrucción tardará más o menos. En nuestro servidor con discos de 10K rpm ha tardado alrededor de 40 minutos, en caliente, ejecutándose en segundo plano mientras el servidor seguía funcionando con normalidad.

Resumen de órdenes de hpacucli
Resumen de órdenes de hpasmcli