CUÉNTAME CÓMO TE HA IDO…

Hace un tiempo comentamos en este blog la posibilidad de monitorizar tus equipos y tus servicios de red de manera cómoda y centralizada con Nagios.

Esta útil aplicación nos avisa inmediatamente de cualquier problema que ocurra en nuestros equipos y servicios, incluso podemos programar que nos lo solucione de manera automática.

Lamentablemente, a veces un problema no es tan sencillo de solucionar, o bien es tan sencillo como arrancar de nuevo el servicio (por ejemplo el servidor apache) pero no sabemos las causas de la parada, con la consiguiente inseguridad e intranquilidad que nos produce.

En estos casos nos vendría muy bien saber cómo se comportó el servidor (uso de CPU, de memoria, accesos a disco, tráfico por red…) durante las últimas 24 horas, la última semana o incluso cómo se ha comportado durante el último año, para poder sacar alguna conclusión al respecto. Y si los datos los vemos mediante gráficas, tanto mejor.

¿Cómo podemos obtener esas ‘maravillosas’ gráficas?

Al igual que comentamos para Nagios, siempre podríamos programar unos scripts que se encarguen de obtener esa información y pasarle los datos a alguna aplicación que genere gráficos. Afortunadamente no tenemos que realizar esas tareas, gracias a ‘Munin’.

Munin nos permite visualizar el funcionamiento de los componentes principales de cada uno de nuestros equipos, así como de los servicios que tengan arrancados, accediendo cómodamente por web, y seleccionando el servidor a consultar.

Gráficas generadas por Munin sobre el servidor Apache

Y lo mejor de todo es que la instalación y configuración de Munin es extremadamente sencilla. Únicamente necesitamos una máquina con Linux (si ya estamos usando una para monitorizar la red con Nagios, podemos usarla también con Munin), en la que instalaremos el software Munin indicando los clientes de los que mostraremos las estadísticas.

Además, en cada uno de los equipos de los que queremos obtener las gráficas (sean Linux, Windows o MAC), instalaremos el software Munin para clientes, y le indicaremos la dirección del servidor Munin.

Y ya está. Por defecto Munin incluye una larga lista de plugins que se instalan en los clientes, y que se encargarán de obtener toda la información del sistema para generar las gráficas.

Y de manera automática el servidor Munin irá recogiendo los datos de los clientes y generando las gráficas correspondientes.

Si necesitamos alguna gráfica especial no incluida ‘de serie’ por Munin, podemos buscarla en el repositorio de plugins o bien crearnos uno nosotros mismos (es realmente sencillo) si no hemos encontrado lo que buscamos.

Podemos obtener más información en la página oficial (en inglés) http://munin-monitoring.org

Tu red bajo control: monitorización con Nagios

¿No te ha ocurrido nunca que en el peor momento se llena el disco duro? ¿O que se pare esa aplicación por red que tienes encendido 24 horas al día y tardes una semana en enterarte? Sí, podrías realizar unos programas que comprobasen constantemente que todo está funcionando en tus equipos, y te avisara cuando algo falla. Pero, ¿para qué hacerlo, si existe una herramienta profesional (y gratuita) que ya lo hace por ti? Nagios.

Si dispones de una vieja máquina con Linux, puedes instalar Nagios, y monitorizar todas tus máquinas y sus servicios de red en tiempo casi real, mostrando cualquier error vía web (ya que Nagios utiliza apache para mostrar los resultados) o mediante correo. Incluso podemos integrarlo en la barra del Firefox.

 


Nagios te avisará inmediatamente de cualquier problema que vea en los equipos de tu red, mediante unos plugins configurables. Sin embargo, su mayor eficacia la consigue en colaboración con NRPE.

NRPE (Nagios Remote Plugin Ejecutor) es un software disponible para Linux y Windows (en Windows se llama Nsclient++) que se instala en cada uno de los equipos a monitorizar, y que contacta con Nagios para informarle de cualquier anomalía que ocurra en su interior. Por supuesto es fácilmente programable y podemos ajustarlo al control que nos interese (NRPE incluye varios plugins por defecto para las tareas más comunes):


Y lo mejor de todo es que, no sólo nos informa del problema, sino que además es capaz de solucionarlo. Para ello simplemente programaremos NRPE para que ejecute una serie de comandos ante una alarma.

Nagios es una herramienta imprescindible para administradores, pero también muy recomendable para cualquier usuario que quiera estar seguro que sus equipos están funcionando correctamente, sea una máquina o cien.

Es muy sencillo encontrar información en Internet sobre la instalación y configuración de Nagios y NRPE. La página oficial es: http://www.nagios.org

Almacenamiento profesional, económico y en casa.

¡No sólo los grandes centros de datos pueden disponer de un servicio de almacenamiento profesional! Con Openfiler, prácticamente cualquiera, también puede.

Openfiler es una distribución Linux basada en rPatch con licencia GPL, que nos permite utilizar una máquina como servidor de ficheros por red. Soporta multitud de protocolos: HTTP/WEBDAV, NFS, SMB/CIFS, FTP…, pero uno de los más interesantes es iSCSI. Gracias a ello podemos convertir nuestro servidor en una SAN (Storage Area Network) sin necesidad del desembolso económico que suele ser necesario.

Continue reading “Almacenamiento profesional, económico y en casa.”

Alta disponibilidad con Heartbeat

En la entrada sobre DRBD explicábamos cómo crear RAID1 sobre dos servidores conectados por red.

Imaginemos que hemos instalado un servidor web en el servidor maestro, con lo que tendremos replicada la información en el servidor secundario en tiempo real gracias al DRBD. Esta configuración de los servidores nos permite recuperar el servicio sin pérdida de información en muy poco tiempo. Sin embargo, necesitamos la intervención del administrador para levantar el servicio tras caída del servidor primario: cambiar el estado del DRBD de secundario a primario, configurar la red y levantar el servicio Web.

Para conseguir alta disponibilidad necesitamos que el propio sistema realice todos estos pasos de manera automática, dando al usuario la sensación de que el servicio no ha sufrido ninguna interrupción (el tiempo sin servicio sería muy pequeño).

Continue reading “Alta disponibilidad con Heartbeat”

RAID1 por TCP/IP (DRBD)

Cuando se maneja información valiosa siempre es necesario tenerla replicada para poder disponer de ella en el menor tiempo posible (inmediatamente de manera óptima), y por supuesto, sin ninguna pérdida de datos.

Hace ya mucho tiempo que se usa RAID1 (y el resto de opciones RAID) en los discos de los servidores para tener una réplica exacta de los datos en ambos discos. De esta manera, en caso de fallo en uno de los discos, los datos siguen intactos en el otro, con lo que el servicio ofrecido seguirá disponible mientras solucionamos el problema del disco afectado.

Evidentemente, RAID1 no podrá mantener la disponibilidad del servicio si lo que falla es cualquier otra parte del servidor: controladora, alimentación, red, etc. Para poder hacerlo deberíamos tener duplicadas cada una de las partes que se pueden ver afectadas…pero siempre se puede estropear la placa base.

Continue reading “RAID1 por TCP/IP (DRBD)”

Infraestructura de gestión de usuarios en la EPS.

En la Escuela Politécnica Superior, desde hace más de 6 años, se identifica, autentica y autoriza (AAA) a los usuarios para acceder a los equipos de los laboratorios (así como a muchos de los servicios disponibles en la web). La base del proceso AAA de la EPS está en el manejo de directorios y el protocolo LDAP.

El número elevado de autenticaciones concurrentes, así como la necesidad de encriptar las comunicaciones, requiere de una infraestructura dedicada exclusivamente a garantizar el correcto y rápido funcionamiento del servicio.

En la gráfica siguiente se muestra el esquema utilizado para la autenticación de los laboratorios de la EPS, tanto los de Politécnica I como los de Politécnica IV:

Esquema de autenticación de usuarios en la EPS

Arquitectura para AAA en la EPS

Politécnica I
El acceso al sistema desde los clientes de laboratorios realiza la autenticación mediante LDAPS (LDAP+SSL)
Para ello se dispone de seis servidores (Stunnel1, Stunnel1, Stunnel2, Stunnel3, Stunnel4, Stunnel5) que se encargan de desencriptar la comunicación SSL de los clientes (mediante una aplicación GNU llamada stunnel), obtener las peticiones y enviar la petición sin SSL a los servidores LDAP (Slave1-P1, Slave2-P1, Slave3-P1, Slave4-P1).

Se realiza de esta manera en lugar de acceder directamente a los servidores LDAPS, por el elevado consumo de recursos necesarios para la desencriptación. Éste fue el motivo que nos llevó a separar las tareas de desencriptación y consulta en la base de datos del directorio LDAP: el objetivo era disponer de un mayor número de servidores, aunque fueran menos potentes, y balancear las peticiones entre ellos.

Con el fin de conseguir alta disponibilidad y reparto de carga, se utiliza el router de planta para balancear los servicios. Así, los clientes no realizan las peticiones encriptadas con SSL (a través del programa stunnel instalado en cada cliente que encripta las peticiones) directamente a los servidores SSL (Stunnel1 a Stunnel5), sino que las realizan a una dirección IP gestionado por el router de planta que se encarga de balancear la petición entre los servidores Stunnel. De la misma manera, una vez desencriptada cada petición, tampoco se envía directamente a los servidores LDAP, sino que se vuelve a enviar a otra dirección IP gestionada por el router para que la balancee entre los distintos servidores LDAP en función de la carga soportada.

Con este sistema montado para la Politécnica I (donde hay 16 laboratorios con más 500 PCs) se consiguen 2 objetivos: mejorar la respuesta ante picos de concurrencia y alta disponibilidad (si cae un servidor, el router lo elimina del balanceo sin que el servicio se vea perjudicado).

Según el monitor Nagios que vigila los servicios y sistemas de la EPS, la disponibilidad de este servicio durante el año 2008 fue de 99% del tiempo. Es más, si sólo se tiene en cuenta los periodos lectivos, este porcentaje sube al 99’99%, es decir, prácticamente sin periodos de inactividad que afecte a los laboratorios.

Politécnica IV
Los clientes de la politécnica IV no se conectan a los servidores de la Politécnica I para realizar la autenticación. Para acelerar la respuesta, disponen de sus propios servidores con Stunnel y LDAP.

En este caso, los clientes se conectan del mismo modo a la dirección del router de la PIV. El router balancea las peticiones SSL entre los servidores de la PIV (Slave1-P4 y slave2-P4), que una vez desencriptadas, envía las peticiones LDAP (sin SSL) al servidor LDAP destinado, en lugar de hacerlo al router como en la PI (ya que sólo se dispone de dos servidores, y el reparto de carga ya está realizado con el primer balanceo).