Capítulo 9. Descripción general del Servidor Virtual Linux

Red Hat Enterprise Linux LVS clustering utiliza una máquina Linux llamada el enrutador activo para enviar las peticiones desde la Internet a un conjunto de servidores. Para lograr esto, un LVS cluster consiste de dos clasificaciones de máquinas básicas — los enrutadores LVS (uno activo y otro de respaldo) y un conjunto de servidores reales los cuales proveen los servicios críticos.

El enrutador activo tiene dos papeles en el cluster:

La función del enrutador de respaldo es monitorear el enrutador activo y asumir su papel en el evento de una falla.

9.1. Una Configuración LVS Básica

La Figura 9-1 muestra un LVS cluster simple que consiste de dos capas. En la primera capa hay dos enrutadores LVS — uno activo y otro de respaldo. Cada uno de los enrutadores LVS tienen dos interfaces de red, una interfaz en la Internet y una en la red privada, permitiéndoles regular el tráfico entre las dos redes. Para este ejemplo el enrutador activo está usando una Traducción de direcciones de red o NAT para dirigir el tráfico desde la Internet a un número variable de servidores reales en la segunda capa, la cual en turno, provee los servicios necesarios. Por lo tanto, los servidores reales en este ejemplo están conectados a un segmento de red dedicado y pasan todo el tráfico público hacia adelante y hacia atrás a través del enrutador LVS activo. Para el mundo externo, el servidor cluster aparece como una sola entidad.

Figura 9-1. Una Configuración LVS Básica

Las peticiones de servicios que llegan al LVS cluster son direccionadas a su dirección IP virtual o VIP. Esta es una dirección enrutable públicamente que el administrador del sitio asocia con un nombre de dominio completamente cualificado, tal como www.example.com, y la cual es asignada a uno o más servidores virtuales [1]. Es importante resaltar que una dirección VIP migrará desde un enrutador LVS al otro durante un failover manteniendo de esta manera una presencia en esa dirección IP, también conocido como direcciones IP flotantes.

A las direcciones VIP se les puede establecer un alias o sobrenombre al mismo dispositivo que conecta el enrutador LVS a la Internet. Por ejemplo, si eth0 está conectado a la Internet, entonces a múltiples servidores virtuales se les puede colocar alias a eth0:1. Alternativamente, se puede asociar cada servidor virtual con un dispositivo separado por servicio. Por ejemplo, se puede manejar el tráfico HTTP en eth0:1 y el tráfico FTP se puede manejar en eth0:2.

Solamente hay un enrutador LVS activo a la vez. El papel de un enrutador activo es de redirigir las peticiones de servicios desde las direcciones IP virtuales a los servidores reales. La redirección está basada en uno de los ocho algoritmos de balanceo de cargas descritos más adelante en Sección 9.3.

El enrutador activo también monitorea dinámicamente la salud general de los servicios específicos en los servidores reales a través de un simple send/expect scripts. Para ayudar a detectar la salud de los servicios que requieren data dinámica, tal como HTTPS o SSL, el administrador también puede llamar ejecutables externos. Si un servicio en un servidor real tiene una falla o mal funcionamiento, el enrutador activo detiene el envío de trabajos a ese servidor hasta que este retorne a su operación normal.

El enrutador de respaldo lleva a cabo el papel de un sistema standby. Periódicamente, los enrutadores LVS intercambian mensajes de heartbeat o latidos a través de la interfaz pública externa y, en una situación de failover, a través de la interfaz privada. Si el nodo de respaldo falla en recibir un latido dentro de un intervalo esperado, iniciará un proceso de failover y asumirá el papel de enrutador activo. Durante un failover, el enrutador de respaldo toma el control de las direcciones VIP servidas por el enrutador fallido usando la técnica conocida como ARP spoofing — donde el enrutador de respaldo LVS se anuncia asímismo como el destino para los paquetes IP direccionados al nodo fallido. Cuando el nodo fallido retorna a servicio activo, el nodo de respaldo asume su papel de hot-backup otra vez.

La configuración sencilla de dos capas, usada en la Figura 9-1 es más apropiada para clusters que sirven datos que no cambian con frecuencia — tal como páginas Web estáticas — porque los servidores reales individuales no sincronizan automáticamente los datos entre cada nodo.

9.1.1. Replicar y compartir datos entre Servidores Reales

Puesto que no existe un componente incorporado en LVS clustering para compartir los mismos datos entre servidores reales, el administrador tiene dos opciones básicas:

  • Sincronizar los datos a lo largo del pool de servidores

  • Agregar una tercera capa a la topología para acceso compartido de datos

La primera opción es mejor para servidores que no permiten a un gran número de usuarios cargar o cambiar los datos en los servidores reales. Si el cluster permite a muchos usuarios modificar los datos, como en el caso de un sitio web de e-commerce, entonces es preferible añadir una tercera capa.

9.1.1.1. Configurando Servidores Reales para sincronizar los datos

Hay muchas formas que el administrador puede escoger para sincronizar los datos a lo largo del grupo de servidores reales. Por ejemplo, los scripts del shell pueden ser empleados para que si un ingeniero Web actualiza una página, la página sea publicada a todos los servidores simultáneamente. También, el administrador del cluster puede usar programas tales como rsync para replicar los datos cambiados a través de todos los nodos en un intervalo especificado.

Sin embargo, este tipo de sincronización de datos no funciona bien si el cluster está extremadamente cargado con usuarios cargando archivos o emitiendo transacciones de bases de datos. Para un cluster con una gran carga, la mejor solución es una topología de tres capas.

Notas

[1]

Un servidor virtual es un servicio configurado para escuchar en una IP virtual específica. Vea la Sección 12.6 para más información sobre la configuración de un servidor virtual usando la Herramienta de configuración Piranha.