Alta disponibilidad en Linux: La IP de servicio, parte 2

En esta segunda parte del artículo se configura la dirección IP de servicio y se comenta el uso de la interfaz de red virtual “dummy0”.

Configurando la IP de servicio

Como ya se mencionó en la primera parte, utilizando “keepalived” -que implementa el protocolo VRRP-, haremos que una dirección IP esté asignada a un servidor de forma inicial; y si este falla, que esa dirección IP sea asignada automáticamente al otro servidor.

El fichero de configuración de”keepalived” es “/etc/keepalived/keepalived.conf”. Cada servidor tendrá el suyo propio, muy similar a su par.

Para el primer servidor, ejecutaremos lo siguiente

Para el segundo servidor, ejecutaremos:

Las líneas resaltadas son aquellas que difieren según el servidor.

Analicemos este fichero de forma genérica:

Las líneas 1 a 3 son un bloque de definiciones globales. En este caso solo hemos utilizado “router_id” para identificar el servidor cuando intercambie información de VRRP. Otra funcionalidad no mostrada aquí es notificar vía email cuando se produce algún cambio de estado.

Las líneas 5 a 28 definen una “instancia VRRP”. Una instancia es un grupo de servidores que se comunicaran entre ellos intercambiando información de estado siguiendo unas reglas que nosotros indiquemos.

Dentro de la instancia VRRP definimos qué estado inicial (línea 6) tiene cada servidor: MASTER, que será el que tenga asignada la dirección IP de servicio por defecto; o BACKUP, que la tendrá si el servidor MASTER no responde o notifica que alguna regla no se cumple.

Cuando un servidor en estado BACKUP no puede comunicarse con el servidor MASTER, o el servidor MASTER informa que no se cumplen las reglas de la instancia VRRP, el servidor BACKUP tomará el estado de MASTER y el servidor MASTER el estado de BACKUP, invirtiendo sus roles.

La información sera intercambiada con un cifrado simétrico a través de la interfaz de red eth0 (línea 7) para evitar que un servidor malintencionado altere el intercambio de información de estado (líneas 12 a 15).

VRRP es un protocolo que intercambia información de estado mediante paquetes de red multicast. Como solo tenemos dos servidores, establecemos una comunicación directa entre ellos –unicast– (líneas 21 a 23) y no utilizaremos el envío de paquetes multicast. Otra razón para hacer esto es la posibilidad de que el switch al que están conectados los servidores no permita el “tráfico multicast”.

En las líneas 17 a 19 indicamos que esta instancia VRRP debe asignar a la interfaz de red “dummy0” la dirección IP de servicio “192.0.2.100/24”. Es aquí donde se define que IP (o IPs) tendrá el servidor si esta en estado MASTER.

En las líneas 25 a 28 le indicamos una regla a VRRP: Vigila las interfaces de red eth0 y dummy0. Si alguna de estas interfaces de red no está disponible (estado “down”), entonces se notificará para que el nodo “BACKUP” (el que no tiene la IP de servicio en ese momento) se la asigne.

Finalmente reiniciaremos en cada servidor el servicio “keepalived”:

Podemos verificar el correcto arranque de keepalived con la configuración arriba indicada mediante el comando journalctl.

Para el primer nodo veremos algo así:

Vemos en las dos últimas líneas como se fuerza una nueva elección de maestro y como este nodo, “servidor-1”, es elegido como tal (MASTER STATE).

Tambien podemos verificar que la interfaz de red “dummy0” tiene asignada la IP 192.0.2.100 al ser el maestro:

En el segundo nodo veremos lo siguiente:

En las dos últimas líneas igualmente vemos que este nodo recibe un aviso de “prioridad superior” (desde el nodo “servidor-1”) y que por tanto pasa a tener el estado de respaldo (BACKUP STATE).

En el segundo nodo no habrá ninguna dirección IP asociada a la interfaz de red “dummy0” al estar como nodo de respaldo:

Verificando el funcionamiento

Con “keepalived” funcionando y los nodos definidos en maestro y esclavo, llega el momento de hacer las pruebas necesarias para verificar que, realmente, el comportamiento es el adecuado.

Utilizaremos el comando “ping” desde algún sistema en la misma subred 192.0.2.100/24 para verificar que la dirección IP de servicio está disponible. Puede hacerse desde el nodo de respaldo, aunque es recomendable utilizar un sistema externo a los nodos que están siendo puestos en marcha:

La primera prueba real que haremos será verificar qué ocurre cuando el nodo activo deja de estar disponible por reinicio o perdida de corriente eléctrica; y la segunda consistirá en simular un fallo en la interfaz de red.

En caso de reinicio del nodo activo

Conectados a ambos nodos, en el maestro reiniciaremos el servidor y en el secundario observaremos qué ocurre:

El nodo esclavo pasa a ser el maestro, y la dirección IP es asignada a este nodo:

La dirección IP de servicio seguirá siendo accesible desde los demás sistemas de la red. La siguiente salida muestra qué percepción ha tenido un cliente durante el proceso desde que falló el primer nodo hasta que el secundario tomó el control y comenzó a responder las peticiones:

Como puede observarse, la dirección IP virtual no ha estado disponible durante 25 segundos.

En caso de perdida de la interfaz de red física

Es posible simular la pérdida de una interfaz de red mediante el siguiente comando:

Podremos comprobar que el nodo esclavo detecta dicho fallo en el maestro y asigna la dirección IP virtual a su interfaz dummy0:

Al igual que en el caso anterior, la dirección IP virtual es reasignada:

El estado actual del servicio sería como muestra la siguiente imagen:

IP de servicio compartida - Servidor servidor-1 en fallo - Español
En caso de deshabilitar la interfaz de red en el segundo nodo mediante

Al no tener ninguna interfaz habilitada (ni en el primer nodo ni en el segundo), el servicio dejaría de ser prestado.

IP de servicio compartida - Todos los servidores en fallo - Español

El uso de la interfaz virtual “dummy0”

En lugar de utilizar la interfaz de red física “eth0”, decidimos utilizar “dummy0”, una interfaz virtual.

Una ventaja que presenta el uso de la interfaz virtual es la de poder deshabilitarla sin perder conexión al equipo a la hora de su administración.

Tambien podemos deshabilitar la interfaz de red “dummy0” según convenga para tareas administrativas, como la actualización del software del servidor. Al deshabilitarla, el tráfico fluirá automáticamente al nodo esclavo mientras estas tareas son completadas sin afectar a los usuarios.

Notas finales

Por simplicidad a lo largo de estos dos artículos relacionados con la dirección IP de servicio, hemos utilizado una única interfaz de red física tanto para la gestión del servidor como para prestar el servicio.

Es recomendable utilizar múltiples interfaces de red físicas, cada una para una tarea. Idealmente la interfaz de red física “eth0” se utilizará para prestar el servicio, mientras que otra interfaz de red “eth1” será la utilizada para administrar el servidor y donde “keepalived” intercambia el estado de ambos nodos.

De igual modo, por simplicidad, sólo hemos utilizado una conexión para cada tarea. En entornos donde prime la alta disponibilidad debe utilizarse un doble enlace de red mediante “bonding” o “teaming”, utilizando tarjetas de red independientes; en un futuro publicaré sobre ello.

Hemos utilizado una interfaz de red virtual “dummy0” por flexibilidad, de forma que podamos deshabilitarla y seguir operando en el servidor para su mantenimiento. Tambien nos permite forzar a que el nodo esclavo tome el control deshabilitandola en el maestro.

Alta disponibilidad en Linux: La IP de servicio, parte 1

En la entrada anterior vimos qué es la alta disponibilidad y qué debemos conseguir cuando un consumidor intenta acceder a un servicio: Una disponibilidad lo mas cercana posible al 100% del tiempo.

Esta entrada describe qué es la dirección IP de servicio, punto de entrada a los mismos, y cómo prepararla utilizando dos servidores.

Para poder implementar lo descrito bajo estas líneas es necesario disponer de dos servidores físicos o virtuales y una distribución Linux ya instalada en ellos.

Con el fin de no hacer excesivamente largas las entradas, esta está dividida en dos partes. Esta primera parte sirve de introducción y preparación de los sistemas, mientras que la segunda muestra como configurar la propia IP de servicio.

La dirección IP de servicio

Cuando accedemos a un servicio la conexión se realiza hacia una dirección IP, de forma directa (192.0.2.100) o a través de un nombre de host (www.example.com).

Supongamos que queremos acceder a una página web (http://www.example.com) y que su dirección IP asociada es “192.0.2.100”. Esta dirección IP, a través de la cual la página es accesible, es denominada “IP de servicio”.

El objetivo es que esta dirección IP esté siempre disponible. Para el consumidor la percepción debe ser como la siguiente imagen:

Conexion a Host (es)

Para conseguirlo, teniendo un mínimo de dos servidores, uno tendrá asignada la dirección IP de servicio y el otro estará en espera por si el primero de ellos falla para tomarla.

IP de servicio compartida

Conexion a Host (es)

Si el servidor “servidor-1” no fuese funcional, entonces el servidor “servidor-2” sería quien utilizase la dirección IP de servicio.  El servicio estaría degradado -un componente en estado de fallo-, pero operativo y accesible de cara al consumidor.

IP de servicio compartida - Servidor servidor-1 en fallo

Conexion a Host (es)

En caso de no tener ningún servidor disponible el servicio no se podrá prestar ya que la dirección IP de servicio no podría asignarse a ninguno de ellos.

IP de servicio compartida - Todos los servidores en fallo

Conexion a Host en fallo(es)

El consumidor no podrá acceder al servicio. Su percepción variará:

Conexion a Host en fallo(es)

La técnica que permite a un servidor utilizar una dirección IP de servicio previamente asignada a otro cuando este ya no está disponible se denomina “IP failover”.

Existen varios protocolos estandarizados que implementan métodos de “IP failover”, siendo VRRP el mas famoso de todos ellos y el que utilizaremos.

Configuración previa necesaria

Antes de comenzar hemos de tener preparado el material necesario.

Utilizaremos 2 servidores llamados “servidor-1” y “servidor-2”. He utilizado Debian 8, pero esta configuración es prácticamente idéntica en otros sistemas como CentOS donde varía el fichero de configuración de red y el comando de instalación de software.

Ambos servidores están conectados mediante la interfaz de red “eth0” a un switch y pertenecen a la subred 192.0.2.0/24. El switch está conectado a su vez a un router con dirección IP 192.0.2.1 que actúa como puerta de enlace (“gateway“).

El siguiente diagrama muestra la interconexión:

Conexión entre máquinas

Anotaremos los datos de ambos servidores para su posterior consulta:

Preparando los sistemas

En Linux existen varias implementaciones del protocolo VRRP. En estos artículos utilizaremos “keepalived” por su funcionalidad extra, pero otra opción valida sería “vrrpd“.

Los siguientes pasos se realizarán en ambos servidores.

Dependendiendo de la distribución utilizada podemos instalar “keepalived” mediante “apt” o “yum”:

También necesitamos que el servidor tenga cargado y configurado el módulo “dummy” que provee una interfaz de red virtual donde se asignará la dirección IP de servicio. Mas adelante explicaremos por qué utilizamos esta interfaz virtual en lugar de las clásicas interfaces “ethX”.

Para cargarlo y que sea permanente tras reiniciar un servidor ejecutaremos:

Para configurarlo y que sea permanente tras reiniciar un servidor ejecutaremos:

Una vez cargado, verificaremos que la interfaz “dummy0″ esté disponible:

Dejaremos la interfaz disponible para su uso:

Necesitamos un último cambio en el sistema operativo: Debemos permitir que los procesos (programas en segundo plano) puedan atender peticiones de red en una dirección IP que no les pertenece.

Ya que la dirección IP de servicio estará asignada únicamente a un servidor el otro no tendrá, por lo que no permitirá que los programas la utilicen para recibir datos. Esto implicaría, una vez que la dirección IP de servicio cambia de servidor, entrar en el servidor que la posee en ese momento y ejecutar los programas necesarios que, ahora sí, podrían utilizar dicha dirección IP.

Esto nos limitaría mucho y no cumpliríamos la premisa de “alta disponibilidad” -la IP de servicio cambiaría de servidor, sí, pero los procesos se ejecutarían para prestar servicio sin intervención manual- por lo que configuraremos el sistema para que permita a los procesos atender en cualquier IP, aunque no le pertenezca.

Llegados a este punto verificaremos lo siguiente:

– El software keepalived está instalado en ambos nodos:

– El módulo “dummy” está cargado y configurado en ambos nodos

– La interfaz “dummy0” existe en ambos nodos y está levantada

– El sistema tiene la variable net.ipv4.ip_nonlocal_bind a 1

Una vez se haya revisado todo, podemos comenzar con la configuración de la dirección IP de servicio, pero eso será en la próxima entrada de esta serie.

Alta disponibilidad: Introducción

Esta entrada es la primera de varias que escribiré sobre sistemas en alta disponibilidad, siendo esta una introducción a los conceptos básicos necesarios para comprender qué es y para qué sirve. Los artículos se centrarán en la alta disponibilidad de programas informáticos (o software).

La entrada servirá tanto a usuarios nóveles o personas que gestionan servicios informáticos y que no son técnicos como a introducidos en la materia que quieran refrescar su memoria o corregirme en aquello que crean conveniente.

Según avancen las entradas, estas serán mas técnicas y requerirán de un mayor conocimiento. El uso de la consola en una distribución Linux, la instalación de software y la edición de ficheros en ella serán requisitos indispensables.

A lo largo de ellas se configuraran algunos servicios en alta disponibilidad, como servidores web o servidores de bases de datos, de forma que puedan plasmarse los conceptos de estas entradas en algo tangible y que pueda llevarse a la práctica teniendo un componente teórico.

Tras esta introducción, comencemos.

Un mundo de servicios informáticos

La informática de hoy en día no puede concebirse sin eso que llamamos “servicios”. Los servicios son una mezcla de programas de ordenador y aparatos que están funcionando el 100% del tiempo, permanentemente conectados a una red informática y cuya misión es la transformación y transmisión de información.

Si alguno de esos programas o aparatos no se encuentran en funcionamiento, entonces no podrá utilizarse el servicio y no podremos obtener o transformar la información que queremos.

Un servicio puede ser tan simple como un único programa en un único servidor (o PC doméstico) o muy complejo como para estar formado por múltiples programas y aparatos. Sitios tan populares como Google o Facebook ejecutan muchos programas en miles de servidores y aparatos para prestar sus servicios de búsqueda, mapas, fotografías, red social, etc.

Cuando hablamos de servicio nos referimos a todas las cosas necesarias (programas, aparatos, etc.) que lo componen para que pueda ser utilizado.

Algunos programas que prestan servicios pueden ser “Apache HTTPD Server” que permite servir páginas web con un único programa, o Postfix que sirve correo electrónico y utiliza múltiples programas para ello. Ambos pueden ejecutarse en un único servidor o PC doméstico.

¿Qué es la disponibilidad?

Antes de poder responder a qué es la alta disponibilidad, hemos de saber que es la disponibilidad.

Este término, en el mundo informático, hace referencia a que un servicio existente sea accesible. Un servicio típico puede ser un servidor web, donde hay páginas alojadas que son accedidas desde navegadores web, como este blog.

Cuando un usuario a través de su navegador web intenta visitar una página existente -la hemos escrito correctamente- y esta no carga, decimos que “no está disponible” o que “está caída” y no podemos visualizarla.

Por tanto, “disponibilidad” es aquello que permite que un servicio existente pueda ser accedido y utilizado sin inconveniente.

Tiempo de disponibilidad

La disponibilidad se puede medir en un porcentaje de tiempo anual, en minutos. De 0% (0 minutos) a 100% (525600 minutos, aproximadamente). Un 1% corresponde a 5256 minutos u 87,6 horas o 3,65 días.

A este porcentaje lo llamamos “tiempo de disponibilidad” o “(service) uptime”. Y al tiempo en el cual el servicio no ha estado disponible lo llamamos “tiempo de indisponibilidad”, “tiempo de caída” o “downtime”.

En algunos servicios se calcula desde el primer día del año y en otros se calcula en periodos anuales desde el día su activación.

¿Qué es la alta disponibilidad?

Podemos definir la alta disponibilidad como la técnica utilizada para prestar un servicio de forma ininterrumpida, permitiendo que uno o más elementos (programas, servidores, aparatos de red, etc.) de ese servicio se encuentren en estado de fallo sin que ello repercuta en el funcionamiento o no sea perceptible para el usuario final.

La alta disponibilidad se consigue a través de la redundancia de los elementos que conforman el servicio: aparatos de red (switches, routers), servidores y componentes de servidor (dos o más discos duros, dos o más módulos de memoria RAM del tipo ECC, dos o más procesadores, dos o más fuentes de alimentación) conectados a dos o más tomas eléctricas en dos o más regletas -cada una de un proveedor eléctrico independiente-, etc.). Y lo mas importante: que los programas que prestan el servicio estén listos en toda esa infraestructura redundada para funcionar.

En Wikipedia hay también un artículo dedicado a la alta disponibilidad.

¿Para qué sirve la alta disponibilidad?

Desde un punto de vista de usuario, gracias a los servicios en alta disponibilidad podemos acceder a un servicio en cualquier momento y darle uso.

Para un profesional o empresa, la alta disponibilidad se traduce en una mejor imagen profesional. ¿Qué ocurriría si nuestros usuarios no pudieran acceder a nuestra página web? No podrían visualizarla. Y, ¿qué ocurriría si, además, somos proveedores de alojamiento y dejamos a muchos usuarios sin sus páginas web accesibles? Muchos usuarios que han depositado su confianza en nuestra empresa verán como durante un intervalo de tiempo sus páginas no serán accesibles con los perjuicios que eso podría provocarles; y a la empresa, si debe compensar económicamente por la indisponibilidad.

Podría ser mas trágico: Imaginemos que un servicio de un banco que se encarga de mover dinero de una entidad a otra deja de funcionar; o el servicio que abona las nóminas a los empleados; o el servicio de intercambio de información entre consultas médicas.

La alta disponibilidad permite que los servicios siempre estén disponibles. A un usuario le permite disfrutar de ellos, y a un profesional o empresa asegurarse de que sus servicios siempre puedan ser disfrutados el máximo tiempo posible, intentando que sea muy cercano al 100%.

 

¡Tengo un blog! (una vez más)

Ha llovido mucho desde el 26 de Septiembre de 2007. Aquél día fue el último que escribí en mi antiguo blog, salvo algún escarceo en Marzo de 2009.

Llevo dándole vueltas a retomar un blog desde poco después. O a tomarlo, porque en varios intentos lo mas próximo que estuve fue durante aquel 2007. Utilicé blogger, bitácoras.com, mi propio dominio (blog.daijo.org) con DrupalWordPress  y al final por una razón u otra: nada.

8 años después es un buen momento para ello. Uno ya pasa la treintena y se plantea que debe hacer lo que quiere hacer y no hace sin razón justificada más que su propio yo luchando contra sí mismo para ponerse o no a ello.

Hoy, 19 de Julio de 2016, con 40ºC de agradable temperatura en Ciudad Real, retomo mi blog. No tengo marcado ningún ritmo de publicación, cada entrada aparecerá cuando considere que está lista para ser publicada y comentada.

Antaño el blog tuvo como título (o subtitulo, según la época) “El Caldero de Temas”. Al igual que por entonces, mezclaré temáticas variadas: informática técnica, puntos de vista y opiniones personales, gestión de equipos, algo de como deberían ser las empresas de hoy en día del mundo informático “según yo”, etc. Soy un clásico mezclando churras con merinas.

En esta ocasión intentaré que las entradas aparezcan tanto en Español como en Inglés, según me permita el tiempo y para lo que utilizaré el complemento WPML. Tengo como objetivo mejorar mi inglés escrito y el uso de expresiones de forma correcta y agradeceré que en las traducciones todo aquel que encuentre fallos de expresión o escritura me lo indique.

Estuve tentado de reinsertar las entradas viejas de los blogs que tuve en blog.daijo.org, sin embargo, estas están indexadas gracias a la máquina del tiempo de archive.org. Los enlaces son los siguientes:

– Entre Diciembre de 2005hasta mayo de 2006 (utilizando Drupal).

– Entre Diciembre de 2006 y Octubre de 2007 (utilizando WordPress)

No debo olvidarme de que para cumplir con la legislación Española, he adaptado la plantilla de “Aviso Legal y Política de Privacidad” que ofrece la web “Ciudadano 2.0” en su zona de descargas gratuitas para sus lectores. Gracias a su autora, Raquel Rubín, por compartirla.