Administración del Equilibrador de carga
Equilibrador de carga para Red Hat Enterprise Linux
Edición 6
Equilibrador de carga para Red Hat Enterprise Linux
Edición 6
Copyright © 2014 Red Hat, Inc.
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.
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.
. . . . . . . . . . . . . . . .
Table of Contents
INTRODUCCIÓN 1. COMENTARIOSCAPÍ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 4 5 5 7 7 7 8 9 10 11 11 12 13 14 14 14 15 16 16 16 16 16 17 17 17 18 18 19 19 20 20 21 22 23 23 23 24 25 26 27 28 29 29 30 30 31 32 32
. . . .
. . . . . . . . . . . .
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 32 33 33 33 35 36 36 36 37 39 41 43 44 48 50 52 52 53 53 54 55 57 58
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.
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
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.
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
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.
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 demonio 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 demonio lvs y responde a los pulsos que provienen del enrutador LVS de respaldo.
Una vez iniciado, el demonio 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 demonio lvs si el servicio en el servidor real no está funcionando. Si el servicio no está funcionando, el demonio 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 demonio lvs en el enrutador activo e iniciar el demonio 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.
pulseEste es el proceso que inicia el resto de demonios relacionados con los enrutadores. Durante el inicio, el script /etc/rc.d/init.d/pulse inicia el demonio. Luego lee el archivo de configuración
/etc/sysconfig/ha/lvs.cf. En el enrutador activo, pulse inicia el demonio. 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 demonio 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 demonio lvs.
1.6.1.2.
lvsEl demonio 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.
ipvsadmEste servicio actualiza la tabla de rutas IPVS en el kernel. El demonio 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.
nannyEl demonio de sondeo nanny se ejecuta en el enrutador LVS activo. A través de este demonio, 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.cfEste es el archivo de adición del equilibrador de carga. Directa o indirectamente, todos los demonios 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_arpEste 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 demonio on
En el comando de arriba, remplace demonio 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:
AVISO
El encendido de alguno de los servicios de arriba mediante chkconfig no inicia el demonio. 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 o
/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:
1. Apache HTTP Server debe estar instalado en el sistema.
2. 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 demonios de servidor apropiados para activar en tiempo de arranque. Estos demonios 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 demonio 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_jfA 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:
1. 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.
2. 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.
3. 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.
4. 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
iptablesTambié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: 1. 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.
2. 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).
