Language:
Format:

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Administración del Equilibrador de carga

Red Hat Enterprise Linux 6

Equilibrador de carga para Red Hat Enterprise Linux

Edición 6

Resumen

La construcción de un sistema de adición del equilibrador de carga ofrece solución disponible y escalable para servicios de producción que usan servidores virtuales Linux especializados (LVS) para dirigir las técnicas de balanceo de cargas. Este libro describe la configuración de los sistemas y servicios de alta disponibilidad de Red Hat Enterprise Linux y la adición del equilibrador de carga para Red Hat Enterprise Linux 6.

Introducción

Este documento proporciona información sobre instalación, configuración y manejo de los componentes de adición del equilibrador de carga. La adición del equilibrador de carga proporciona balanceo de carga a través de técnicas de enrutamiento especializadas que despachan tráfico a un grupo de servidores.

La audiencia de este documento debe tener amplia experiencia con Red Hat Enterprise Linux y comprender los conceptos de clúster, almacenamiento y servidor de informática.

Este documento está organizado así:

Capítulo 1, Sinopsis de adición del equilibrador de carga
Capítulo 2, Configuración inicial de adición del equilibrador de carga
Capítulo 3, Configuración de adición del equilibrador de carga
Capítulo 4, Configuración de la adición del equilibrador de carga mediante Piranha Configuration Tool
Apéndice A, Cómo usar la adición del equilibrador de carga con la adición de alta disponibilidad

Para obtener mayor información acerca de Red Hat Enterprise Linux 6, consulte los siguientes recursos:

Guía de instalación de Red Hat Enterprise Linux — Proporciona información sobre instalación de Red Hat Enterprise Linux 6.
Guía de implementación de Red Hat Enterprise Linux — Proporciona información sobre la implementación, configuración y administración de Red Hat Enterprise Linux 6.

Para obtener más información sobre la adición del equilibrador de carga y los productos relacionados para Red Hat Enterprise Linux 6, consulte los siguientes recursos:

Vista General — Proporciona un resumen de alto nivel de adiciones de alta disponibilidad y almacenamiento resistente y equilibrador de carga.
Cómo configurar y administrar la adición de alta disponibilidad Proporciona información sobre la configuración y manejo de la adición de alta disponibilidad (conocida también como Red Hat Cluster) para Red Hat Enterprise Linux 6.
Administración del Gestor de volúmenes lógicos — Proporciona una descripción del Gestor de Volúmenes Lógicos (LVM) e incluye información sobre la ejecución de LVM en un entorno de clúster.
Sistema de archivos global 2: Configuración y administración — Proporciona información sobre la instalación, configuración y mantenimiento de Red Hat Resilient Storage Add-On (también conocido como Red Hat Global File System 2).
DM Multipath — Proporciona información sobre el uso de la función Device-Mapper Multipath de Red Hat Enterprise Linux 6.
Notas de lanzamiento — Proporciona información sobre el lanzamiento actual de productos de Red Hat.

Este y otros documentos de Red Hat están disponibles en versiones HTML, PDF, PDF y EPUB en http://access.redhat.com/documentation/docs.

1. Comentarios

Si encuentra un error tipográfico o si ha pensado en alguna forma de mejorar este manual, nos encantaría saberlo. Por favor, envíe un informe en Bugzilla (http://bugzilla.redhat.com/bugzilla/) con el nombre del producto Red Hat Enterprise Linux 6, el componente doc-Load_Balancer_Administration y el número de versión 6.1.

Si tiene alguna sugerencia de cómo mejorar la documentación, por favor trate de ser lo más explícito posible. Si ha encontrado algún error, incluya el número de la sección y parte del texto que lo rodea para así poderlo hallar fácilmente.

Capítulo 1. Sinopsis de adición del equilibrador de carga

Nota

A partir de Red Hat Enterprise Linux 6.6, Red Hat proporciona soporte para HAProxy y keepalived además del software del equilibrador de carga Piranha. Para obtener más información sobre cómo configurar un sistema Red Hat Enterprise Linux con HAProxy y keepalived, consulte la documentación de administración del equilibrador de carga para Red Hat Enterprise Linux 7.

La adición del equilibrador de carga es una serie de componentes de software integrados que proporcionan Servidores virtuales de Linux (LVS) para balanceo de carga IP, a través de un conjunto de servidores reales. La adición del equilibrador de carga se ejecuta en un enrutador LVS activo y también como un enrutador LVS de respaldo. El enrutador LVS activo tiene dos roles:

Balancear la carga a través de los servidores reales.
Revisar la integridad de los servicios en cada servidor real.

El enrutador LVS de respaldo sondea el estado del enrutador LVS activo y toma el control de sus tareas en caso de que falle.

Este capítulo proporciona una visión general de los componentes y funciones de la adición del equilibrador de carga. Consta de las siguientes secciones:

La Sección 1.1, “ Configuración básica de una adición del equilibrador de carga”
La Sección 1.2, “Configuración de adición del equilibrador de carga de tres partes ”
La Sección 1.3, “Sinopsis de programación de la adición del equilibrador de carga ”
La Sección 1.4, “Métodos de enrutamiento”
La Sección 1.5, “Marcas de cortafuegos y persistencia”
La Sección 1.6, “Adición del equilibrador de carga — Un diagrama de bloques”

1.1. Configuración básica de una adición del equilibrador de carga

Figura 1.1, “ Configuración básica de una adición del equilibrador de carga” muestra una adición simple del equilibrador de carga de dos capas. En la primera capa hay un enrutador activo y un enrutador LVS de respaldo. Cada enrutador LVS tiene dos interfaces de red, una interfaz en la Internet y la otra en una red privada, lo cual permite regular el tráfico entre las dos redes. En este ejemplo, el enrutador activo utiliza Traducción de acceso de redes o NAT para dirigir el tráfico desde la Internet a un número variable de servidores reales en la segunda capa, la cual a su vez proporciona los servicios necesarios. Por lo tanto, los servidores reales en este ejemplo, se conectan a una red privada dedicada y pasan todo el tráfico que va y viene a través del enrutador LVS activo. Para el mundo exterior, los servidores aparecen como una entidad.

Figura 1.1. Configuración básica de una adición del equilibrador de carga

Las solicitudes de servicios que llegan al enrutador LVS se dirigen a la 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 totalmente calificado, tal como www.example.com, y se asigna a uno o más servidores virtuales. Un servidor virtual es un servicio configurado para escuchar en una IP virtual específica. Consulte la Sección 4.6, “SERVIDORES VIRTUALES” para obtener más información sobre cómo configurar un servidor virtual mediante Piranha Configuration Tool. Una dirección VIP migra desde un enrutador LVS a otro durante una conmutación, manteniendo así una presencia en esa dirección IP (conocidas también direcciones IP flotantes).

Las direcciones VIP pueden tener alias que se dirijan al mismo dispositivo que conecta al enrutador LVS a la Internet. Por ejemplo, si eth0 está conectado a la Internet, puede haber varios servidores virtuales con alias para eth0:1. Alternativamente, cada servidor virtual puede asociarse con un dispositivo por servicio. Por ejemplo, el tráfico HTTP puede ser manejado en eth0:1 y el tráfico FTP puede ser manejado en eth0:2.

Solo un enrutador LVS está activo a la vez. El rol del enrutador activo es redirigir la solicitud del servicio desde la dirección IP virtual al servidor real. La redirección está basada en uno de ocho algoritmos de balance de carga descritos más adelante en la Sección 1.3, “Sinopsis de programación de la adición del equilibrador de carga ”.

Asimismo, el enrutador activo sondea de forma dinámica la salud de los servicios específicos en los servidores reales mediante un script de envío y espera. Para ayudar en la detección de la salud de servicios que requieren datos dinámicos, tal como HTTPS o SSL, el administrador puede llamar ejecutables externos. Si un servicio en un servidor real no funciona, el enrutador activo deja de enviar tareas a dicho servidor hasta que vuelva a la operación normal.

El enrutador de respaldo cumple el rol de un sistema en espera. El enrutador LVS intercambia periódicamente mensajes denominados pulsos, a través de la interfaz pública externa primaria y de la interfaz privada en caso de procesos de recuperación contra fallos. Si el nodo de respaldo no recibe un pulso dentro de un intervalo de tiempo determinado, inicia un proceso de conmutación y asume el rol del enrutador LVS activo. Durante el proceso de conmutación, el enrutador de respaldo toma las direcciones VIP servidas por el enrutador fallido mediante una técnica llamada suplantación de identidad ARP — en donde el enrutador LVS de respaldo se anuncia como el servidor de destino para los paquetes IP dirigidos al nodo fallido. Cuando el nodo fallido retorna al servicio activo, el nodo de respaldo asume nuevamente su rol de asistente de respaldo en caliente.

La configuración simple de dos capas utilizada en Figura 1.1, “ Configuración básica de una adición del equilibrador de carga” es la mejor para servir datos que no cambian con frecuencia — como por ejemplo, las páginas web estáticas — porque los servidores individuales reales no sincronizan automáticamente los datos entre cada nodo.

1.1.1. Replicación de datos y la compartición de datos entre servidores reales

Ya que no hay un componente incorporado en la adición del equilibrador de carga para compartir los datos entre los servidores reales, el administrador tiene dos opciones básicas:

Sincronizar los datos a través del grupo de servidores reales.
Añadir una tercera capa a la topología para el acceso de datos compartidos.

La primera opción es la preferida en aquellos servidores que no aceptan que un gran número de usuarios cargue o cambie datos en los servidores reales. Si la configuración permite una gran cantidad de usuarios, tales como un sitio web de comercio electrónico, es preferible adicionar una nueva capa.

1.1.1.1. Cómo configurar servidores reales para sincronizar datos

Hay varias formas en las que un administrador puede sincronizar datos a través del grupo de servidores reales. Por ejemplo, los scripts de shell pueden emplearse para que, si un ingeniero de la red actualiza una página, la página se envíe simultáneamente a todos los usuarios. También el administrador del sistema puede usar programas tales como rsync para replicar los datos cambiados a través de todos los nodos en el intervalo establecido.

Sin embargo, este tipo de sincronización de datos no funciona de forma óptima, si la configuración se sobrecarga constantemente al subir archivos o emitir transacciones de base de datos. Para una configuración con una carga alta, la solución ideal es una topología de tres partes.

1.2. Configuración de adición del equilibrador de carga de tres partes

Figura 1.2, “Configuración de adición del equilibrador de carga de tres partes ” muestra una topología típica de adición del equilibrador de carga. En este ejemplo, el enrutador activo LVS dirige las solicitudes desde la Internet hasta el grupo de servidores reales. Cada uno de los servidores reales accede luego a la fuente de datos compartidos en la red.

Figura 1.2. Configuración de adición del equilibrador de carga de tres partes

Esta configuración es ideal para servidores FTP, en donde los datos son almacenados en un servidor central de alta disponibilidad y pueden ser accedidos por cada servidor real a través de un directorio NFS exportado o una compartición de Samba. Esta topología también se recomienda para sitios web que acceden a una base de datos central de alta disponibilidad para realizar transacciones. Además, al utilizar una configuración activo-activo con una adición del equilibrador de cargas, los administradores pueden configurar un clúster de alta disponibilidad para servir al mismo tiempo los dos roles.

El tercer tercio en el ejemplo anterior no tiene que usar adición del equilibrador de carga, pero al no usar una solución altamente disponible introduciría un punto individual crítico de falla.

1.3. Sinopsis de programación de la adición del equilibrador de carga

Una de las ventajas del uso de la adición del equilibrador de carga es la capacidad de realizar balanceo flexible, balanceo de carga nivel IP en el grupo de servidores reales. Esta flexibilidad se debe a la variedad de algoritmos de programación que un administrador puede elegir desde cuando configura la adición del equilibrador de carga. La adición del equilibrador de carga es superior a los métodos menos flexibles, tales como DNS de Round-robin donde la naturaleza jerárquica de DNS y el almacenamiento en caché por máquinas de clientes pueden conducir a desequilibrios. Además, el filtraje de nivel bajo empleado por el enrutador LVS tiene ventajas sobre el envío de la solicitud del nivel de aplicaciones porque las cargas de balanceo en el nivel de paquetes gastos costos de computación mínimos y permite la escalabilidad.

Al usar programación, el enrutador tiene en cuenta la actividad de servidores reales y, opcionalmente, un factor de peso de administrador asignado, cuando se enrutan las solicitudes de servicios. El uso de pesos asignados otorga prioridad arbitraria a las máquinas individuales. Esta forma de programación, permite crear un grupo de servidores reales, mediante una variedad de combinaciones de hardware y software y permite al enrutador activo, cargar equitativamente cada servidor real.

El mecanismo de programación para la adición del equilibrador de carga es proporcionado por una serie de parches de kernel denominados módulos de Servidor virtual IPr o IPVS. Estos módulos habilitan el cambio dela capa de transporte capa 4 (L4), la cual está diseñada para funcionar bien con múltiples servidores en una dirección IP individual.

Para rastrear y dirigir paquetes de forma eficiente a los servidores reales, IPVS crea una tabla IPVS en el kernel. Esta tabla es utilizada por el enrutador activo LVS para redirigir las peticiones de una dirección de servidor virtual y las respuestas de los servidores reales en el grupo.La tabla IPVS es actualizada constantemente por una herramienta denominada ipvsadm —, la cual adiciona o retira miembros de clúster según su disponibilidad.

1.3.1. Programación de algoritmos

La estructura que la tabla IPVS adquiera, depende del algoritmo de programación que el administrador elige para un servidor determinado. Para otorgar un máximo de flexibilidad en los tipos de servicios que puede agrupar y programar estos servicios, Red Hat Enterprise Linux proporciona los algoritmos programados que aparecen a continuación. Para obtener más información sobre cómo asignar algoritmos de programación, consulte la Sección 4.6.1, “La subsección VIRTUAL SERVER”.

Programación Round-robin: Distribuye en secuencia cada solicitud alrededor del grupo de los servidores reales. Al usar este algoritmo, todos los servidores reales se manejan del mismo modo, independiente de su capacidad o carga. Este modelo de programación es similar a DNS Round-robin, pero es más granular debido a que es una conexión de red y no se basa en host. La programación Round-Robin de adición de carga no experimenta los desequilibrios causados por solicitudes DNS en caché.
Programación Round-robin ponderada: Distribuye en secuencias cada solicitud alrededor del grupo de servidores reales, pero provee más tareas a los servidores con mayor capacidad. La capacidad es indicada por el factor de peso asignado al usuario y se ajusta de arriba a abajo y de abajo a arriba gracias a la información de carga dinámica. Consulte la Sección 1.3.2, “Peso de servidor y programación” para obtener más información sobre cómo ponderar servidores reales.
El programador Round-robin ponderado es la elección preferida cuando hay diferencias significativas en la capacidad de servidores reales en el grupo. Sin embargo, si la carga de solicitudes varía dramáticamente, el servidor con más capacidad respondería más de las solicitudes que le corresponden.
Least-Connection: Distribuye más solicitudes a los servidores reales que tienen menos conexiones activas. Porque hace seguimiento de conexiones en vivo a los servidores reales a través de la tabla IPVS. least-connection es un tipo de algoritmo de programación dinámico, lo cual lo convierte en una elección ideal cuando hay un alto grado de variaciones en la carga de solicitudes. Se ajusta mejor para un grupo de servidores reales en donde cada nodo de miembro tenga aproximadamente la misma capacidad. Si un grupo de servidores tiene diferentes capacidades, la programación least-connection es la mejor opción.
Weighted Least-Connections (default): Distribuye más solicitudes a los servidores con menos conexiones activas en relación con sus capacidades. La capacidad es indicada por el peso asignado al usuario y se ajusta de arriba a abajo y de abajo a arriba , mediante la información de carga dinámica. La adición de ponderación hace que este algoritmo sea ideal cuando la infraestructura contiene hardware de capacidades de hardware variante. Para más información sobre ponderación de servidores reales, consulte la Sección 1.3.2, “Peso de servidor y programación” .
Locality-Based Least-Connection Scheduling: Distribuye más solicitudes a los servidores que tengan un número menor de conexiones activas con relación a las IP de destino. Este algoritmo se utiliza en clúster de servidores proxy-cache. Sirve para asignar los paquetes a una dirección IP al servidor para esa dirección, a menos que ese servidor esté por encima de su capacidad y tenga un servidor en su media carga, en este caso se asigna la dirección IP al servidor real menos cargado.
Locality-Based Least-Connection Scheduling con programación de replicación: Distribuye más solicitudes a los servidores que tienen menos conexiones activas en relación con sus IP de destino. Este algoritmo también está diseñado para ser utilizado en un clúster de servidores proxy-cache. Se diferencia de Locality-Based Least-Connection Scheduling al asignar la dirección IP de destino a un subconjunto de nodos de servidores reales. Las solicitudes se envían luego al servidor en este subconjunto con el número más bajo de conexiones. Si todos los nodos para la dirección IP de destino sobrepasan su capacidad, se replica un servidor para esa dirección IP de destino al adicionar el servidor real con el número más bajo de conexiones posibles de todo el grupo de servidores al subconjunto de servidores reales para esa IP de destino. El nodo con mayor carga se saca del subconjunto de servidores reales para evitar un exceso de replicación.
Destination Hash Scheduling: Distribuye las solicitudes al grupo de servidores reales al buscar la IP de destino en una tabla hash estática. Este algoritmo está diseñado para ser utilizado en un clúster de servidor proxy-cache.
Source Hash Scheduling: Distribuye todas las solicitudes de acuerdo con un diccionario estático de direcciones IP. Este algoritmo se utiliza en enrutadores LVS con varios cortafuegos.

1.3.2. Peso de servidor y programación

El administrador de adición del equilibrador de carga puede asignar un peso a cada nodo en el grupo de servidor real. Este peso es un valor entero que se factoriza dentro de algoritmos de programación distribución de peso (tal como weighted least-connections) y ayuda al enrutador LVS a cargar hardware de una forma más equitativa con diferentes funcionalidades.

Pesa el trabajo como una relación relativa a otra. Por ejemplo, si un servidor real tiene un peso de 1 y el otro servidor tiene un peso de 5, entonces el servidor con un peso de 5 obtiene 5 conexiones para cada conexión 1 que el otro servidor obtenga. El valor predeterminado para el peso de servidor real es 1.

Aunque agregar peso a la configuración de hardware en un grupo de servidores reales puede ayudar al clúster a equilibrar cargas de una forma más eficiente, puede causar desequilibrios temporales cuando se introduce un servidor real al grupo de servidores reales y el servidor virtual está programado mediante least-connections ponderadas. Por ejemplo, suponga que hay tres servidores en un grupo de servidores reales. Los servidores A y B se ponderan a 1 y el tercero, el servidor C, se pondera a 2. Si el servidor C se cae por alguna razón, los servidores A y B distribuyen equitativamente la carga abandonada. Sin embargo, cuando el servidor C se reconecta, el enrutador LVS ve que tiene 0 conexiones e inunda el servidor con todas las solicitudes de entrada hasta que esté a la par con los servidores A y B.

Para evitar este fenómeno, los administradores pueden hacer que el servidor virtual sea un servidor quiesce que , cuando esté habilitado, el servidor C real en el ejemplo de arriba, no se elimine de la tabla del servidor virtual. En su lugar, su peso se establecerá a 0, que lo inhabilita. Cuando un servidor C real esté disponible, será rehabilitado al restaurar su peso original.

1.4. Métodos de enrutamiento

Red Hat Enterprise Linux usa Traducción de dirección de red o enrutamiento NAT para adición del equilibrador de carga, la cual otorga al administrador una amplia flexibilidad cuando utiliza hardware disponible e integra la adición del equilibrador de carga en una red existente.

1.4.1. Enrutamiento NAT

Figura 1.3, “Adición del equilibrador de carga implementado con enrutamiento NAT” una adición del equilibrador de carga que utiliza enrutamiento NAT para trasladar las solicitudes entre la Internet y la red privada.

Figura 1.3. Adición del equilibrador de carga implementado con enrutamiento NAT

En el ejemplo, hay dos NIC en el enrutador LVS activo. El NIC para Internet tiene una dirección IP real en eth0 y tiene una dirección IP flotante en eth0:1. El NIC para la interfaz de red privada tiene una dirección IP real en eth1 y tiene una dirección flotante en eth1:1. En caso de conmutación, la interfaz virtual que apunta a la Internet y la privada, que apunta a la interfaz virtual se toman simultáneamente por el enrutador de respaldo LVS. Todos los servidores reales en la red privada utilizan la IP flotante para el enrutador NAT como el enrutador predeterminado para comunicarse con el enrutador LVS activo, de esta forma la habilidad para responder a solicitudes desde Internet no se ve impedida.

En el ejemplo, la dirección IP flotante pública del enrutador LVS y la dirección IP flotante NAT privada son alias para los dos NIC físicos. Aunque es posible asociar cada dirección IP flotante a su dispositivo físico en el enrutador LVS, no se necesitan más de dos NIC.

Con esta topología, el enrutador LVS activo recibe la solicitud y la enruta al servidor apropiado. El servidor real procesa la solicitud y retorna el paquete al enrutador LVS. El enrutador LVS utiliza NAT para remplazar la dirección del servidor real en los paquetes con la dirección VIP pública del enrutador LVS. Este proceso se llama enmascaramiento de IP porque la dirección IP de los servidores reales se esconde de los clientes.

Al utilizar NAT, los servidores reales pueden estar en cualquier clase de máquina que ejecute varios sistemas operativos. La mayor desventaja es que el enrutador LVS puede volverse un cuello de botella en implementaciones grandes de clúster ya que debe procesar solicitudes entrantes y salientes.

1.4.2. Enrutamiento directo

La construcción de adición del equilibrador de carga que use enrutamiento directo proporciona beneficios de rendimiento aumentado comparado con otras topologías de red de adición del equilibrador de cargas. El enrutamiento directo permite a los servidores reales procesar y dirigir directamente los paquetes para un usuario que los solicita en lugar de pasar todos a los paquetes salientes a través del enrutador LVS. El enrutamiento directo reduce la posibilidad de problemas de rendimiento de red al relegar la tarea del enrutador LVS para procesar paquetes de entrada únicamente.

Figura 1.4. Adición del equilibrador de carga implementada con enrutamiento directo

En una configuración directa típica de adición del equilibrador de carga, el enrutador LVS recibe una solicitud entrante a través de una IP virtual (VIP) y utiliza un algoritmo de programación para dirigir la solicitud a los servidores reales. El servidor real procesa la solicitud y envía directamente la respuesta al cliente, sin pasar por el enrutador LVS. Este método de enrutamiento permite escalabilidad en el que servidores reales pueden ser agregados sin la carga adicional en el enrutador LVS antes de que lleguen al cliente, lo cual puede convertirse en un cuello de botella bajo una carga pesada de red.

1.4.2.1. Enrutamiento directo y limitación ARP

Aunque hay muchas ventajas al utilizar enrutamiento directo en la adición del equilibrador de carga, hay también algunas desventajas. El problema más común se presenta con el Protocolo de resolución de direcciones) ARP .

En situaciones típicas, un cliente en Internet envía una solicitud a una dirección IP. Los enrutadores de red envían respuestas a sus destinatarios al relacionar direcciones IP a la dirección MAC de la máquina con ARP. Las solicitudes ARP se transmiten a todas las máquinas conectadas en la red y la máquina con la combinación IP/MAC correcta recibe el paquete. Las asociaciones IP/MAC se almacenan en una caché ARP que se limpia periódicamente (generalmente cada 15 minutos).

El problema con las solicitudes ARP en un enrutamiento directo de la configuración de la adición del equilibrador de carga se debe a que una solicitud de cliente debe estar asociada a una dirección MAC para que pueda procesarse, la dirección IP virtual del sistema de la adición del equilibrador de carga también debe estar asociada con una MAC. Sin embargo, puesto que tanto el enrutador LVS como los servidores reales tienen el mismo VIP, la solicitud ARP se enviará a todas las máquinas asociadas con el VIP. Esa conducta puede ocasionar varios problemas, por ejemplo, el VIP puede asociarse directamente a uno de los servidores reales y procesar la solicitud directamente, dejando de lado al enrutador LVS y frustrando así la configuración de la adición del equilibrador de carga.

Para resolver este problema, asegúrese de que las solicitudes de entrada sean enviadas siempre al enrutador LVS y no a los servidores reales. Esto puede realizarse mediante arptables_jf o la herramienta de filtro de paquetes iptables por las siguientes razones:

El comando arptables_jf evita la asociación de ARP desde los VIP con servidores reales.
El método iptables evita el problema de ARP al no confiugar en primer lugar los VIP en los servidores reales.

Para obtener más información sobre el uso de arptables o iptables en un enrutamiento directo de adición de entorno de adición del equilibrador de carga, consulte la Sección 3.2.1, “Enrutamiento directo y arptables_jf” o la Sección 3.2.2, “Enrutamiento directo e iptables”.

1.5. Marcas de cortafuegos y persistencia

En algunas situaciones, puede ser que un cliente desee reconectarse al mismo servidor repetidas veces, en lugar de tener que enviar un algoritmo de adición de equilibrador de carga que solicite el mejor servidor disponible. Ejemplos de estas situaciones, incluyen múltiples formas de pantallas de red, cookies, SSL y conexiones FTP. En estos casos, el cliente puede no funcionar adecuadamente a menos que las transacciones sean manejadas por el mismo servidor para retener contexto. La adición del equilibrador de carga, proporciona dos funcionalidades diferentes para manejar esto: marcas de persistence y firewall marks.

1.5.1. Persistencia

Cuando persistencia está activada, actúa como un temporizador. Cuando un cliente se conecta a un servidor, la adición del equilibrador de carga recuerda la última conexión por un tiempo especificado. Si esa misma dirección IP de cliente se reconecta dentro de ese periodo, se envía al mismo servidor al que se conectó anteriormente — y evita así, los mecanismos de balanceo de carga. Si una conexión se presenta fuera del periodo especificado, se maneja de acuerdo con las reglas de programación vigentes. .

Persistencia también permite al administrador especificar una máscara de subred para aplicar a las direcciones IP del cliente como herramienta para controlar las direcciones que tienen un mayor nivel de persistencia, agrupando así conexiones a esa subred.

La agrupación de conexiones destinadas a diferentes puertos puede ser importante para los protocolos que utilicen más de un puerto para comunicarse, tal como FTP. Sin embargo, la persistencia no es la manera más efectiva de agrupar las conexiones destinadas a diferentes puertos. Para estas situaciones, es mejor utilizar marcas de cortafuegos.

1.5.2. Marcas de cortafuegos

Las marcas de cortafuegos ofrecen una manera fácil y eficiente de agrupar puertos utilizados por un protocolo o grupo de protocolos relacionados. Por ejemplo, si la adición del equilibrador de carga se implementa en un sitio de comercio electrónico, las marcas de cortafuegos pueden ser usadas para agrupar conexiones HTTP en el puerto 80 y conexiones seguras en el puerto 443. Al asignar la misma marca de cortafuegos al servidor virtual para cada protocolo, la información de estado para la transacción puede ser preservada porque el enrutador LVS envía todas las solicitudes al mismo servidor real, después de que la conexión ha sido abierta.

Gracias a su eficiencia y facilidad de uso, los administradores de la adición del equilibrador de carga deben utilizar, en lo posible, marcas de cortafuegos en vez de persistencia para agrupar conexiones. Sin embargo, se debe añadir persistencia a los servidores virtuales junto a las marcas de cortafuegos para asegurarse que los clientes se reconecten al mismo servidor por un periodo de tiempo adecuado.

1.6. Adición del equilibrador de carga — Un diagrama de bloques

Los enrutadores LVS usan una colección de programas para monitorizar miembros y servicios de clúster. La Figura 1.5, “Componentes de adición del equilibrador de carga” ilustra cómo estos programas, tanto los enrutadores activos como los de respaldo, funcionan juntos para administrar el clúster.

Figura 1.5. Componentes de adición del equilibrador de carga

El daemon pulse se ejecuta tanto en el servidor LVS activo como en el pasivo. En el enrutador LVS de respaldo, pulse envía un pulso a la interfaz pública del enrutador activo para asegurarse de que el enrutador activo esté funcionando. En el enrutador activo, pulse inicia el daemon lvs y responde a los pulsos que provienen del enrutador LVS de respaldo.

Una vez iniciado, el daemon lvs llama a la herramienta ipvsadmin para configurar y mantener la tabla de rutas IPVS en el kernel e inicia un proceso nanny para cada servidor virtual configurado en cada servidor real. Cada proceso nanny revisa el estado de cada servidor configurado en un servidor real e informa al daemon lvs si el servicio en el servidor real no está funcionando. Si el servicio no está funcionando, el daemon lvs ordena a ipvsadm que retire el servidor real de la tabla de rutas IPVS.

Si el enrutador de respaldo no recibe una respuesta desde el enrutador activo, el primero inicia un proceso de conmutación llamando a send_arp para que reasigne todas las direcciones IP virtuales a las direcciones de hardware NIC (dirección MAC) del nodo de respaldo, envía un comando para activar el enrutador activo a través de las interfaces de red pública y privada para apagar el daemon lvs en el enrutador activo e iniciar el daemon lvs en el nodo de respaldo con el fin de aceptar solicitudes para los servidores virtuales configurados.

1.6.1. Componentes de adición del equilibrador de carga

La Sección 1.6.1.1, “pulse” muestra una lista detallada de cada componente de software en un enrutador LVS.

1.6.1.1. `pulse`

Este es el proceso que inicia el resto de daemons relacionados con los enrutadores. Durante el inicio, el script /etc/rc.d/init.d/pulse inicia el daemon. Luego lee el archivo de configuración /etc/sysconfig/ha/lvs.cf. En el enrutador activo, pulse inicia el daemon. En el enrutador de respaldo, pulse determina la salud del enrutador activo ejecutando un pulso cada cierto tiempo (puede ser configurado por el usuario). Si el enrutador activo no responde después de un tiempo determinado, se inicia la conmutación. Durante este proceso, pulse en el enrutador de respaldo ordena al daemon pulse en el enrutador activo, apagar todos los servicios LVS, inicia el programa send_arp para reasignar las direcciones IP flotantes a las direcciones MAC del enrutador de respaldo, e inicia el daemon lvs.

1.6.1.2. `lvs`

El daemon lvs se ejecuta en el enrutador LVS activo una vez es llamado por pulse. Lee el archivo de configuración /etc/sysconfig/ha/lvs.cf, llama a la herramienta ipvsadm para construir y mantener la tabla de rutas IPVS y asigna un proceso nanny para cada servicio de adición del equilibrador de carga configurado. Si nanny reporta que un servidor real ha sido apagado, lvs ordena a la herramienta ipvsadm retirar el servidor real de la tabla de rutas IPVS.

1.6.1.3. `ipvsadm`

Este servicio actualiza la tabla de rutas IPVS en el kernel. El daemon lvs configura y administra la adición del equilibrador de carga al llamar a ipvsadm para agregar, cambiar o borrar entradas en la tabla de rutas IPVS.

1.6.1.4. `nanny`

El daemon de sondeo nanny se ejecuta en el enrutador LVS activo. A través de este daemon, el enrutador activo determina el estado de cada servidor real y, puede monitorizar la carga de trabajo. Un proceso independiente se ejecuta para cada servido definido en cada servidor real.

1.6.1.5. `/etc/sysconfig/ha/lvs.cf`

Este es el archivo de adición del equilibrador de carga. Directa o indirectamente, todos los daemons obtienen la información de configuración desde este archivo.

1.6.1.6. Piranha Configuration Tool

Esta es la herramienta de red para monitorizar, configurar y administrar la adición del equilibrador de carga. Es la herramienta predeterminada para mantener el archivo de configuración de adición del equilibrador de carga /etc/sysconfig/ha/lvs.cf.

1.6.1.7. `send_arp`

Este programa envía señales ARP cuando la dirección IP de punto flotante cambia de un nodo a otro durante la conmutación.

El Capítulo 2, Configuración inicial de adición del equilibrador de carga revisa pasos importantes de posinstalación que debe seguir antes de configurar Red Hat Enterprise Linux para que sea un enrutador LVS.

Capítulo 2. Configuración inicial de adición del equilibrador de carga

Después de instalar Red Hat Enterprise Linux, debe realizar unos pasos básicos para configurar el enrutador LVS y los servidores reales. Este capítulo cubre en detalle los pasos iniciales.

Nota

El nodo de enrutador LVS que se activa cuando la adición del equilibrador de carga inicia, también se conoce como el nodo primario. Al configurar la adición del equilibrador de carga, use Piranha Configuration Tool en el nodo primario.

2.1. Configuración de servicios en el enrutador LVS

El programa de instalación Red Hat Enterprise Linux instala los componentes necesarios para configurar la adición del equilibrador de carga, pero los servicios apropiados deben activarse antes de la configuración. Para el enrutador LVS, establezca los servicios apropiados a fin de iniciar en tiempo de arranque. Hay tres herramientas primarias disponibles de configuración de servicios para activar en el momento de arranque en Red Hat Enterprise Linux: el programa de línea de comandos chkconfig, el programa basado en línea de comandos en ncurses ntsysv, y Services Configuration Tool gráficas. Todas las demás herramientas requieren acceso de root.

Nota

Para obtener acceso de root, abra un indicador de shell y use el comando su - seguido de la contraseña de root. Por ejemplo:

$ su - Password de root

En el enrutador LVS, hay tres servicios que se deben establecer para ser activados en el tiempo de arranque:

El servicio piranha-gui (nodo primario únicamente)
El servicio pulse
El servicio sshd

Si agrupa servicios multipuertos o si usa indicadores de cortafuegos, también debe habilitar el servicio iptables.

Es mejor establecer estos servicios para que se activen en nivel de ejecución 3 y nivel de ejecución 5. Para hacerlo mediante el comando chkconfig, escriba el siguiente comando para cada servicio:

/sbin/chkconfig --level 35 daemon on

En el comando de arriba, remplace daemon por el nombre del servicio que está activando. Para obtener una lista de los servicios en el sistema y el nivel de ejecución en que están configurados para activar encendido, ejecute el siguiente comando:

/sbin/chkconfig --list

Aviso

El encendido de alguno de los servicios de arriba mediante chkconfig no inicia el daemon. Para hacerlo, use el comando /sbin/service. Consulte la Sección 2.3, “Inicio del servicio Piranha Configuration Tool” para obtener un ejemplo de cómo usar el comando /sbin/service.

Para obtener más información sobre los niveles de ejecución y la configuración de servicios con ntsysv y Services Configuration Tool, consulte el capítulo "Controlling Access to Services" en Red Hat Enterprise Linux System Administration Guide.

2.2. Establecer una contraseña para Piranha Configuration Tool

Antes de usar Piranha Configuration Tool por primera vez en el enrutador primario LVS, debe restringir el acceso mediante una contraseña. Para ello, ingrese como root y ejecute el siguiente comando:

/usr/sbin/piranha-passwd

Después de ingresar el comando, cree la contraseña administrativa cuando se le solicite.

Aviso

Por ejemplo, para más seguridad, no debe contener nombres propios, acrónimos comúnmente usados o palabras de diccionario en ningún idioma. No deje la contraseña sin codificar en ninguna parte de su sistema.

Si la contraseña cambió durante una sesión activa de Piranha Configuration Tool, se solicitará al administrador proveer otra contraseña.

2.3. Inicio del servicio Piranha Configuration Tool

Después de establecer la contraseña para Piranha Configuration Tool, inicie o reinicie el servicio piranha-gui localizado en /etc/rc.d/init.d/piranha-gui. Para hacerlo, escriba el siguiente comando como root:

/sbin/service piranha-gui start

/sbin/service piranha-gui restart

La ejecución de este comando inicia una sesión privada de Apache HTTP Server llamando al enlace simbólico /usr/sbin/piranha_gui -> /usr/sbin/httpd. Por razones de seguridad, la versión piranha-gui de httpd se ejecuta como el usario de Piranha en un proceso independiente. El hecho de que piranha-gui utilice el servicio httpd significa que:

Apache HTTP Server debe estar instalado en el sistema.
Al parar y reiniciar Apache HTTP Server vía el comando service se detiene el servicio piranha-gui.

Aviso

Si el comando /sbin/service httpd stop o /sbin/service httpd restart se ejecuta en un enrutador LVS, debe iniciar el servicio piranha-gui con el siguiente comando:

/sbin/service piranha-gui start

El servicio piranha-gui es lo que se necesita para comenzar a configurar una adición del equilibrador de carga. Sin embargo, también requerirá el servicio sshd, si está configurando la adición del equilibrador de carga de forma remota. No necesita iniciar el servicio pulse hasta que la configuración que usa Piranha Configuration Tool termine. Consulte la Sección 4.8, “Inicio de la adición del equilibrador de carga” para obtener información sobre cómo iniciar el serviciopulse.

2.3.1. Configuración del puerto de servidor Web Piranha Configuration Tool

Piranha Configuration Tool se ejecuta en el puerto 3636. Para cambiar este número de puerto, cambie la línea Listen 3636 en la Sección 2 del archivo de configuración de servidor Web piranha-gui /etc/sysconfig/ha/conf/httpd.conf.

Para usar Piranha Configuration Tool necesita como mínimo un navegador Web de solo texto. Si inicia un navegador Web en el enrutador LVS primario, abra la ubicación http://host local:3636. Conecte Piranha Configuration Tool desde cualquier parte a través del navegador, remplace localhost por el nombre de host o dirección IP del enrutador primario LVS.

Cuando su navegador se conecta a Piranha Configuration Tool, usted debe ingresar a los servicios de configuración. Escriba piranha en el campo de Username y establezca la contraseña con piranha-passwd en el campo Password.

Ahora que la Piranha Configuration Tool se está ejecutando, si desea puede limitar el acceso a la herramienta en toda la red. La siguiente sección revisa las formas de realizar esta tarea.

2.4. Cómo limitar el acceso a Piranha Configuration Tool

Piranha Configuration Tool pide la combinación de nombre de usuario válido y contraseña. Sin embargo, debido a que todos los datos pasan a Piranha Configuration Tool están en texto plano, se recomienda que restrinja el acceso únicamente a las redes confiables o a la máquina local.

La forma más fácil de restringir el acceso, es usar la construcción de Apache HTTP Server en mecanismos de control de acceso al editar /etc/sysconfig/ha/web/secure/.htaccess. Después de alterar el archivo, no necesita reiniciar el servicio piranha-gui porque el servidor revisa el archivo .htaccess cada vez que accede el directorio.

Los controles de acceso para este directorio, permiten de forma predeterminada ver el contenido del directorio. El acceso predeterminada se ve así:

Order deny,allow
Allow from all

Para limitar el acceso a Piranha Configuration Tool a un host local únicamente, cambie el archivo .htaccess para permitir el acceso de solo el dispositivo de bucle de retroceso (127.0.0.1). Para obtener más información sobre el dispositivo de bucle de retroceso, consulte el capítulo titulado Network Scripts en Red Hat Enterprise Linux Reference Guide.

Order deny,allow
Deny from all
Allow from 127.0.0.1

También permite hosts específicos o subredes como se ve en este ejemplo:

Order deny,allow
Deny from all
Allow from 192.168.1.100
Allow from 172.16.57

En este ejemplo, solo los navegadores de red de la máquina con la dirección IP: 192.168.1.100 y máquinas en la red 172.16.57/24, pueden acceder a Piranha Configuration Tool.

Aviso

Al editar el archivo Piranha Configuration Tool .htaccess limita el acceso a las páginas de configuración en el directorio /etc/sysconfig/ha/web/secure/, pero no al inicio de sesión y las páginas de ayuda en /etc/sysconfig/ha/web/. Para limitar el acceso al directorio, cree un archivo .htaccess en el directorio /etc/sysconfig/ha/web/ con líneas idénticas order, allow, y deny a /etc/sysconfig/ha/web/secure/.htaccess.

2.5. Activación de reenvío de paquetes

A fin de que el enrutador LVS reenvíe los paquetes de red correctamente a los servidores reales, cada nodo de enrutador LVS debe tener reenvío IP activado en el kernel. Ingrese como root y cambie la línea que dice net.ipv4.ip_forward = 0 en /etc/sysctl.conf a lo siguiente:

net.ipv4.ip_forward = 1

Los cambios se efectuarán después de reiniciar el sistema.

Para verificar si el reenvío IP está activado, ejecute el siguiente comando como root:

/sbin/sysctl net.ipv4.ip_forward

Si el comando de arriba retorna 1, quiere decir que el reenvío IP está habilitado. Si retorna 0, entonces puede activarlo manualmente con el siguiente comando:

/sbin/sysctl -w net.ipv4.ip_forward=1

2.6. Cómo configurar servicios en los servidores reales

Si los servidores reales son sistemas Red Hat Enterprise Linux , establezca los daemons de servidor apropiados para activar en tiempo de arranque. Estos daemons incluyen httpd para servicios de red o xinetd para servicios FTP o Telnet.

Igualmente, puede ser útil para acceder de forma remota a los servidores reales, por lo tanto, el daemon sshd debe estar instalado y en ejecución.

Capítulo 3. Configuración de adición del equilibrador de carga

La adición del equilibrador de carga consta de dos grupos básicos: los enrutadores LVS y los servidores reales. Para evitar un punto de falla individual, cada grupo debe contener por lo menos dos sistemas miembros.

El grupo de enrutador LVS debe constar de dos sistemas idénticos o sistemas muy similares que ejecuten Red Hat Enterprise Linux. Uno, actuará como el enrutador LVS activo y otro, permanecerá en modo de espera en caliente, por lo tanto deben tener las mismas capacidades en lo posible.

Antes de elegir y configurar el hardware para el grupo del servidor real, determine cuál de las topologías de adición del equilibrador de carga debe usar.

3.1. La red de adición del equilibrador de carga NAT

La red de adición del equilibrador de carga NAT proporciona un gran alcance en el uso de hardware existente, pero se limita en su capacidad para manejar grandes cargas porque todos los paquetes que entran y salen del grupo pasan por el enrutador de adición del equilibrador de carga.

Distribución de red: La topología para la adición del equilibrador de carga mediante enrutamiento NAT es la forma más fácil de configurar desde una perspectiva de distribución de red porque solo se requiere un punto de acceso a la red pública. Los servidores reales pasan todas las solicitudes a través del enrutador LVS para que estén en su propia red privada.
Hardware: La topología NAT es la más flexible con respecto al hardware porque los servidores reales no requieren máquinas Linux para funcionar correctamente. En una topología NAT, cada servidor real necesita únicamente un NIC, ya que solamente responderá al enrutador LVS. Por otra parte, cada enrutador LVS requiere dos NIC enrutar tráfico entre las dos redes. Puesto esta topología crea un cuello de botella en el enrutador LVS, los Ethernet NIC de gigabits pueden emplearse en cada enrutador LVS para aumentar el ancho de banda que los enrutadores LVS pueden manejar. Si Ethernet gigabit se emplea en los enrutadores LVS, cualquier interruptor que conecte los servidores reales a los enrutadores LVS debe tener al menos dos puertos Ethernet gigabits para manejar la carga eficientemente.
Software: Puesto que la topología NAT requiere iptables para algunas configuraciones, puede haber una gran cantidad de configuración de software externa a Piranha Configuration Tool. En particular, los servicios FTP y el uso de marcas de cortafuegos requieren una configuración manual adicional de los enrutadores LVS para dirigir correctamente las solicitudes.

3.1.1. Configuración de interfaces de red para adición del equilibrador de carga con NAT

Para configurar la adición del equilibrador de carga con NAT, primero debe configurar las interfaces de red para redes pública y privada en los enrutadores LVS. En este ejemplo, las interfaces públicas de enrutadores LVS (eth0) estarán en la red 192.168.26/24 (Esta no es una IP enrutable, pero se asume que hay un cortafuegos en frente del enrutador LVS) y las interfaces privadas que vinculan a todos los servidores reales (eth1) estarán en la red 10.11.12/24.

Importante

Observe que la modificación de los siguientes archivos pertenece al servicio network y la adición del equilibrador de carga no es compatible con el servicio NetworkManager.

Entonces, en un nodo de enrutador activo LVS o primario, el script de red de la interfaz pública, /etc/sysconfig/network-scripts/ifcfg-eth0, podría ser parecida a la siguiente:

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.26.9
NETMASK=255.255.255.0
GATEWAY=192.168.26.254

El script de red /etc/sysconfig/network-scripts/ifcfg-eth1 para esta interfaz NAT privada en el enrutador LVS sería similar al siguiente:

DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.11.12.9
NETMASK=255.255.255.0

En este ejemplo, el VIP para la interfaz pública de enrutador LVS será 192.168.26.10 y el VIP para la interfaz NAT o la interfaz privada será 10.11.12.10. Por lo tanto, es imperativo que las solicitudes de los servidores reales redirijan sus solicitudes al VIP para la interfaz NAT.

Importante

La muestra de parámetros de configuración de interfaz Ethernet en esta sección es para las direcciones IP reales de un enrutador LVS y no para las direcciones flotantes IP. En la configuración de las direcciones flotantes IP públicas y privadas el administrador debe usar Piranha Configuration Tool, como se muestra en la Sección 4.4, “GLOBAL SETTINGS” y en la Sección 4.6.1, “La subsección VIRTUAL SERVER”.

Después de configurar las interfaces de red de nodo del enrutador primario LVS, configure las interfaces de red del enrutador LVS de respaldo — tenga cuidado de que ninguna de las direcciones IP estén en conflicto con otra dirección IP en la red.

Importante

Asegúrese de que cada interfaz en el nodo de respaldo sirva la misma red como la interfaz en el nodo primario. Por ejemplo, si eth0 se conecta a la red pública en el nodo primario, debe también conectarse a la red pública en el nodo de respaldo.

3.1.2. Enrutamiento en servidores reales

Es muy importante recordar que durante la configuración de interfaces de red de servidores reales en una topología NAT se debe establecer la puerta de enlace para dirección IP flotante de NAT del enrutador LVS. En este ejemplo la dirección 10.11.12.10.

Nota

Cuando las interfaces de red estén activas en servidores reales, las máquinas podrán contactar o conectarse en otras formas a la red pública. Esto es normal. Sin embargo, usted podrá contactar a las IP reales para la interfaz de red privada del enrutador LVS, en este caso: 10.11.12.9.

Por lo tanto, el archivo /etc/sysconfig/network-scripts/ifcfg-eth0 del servidor real sería similar al siguiente:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.11.12.1
NETMASK=255.255.255.0
GATEWAY=10.11.12.10

Aviso

Si un servidor real tiene más de una interfaz de red configurada con una línea GATEWAY=, la primera que aparece será la puerta de enlace. Por lo tanto, si eth0 y eth1 están configuradas y eth1 se utiliza para adición del equilibrador de carga, los servidores reales no podrán dirigir solicitudes correctamente.

Es mejor apagar las interfaces ajenas de red mediante la configuración de ONBOOT=no en sus scripts de red dentro del directorio /etc/sysconfig/network-scripts/ o asegurándose de que la puerta de enlace esté configurada correctamente en la interfaz que aparece primero.

3.1.3. Activación de enrutamiento NAT en enrutadores LVS

En una configuración simple de adición del equilibrador de carga con NAT en la que el servicio en clúster usa únicamente un puerto como HTTP en puerto 80, el administrador debe activar únicamente el envío de paquetes en enrutadores LVS para que las solicitudes se dirijan correctamente entre el mundo exterior y los servidores reales. Consulte la Sección 2.5, “Activación de reenvío de paquetes” para obtener instrucciones sobre cómo activar el envío de paquetes. Sin embargo, se requiere más configuración cuando los servicios en clúster necesitan más de un puerto para ir al mismo servidor real durante la sesión de usuario. Si desea obtener más información sobre la creación de servicios multipuertos mediante marcas de cortafuegos, consulte la Sección 3.4, “Servicios multipuertos y adición del equilibrador de carga”.

Una vez el reenvío es activado en los enrutadores LVS y los servidores reales están configurados y tienen los servicios en clúster en ejecución, use Piranha Configuration Tool para configurar la adición del equilibrador de carga como se muestra en el Capítulo 4, Configuración de la adición del equilibrador de carga mediante Piranha Configuration Tool.

Aviso

No configure la dirección IP flotante para eth0:1 o eth1:1 al editar de forma manual los scripts de redes o mediante una herramienta de configuración de redes. En su lugar, use Piranha Configuration Tool como se muestra en la Sección 4.4, “GLOBAL SETTINGS” y en la Sección 4.6.1, “La subsección VIRTUAL SERVER”.

Cuando termine, inicie el servicio pulse como se muestra en la Sección 4.8, “Inicio de la adición del equilibrador de carga”. Cuando el comando pulse esté ejecutándose, el enrutador LVS activo, comenzará a dirigir solicitudes al grupo de servidores reales.

3.2. Enrutamiento directo de adición del equilibrador de carga

Como se mencionó en la Sección 1.4.2, “Enrutamiento directo” el enrutamiento directo permite que los servidores reales procesen y dirijan los paquetes directamente al usuario que los solicitó en vez de pasar los paquetes salientes a través del enrutador LVS. El enrutamiento directo requiere que los servidores reales sean estén conectados físicamente al segmento de red con el enrutador LVS y también puedan procesar y dirigir paquetes de salida.

Distribución de red: En un enrutamiento directo de configuración de la adición del equilibrador de carga, el enrutador LVS debe recibir solicitudes de entrada y dirigirlas al propio servidor real para procesamiento. Los servidores reales luego, deben dirigir directamente la respuesta al cliente. Por lo tanto, si el cliente está en Internet, y envía el paquete a través del enrutador LVS a un servidor real, el servidor real debe ser capaz de ir directamente al cliente a través de la Internet. Esto se puede realizar al configurar una puerta de entrada para que el servidor real pase paquetes a la Internet. Cada servidor real en el grupo de servidores puede tener su puerta de enlace independiente (y cada puerta de enlace con su propia conexión a Internet), lo cual permite un máximo de rendimiento y de escalabilidad. No obstante, para una configuración típica de la adición del equilibrador de carga, los servidores reales pueden comunicarse a través de una puerta de entrada (y por ende, a una conexión de red).
Importante
No se recomienda utilizar el enrutador LVS activo como puerta de enlace para los servidores reales, ya que agrega complejidad y carga de red en el enrutador LVS, lo cual reintroduce el cuello de botella de redes que existe en enrutamiento de NAT.
Hardware: Los requerimientos de hardware de una adición del equilibrador de carga que usa enrutamiento directo son similares a otras topologías de adición del equilibrador de carga. Aunque el enrutador LVS debe estar ejecutando Red Hat Enterprise Linux para procesar las solicitudes de entrada y realizar su equilibrio de carga para servidores reales, los servidores reales no tienen que ser máquinas Linux para funcionar correctamente. Los enrutadores LVS requieren uno o dos NIC cada uno (depende de si existe un enrutador de respaldo). También puede usar dos NIC para facilitar la configuración y separar el tráfico independiente — las solicitudes de entrada que son administradas por un NIC y los paquetes dirigidos a los servidores reales en el otro.
Puesto que los servidores reales evitan el enrutador LVS y envían directamente paquetes de salida a un cliente, se requiere una puerta de enlace. Para obtener disponibilidad y rendimiento máximos, cada servidor real puede conectarse de forma independiente a su puerta de enlace, la cual tiene una propia conexión dedicada al proveedor de red al que está conectado(tal como Internet o Intranet).
Software: Hay alguna configuración fuera de Piranha Configuration Tool que debe hacerse, en particular, para los administradores que enfrentan problemas de ARP cuando utilizan adición del equilibrador de carga directamente de enrutamiento directo. Para obtener más información, consulte, la Sección 3.2.1, “Enrutamiento directo y arptables_jf” o la Sección 3.2.2, “Enrutamiento directo e iptables”.

3.2.1. Enrutamiento directo y `arptables_jf`

A fin de configurar el enrutamiento directo mediante arptables_jf, cada servidor real debe tener configurada la dirección IP virtual, para poder dirigir directamente los paquetes. Los servidores reales ignoran totalmente las solicitudes ARP y cualquier paquete ARP que podría, de otro modo, ser enviado con los VIP se truncan para contener la IP de servidor real en lugar de los VIP.

Al usar el método arptables_jf, las aplicaciones pueden vincular cada VIP o puerto individual que sirva el servidor real. Por ejemplo, el método arptables_jf permite que múltiples instancias de Apache HTTP Server se ejecuten vinculadas explícitamente a diferentes VIP en el sistema. También hay ventajas de rendimiento significativo al usar arptables_jf en comparación con la opción iptables .

Sin embargo, al usar el método arptables_jf, los VIP no puede configurarse al inicio en el arranque mediante las herramientas de configuración del sistema Red Hat Enterprise Linux.

Para configurar cada servidor real para que ignore las solicitudes ARP para cada dirección IP virtual, siga los siguientes pasos:

Cree una tabla ARP de entradas para cada dirección IP virtual en cada servidor real (real_ip es la IP que el directorio usa para comunicarse con el servidor real; por lo general es la IP vinculada a eth0):
```
arptables -A IN -d <virtual_ip> -j DROP
arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
```
Esto hará que los servidores reales ignoren todas las solicitudes para direcciones IP virtuales y cambien cualquier respuesta de salida ARP que pueda de otra manera contener IP virtual, para que contengan la IP real del servidor en su lugar. El único nodo que debe responder a las solicitudes ARP para cualquier VIP es el nodo LVS activo.
Una vez que haya completado esto en cada servidor real, guarde las entradas de tabla ARP mediante los siguientes comandos en cada servidor real:
service arptables_jf save
chkconfig --level 2345 arptables_jf on
El comando chkconfig hará que el sistema recargue la configuración de arptables en el arranque — antes de que se inicie la red.
Configure la dirección IP virtual en todos los servidores reales mediante ifconfig para crear un alias IP. Por ejemplo:
```
# ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 up
```
Or using the iproute2 utility ip, for example:
```
# ip addr add 192.168.76.24 dev eth0
```
Como se dijo anteriormente, las direcciones IP virtuales no pueden ser configuradas para iniciar en el arranque mediante las herramientas de configuración del sistema Red Hat. Una solución a este problema es poner los comandos en /etc/rc.d/rc.local.
Configure Piranha para enrutamiento directo. Para obtener más información, consulte el Capítulo 4, Configuración de la adición del equilibrador de carga mediante Piranha Configuration Tool.

3.2.2. Enrutamiento directo e `iptables`

También puede solucionar el problema de ARP mediante el método de enrutamiento directo al crear reglas de cortafuegos iptables. Para configurar el enrutamiento con iptables, agregue reglas que creen un proxy transparente para que el servidor real sirva los paquetes enviados a la dirección VIP, aunque la dirección VIP no exista en el sistema.

El método iptables es más fácil de configurar que el método de arptables_jf. Este método también evita todo el problema de LVS ARP, ya que la dirección IP virtual solo existe en el director activo LVS.

Sin embargo, hay problemas de rendimiento cuando se utiliza el método iptables en comparación con arptables_jf, ya que hay sobrecarga en el envío y enmascaramiento de cada paquete.

Tampoco puede reutilizar puertos mediante el método iptables. Por ejemplo, no es posible ejecutar dos servicios Apache HTTP Server independientes vinculados al puerto 80, ya que ambos se deben vincular INADDR_ANY en lugar de las direcciones IP virtuales.

Para configurar el enrutamiento directo mediante el método iptables, siga los pasos a continuación:

En cada servidor real, ejecute el siguiente comando para cada combinación VIP, puerto y protocolo (TCP o UDP) que va a ser servida para el servidor real:
iptables -t nat -A PREROUTING -p <tcp|udp> -d <vip> --dport <port> -j REDIRECT
Este comando hará que los servidores reales procesen paquetes destinados para VIP y el puerto que les asignen.
Guarde la configuración en cada servidor real:
```
# service iptables save
# chkconfig --level 2345 iptables on
```
Los comandos anteriores hacen que el sistema recargue la configuración de iptables en el arranque — antes de que se inicie la red.

3.3. Recopilación de toda la configuración

Después de determinar cuál de los métodos de enrutamiento anteriores usar, debe vincular el hardware a la red.

Importante

Los dispositivos en los enrutadores LVS deben configurarse para acceder a las mismas redes. Por ejemplo, si eth0 se conecta a la red pública y eth1 conecta a la red privada, entonces estos mismos dispositivos en el enrutador LVS de respaldo deben conectarse a las mismas redes.

La puerta de enlace, listada en la primera interfaz para que aparezca en el tiempo de arranque, se agrega a la tabla de rutas. Las puertas de enlace posteriores listadas en otras interfaces, se ignoran. Esto es muy importante al configurar servidores reales.

Después de conectarse físicamente al hardware, configure las interfaces de red en los enrutadores LVS primarios y de respaldo. Esta acción se puede realizar mediante una aplicación gráfica tal como system-config-network o al modificar los scripts de red de forma manual. Para obtener más información sobre cómo agregar dispositivos mediante system-config-network, consulte el capítulo Configuración de red en la Red Hat Enterprise Linux Guía de implementación. Para lo que resta del capítulo, las alteraciones de ejemplo a las interfaces se pueden hacer de forma manual o, a través de Piranha Configuration Tool.

3.3.1. Consejos de conexión para una adición del equilibrador de carga de red

Configure las direcciones IP reales tanto para las redes públicas como privadas en los enrutadores LVS antes de intentar configurar la adición del equilibrador de carga mediante Piranha Configuration Tool. Las secciones en cada topología dan un ejemplo de direcciones de redes, pero las direcciones de redes reales son necesarias. Abajo verá comando útiles para activar las interfaces de red o verificar el estatus.

Activación de interfaces de red reales: Para activar una interfaz de red real, use el siguiente comando como root, remplace N por el número correspondiente a la interfaz (eth0 y eth1).
/sbin/ifup ethN
Aviso
No use scripts ifup para activar las direcciones IP flotantes que puede configurar con Piranha Configuration Tool (eth0:1 o eth1:1). Use el comando service para iniciar pulse en su lugar (Para obtener información, consulte la Sección 4.8, “Inicio de la adición del equilibrador de carga”).
Desactivación de interfaces de red reales: Para desactivar una interfaz de red real, use el siguiente comando como root, remplace N por el número correspondiente a la interfaz (eth0 y eth1).
/sbin/ifdown ethN
Comprobación del estatus de interfaces de red: Si en algún momento, necesita comprobar cuáles interfaces de red que están activas, escriba lo siguiente:
/sbin/ifconfig
Para ver la tabla de rutas para una máquina, ejecute el siguiente comando:
/sbin/route

3.3.1.1. Diagnóstico y resolución de problemas de direcciones IP virtuales

Hay instancias en las que un administrador encuentra problemas durante una conmutación automática de un host LVS activo a un host en espera. Todas las direcciones IP virtuales no pueden activarse en el host en espera. Este problema también puede presentarse si el host se detiene o si se activa el host primario. Solamente cuando el servicio pulse sea reiniciado de forma manual, todas las direcciones IP virtuales se activan.

Para remediar temporalmente este problema, ejecute el siguiente comando en el indicador de shell root.:


echo 1 > /proc/sys/net/ipv4/conf/all/promote_secondaries

Observe que esto solo remediará temporalmente este problema y que el comando no se mantendrá a través del reinicio del sistema.

Para remediar permanentemente este problema, abra el archivo /etc/sysctl.conf y agregue la siguiente línea:

net.ipv4.conf.all.promote_secondaries = 1

3.4. Servicios multipuertos y adición del equilibrador de carga

Los enrutadores en cualquier topología requieren configuración adicional cuando crean servicios multipuertos de adición del equilibrador de carga. Los servicios multipuertos pueden crearse artificialmente con marcas de cortafuegos para vincularlas protocolos diferentes pero relacionados, tales como HTTP (puerto 80) y HTTPS (puerto 443), o cuando la adición del equilibrador de carga se utiliza con verdaderos protocolos multipuertos, tales como FTP. En cualquier caso, el enrutador LVS usa marcas de cortafuegos para reconocer que los paquetes destinados a diferentes puertos, pero que soportan la misma marca de cortafuegos, deben manejarse de forma idéntica. También cuando se combinan con persistencia, las marcas de cortafuegos garantizan que conexiones desde la máquina cliente sean dirigidas al mismo host, siempre y cuando las conexiones ocurran dentro del tiempo especificado por el parámetro de persistencia. Para obtener más información, sobre asignación de persistencia a un servidor virtual, consulte la Sección 4.6.1, “La subsección VIRTUAL SERVER”.

Infortunadamente, el mecanismo utilizado para balancear cargas en servidores reales — IPVS — puede reconocer las marcas de cortafuegos asignadas a un paquete, pero no puede autoasignarse marcas de cortafuegos. La tarea de asignación de cortafuegos debe realizarse por el filtro de paquetes de red, iptables, por fuera de Piranha Configuration Tool.

3.4.1. Asignación de marcas de cortafuegos

Para asignar marcas de cortafuegos a un paquete destinado para un puerto determinado, el administrador debe usar iptables.

Esta sección muestra a manera de ejemplo, cómo vincular HTTP y HTTPS; no obstante FTP es otro protocolo de multipuertos comúnmente en clúster. Si se utiliza una adición del equilibrador de carga para servicios FTP, consulte la Sección 3.5, “Configuración de FTP” para obtener información sobre configuración.

La regla básica para recordar cómo usar marcas de cortafuegos es que cada protocolo que use una marca de cortafuegos en Piranha Configuration Tool debe ser una regla conmensurada de iptables para paquetes de red.

Antes de crear reglas de filtraje de paquetes de redes, asegúrese de que no ya haya reglas. Para ello, abra el indicador de shell, ingrese como root y escriba:

/sbin/service iptables status

Si iptables no se está ejecutando, el indicador reaparecerá instantáneamente.

Si iptables está activo, muestra un conjunto de reglas. Si las reglas están presentes, escriba este comando:

/sbin/service iptables stop

Si las reglas que ya existen son importantes, revise el contenido de /etc/sysconfig/iptables y copie las reglas que valen la pena salvar antes de proceder.

Las reglas a continuación, asignan la misma marca de cortafuegos, 80, para tráfico entrante destinado a la dirección IP flotante, n.n.n.n, en los puertos 80 y 443.

/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 -m multiport --dports 80,443 -j MARK --set-mark 80

Para obtener instrucciones sobre cómo asignar el VIP a la interfaz de red pública, consulte la Sección 4.6.1, “La subsección VIRTUAL SERVER”. También observe que debe ingresar como root y cargar el módulo para iptables antes de proporcionar reglas por primera vez.

En los comandos anteriores iptables, n.n.n.n debe remplazarse por la dirección IP flotante para sus servidores virtuales. Estos comandos asignan el tráfico dirigido a VIP en los puertos en la marca de cortafuegos apropiados a 80, lo cual a su vez, es reconocido por IPVS y reenviado de forma apropiada.

Aviso

Los comandos anteriores tomarán efecto inmediatamente, pero no persisten a través de un reinicio del sistema. Para asegurase de que los parámetros de filtro de paquetes de red sean restaurados tras el reinicio, consulte la Sección 3.6, “Guardado de parámetros de filtraje de paquetes de red”

3.5. Configuración de FTP

El archivo de protocolo de transporte (FTP) es un protocolo multipuertos antiguo y complejo que presenta un conjunto distinto de retos para un entorno de adición del equilibrador. Para entender la naturaleza de estos cambios, primero debe entender aspectos importantes acerca del funcionamiento de FTP.

3.5.1. Cómo funciona FTP

Con la mayoría de relaciones de cliente servidor, la máquina de cliente abre una conexión para el servidor en un puerto particular y el servidor luego responde al cliente en dicho puerto. Cuando un cliente FTP conecta a un servidor FTP abre una conexión para el puerto 80 de control FTP. Luego, el cliente le indica al servidor FTP si debe establecer una conexión activa o pasiva. El tipo de conexión elegido por el cliente determina la forma como el servidor responde y los puertos en donde ocurren las transacciones.

Los dos tipos de conexiones de datos son:

Conexiones activas: Cuando se establece una conexión activa, el servidor abre una conexión para el cliente desde el puerto 20 a un puerto con un rango alto en la máquina cliente. Todos los datos del servidor se pasan por esta conexión.
Conexiones pasivas: Cuando se establece una conexión pasiva, el cliente solicita al servidor FTP establecer un puerto de conexión pasiva, el cual puede ser cualquier puerto superior a 10.000. El servidor se vincula al puerto de un número alto para una determinada sesión y retransmite ese número de puerto al cliente. Luego, el cliente abre el puerto recién vinculado para la conexión de datos. Cada solicitud de datos que el cliente haga produce una conexión de datos independiente. La mayoría de clientes FTP modernos, intentan establecer una conexión pasiva cuando solicitan datos desde servidores.

Nota

El cliente determina el tipo de conexión, no el servidor. Es decir que para agrupar en clúster FTP, debe configurar los enrutadores LVS a fin de manejar tanto las conexiones activas como las pasivas.

La relación de cliente/servidor FTP puede en potencia abrir un gran número de puertos que Piranha Configuration Tool e IPVS desconocen.

3.5.2. Cómo se afecta la adición del equilibrador de carga en enrutamiento

El paquete de reenvío IPVS solamente permite conexiones de entrada y salida del clúster cuando se detecta el número de puerto o la marca de cortafuegos. La conexión se rechaza, si un cliente desde fuera del clúster intenta abrir un puerto IPVS que no esté configurado para su manejo. Igualmente, la conexión se rechaza, si un servidor real intenta abrir una conexión para Internet en un puerto IPVS que desconoce. Es decir que todas las conexiones desde clientes FTP en la Internet deben tener la misma marca de cortafuegos asignadas y todas las conexiones del servidor FTP deben reenviarse a la Internet mediante reglas de filtraje de paquetes de red.

Nota

A fin de habilitar conexiones FTP pasivas, revise si tiene cargado el módulo de kernel ip_vs_ftp. Para realizar esta acción, ejecute el comando modprobe ip_vs_ftp como un usuario administrativo en un indicador de shell.

3.5.3. Creación de reglas de filtraje de paquetes de red

Antes de asignar cualquier regla iptables al servicio FTP, revise la información en la Sección 3.4.1, “Asignación de marcas de cortafuegos” relacionada con servicios multipuertos y técnicas para verificar las reglas de filtraje de paquetes existentes.

A continuación se presentan las reglas que asignan la misma marca de cortafuegos, 21, al tráfico FTP . A fin de que estas reglas funcionen adecuadamente, también debe ir a la subsección VIRTUAL SERVER de Piranha Configuration Tool para configurar un servidor virtual para puerto 21 con un valor de 21 en el campo Firewall Mark. Si desea obtener más información, consulte la Sección 4.6.1, “La subsección VIRTUAL SERVER”.

3.5.3.1. Reglas para conexiones activas

Las reglas para conexiones activas le indican al kernel que acepte las conexiones de reenvío que llegan a la dirección IP interna flotante en el puerto 20 — el puerto de datos FTP.

El siguiente comando iptables permite al enrutador LVS aceptar conexiones salientes de servidores reales que IPVS desconoce:

/sbin/iptables -t nat -A POSTROUTING -p tcp -s n.n.n.0/24 --sport 20 -j MASQUERADE

En el comando iptables, remplace n.n.n por los primeros tres valores para IP flotante para que la interfaz de red interna de la interfaz NAT definida en el panel de GLOBAL SETTINGS de Piranha Configuration Tool.

3.5.3.2. Reglas para conexiones pasivas

Las reglas para conexiones pasivas asignan la marca de cortafuegos apropiada para conexiones entrantes desde la Internet hasta la IP flotante para el servicio en un rango ancho de puertos — 10,000 a 20,000.

Aviso

Si limita el rango de puerto para conexiones pasivas, también debe configurar el servidor VSFTP a fin de que use el rango de puerto correspondiente. Para ello, agregue las siguientes líneas a /etc/vsftpd.conf:

pasv_min_port=10000

pasv_max_port=20000

Al establecer pasv_address para sobrescribir la dirección del servidor FTP real, no use la dirección del servidor, ya que es actualizada a la dirección IP virtual por LVS.

Para configurar otros servidores FTP, consulte la documentación respectiva.

Este rango debe ser lo suficientemente amplio para la mayoría de las situaciones; no obstante, puede aumentar este número para incluir todos los puertos inseguros 10000:20000 a 1024:65535 en los comandos de abajo.

Los siguientes comandos iptables tienen el efecto de asignar la marca de cortafuegos 21 al tráfico dirigido a una IP flotante en los puertos apropiados. La marca de cortafuegos 21 es detectada por IPVS y reenviada correctamente:

/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 21 -j MARK --set-mark 21

/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 10000:20000 -j MARK --set-mark 21

En los comandos iptables, remplace n.n.n.n por la IP flotante para el servidor virtual FTP en la subsección VIRTUAL SERVER de Piranha Configuration Tool.

Aviso

Los comandos de arriba se efectúan inmediatamente, pero no persisten a través de reinicios del sistema. Para garantizar que los parámetros de filtro de paquetes de red sean restablecidos después del rearranque, consulte la Sección 3.6, “Guardado de parámetros de filtraje de paquetes de red”

Por último, asegúrese de que el servicio apropiado esté activado en el nivel de ejecución correcto. Para obtener más información, consulte la Sección 2.1, “Configuración de servicios en el enrutador LVS”.

3.6. Guardado de parámetros de filtraje de paquetes de red

Después de configurar los filtros de paquetes de red apropiados para su situación, guarde los parámetros para que puedan ser restaurados después del reinicio. Para iptables, escriba el siguiente comando:

/sbin/service iptables save

De esta manera, guarda los parámetros en /etc/sysconfig/iptables para que puedan llamarse en el momento del arranque.

Cuando haya escrito el archivo, podrá usar el comando /sbin/service para iniciar, detener y chequear el estatus (mediante el interruptor de estatus) de iptables. El comando /sbin/service cargará de forma automática el módulo apropiado para usted. Para ver un ejemplo de cómo utilizar el comando /sbin/service , consulte la Sección 2.3, “Inicio del servicio Piranha Configuration Tool”.

El siguiente capítulo explica cómo usar Piranha Configuration Tool para configurar el enrutador LVS y describir los pasos necesarios para activar la adición del equilibrador de carga.

Capítulo 4. Configuración de la adición del equilibrador de carga mediante Piranha Configuration Tool

Piranha Configuration Tool proporciona un enfoque estructurado para crear el archivo de configuración necesario para la adición del equilibrador de carga — /etc/sysconfig/ha/lvs.cf. Este capítulo describe la operación básica de Piranha Configuration Tool y la forma de activar la adición del equilibrador de carga una vez la configuración se complete.

Importante

El archivo de configuración para la adición del equilibrador de carga sigue reglas estrictas de formato. El uso de Piranha Configuration Tool es la mejor forma de evitar errores de sintaxis en lvs.cf y por ende, evitar fallas de software.

4.1. Software necesario

El servicio piranha-gui debe estar ejecutándose en el enrutador primario LVS para usar Piranha Configuration Tool. Para configurar la adición del equilibrador de carga, lo mínimo que necesita es un navegador Web de solo texto, tal como links. Si accede al enrutador LVS desde otra máquina, también necesitará una conexión ssh al enrutador LVS primario como usuario root.

Durante la configuración del enrutador primario LVS se recomienda mantener una conexión concurrente ssh en una ventana de terminal. Esta conexión proporciona una forma segura de reiniciar pulse y otros servicios, configurar filtros de paquetes de red, y monitorizar /var/log/messages durante el diagnóstico y resolución de problemas.

Las siguientes cuatro secciones lo llevan a través de las páginas de configuración de Piranha Configuration Tool y le dan instrucciones de uso para configurar la adición del equilibrador de carga.

4.2. Ingreso a Piranha Configuration Tool

Durante la configuración de la adición del equilibrador de carga , debe comenzar siempre con la configuración del enrutador primario con Piranha Configuration Tool. Para hacerlo, verifique si el servicio piranha-gui está en ejecución y si ha establecido la contraseña como se describe en la Sección 2.2, “Establecer una contraseña para Piranha Configuration Tool”.

Si accede de forma local a la máquina, abra http://localhost:3636 en un navegador Web para acceder a Piranha Configuration Tool. De lo contrario, ingrese el nombre de host o la dirección IP real para el servidor seguido de :3636. Cuando el navegador se conecte, verá la pantalla que se muestra en la Figura 4.1, “El panel de bienvenida”.

Haga clic en el botón Login, escriba piranha en el campo Username y la contraseña administrativa que usted creó, en el campo Password.

Piranha Configuration Tool consta de cuatro pantallas principales o paneles. Además, el panel de Virtual Servers contiene cuatro subsecciones. El panel CONTROL/MONITORING es el primer panel después de la pantalla de inicio de sesión.

4.3. CONTROL/MONITORING

El panel CONTROL/MONITORING presenta el estatus de tiempo de ejecución limitado de la adición del equilibrador de cargas. Muestra el estatus del daemon pulse, la tabla de rutas LVS y los procesos nanny LVS generados.

Nota

Los campos para CURRENT LVS ROUTING TABLE y CURRENT LVS PROCESSES se dejan en blanco hasta que usted realmente inicie la adición del equilibrador de cargas, como se muestra en la Sección 4.8, “Inicio de la adición del equilibrador de carga”.

Figura 4.2. Panel CONTROL/MONITORING

Auto update: La pantalla de estatus en esta página se puede actualizar automáticamente en un intervalo configurable por el usuario. Para habilitar esta funcionalidad, haga clic en la casilla de verificación Auto update y establezca la frecuencia de actualización deseada en el cuadro de texto Update frequency in seconds (el valor predeterminado es 10 segundos).
No se recomienda que el intervalo de tiempo sea menor de 10 segundos. Si lo hace, podría dificultarse la reconfiguración del intervalo Auto update porque la página se actualizaría con demasiada frecuencia. Si encuentra este problema, simplemente haga clic en otro panel y regrese a CONTROL/MONITORING.
La funcionalidad Auto update no funciona con todos los navegadores, como por ejemplo, Mozilla.
Update information now: Puede actualizar de forma manual la información de estatus con este botón.
CHANGE PASSWORD: Al hacer clic en este botón se tendrá acceso a una pantalla de ayuda con información sobre cómo cambiar la contraseña administrativa para la Piranha Configuration Tool.

4.4. GLOBAL SETTINGS

El panel GLOBAL SETTINGS es donde usted define la información de conexión para las interfaces de redes públicas y privadas del enrutador primario LVS.

Figura 4.3. El panel GLOBAL SETTINGS

La parte superior de este panel configura las interfaces de red públicas y privadas del enrutador LVS primario. Estas son las interfaces ya configuradas en la Sección 3.1.1, “Configuración de interfaces de red para adición del equilibrador de carga con NAT”.

IP público de servidor primario: En este campo, ingrese la dirección IP real enrutable para el nodo primario LVS.
Primary server private IP: Ingrese la dirección IP real para una interfaz de red alternativa en el nodo LVS primario. Esta dirección se utiliza únicamente como un canal alternativo de pulsos para el enrutador de respaldo y no tiene que correlacionarse con la dirección IP privada asignada en la Sección 3.1.1, “Configuración de interfaces de red para adición del equilibrador de carga con NAT”. Puede dejar este campo en blanco, pero al hacerlo, significa que no hay canal de pulsos alternos para el enrutador LVS de respaldo y por lo tanto, creará un punto individual de falla.
Nota
La dirección IP privada no se necesita para configuraciones de Direct Routing, ya que todos los servidores reales y directorios LVS comparten las mismas direcciones IP virtuales y deben tener la misma configuración de rutas IP.
Nota
La IP privada de enrutador se puede configurar en cualquier interfaz que acepte TCP e IP, sea un adaptador Ethernet o un puerto serial.
TCP Timeout: Ingrese el tiempo (en segundos ) antes de que la sesión TCP expire. El valor del tiempo límite es 0.
TCP Fin Timeout: Ingrese el tiempo (en segundos ) antes de que la sesión TCP expire tras recibir un paquete FIN. El valor del tiempo límite es 0.
UDP Timeout: Ingrese el tiempo (en segundos ) antes de que la sesión UDP expire. El valor del tiempo límite es 0.
Use network type: Haga clic en el botón NAT para seleccionar el enrutamiento NAT.
Haga clic en el botón Direct Routing para seleccionar el enrutamiento directo.

Los tres campos siguientes, manejan específicamente la interfaz de red del enrutador virtual NAT. Estos campos no aplican al tipo de red de enrutamiento directo.

NAT Router IP: Ingrese la IP flotante privada en este campo de texto. Esta IP flotante debe utilizarse como puerta de enlace para los servidores reales.
NAT Router netmask: Si la IP flotante del enrutador NAT necesita una máscara de red particular, selecciónela de la lista desplegable.
NAT Router device: Use este campo para definir el nombre del dispositivo de la interfaz de red para la dirección IP flotante, tal como eth1:1.
Nota
Cree un alias de la dirección IP flotante NAT para la interfaz Ethernet conectada a la red privada. En este ejemplo, la red privada está en la interfaz eth1, por lo tanto eth1:1 es la dirección IP flotante.

Aviso

Después de completar esta página, haga clic en el botón ACCEPT para asegurarse de que pierda los cambios cuando seleccione un nuevo panel.

4.5. REDUNDANCY

El panel REDUNDANCY permite la configuración del nodo del enrutador LVS de respaldo y establecer varias opciones de monitorización de pulsos.

Nota

La primera vez que visite esta pantalla, muestra un estatus de Backup inactivo y el botón ENABLE. Para configurar el enrutador LVS de respaldo, haga clic en el botón ENABLE para que la pantalla coincida con la Figura 4.4, “El panel REDUNDANCY”.

Figura 4.4. El panel REDUNDANCY

Redundant server public IP: Ingrese la dirección IP real pública para el nodo de enrutador LVS de respaldo.
Redundant server private IP: Ingrese la dirección IP real privada del nodo de respaldo en este campo.
Si no ve el campo llamado Redundant server private IP, vuelva al panel de GLOBAL SETTINGS, ingrese una dirección Primary server private IP y haga clic en ACCEPT.

La siguiente sección del panel se dedica a la configuración de canal de pulso, el cual es utilizado por el nodo de respaldo para monitorizar el nodo primario para fallos.

Heartbeat Interval (seconds): Este campo establece el intervalo de segundos entre pulsos — El intervalo en el que el nodo de respaldo revisará el estatus de nodo LVS primario.
Assume dead after (seconds): Si el nodo LVS primario no responde después de este intervalo de tiempo, el enrutador LVS de respaldo inicia el procedimiento de conmutación.
Heartbeat runs on port: Este campo establece el puerto utilizado para la comunicación de pulsos con el nodo LVS primario. Si este campo se deja en blanco, se predetermina a 539.

La sección final del panel es para habilitar y configurar el daemon de sincronización y sus opciones. El daemon de sincronización permite al director de LVS activas y de respaldo mantener sincronizado el estado TCP. Cuando está habilitado, el director activo enviará un mensaje de multidifusión por la red con un ID de sincronización configurable (o syncid) a un director receptor de respaldo.

Aviso

Red Hat Enterprise Linux 6.5 introduce un nuevo formato de protocolo de mensajes, diseñado para evitar interrupciones a los servicios empresariales causados por tiempo de expiración prematuro de conexiones persistentes en los nodos de respaldo, lo cual ocasiona estado inconsistente en caso de conmutación.

El formato del nuevo protocolo no es compatible con versiones de Red Hat Enterprise Linux 6.4 o anteriores, o las versiones de kernel anteriores al kernel-2.6.32-406.el6. Se recomienda actualizar los nodos de respaldos antes de actualizar el nodo maestro para Red Hat Enterprise Linux 6.5.

Para seguir utilizando el anterior formato de mensajes de sincronización (por ejemplo, si necesita actualizar el nodo maestro antes de los nodos de respaldo), establezca el valor de sync_version mediante el comando echo como root en un indicador de shell de la siguiente manera:

echo 0 > /proc/sys/net/ipv4/vs/sync_version

Usar daemon de sincronización: Seleccione el cuadro si desea habilitar el daemon de sincronización.
Interfaz del daemon de sincronización: La interfaz de red a través de la cual el daemon de sincronización envía y recibe el mensaje de multidifusión. La interfaz predeterminada en este campo es eth0.
Id de daemon de sincronización: Este campo establece un identificador (ID) para multidifundir mensajes sync. Los valores con soporte son de 0 a 255, se predetermina a 0 si se deja el campo en blanco.

Aviso

No olvide hacer clic en el botón ACEPTAR después de hacer los cambios en este panel, para que no pierda los cambios al seleccionar un nuevo panel.

4.6. SERVIDORES VIRTUALES

El panel VIRTUAL SERVERS muestra la información para cada servidor virtual definido actualmente. Cada entrada en la tabla muestra el estado del servidor virtual, el nombre del servidor, la IP virtual asignada al servidor, la máscara de red de la IP virtual, el número de puerto al cual se comunica el servicio, el protocolo usado y la interfaz del dispositivo virtual.

Figura 4.5. El panel VIRTUAL SERVERS

Cada servidor que se muestra en el panel VIRTUAL SERVERS se puede configurar en las siguientes pantallas o subsecciones.

Para añadir un servicio, haga clic en el botón ADD. Para remover un servicio, seleccione éste haciendo clic en el botón de radio al lado del servidor virtual y luego haga clic en DELETE.

Para activar o desactivar un servidor virtual en la tabla, haga clic en el botón de radio apropiado y luego en el botón (DE)ACTIVATE.

Después de agregar un servidor virtual, puede configurarlo al hacer clic en el botón de radio a la izquierda y luego en EDIT para ir a la subsección VIRTUAL SERVER.

4.6.1. La subsección VIRTUAL SERVER

La subsección VIRTUAL SERVER del panel que se muestra en Figura 4.6, “La subsección de VIRTUAL SERVERS” le permite configurar un servidor virtual individual. Los enlaces a subsecciones relacionadas específicamente con este servidor virtual están localizadas a lo largo de la parte superior de la página. Sin embargo, antes de configurar cualquiera de las subsecciones relacionadas a este servidor virtual, complete esta página y haga clic en el botón ACCEPT.

Figura 4.6. La subsección de VIRTUAL SERVERS

Name: Ingrese un nombre descriptivo para identificar el servidor virtual. Este nombre no es el nombre de host para la máquina, debe ser descriptivo y fácilmente identificable. Incluso, puede referirse al protocolo utilizado por el servidor virtual, tal como HTTP.
Application port: Ingrese el número de puerto a través del cual la aplicación del servicio escuchará. En el ejemplo se utiliza el puerto 80, debido a que es para servicios HTTP.
Protocol: Elija entre UDP y TCP en el menú desplegable. Los servidores Web típicamente se comunican a través del protocolo TCP, por lo tanto se ha seleccionado en el ejemplo de arriba.
Virtual IP Address: Ingrese la dirección IP flotante del servidor real en este campo.
Virtual IP Network Mask: La máscara de red para el servidor virtual con el menú desplegable.
Firewall Mark: No ingrese un entero de marca de cortafuegos en este campo, a menos que esté vinculando protocolos multipuertos o creando un servidor virtual multipuertos por separado, sino los protocolos relacionados. En el ejemplo de arriba el servidor virtual tiene una Firewall Mark de 80 porque estamos vinculando conexiones a HTTP en el puerto 80 y a HTTPS en el puerto 443 mediante el valor de marca de cortafuegos 80. Cuando se combina esta técnica con persistencia, se garantizará a los usuarios que acceden tanto a páginas Web seguras como a las páginas Web inseguras, que serán dirigidos al mismo servidor real, preservando el estado.
Aviso
Al insertar una marca de cortafuegos en este campo le permite a IPVS reconocer que los paquetes que llevan esta marca de cortafuegos se manejen de la misma forma, pero usted debe realizar otra configuración por fuera de Piranha Configuration Tool para asignar en realidad las marcas de cortafuegos. Consulte la Sección 3.4, “Servicios multipuertos y adición del equilibrador de carga” para obtener instrucciones sobre cómo crear servicios multipuertos y la Sección 3.5, “Configuración de FTP” para crear un servidor virtual FTP altamente disponible.
Device: Ingrese el nombre del dispositivo de red al cual desea vincular la dirección IP flotante definida en el campo Virtual IP Address.
Cree un alias de la dirección IP flotante a la interfaz Ethernet conectada a la red pública. En este ejemplo, la red pública está en la interfaz eth0, por lo tanto eth0:1 se debe ingresar como nombre de dispositivo.

Re-entry Time: Ingrese un valor entero que defina el tiempo en segundos, antes de que el enrutador LVS activo devuelva un servidor real dentro del grupo tras una falla.
Service Timeout: Ingrese un valor entero que defina el tiempo, en segundos, antes de que el servidor real sea considerado como muerto y retirado del grupo.
Quiesce server: Cuando se selecciona el botón de radio Quiesce Server, el peso de un servidor real se establecerá a 0 cuando no esté disponible. Esto, inhabilita el servidor real de forma efectiva. Si el servidor real está disponible más adelante, los servidores reales se reactivarán con el peso original. Si el Quiesce Server se inhabilita, el servidor real fallido será retirado de la tabla de servidores. Cuando el servidor real esté disponible, se agregará otra vez a la tabla del servidor virtual.
Load monitoring tool: El enrutador LVS puede sondear la carga de los servidores reales utilizando rup o ruptime. Si selecciona rup desde el menú desplegable, cada servidor real debe ejecutar el servicio rstatd. Si selecciona ruptime, cada servidor real debe ejecutar el servicio rwhod.
Aviso
La monitorización de carga no es lo mismo que balanceo de carga y puede ser difícil predecir la conducta de programación cuando se combina con algoritmos de programación ponderados. Además, si utiliza la monitorización de carga, los servidores reales deben ser máquinas Linux.
Scheduling: Seleccione su algoritmo de programación preferido desde el menú desplegable. El valor predeterminado es Weighted least-connection. Para obtener más información sobre algoritmos, consulte la Sección 1.3.1, “Programación de algoritmos”.
Persistence: Si un administrador necesita conexiones persistentes para un servidor virtual durante transacciones de clientes ingrese, en el campo de texto, el tiempo en segundos de inactividad permitida antes de que el tiempo de conexión expire.
Importante
Si ingresó un valor en el campo Firewall Mark arriba, debe ingresar también un valor para persistencia. También asegúrese de que si usted usa marcas de cortafuegos y persistencia a la vez, esa cantidad de persistencia es la misma para cada servidor virtual con marca de cortafuegos. Para obtener más información sobre persistencia y marcas de cortafuegos, consulte la Sección 1.5, “Marcas de cortafuegos y persistencia”.
Persistence Network Mask: Para limitar la persistencia a una subred particular, seleccione la máscara apropiada de red desde el menú desplegable.
Nota
Antes de la llegada de las marcas de cortafuegos, la persistencia limitada mediante una subred era una forma cruda de vincular conexiones. Ahora es mejor usar persistencia en relación con las marcas de cortafuegos para obtener el mismo resultado.

Aviso

No olvide hacer clic en el botón ACCEPT después de hacer los cambios en este panel, para que no pierda los cambios al seleccionar un nuevo panel.

4.6.2. Subsección REAL SERVER

Al hacer clic en el enlace de la subsección REAL SERVER en la parte superior del panel, se llegará a la subsección EDIT REAL SERVER. Muestra el estado de los hosts del servidor físico para un servicio virtual particular.

Figura 4.7. La subsección SERVIDOR REAL

Haga clic en el botón ADD para agregar un nuevo servidor. Si desea borrar un servidor, seleccione el botón de radio al lado del servidor y haga clic en DELETE. Luego, pulse el botón EDIT para cargar el panel EDIT REAL SERVER, como aparece en la Figura 4.8, “El panel de configuración SERVIDOR REAL”.

Figura 4.8. El panel de configuración SERVIDOR REAL

Este panel está constituido por tres campos:

Name: Un nombre descriptivo para el servidor real.
Nota
Este nombre no es el nombre de host de la máquina. Utilice un nombre descriptivo y fácilmente identificable.
Address: La dirección IP del servidor real. Como el puerto de escucha ya está especificado para el servidor virtual asociado, no es necesario especificar el número de puerto.
Weight: Un valor entero que indica la capacidad del host en comparación con otros hosts en el grupo. El valor puede ser arbitrario, pero trátelo como una proporción en relación con otros servidores reales en el grupo. Para obtener más información sobre peso, consulte la Sección 1.3.2, “Peso de servidor y programación”.

Aviso

No olvide hacer clic en el botón ACEPTAR después de hacer los cambios en este panel, para que no pierda los cambios al seleccionar un nuevo panel.

4.6.3. Subsección EDIT MONITORING SCRIPTS

Haga clic en el enlace MONITORING SCRIPTS en la parte superior de la página. La subsección EDIT MONITORING SCRIPTS permite que los administradores especifiquen una secuencia de envío y expectativa para verificar que el servicio para el servidor virtual esté funcionando en cada servidor real. También es posible especificar scripts personalizados para revisar los servicios que requieren cambios de datos de forma dinámica.

Figura 4.9. La subsección EDIT MONITORING SCRIPTS

Sending Program

Se puede utilizar este campo para especificar un script para una verificación de servicios más avanzada. Esta función es especialmente útil para servicios que requieren cambios de datos de forma dinámica, como HTTPS o SSL.

Para usar esta funcionalidad, se debe escribir un script que retorne una respuesta textual. Establezca el script a ejecutable y escriba la ruta en el campo Sending program.

Nota

Para asegurarse de que cada grupo de servidor real sea marcado, use el símbolo especial %h después de la ruta al script en el campo Sending program. Este símbolo se remplaza por cada dirección IP real del servidor cuando el script es llamado por el daemon nanny.

A continuación, un script de muestra para usar como guía cuando se cree un script de marcado externo:

#!/bin/sh

TEST=`dig -t soa example.com @$1 | grep -c dns.example.com

if [ $TEST != "1" ]; then
	echo "OK
else
	echo "FAIL"
fi

Nota

Si se introduce un programa externo en el campo Sending Program, el campo Send será ignorado.

Enviar

En este campo, ingrese una cadena para el daemon nanny que será enviada a cada servidor real. La entrada se completa de forma predeterminada para HTTP. Puede alterar este valor si lo requiere. Si se deja este campo en blanco, el daemon nanny intentará abrir el puerto y, si lo logra, asumirá que el servicio está en ejecución.

Solo una secuencia de envío es permitida en este campo y solo puede contener caracteres ASCII y los siguientes caracteres de escape:

\n para nueva línea.
\r para retorno de línea.
\t para Tabulador
\ para escapar el siguiente caracter.

Esperar

Ingrese la respuesta textual que el servidor debe retornar si está funcionando correctamente. Si escribió su propio programa de envío, introduzca la respuesta que le dijo que enviara si tenía éxito.

Nota

Para determinar qué enviar a un servicio determinado, abra una conexión telnet a un puerto en un servidor real y vea lo que retorna. Por ejemplo, FTP reporta 220 tras conexión, es decir que podría ingresar quit en el campo Enviar y 220 en el campo Esperado.

Aviso

No olvide hacer clic en el botón ACEPTAR después de hacer los cambios en este panel, para que no pierda los cambios al seleccionar un nuevo panel.

Cuando haya configurado los servidores virtuales mediante Piranha Configuration Tool, copie los archivos de configuración específicos al enrutador LVS de respaldo. Consulte la Sección 4.7, “Sincronización de archivos de configuración” para obtener más información.

4.7. Sincronización de archivos de configuración

Después de configurar el enrutador primario LVS, hay varios archivos de configuración que deben ser copiados al enrutador de respaldo LVS antes de iniciar la adición del equilibrador de carga.

Estos archivos incluyen:

/etc/sysconfig/ha/lvs.cf — el archivo de configuración para los enrutadores LVS.
/etc/sysctl — el archivo de configuración he que, entre otras cosas, enciende el envío de paquetes en el kernel
/etc/sysconfig/iptables — Si usa marcas de cortafuegos, sincronice uno de estos archivos según el filtro de paquetes de red que utilice.

Importante

Los archivos /etc/sysctl.conf y /etc/sysconfig/iptables no cambian al configurar la adición del equilibrador de carga mediante Piranha Configuration Tool.

4.7.1. Sincronización de `lvs.cf`

Cuando el archivo de configuración LVS, /etc/sysconfig/ha/lvs.cf, se crea o actualiza, debe copiarlo al nodo de enrutador LVS de respaldo.

Aviso

Ambos nodos de enrutador LVS de retorno tener archivos lvs.cf idénticos. Los archivos de configuración LVS entre los nodos de enrutador LVS pueden evitar la conmutación.

La mejor forma de hacerlo es con el comando scp

Importante

Para usar scp y sshd se debe ejecutar el enrutador de respaldo, consulte la Sección 2.1, “Configuración de servicios en el enrutador LVS” para obtener información sobre cómo configurar los servicios necesarios en los enrutadores LVS.

Ejecute el siguiente comando como usuario root desde el enrutador LVS primario para sincronizar los archivos lvs.cf entre los nodos de enrutador:

scp /etc/sysconfig/ha/lvs.cf n.n.n.n:/etc/sysconfig/ha/lvs.cf

En el comando, remplace n.n.n.n por la dirección IP real del enrutador LVS de respaldo.

4.7.2. Sincronización de `sysctl`

El archivo sysctl solo se modifica una vez en la mayoría de las situaciones. Este archivo se lee en el momento del arranque y le pide al kernel que active el envío de paquetes.

Importante

Si no está seguro de que el reenvío de paquetes está activado en el kernel, consulte la Sección 2.5, “Activación de reenvío de paquetes” para obtener instrucciones sobre cómo revisar y, si es necesario, activar esta funcionalidad clave.

4.7.3. Sincronización de reglas de filtraje de paquetes de red

Si utiliza iptables, debe sincronizar el archivo de apropiado en el enrutador LVS de respaldo.

Si altera alguna de las reglas de filtraje de paquetes de red, ingrese el siguiente comando como root desde el enrutador LVS primario:

scp /etc/sysconfig/iptables n.n.n.n:/etc/sysconfig/

En el comando, remplace n.n.n.n por la dirección IP real del enrutador LVS de respaldo.

Luego pued abrir una sesión ssh al enrutador de respald o ingresar a la máquina como root y escribir el siguiente comando:

/sbin/service iptables restart

Una vez que haya copiado estos archivos al enrutador de respaldo e iniciado los servicios apropiados, estará listo para iniciar la adición del equilibrador de carga (consulte la Sección 2.1, “Configuración de servicios en el enrutador LVS” para más información).

4.8. Inicio de la adición del equilibrador de carga

Para iniciar la adición del equilibrador de carga, es mejor tener dos terminales root abiertas al mismo tiempo o dos sesiones root ssh abiertas simultáneamente para el enrutador LVS primario.

En una terminal, observe los mensajes del registro de kernel con el comando:

tail -f /var/log/messages

Luego ejecute el siguiente comando en la terminal para iniciar la adición del equilibrador de carga:

/sbin/service pulse start

Siga el progreso del inicio del servicio pulse en la terminal con los mensajes de registro de kernel. Cuando vea la siguiente salida, el daemon pulse habrá iniciado correctamente:

gratuitous lvs arps finished

Para dejar de ver /var/log/messages, escriba Ctrl+c.

Desde este punto, el enrutador LVS primario también activa el enrutador LVS. Aunque puede solicitar la adición del equilibrador de carga en este punto, debería iniciar el enrutador LVS de respaldo antes de poner la adición del equilibrador de carga en servicio. Para hacerlo, simplemente repita el proceso descrito arriba en el nodo de enrutador LVS.

Después de completar el paso final, la adición del equilibrador de carga estará activa y lista para ejecutarse.

Apéndice A. Cómo usar la adición del equilibrador de carga con la adición de alta disponibilidad

Puede usar la adición del equilibrador de carga con la adición de alta disponibilidad para implementar el sitio que proporciona balanceo de carga, integridad de datos y disponibilidad de aplicaciones.

La configuración en la Figura A.1, “Adición del equilibrador de carga con una adición de alta disponibilidad ” representa un sitio e-commerce utilizado para ordenar mercancía en línea a través de una URL. Las solicitudes de clientes a la URL pasan a través del cortafuegos al enrutador de balanceo de cargas activo LVS, el cual reenvía las solicitudes a uno de los servidores Web. Los nodos de adición de alta disponibilidad sirven datos dinámicos para los servidores Web, los cuales envían datos al cliente que los solicita.

Figura A.1. Adición del equilibrador de carga con una adición de alta disponibilidad

Servir contenido de Web dinámico con la adición del equilibrador de cargas requiere una configuración de tres partes (como se muestra en la Figura A.1, “Adición del equilibrador de carga con una adición de alta disponibilidad ”). Esta combinación de adición del equilibrador de carga de alta disponibilidad permite configuración de alta integridad , no un sitio de comercio-e de fallas de un solo punto. La adición de alta disponibilidad puede ejecutar una instancia de alta disponibilidad de base de datos o establecer un conjunto de base de datos que sea accesible en red para los servidores Web.

Se requiere una configuración de tres partes para proporcionar un contenido dinámico. Aunque una configuración de adición del equilibrador de carga es apta si los servidores Web sirven solamente contenido estático (que consta de pequeñas cantidades de datos que cambian con poca frecuencia), una configuración de dos no es apta si los servidores Web sirven contenido dinámico. El contenido dinámico puede incluir inventario de productos, órdenes de comprar y bases de datos de clientes, los cuales deben ser consistentes en todos los servidores Web para garantizar que los clientes puedan tengan acceso a datos actualizados y precisos.

Cada tercio provee las siguientes funciones:

Primer tercio — enrutador LVS que realiza balanceo de carga para distribuir las solicitudes de red.
Segundo tercio — Un conjunto de servidores Web para servir las solicitudes.
Tercer tercio — Una adición de alta disponibilidad para servir datos a los servidores Web.

En una configuración de adición del equilibrador de carga como la de la Figura A.1, “Adición del equilibrador de carga con una adición de alta disponibilidad ”, los sistemas cliente envían solicitudes en World Wide Web. Por razones de seguridad, estas solicitudes ingresan a un sitio Web a través de un cortafuegos, el cual puede ser un sistema Linux que sirva en esta funcionalidad o dispositivo de cortafuegos dedicado. Para redundancia, configure los dispositivos de cortafuegos en una configuración de conmutación. Detrás de un cortafuegos se encuentra un enrutador LVS que proporciona balanceo de carga, el cual puede configurarse en modo activo-pausado. El enrutador de balanceo de carga activo reenvía las solicitudes al conjunto de servidores Web.

Cada servidor Web puede procesar de forma independiente, una solicitud HTTP desde un cliente y responder al cliente. La adición del equilibrador de carga le permite expandir un sitio Web al adicionar servidores Web detrás del enrutador LVS; el enrutador LVS realiza balanceo de carga a través de un amplio set de servidores Web. Además, si un servidor Web falla, puede retirarse; la adición del equilibrador de carga realiza el balanceo a través de un grupo pequeño de servidores Web.

Apéndice B. Historia de revisiones

Historial de revisiones

Revisión 1-15.2

Thu Apr 16 2015

Gladys Guerrero-Lozano

Translated

Revisión 1-15.1

Thu Apr 16 2015

Gladys Guerrero-Lozano

Los archivos de traducción sincronizados con fuentes XML 1-15

Revisión 1-15

Tue Dec 16 2014

Steven Levine

Actualización para implementar sort_order en la página de inicio de RHEL 6.

Revisión 1-13

Thu Oct 9 2014

Steven Levine

Lanzamiento para disponibilidad general de Red Hat Enterprise Linux 6.6

Revisión 1-10

Tue Nov 19 2013

John Ha

Lanzamiento para disponibilidad general de Red Hat Enterprise Linux 6.5

Revisión 1-8

Fri Sep 27 2013

John Ha

Lanzamiento para Beta de Red Hat Enterprise Linux 6.5

Revisión 1-4

Wed Nov 28 2012

John Ha

Lanzamiento para Beta de Red Hat Enterprise Linux 6.4

Revisión 1-3

Mon Jun 18 2012

John Ha

Actualización para alta disponibilidad de Red Hat Enterprise Linux 6.3

Revisión 1-2

Fri Dec 2 2011

John Ha

Lanzamiento para GA de Red Hat Enterprise Linux 6.2

Revisión 1-1

Wed Nov 10 2010

Paul Kennedy

Lanzamiento inicial de libro para Red Hat Enterprise Linux 6

Índice

Símbolos

/etc/sysconfig/ha/lvs.cf archivo, /etc/sysconfig/ha/lvs.cf

A

Adición de alta disponibilidad

y la adición del equilibrador de carga, Cómo usar la adición del equilibrador de carga con la adición de alta disponibilidad

Adición del equilibrador de carga

/etc/sysconfig/ha/lvs.cf archivo, /etc/sysconfig/ha/lvs.cf

Cómo usar la adición del equilibrador de carga con adición de alta disponibilidad, Cómo usar la adición del equilibrador de carga con la adición de alta disponibilidad

componentes, Componentes de adición del equilibrador de carga

configuración inicial, Configuración inicial de adición del equilibrador de carga

datos compartidos, Replicación de datos y la compartición de datos entre servidores reales

enrutadores LVS

configuración de servicios, Configuración inicial de adición del equilibrador de carga
nodo primario, Configuración inicial de adición del equilibrador de carga
servicios necesarios, Configuración de servicios en el enrutador LVS

enrutamiento directo

requerimientos, hardware, Enrutamiento directo, Enrutamiento directo de adición del equilibrador de carga
requerimientos, red, Enrutamiento directo, Enrutamiento directo de adición del equilibrador de carga
requerimientos, software, Enrutamiento directo, Enrutamiento directo de adición del equilibrador de carga
y arptables_jf, Enrutamiento directo y arptables_jf

enrutamiento NAT

requerimientos, hardware, La red de adición del equilibrador de carga NAT
requerimientos, red, La red de adición del equilibrador de carga NAT
requerimientos, software, La red de adición del equilibrador de carga NAT

Inicio de la adición del equilibrador de carga, Inicio de la adición del equilibrador de carga

ipvsadm programa, ipvsadm

métodos de enrutamiento

NAT, Métodos de enrutamiento

nanny daemon, nanny

Piranha Configuration Tool , Piranha Configuration Tool

prerrequisitos de enrutamiento, Configuración de interfaces de red para adición del equilibrador de carga con NAT

programación de tareas, Sinopsis de programación de la adición del equilibrador de carga

programación, tareas, Sinopsis de programación de la adición del equilibrador de carga

pulse daemon, pulse

reenvío de paquetes, Activación de reenvío de paquetes

replicación de datos, servidores reales, Replicación de datos y la compartición de datos entre servidores reales

send_arp programa, send_arp

servicios multipuertos, Servicios multipuertos y adición del equilibrador de carga

FTP, Configuración de FTP

sincronización de archivos de configuración, Sincronización de archivos de configuración

tres niveles

Adición del equilibrador de carga, Configuración de adición del equilibrador de carga de tres partes

arptables_jf, Enrutamiento directo y arptables_jf

C

chkconfig, Configuración de servicios en el enrutador LVS

clúster

Cómo usar la adición del equilibrador de carga con la adición de alta disponibilidad, Cómo usar la adición del equilibrador de carga con la adición de alta disponibilidad

Comentarios, Comentarios

Componentes

de Adición del equilibrador de carga, Componentes de adición del equilibrador de carga

E

enrutamiento

prerrequisitos para adición del equilibrador de carga, Configuración de interfaces de red para adición del equilibrador de carga con NAT

Enrutamiento directo

y arptables_jf, Enrutamiento directo y arptables_jf

F

FTP, Configuración de FTP

(ver también Adición del equilibrador de carga)

I

Introducción, Introducción

otros documentos de Red Hat Enterprise Linux, Introducción

iptables , Configuración de servicios en el enrutador LVS

ipvsadm programa, ipvsadm

L

least connections (ver job scheduling, Load Balancer Add-On)

LVS

daemon, lvs

enrutamiento NAT

activación, Activación de enrutamiento NAT en enrutadores LVS

lvs daemon, lvs

servidores reales, Sinopsis de adición del equilibrador de carga

Sinopsis de, Sinopsis de adición del equilibrador de carga

lvs daemon, lvs

N

nanny daemon, nanny

NAT

activación, Activación de enrutamiento NAT en enrutadores LVS
métodos de enrutamiento, adición del equilibrador de carga, Métodos de enrutamiento

P

Piranha Configuration Tool , Piranha Configuration Tool

CONTROL/MONITORING , CONTROL/MONITORING

EDIT MONITORING SCRIPTSsubsección, Subsección EDIT MONITORING SCRIPTS

establecer una contraseña, Establecer una contraseña para Piranha Configuration Tool

GLOBAL SETTINGS , GLOBAL SETTINGS

limitar el acceso a, Cómo limitar el acceso a Piranha Configuration Tool

panel de ingreso, Ingreso a Piranha Configuration Tool

REAL SERVERSsubsección, Subsección REAL SERVER

REDUNDANCY , REDUNDANCY

SERVIDORES VIRTUALES , SERVIDORES VIRTUALES

software necesario, Software necesario

VIRTUAL SERESsubsección

Virtual IP Address , La subsección VIRTUAL SERVER

VIRTUAL SERVER subsección, La subsección VIRTUAL SERVER

Persistence , La subsección VIRTUAL SERVER

VIRTUAL SERVERSsubsección

Firewall Mark , La subsección VIRTUAL SERVER
Scheduling , La subsección VIRTUAL SERVER

vista general de, Configuración de la adición del equilibrador de carga mediante Piranha Configuration Tool

piranha-gui servicio, Configuración de servicios en el enrutador LVS

piranha-passwd , Establecer una contraseña para Piranha Configuration Tool

Programación de tareas, adición del equilibrador de carga, Sinopsis de programación de la adición del equilibrador de carga

Programación,tarea ( adición del equilibrador de carga), Sinopsis de programación de la adición del equilibrador de carga

pulse daemon, pulse

pulse servicio, Configuración de servicios en el enrutador LVS

R

Reenvío de paquetes, Activación de reenvío de paquetes

(ver también Adición del equilibrador de carga)

round robin (ver job scheduling, Load Balancer Add-On)

S

seguridad

Piranha Configuration Tool , Cómo limitar el acceso a Piranha Configuration Tool

send_arp programa, send_arp

Servicios multipuertos, Servicios multipuertos y adición del equilibrador de carga

(ver también Adición del equilibrador de carga)

Servidores reales

configuración de servicios, Cómo configurar servicios en los servidores reales

Sincronización de configuración, Sincronización de archivos de configuración

sshd service, Configuración de servicios en el enrutador LVS

T

Traducción de dirección de red (ver NAT)

W

weighted least connections (ver job scheduling, Load Balancer Add-On)
weighted round robin (ver job scheduling, Load Balancer Add-On)

Aviso Legal

This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Language and Page Formatting Options

Red Hat Training

Administración del Equilibrador de carga

Equilibrador de carga para Red Hat Enterprise Linux

Introducción

1. Comentarios

Capítulo 1. Sinopsis de adición del equilibrador de carga

1.1. Configuración básica de una adición del equilibrador de carga

1.1.1. Replicación de datos y la compartición de datos entre servidores reales

1.1.1.1. Cómo configurar servidores reales para sincronizar datos

1.2. Configuración de adición del equilibrador de carga de tres partes

1.3. Sinopsis de programación de la adición del equilibrador de carga

1.3.1. Programación de algoritmos

1.3.2. Peso de servidor y programación

1.4. Métodos de enrutamiento

1.4.1. Enrutamiento NAT

1.4.2. Enrutamiento directo

1.4.2.1. Enrutamiento directo y limitación ARP

1.5. Marcas de cortafuegos y persistencia

1.5.1. Persistencia

1.5.2. Marcas de cortafuegos

1.6. Adición del equilibrador de carga — Un diagrama de bloques

1.6.1. Componentes de adición del equilibrador de carga

1.6.1.1. pulse

1.6.1.2. lvs

1.6.1.3. ipvsadm

1.6.1.4. nanny

1.6.1.5. /etc/sysconfig/ha/lvs.cf

1.6.1.6. Piranha Configuration Tool

1.6.1.7. send_arp

Capítulo 2. Configuración inicial de adición del equilibrador de carga

2.1. Configuración de servicios en el enrutador LVS

2.2. Establecer una contraseña para Piranha Configuration Tool

2.3. Inicio del servicio Piranha Configuration Tool

2.3.1. Configuración del puerto de servidor Web Piranha Configuration Tool

2.4. Cómo limitar el acceso a Piranha Configuration Tool

2.5. Activación de reenvío de paquetes

2.6. Cómo configurar servicios en los servidores reales

Capítulo 3. Configuración de adición del equilibrador de carga

3.1. La red de adición del equilibrador de carga NAT

3.1.1. Configuración de interfaces de red para adición del equilibrador de carga con NAT

3.1.2. Enrutamiento en servidores reales

3.1.3. Activación de enrutamiento NAT en enrutadores LVS

3.2. Enrutamiento directo de adición del equilibrador de carga

3.2.1. Enrutamiento directo y arptables_jf

3.2.2. Enrutamiento directo e iptables

3.3. Recopilación de toda la configuración

3.3.1. Consejos de conexión para una adición del equilibrador de carga de red

3.3.1.1. Diagnóstico y resolución de problemas de direcciones IP virtuales

3.4. Servicios multipuertos y adición del equilibrador de carga

3.4.1. Asignación de marcas de cortafuegos

3.5. Configuración de FTP

3.5.1. Cómo funciona FTP

3.5.2. Cómo se afecta la adición del equilibrador de carga en enrutamiento

3.5.3. Creación de reglas de filtraje de paquetes de red

3.5.3.1. Reglas para conexiones activas

3.5.3.2. Reglas para conexiones pasivas

3.6. Guardado de parámetros de filtraje de paquetes de red

Capítulo 4. Configuración de la adición del equilibrador de carga mediante Piranha Configuration Tool

4.1. Software necesario

4.2. Ingreso a Piranha Configuration Tool

4.3. CONTROL/MONITORING

4.4. GLOBAL SETTINGS

4.5. REDUNDANCY

4.6. SERVIDORES VIRTUALES

4.6.1. La subsección VIRTUAL SERVER

4.6.2. Subsección REAL SERVER

4.6.3. Subsección EDIT MONITORING SCRIPTS

4.7. Sincronización de archivos de configuración

4.7.1. Sincronización de lvs.cf

4.7.2. Sincronización de sysctl

4.7.3. Sincronización de reglas de filtraje de paquetes de red

4.8. Inicio de la adición del equilibrador de carga

Apéndice A. Cómo usar la adición del equilibrador de carga con la adición de alta disponibilidad

Apéndice B. Historia de revisiones

Índice

Símbolos

A

C

E

1.6.1.1. `pulse`

1.6.1.2. `lvs`

1.6.1.3. `ipvsadm`

1.6.1.4. `nanny`

1.6.1.5. `/etc/sysconfig/ha/lvs.cf`

1.6.1.7. `send_arp`

3.2.1. Enrutamiento directo y `arptables_jf`

3.2.2. Enrutamiento directo e `iptables`

4.7.1. Sincronización de `lvs.cf`

4.7.2. Sincronización de `sysctl`