¿A cuántos targets iSCSI estoy conectado?

Siempre tengo que estar mirando la ayuda. Cuando ya tenemos un equipo Linux conectado a volúmenes iSCSI remotos, podemos ver si efectivamente se ha conectado o no mediante:

iscsiadm -m session

Curso de Nagios (I): Prólogo

Llevo ya varios años ofertando entre mis servicios de consultoría de sistemas, la puesta en marcha de sistemas de monitorización basados en herramientas OpenSource como Nagios, Cacti u Ossim. Nagios lo he visto crecer desde la versión 1.0 hasta la 3.2 y ahora, contemplo fascinado como el fork de Icinga mejora a su antecesor, sin quitarle la potencia y flexibilidad que teníamos de siempre. En todos estos años, he presenciado siempre la mismas diferentes historias con un mismo final, al conversar con los técnicos de las organizaciones:

• Si, tenemos Nagios pero no lo usamos porque envía demasiados correos...
• Si, tenemos Nagios pero sin notificaciones y sólo comprobamos que haga ping a los equipos, nadie lo mira
• Oh si, claro, pero hay que saber mucho para mantenerlo bien, es un rollo
• Ufff, Nagios está bien para monitorizar Linux, ¿pero qué hacemos con Windows?

... y el final que tienen todas estas historias en común, es siempre que acaban por apagar y desinstalar Nagios con un amargo sabor de boca sobre lo que és y para qué sirve, y claro, cuando llego vendiendo Nagios, pufff no veais lo que me lo que me cuesta :(. Al fín me he animado a escribir una serie de posts que, humildemente me he atrevido a llamar Curso de Nagios (ya se sabe que la ignorancia es muy atrevida), en el que intentaré ir mostrando uno de los caminos que podemos recorrer para configurarlo correctamente y descubrir su verdadera utilidad y potencia, evitar que lo desinstaleis, y contribuir modestamente con alguna de las deficiencias que creo que existen entorno a esta y otras herramientas similares:

• De los libros que he leído, pienso que todos fallan en lo mismo: sólo llegan a ofrecernos recomendaciones sobre cómo configurarlo, sin proponer una configuración que luego poder adaptar a la realidad de nuestro servicio informático, e ir aprendiendo en el proceso. Reconozco que la curva de aprendizaje es muy elevada cuando empezamos a trabajar con Nagios, y los libros con los que he trabajado, ayudan pero no lo suficiente.
• La gran mayoría de blogs que hablan sobre Nagios suelen quedarse en la superficie, y no nos explican qué preguntas debemos hacernos durante el proceso de configuración de Nagios, y por supuesto, no ofrecen respuestas.
• Los servicios de informática están evolucionando en los últimos tiempos y ahora los técnicos tenemos que aprender las cosas de siempre a las que les han cambiado el nombre: ITIL, LeanIT, incidente, respuesta, proactividad, control del cambio, gestión de la capacidad, de la disponibilidad, etc.A veces, pienso que estas cosas se hacen para que los responsables de tomar las decisiones de compra y contratación, no les suene nada y decidan comprar esto que es lo más nuevo y lo mejor, y el futuro.

En resumen, entre tanta documentación técnica sobre Nagios, echo de menos una guía de consultoría que ayude a configurarlo paso a paso en entornos heterogéneos actuales de tamaño considerable (Windows, Linux, ESX, Novell, etc), con administradores que no se ven ni en la máquina del café, y en muchos casos mezclados con personal externo, que no se sienten parte de la organización, y consideran al administrador de Nagios el friki del Linux que se aburre, mientras ellos se dedican a administrar servidores, y todos dirigidos por responsables que pasan el tiempo pidiéndonos informes, y hablándonos de cosas como Itil, gestión de la disponibilidad, de la capacidad, etc.

Intentaré escribir esta guía en una serie de posts, de los que aún no sé el número al que llegaré ni la fecha, pero que espero que os sirva y podais adpatarla en vuestras configuraciones con éxito.

Multipath en OUL 5.7 con IBM Storwize V7000

Esta semana estoy configurando DeviceMapper Multipath en Oracle Unbreakable Linux 5 update 7, conectado a una SAN IBM Storwize V7000. El fichero /etc/multipath.conf que uso es el siguiente:

defaults {
  user_friendly_names     yes
  udev_dir                /dev
}

blacklist {
      devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
      devnode "^hd[a-z][[0-9]*]"
      devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}

devices {
  device{
      # Identificar la cabina (IBM v7000)
      vendor          "IBM*"
      product         "2145*"

      # Como comprobar si los caminos estan arriba...
      path_checker tur

      # Como agrupar los caminos (por prioridad)
      path_grouping_policy  group_by_prio

      # Como obtener los IDs de los discos...
      getuid_callout "/sbin/scsi_id -g -u -s /block/%n"

      # Como obtener las prioridades de los discos...
      prio    "alua"

      # Algoritmo para presentar io al kernel por los caminos vivos
      path_selector "round-robin 0"

      # No reintente i/o por los caminos caido y haga fail immediate
      no_path_retry fail

      hardware_handler "1 alua"

      # Le dice al demonio como manejar los caminos caídos...
      failback immediate
  }
}

multipaths {
  multipath {
      wwid        360050768028081874dc00000000000000
      alias       Lun_ibm
  }
}

...y después de guardar los cambios del fichero, aplicar la configuración ejecutando la siguiente secuencia de pasos:

/etc/init.d/multipathd restart
multipath -F
multipath -v3

Al ejecutar el comando multipath -ll , deberíamos obtener una salida similar a la siguiente:

Lun_ibm (36005076802808187dc00000000000000) dm-18 IBM,2145
size=2.0G features='0' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 3:0:3:0  sdcc 69:0   active ready running
| `- 4:0:3:0  sdca 68:224 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
|- 3:0:2:0  sdcb 68:240 active ready running
`- 4:0:2:0  sdbz 68:208 active ready running

VMware y la copia de máquinas virtuales

A menudo creo máquinas virtuales con VMware Server 2.X que luego al llevo a otros equipos, pero cuando voy a inciar la máquina virtual me encuentro que nunca termina de iniciar. Al consultar la consola de VMware me encuentro que VMware me está preguntando qué he hecho con esa máquina y no la iniciará hasta que responda a la pregunta.

Para evitarlo, podemos añadir al fichero .VMX las siguientes líneas:

uuid.action = "create"
msg.autoAnswer = "TRUE"

...pero ... ¿para qué vale Multipath?

Llevo ya varios posts escribiendo sobre software Multipath y acabo de caer en la cuenta... vaaleee ... ¿qué es esto del software MultiPath?, ¿para qué sirve?, ¿por qué tanto interés en documentar todo esto?. Bien, habrá que empezar por el principio.

Desde los años setenta nos han machacado con el concepto de jerarquía de memoria: La memoria cuanto más cerca de la CPU más rápida y más cara, y cuanto más lejos, más barata y más lenta. Desde entonces hemos asistido a una desenfrenada evolución de las tecnologías de almacenamiento, para acercar a la CPU más cantidad de almacenamiento, a menor coste y a mayor velocidad ... pero ... ¿por qué?... porque la información es el recurso más valioso de cualquier organización, como siempre fue y será, y ya se sabe desde hace siglos que la información es poder. Si combinamos estas ideas aparece un mercado que vende almacenamiento masivo y rápido a un precio razonable, dirigido a cubrir las necesidades de almacenamiento de cualquier organización. Estas necesidades se suelen empaquetar y distribuir en forma de discos duros, relegando las cintas magenéticas a la copia de seguridad de los primeros en el siguiente escalón de la jerarquía de memoria... pero claro, la tecnología tiene sus limitaciones y no podemos empaquetar toda la información que requiere el poder en un único disco duro: necesitamos varios discos duros con la máxima capacidad, los metemos en una caja que los contenga todos y los conectamos entre sí, superando así las limitaciones que nos impone la tecnologia y sumando la capacidad de todos ellos, y los organizamos en cajones dentro de la caja, para poder ampliar con más discos en el futuro.

Confiar toda la información de nuestra organización y el poder a una única caja de discos duros, en la que el fallo de uno de ellos pondría en peligro el resto de la información, es bastante arriesgado: Sacrifiquemos algo de capacidad a cambio de seguridad de la información y nos encontraremos con lo que se conoce por RAID, y sus distintos tipos: RAID-0, RAID-1, RAID-5 etc. RAID viene del acrónimo conjunto redundante de discos independientes, pero en inglés (Redundant Array Independient Disks) y los distintos tipos se corresponden con distintas combinaciones para repartir la información entre los discos de la caja, y ganar velocidad y/o seguridad, pero claro... ¿quién implementará esto?, ¿quien se encargará de distribuir la información entre los discos de la caja? ... está claro que necesitamos un elemento nuevo en la caja que implemente esta lógica de acceso: Este elemento lo llamaremos controladora y no deja de ser un pequeño computador dedicado a implementar estas funcionalidades. Vale, ya tenemos solucionado el problema de que falle alguno de los discos... ¿pero qué pasa si falla la controladora? ... que lo perdemos todo, nada, nada, metemos una segunda controladora y un mecanismo para detectar que si una cae entre en funcionamiento la segunda.

Como no se puede acercar todo el almacenamiento que necesitemos a la CPU, había que buscar un método para llevarle la información y se usó lo que se conocía hasta entonces que era bueno: SCSI es un estándard para la transferencia de información hacia la CPU, que se implementó en las controladoras de la caja de discos... pero claro... ¿cómo hacemos llegar los bytes del poder hasta la CPU, desde las controladoras de la caja? ... mediantes cables de red (iSCSI) o de fibra óptica (FC-ALL): Pinchamos una tarjeta de expansión especial (que llamaremos HBA) al ordenador de la que salga un cable de fibra óptica y que se conecte a la controladora. Esta tarjeta se encargará de convertir los rayos de luz en señales eléctricas SCSI y a través del bus del sistema llevar los bytes hasta la CPU. Perfecto, todo solucionado, pero ¿qué pasará si se rompe esta HBA? ... que nos quedamos sin bytes ... la solución: Poner una segunda HBA en el equipo, o vender tarjetas de expansión con doble HBA, y conectamos cada HBA a una controladora.

¿Y si queremos conectar más de un ordenador a la caja de discos? ... en ese caso necesitaremos usar un elemento intermedio que realice labores de conmutación, igual que hacemos con los switches de red, y ya podremos conectar muchos equipos a nuestra caja de discos: todos conectados a este switch especial y las controladoras también, pero claro ... ¿y si se rompe ese switch?, pues lo de siempre: nos quedamos sin información; nada, nada pongamos dos switches, y conectemos una de las HBAs y una controladora a uno de los switches y la otra HBA y la otra controladora al otro switch.

En esta pequeña historia, nos encontramos que los actores reales que fabrican cajas de discos son muchos, aunque es habitual encontrarnos:

• EMC, que fabrica Clariion, Cellerra, Symmetrix, por nombrar alguno,
• IBM, que fabrica DS4xxx, DS5xxx, EXPxx, v7000, etc...
• HP, que fabrica EVA 4xxx, EVA 5xxx, EVA 6xxx, XP P9xxx, MSA, etc...

Las diferencias entre los fabricantes radican principalmente en el precio, los servicios postventa que ofrecen, y el funcionamiento técnico interno de estas cajas de discos: Unas permiten que las dos controladoras trabajen simultáneamente sobre los mismos discos, otras trabajan las dos controladoras pero no sobre los mismos discos, en otras, el almacenamiento global se gestiona como un todo sobre el que vamos haciendo particiones y asignando a los servidores, en otras solo vemos como un todo el espacio de los discos del mismo cajón, etc...

Recordemos que el objetivo de todo esto al final, se hace para conseguir ofrecer más cantidad de almacenamiento a los equipos de nuestra infraestructura, un cachito de espacio, que el sistema operativo verá como un nuevo disco duro SCSI, pero claro, se llega al mismo disco por diferentes caminos:

1. Desde la HBA-1, al Switch-1, a la controladora-1 y de ahí al disco
2. Desde la HBA-1, al Switch-1, a la controladora-2 y de ahí al disco
3. Desde la HBA-2, al Switch-2, a la controladora-1 y de ahí al disco
4. Desde la HBA-2, al Switch-2, a la controladora-2 y de ahí al disco

Esto hace que el sistema operativo vea cuatro discos, en vez de uno que en realidad son el mismo, y además, que algunos elementos están por si falla el análogo, y por tanto y dependiendo de la tecnología que use el fabricante, no se podrá acceder al disco. ¿Qué sucede entonces? ... que necesitaremos de un software especial en el sistema operativo, capaz de hablar correctamente con las controladoras y las HBAs, que sepa en qué estado están los diferentes caminos, y elija el más óptimo para acceder al disco, y si en un momento falla alguno de los elementos, dirija el tráfico de bytes por otro camino que sí que funcione correctamente.

Hace unos años, este software que llamamos de Multipath (por aquello de trabajar con múltiples caminos) lo proporcionaba el propio fabricante de cajas de discos, pero nos lo cobraba aparte, aunque eso sí, funcionaba perfecto: Si luego queríamos conectar a los switches otra caja de discos de otro fabricante, el software del primero era incompatible con el del segundo, y por supuesto, también los cobraba aparte.

Esta pequeña dictadura de los fabricantes la rompe la comunidad del software libre, desarrollando DeviceMapper Multipath, que permite controlar caminos hacia diferentes discos de diferentes cajas de discos y además evitarnos pagar una licencia extra por el uso del software: Ya pagamos por la caja, los cajones, los discos y el soporte ... ¿por qué no nos regalan ese software?, ¿por qué tenemos que pagar encima, para poder usar todos los cacharros que ya hemos tenido que pagar a la misma empresa?...

La actitud de estas empresas entonces, es dificultar el acceso a las configuraciones y a la documentación de cómo configurar correctamente DeviceMapper MultiPath con sus productos, y la comunidad del Software Libre no tiene acceso a todos estos modelos para elaborar guías de configuración.

Es gente anónima y blogs como este, que tenemos acceso a estas cajas de discos, los que nos peleamos con las cabinas de almacenamientos y las configuraciones de multipath, comprobamos que todo funciona como debe y los publicamos para que otros usuarios se encuentren este trabajo hecho y lo tengan más fácil.

Multipath en OUL 5.7 con Clariion CX3-20

Esta semana necesité configurar DeviceMapper Multipath en Oracle Unbreakable Linux 5 update 7, conectado a una SAN de EMC Clariion CX3-20.

El primer paso será crear el fichero /etc/multipah.conf con el siguiente contenido:

defaults {
    user_friendly_names     yes
    udev_dir                /dev
}

blacklist {
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z][[0-9]*]"
        devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}

devices {
    device {
        # Identificar la cabina (EMC Clariion)
        vendor "DGC*"
        product "*"

        # Como comprobar si los caminos estan arriba...
        path_checker emc_clariion

        # Como agrupar los caminos (por prioridad)
        path_grouping_policy group_by_prio

        # Como obtener los IDs de los discos...
        getuid_callout "/sbin/scsi_id -g -u -s /block/%n"

        # Como obtener las prioridades de los discos...
        # ... podemos obtener los valores disponibles...
        # rpm -ql device-mapper-multipath-libs-0.4.9-23.0.9.el5 | grep libprio | cut -c25- | cut -d'.' -f1
        prio     "emc"

#        ..esto era en Ubuntu
#       prio_callout "/sbin/mpath_prio_emc /dev/%n"

        # Algoritmo para presentar io al kernel por los caminos vivos
        path_selector "round-robin 0"

        # Esto es casi que así, porque es lo unico que hay implementado
        #features "0"
        features "1 queue_if_no_path"

        # Cada cuando se reintenta si el camino esta vivo (aunque
        # lo que manda muchas veces el valor del firmware y nvram)
        no_path_retry 300

        # Esto es así para Cabinas EMC
        hardware_handler "1 emc"

        # Le dice al demonio como manejar los caminos caídos...
        failback immediate
    }
}
multipaths {
    multipath {
        wwid        360060160066021007ebcc08b0c38df11
        alias       LunDatos
    }
}

...y después de guardar los cambios del fichero /etc/multipah.conf, aplicaremos la nueva configuración ejecutando...

1. Eliminar la configuración que previa que tenía el sistema, sobre los caminos...

   multipath -F

2. Refrescar la información de los caminos que vemos desde la SAN, con esta nueva configuración ...

   multipath -v3

3. Comprobar el acceso a los discos, y el estado de multipath

   multipath -ll