Este capítulo explica cómo configurar los parámetros de equilibrio de carga y cómo configurar Load Balancer para funciones avanzadas.
Tarea | Descripción | Información relacionada |
---|---|---|
Ubicar de manera compartida Load Balancer en una máquina que tiene equilibrio de carga | Configura una máquina Load Balancer colocada. | Utilización de servidores con ubicación compartida |
Configurar alta disponibilidad o alta disponibilidad mutua | Configura una segunda máquina Dispatcher para proporcionar una máquina de reserva. | Alta disponibilidad |
Configurar el equilibrio de carga basado en normas | Define las condiciones en las que se utiliza un conjunto de servidores. | Configuración de equilibrio de carga basado en normas |
Utilizar la alteración temporal de la afinidad entre puertos para proporcionar un mecanismo para que un servidor altere la característica de permanencia en memoria. | Permite a un servidor alterar el valor de permanencia en memoria en este puerto. | Alteración temporal de la afinidad entre puertos |
Utilizar característica de permanencia en memoria (afinidad) para configurar el puerto de un clúster para que sea permanente en memoria | Permite dirigir al mismo servidor las solicitudes de cliente. | Cómo funciona la característica de afinidad para Load Balancer |
Utilizar afinidad entre puertos para expandir la característica de permanencia en memoria(afinidad) entre los puertos | Permite dirigir al mismo servidor las peticiones de cliente que se reciben en distintos puertos. | Afinidad entre puertos |
Utilizar máscara de dirección de afinidad para designar una dirección de subred IP común | Permite dirigir al mismo servidor las peticiones de cliente que se reciben en la misma subred. | Máscara de dirección de afinidad (stickymask) |
Utilizar afinidad de cookies activos para equilibrar la carga en servidores de CBR | Una opción de norma que permite que una sesión mantenga afinidad para un servidor concreto. | Afinidad de cookies activos |
Utilizar afinidad de cookies pasivos para equilibrar la carga en servidores con direccionamiento basado en contenido de Dispatcher y el componente CBR | Una opción de norma que permite que una sesión mantenga afinidad para un servidor concreto en función del valor de cookie/nombre de cookie. | Afinidad de cookies pasivos |
Utilizar la afinidad de URI para equilibrar la carga en los servidores Caching Proxy con contenido exclusivo para almacenarlo en la antememoria de cada uno de ellos | Una opción de norma que permite que una sesión mantenga afinidad para un servidor concreto en función del URI. | Afinidad de URI |
Configurar el soporte de Dispatcher de red de área amplia | Configura un Dispatcher remoto para equilibrar la carga en toda una red de área amplia. O bien, equilibra la carga en toda una red de área amplia (sin un Dispatcher remoto) utilizando una plataforma de servidor que dé soporte a GRE. | Configurar soporte de Dispatcher de área amplia |
Utilizar enlace explícito | Evita que Dispatcher se pase por alto en los enlaces. | Utilización de enlaces explícitos |
Utilizar una red privada | Configura Dispatcher para equilibrar la carga en los servidores de una red privada. | Utilización de una configuración de red privada |
Utilizar clúster comodín para combinar configuraciones de servidor comunes | Las direcciones que no se han configurado de forma explícita utilizarán el clúster comodín como una forma de equilibrar la carga del tráfico. | Utilizar un clúster comodín para combinar configuraciones de servidor |
Utilizar clúster comodín cara equilibrar la carga de cortafuegos | Se equilibrará la carga de todo el tráfico en cortafuegos. | Utilizar un clúster comodín para equilibrar la carga de cortafuegos |
Utilizar el clúster comodín con Proxy de memoria caché para un proxy transparente | Permite utilizar Dispatcher para habilitar un proxy transparente. | Utilizar un clúster comodín con Proxy de memoria caché para el proxy transparente |
Utilizar puerto comodín para dirigir tráfico de puerto no configurado | Maneja el tráfico que no está configurado para cualquier puerto específico. | Utilizar puerto comodín para dirigir tráfico de puerto no configurado |
Utilizar la detección de "ataques para rechazo de servicio" (DoS) para notificar a los administradores (mediante una alerta) los ataques potenciales | Dispatcher analiza solicitudes entrantes para una cantidad llamativa de conexiones TCP medio abiertas en servidores. | Detección de ataque para rechazo de servicio |
Utilizar el registro cronológico binario para analizar estadísticas de servidor | Permite almacenar en archivos binarios la información del servidor y recuperarla. | Utilización del registro cronológico binario para analizar estadísticas de servidor |
Utilizar una configuración de cliente con ubicación compartida | Permite a Load Balancer residir en la misma máquina que un cliente | Utilización de un cliente con ubicación compartida |
Load Balancer puede residir en la misma máquina que un servidor para el que equilibre la carga de las peticiones. Esto se conoce habitualmente como ubicación compartida de un servidor. La ubicación compartida se aplica a los componentes Dispatcher y Site Selector. La ubicación compartida también se admite en CBR, pero sólo cuando utiliza servidores Web específicos del enlace y Caching Proxy específico del enlace.
Linux: para configurar la ubicación compartida y la alta disponibilidad a la vez cuando se ejecuta el componente Dispatcher utilizando el método de reenvío MAC, consulte el apartado Alternativas de alias de bucle de retorno de Linux cuando se utiliza el reenvío MAC de Load Balancer.
Solaris: existe una limitación; no pueden configurarse asesores WAN cuando Dispatcher de punto de entrada tiene ubicación compartida. Consulte el apartado Utilización de asesores remotos con el soporte de área amplia de Dispatcher.
Windows: la ubicación compartida ya no está disponible.
En releases anteriores, era necesario especificar que la dirección del servidor con ubicación compartida fuera la misma que la dirección de no reenvío (NFA) en la configuración. Esta restricción ya no existe.
Para configurar que un servidor tenga ubicación compartida, el mandato dscontrol server proporciona una opción llamada collocated que se puede establecer en yes o no. El valor predeterminado es no. La dirección del servidor debe ser una dirección IP válida de una tarjeta de interfaz de red de la máquina. El parámetro collocated no debe establecerse para servidores con ubicación compartida que utilizan el método de reenvío NAT o CBR de Dispatcher.
Puede configurar un servidor con ubicación compartida de una de las siguientes maneras:
Para el reenvío NAT o CBR de Dispatcher, debe configurar (crear un alias) una dirección de adaptador no utilizada en la NFA. El servidor debe configurarse de modo que escuche en esta dirección. Configure el servidor con la siguiente sintaxis de mandato:
dscontrol server add clúster:puerto:nuevo_alias address nuevo_alias router IP_direccionador returnaddress dirección_retorno
Si no se configura pueden producirse errores del sistema, que no haya respuesta del servidor, o los dos.
Al configurar un servidor con ubicación compartida utilizando el método de reenvío nat de Dispatcher, el direccionador especificado en el mandato dscontrol server add debe ser una dirección de direccionador real y no la dirección IP del servidor.
El soporte para la ubicación compartida al configurar el método de reenvío NAT de Dispatcher ahora puede llevarse a cabo en los sistemas operativos si se llevan a cabo los siguientes pasos en la máquina Dispatcher:
arp -s hostname ether_addr pubutilizando la dirección MAC local para ether_addr. Esto permite a la aplicación local enviar tráfico a la dirección de retorno en el kernel.
CBR da soporte a la ubicación compartida en plataformas AIX, HP-UX, Linux y Solaris sin que sea necesario realizar configuraciones adicionales. No obstante, los servidores Web y Caching Proxy que utilice deben ser específicos del enlace.
Site Selector da soporte a la ubicación compartida en plataformas AIX, HP-UX, Linux y Solaris sin que sea necesario realizar configuraciones adicionales.
La función de alta disponibilidad (que puede configurarse con el mandato dscontrol highavailability) está disponible para el componente Dispatcher, pero no para el componente CBR o Site Selector.
Para mejorar la disponibilidad de Dispatcher, la función del alta disponibilidad de Dispatcher utiliza los siguientes mecanismos:
Si es posible, al menos uno de los pares de pulsos debe estar en una subred distinta del tráfico del clúster normal. Si el tráfico de pulsos se identifica claramente se evitará que se produzcan falsas lecturas de otras señales en condiciones de cargas elevadas en la red y se mejorarán los tiempos de recuperación completos después de producirse una sustitución por anomalía.
La sintaxis completa para dscontrol highavailability se encuentra en dscontrol highavailability — controlar la alta disponibilidad.
Para obtener una descripción más completa de muchas de las tareas siguientes, consulte Configuración de la máquina Dispatcher.
dscontrol highavailability heartbeat add dirección_origen dirección_destino
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3Como mínimo un par de pulsos debe tener las NFA del par como dirección de origen y destino.
Si es posible, al menos uno de los pares de pulsos debe estar en una subred distinta del tráfico del clúster normal. Si el tráfico de pulsos se identifica claramente se evitará que se produzcan falsas lecturas de otras señales en condiciones de cargas elevadas en la red y se mejorarán los tiempos de recuperación completos después de producirse una sustitución por anomalía.
Establezca dl número de segundos que el ejecutor utiliza para indicar el tiempo de espera de los pulsos de alta disponibilidad. Por ejemplo:
dscontrol executor set hatimeout 3
El valor predeterminado es 2.
dscontrol highavailability reach add 9.67.125.18Los destinos de alcance son recomendables aunque no necesarios. Consulte Capacidad de detección de anomalías utilizando pulsos y destino de alcance para obtener más información.
dscontrol highavailability backup add primary [auto | manual] puerto
dscontrol highavailability backup add backup [auto | manual] puerto
dscontrol highavailability backup add both [auto | manual] puerto
dscontrol highavailability statusCada una de las máquinas debe tener el rol correcto (reserva, primaria o ambos), estados y subestados. La primara debe estar activa y sincronizada; la de reserva debe estar en modalidad de espera y debe sincronizarse en poco tiempo. Las estrategias deben ser las mismas.
dscontrol cluster set clústerA primaryhost NFAdispatcher1 dscontrol cluster set clústerB primaryhost NFAdispatcher2
dscontrol cluster set clústerB primaryhost NFAdispatcher2 dscontrol cluster set clústerA primaryhost NFAdispatcher1
Además de los criterios básicos de detección de anomalía (la pérdida de conectividad entre máquinas Dispatcher activas y en espera, que se detecta a través de los mensajes de pulso), hay otro mecanismo de detección de anomalías denominado criterios de accesibilidad. Al configurar Dispatcher se puede proporcionar una lista de hosts a los que cada una de las máquinas Dispatcher debe poder llegar para funcionar correctamente. Los dos asociados de alta disponibilidad se comunican continuamente entre sí a través de pulsos y se actualizan mutuamente en la cantidad de destinos de alcance en los que cualquiera de ellos puede hacer ping. Si la máquina en espera hace ping en más destinos de alcance que la máquina activa, se produce una sustitución por anomalía.
Los pulsos los envía la máquina Dispatcher activa y está previsto que la máquina Dispatcher en espera los reciba cada medio segundo. Si la máquina Dispatcher en espera no puede recibir un pulso durante un intervalo 2 segundos, se empieza un proceso de sustitución por anomalía. Para que se produzca un proceso de toma de control por parte de la máquina Dispatcher en espera, es necesario que se interrumpan todos los pulsos. Es decir, cuando hay dos pares de pulsos configurados, los dos pulsos deben interrumpirse. Para estabilizar el entorno de alta disponibilidad y para evitar que se produzca una sustitución por anomalía, añada más de un par de pulsos.
Para los destinos de alcance, debe elegir como mínimo un host para cada subred que utiliza la máquina Dispatcher. Los hosts pueden ser direccionadores, servidores IP u otros tipos de hosts. La accesibilidad de hosts se obtiene mediante el asesor de alcance, que hace ping en el host. La sustitución por anomalía tiene lugar si los mensajes de pulso no pueden transmitirse o si los criterios de accesibilidad los satisface mejor la máquina Dispatcher en espera que la máquina Dispatcher activa. Para tomar una decisión basándose en toda la información disponible, la máquina Dispatcher activa envía regularmente su capacidad de accesibilidad a la máquina Dispatcher en espera. Luego la máquina Dispatcher en espera compara esta capacidad con la suya y decide si debe conmutar el control.
Hay configuradas dos máquinas Dispatcher: la máquina primaria y una segunda máquina denominada de reserva. Durante el arranque, la máquina primaria envía todos los datos de conexión a la máquina de reserva hasta que la máquina se sincroniza. La máquina primaria pasa a estar activa, es decir, empieza el equilibrio de carga. Mientras tanto, la máquina de reserva supervisa el estado de la máquina primaria y se dice que está en estado en espera.
Si la máquina de reserva detecta en cualquier punto que la máquina primaria ha fallado, realiza una toma de toma de control de las funciones de equilibrio de carga de la máquina primaria y se convierte en la máquina activa. Cuando la máquina primaria vuelve a estar operativa de nuevo, las máquinas responden de acuerdo con la manera en que el usuario ha configurado la estrategia de recuperación. Existen dos tipos de estrategia:
El parámetro strategy debe tener el mismo valor en ambas máquinas.
Utilizando el mandato takeover, la estrategia de recuperación manual permite forzar el direccionamiento de paquetes a una máquina determinada. La recuperación manual es útil cuando el mantenimiento se lleva a cabo en la otra máquina. La estrategia de recuperación de automática está diseñada para operaciones desatendidas normales.
Para una configuración de alta disponibilidad mutua, no existe ninguna anomalía por clúster. Si hay algún problema en una máquina, incluso si sólo afecta a un clúster, la otra máquina tomará el control de los dos clústeres.
Para que Dispatcher direccione paquetes, cada dirección de clúster debe tener un alias asociado a un dispositivo de interfaz de red.
Para obtener información sobre la creación de alias para la tarjeta de interfaz de red, consulte Paso 5. Crear un alias para la tarjeta de interfaz de red.
Puesto que las máquinas Dispatcher cambiarán su estado cuando se detecte una anomalía, los mandatos anteriores deben emitirse automáticamente. Para ello Dispatcher ejecutará scripts creados por el usuario. Los scripts de ejemplo se encuentran en el directorio siguiente:
Estos scripts se deben mover al directorio siguiente para poder trabajar:
Los scripts se ejecutarán automáticamente sólo si dsserver se está ejecutando.
Se pueden utilizar los siguientes scripts de ejemplo:
En sistemas Windows: en la configuración, si dispone de Site Selector equilibrando la carga de dos máquinas Dispatcher que están funcionando en un entorno de alta disponibilidad, será necesario añadir un alias a la pila de Microsoft para los Metric Servers. Este alias debe añadirse al script goActive. Por ejemplo:
call netsh interface ip add address "Conexión de área local" addr=9.37.51.28 mask=255.255.240.0
En el caso de goStandby y goInOp, será necesario suprimir el alias: Por ejemplo:
call netsh interface ip delete address "Conexión de área local" addr=9.37.51.28
Si hay varias NIC en la máquina, compruebe primero qué interfaz debe utilizar emitiendo el siguiente mandato en el indicador de mandatos: netsh interface ip show address. Este mandato devolverá una lista de las interfaces configuradas actualmente y asignará un número a "Conexión de área local" (por ejemplo, "Conexión de área local 2") para que pueda determinar cuál debe utilizar.
En Linux para S/390: Dispatcher emite un ARP injustificado para mover direcciones IP de un Dispatcher a otro. Este mecanismo está, por lo tanto, relacionado con el tipo de red implícito. Cuando se ejecuta Linux para S/390, Dispatcher sólo puede realizar de forma nativa tomas de control de alta disponibilidad (completas con movimientos de dirección IP) en las interfaces que pueden emitir un ARP injustificado y configurar la dirección en la interfaz local. Este mecanismo no funcionará correctamente en interfaces punto a punto como, por ejemplo, IUCV y CTC, y no funcionará correctamente en algunas configuraciones de qeth/QDIO.
Para estas interfaces y configuraciones donde la función de toma de control de IP nativa del Dispatcher no funcionará correctamente, el cliente puede colocar mandatos adecuados en los scripts go para mover las direcciones de manera manual. De esta manera también se asegurará de que dichas topologías de red se puedan beneficiar de la alta disponibilidad.
Utilice el equilibrio de carga basado en reglas para ajustar cuándo y porqué los paquetes se envían a qué servidores. Load Balancer examina todas las normas que se añaden, desde la primera prioridad a la última, se detiene en la primera norma que es cierta y luego equilibra la carga del contenido entre todos los servidores asociados a la norma. Ya se ha equilibrado la carga basada en el destino y el puerto, pero si se utilizan normas se amplía la capacidad de distribuir conexiones.
En la mayoría de los casos, al configurar normas se debe configurar una norma siempre cierta para poder detectar cualquier petición pasada por otras normas de prioridad más altas. Este valor por omisión puede ser la respuesta "Lo sentimos, el sitio está inactivo actualmente, inténtelo más adelante" cuando los demás servidores no pueden aceptar la petición de cliente.
Debe utilizar el equilibrio de carga basado en normas con Dispatcher y Site Selector cuando por alguna razón desea utilizar un subconjunto de servidores. Siempre debe utilizar normas para el componente CBR.
Puede elegir entre los siguientes tipos de normas:
Antes de empezar a añadir normas a la configuración, planifique la lógica que desea que sigan las normas.
Todas las reglas tienen un nombre, un tipo, una prioridad y pueden tener un inicio del rango y un final del rango, junto con un conjunto de servidores. Además, la norma de tipo contenido para el componente CBR tiene asociado un patrón de expresión regular coincidente. (Si desea ver ejemplos y casos de cómo utilizar la norma de contenido y la sintaxis de patrón válida para la norma de contenido, consulte el Apéndice B. Sintaxis de la norma de contenido (patrón)).
Las normas se evalúen en orden de prioridad. Es decir, una norma con prioridad 1 (número más bajo) se evalúa antes que una norma con prioridad 2 (número más alto). Se utilizará la primera norma que se satisfaga. Una vez que se ha satisfecho una norma, no se evalúan más normas.
Para que una norma se satisfaga, debe cumplir dos condiciones:
Si una norma no tiene asociado ningún servidor, sólo es necesario que la norma cumpla la condición uno para que se satisfaga. En este caso, Dispatcher descartará la petición de conexión, Site Selector devolverá la petición del servidor de nombres con un error, y CBR causará que Proxy de memoria caché devuelva una página de error.
Si no se satisface ninguna norma, Dispatcher seleccionará un servidor del total de servidores disponibles en el puerto, Site Selector seleccionará un servidor del total de servidores disponibles en el nombre de sitio y CBR provocará que Proxy de memoria caché devuelva una página de error.
Este tipo de norma está disponible en el componente Dispatcher, CBR o Site Selector.
Utilice normas basadas en la dirección IP de cliente si desea filtrar los clientes y asignar los recursos en función del lugar de donde proceden.
Por ejemplo, si observa que hay demasiado tráfico sin pagar en la red, y por lo tanto no deseado, que procede de un grupo específico de direcciones IP. Cree una norma utilizando el mandato dscontrol rule, por ejemplo:
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
Esta norma "ni" filtra cualquier conexión de clientes no deseados. A continuación, añada a la norma los servidores a los que se podrá acceder, o si no añade ningún servidor a la norma, los servidores no atenderán las peticiones que procedan de las direcciones 9.x.x.x.
Este tipo de norma sólo está disponible en el componente Dispatcher.
Utilice normas basadas en el puerto de cliente, si los clientes utilizan algún tipo de software que solicita un puerto específico de TCP/IP cuando realiza peticiones.
Por ejemplo, cree una norma que indique que todas las peticiones que tengan el puerto de cliente 10002 podrán utilizar un conjunto de servidores rápidos especiales porque sabe que todas las peticiones de cliente con dicho puerto proceden de un grupo selecto de clientes.
Este tipo de norma está disponible en el componente Dispatcher, CBR o Site Selector.
Utilice reglas basadas en la hora del día por razones de planificación de capacidad. Por ejemplo, si se accede al sitio Web mayormente durante el mismo grupo de horas cada día, puede dedicar cinco servidores adicionales durante el periodo de hora punta.
Otra razón por la que puede utilizar una norma basada en la hora del día es cuando desea apagar algunos de los servidores para realizar su mantenimiento cada día a medianoche, por lo que puede establecer una norma que excluya estos servidores durante el periodo de mantenimiento necesario.
Este tipo de norma sólo está disponible en el componente Dispatcher.
Utilice normas basadas en el contenido del campo de “tipo de servicio” (TOS) en la cabecera IP. Por ejemplo, si una petición de cliente llega con un valor TOS que indica servicio normal, puede direccionarse a un conjunto de servidores. Si una petición de cliente diferente llega con un valor de TOS distinto que indica una prioridad de servicio más alta, puede direccionarse a un grupo de servidores distinto.
La norma TOS permite configurar completamente cada bit del byte TOS utilizando el mandato dscontrol rule. Para bits significativos que desee hacer coincidir en el byte TOS, utilice 0 o 1. Si no, utilice el valor x. A continuación se muestra un ejemplo de adición de una norma TOS:
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
Este tipo de norma está disponible en los componentes Dispatcher y CBR.
Utilice reglas basadas en conexiones por segundo si necesita compartir algunos de los servidores con otras aplicaciones. Por ejemplo, puede establecer dos normas:
O, puede utilizar Telnet y reservar dos de los cinco servidores para Telnet, excepto cuando las conexiones por segundo superen un determinado nivel. De esta forma, Dispatcher equilibrará la carga en todos los cinco servidores durante las horas punta.
Si establece la opción de evaluación de normas "upserversonrule" junto con la norma de tipo "conexión": cuando se utiliza la norma de tipo conexión y se establece la opción upserversonrule, si algunos de los servidores del conjunto de servidores están inactivos, puede garantizar que no se sobrecargarán los servidores restantes. Consulte el apartado Opción de evaluación del servidor para normas para obtener más información.
Este tipo de norma está disponible en el componente Dispatcher o CBR.
Utilice reglas basadas en el total de conexiones activas en un puerto si los servidores se sobrecargan y empiezan a descartar paquetes. Determinados servidores Web seguirán aceptando conexiones incluso cuando no tengan suficientes hebras para responder a la petición. Como resultado, las peticiones de cliente excederán el tiempo de espera y no se atenderá al cliente procedente del sitio Web. Utilice normas basadas en conexiones activas para equilibrar la capacidad dentro de una agrupación de servidores.
Por ejemplo, sabe por experiencia que los servidores dejarán de dar servicio una vez que han aceptado 250 conexiones. Cree una norma utilizando el mandato dscontrol rule o el mandato cbrcontrol rule, por ejemplo:
dscontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 o cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
A continuación, añada a la norma los servidores actuales y a algunos servidores adicionales, que si no se utilizarán para otro proceso.
Las normas de ancho de banda reservado y ancho de banda compartido sólo están disponibles en el componente Dispatcher.
Para las reglas de ancho de banda, Dispatcher calcula el ancho de banda como la velocidad a la que un conjunto de servidores entregan los datos a los clientes. Dispatcher realiza un seguimiento de la capacidad en los niveles de servidor, norma, puerto, clúster y ejecutor. Para cada uno de estos niveles, hay un campo de contador de bytes: kilobytes transferidos por segundo. Dispatcher calcula estas velocidades a un intervalo de 60 segundos. Puede ver estas velocidades en la GUI o en la salida de un informe de línea de mandatos.
La norma de ancho de banda reservado permite controlar el número de kilobytes por segundos que entregan un conjunto de servidores. Si se establece un umbral (asignando un rango de ancho de banda específico) para cada conjunto de servidores en toda la configuración, puede controlar y garantizar la cantidad de ancho de banda que utiliza cada combinación de clúster-puerto.
A continuación se muestra un ejemplo de adición de una norma de ancho de banda reservado:
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
El inicio del rango y el final del rango se especifican en kilobytes por segundo.
Antes de configurar la norma de ancho de banda compartido, debe especificar la cantidad máxima de ancho de banda (kilobytes por segundo) que puede compartirse en el nivel de ejecutor o clúster utilizando el mandato dscontrol executor o dscontrol cluster con la opción sharedbandwidth. El valor de sharebandwidth no debe exceder el ancho de banda total (capacidad total de la red) disponible. Si se utiliza el mandato dscontrol para establecer el ancho de banda compartido sólo se proporciona un límite superior para la norma.
A continuación se muestran ejemplos de la sintaxis de mandato:
dscontrol executor set sharedbandwidth tamaño dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth tamaño
El tamaño para sharedbandwidth es un valor entero (kilobytes por segundo). El valor predeterminado es cero. Si el valor es cero, el ancho de banda no puede compartirse.
El ancho de banda compartido en el nivel de clúster permite que el clúster utilice el máximo ancho de banda especificado. Mientras el ancho de banda utilizado por el clúster esté por debajo de la cantidad especificada, esta norma se evaluará como true. Si el ancho de banda total utilizado es superior a la cantidad especificada, esta norma se evaluará como false.
Si se comparte el ancho de banda en el nivel de ejecutor, se permitirá que toda la configuración de Dispatcher comparta una cantidad máxima de ancho de banda. Mientras el ancho de banda utilizado en el nivel de ejecutor esté por debajo de la cantidad especificada, esta norma se evaluará como true. Si el ancho de banda total utilizado es superior al definido, esta norma se evaluará como false.
A continuación se muestran ejemplos de la adición o definición de una norma de ancho de banda compartido:
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel valor dscontrol rule set 9.20.34.11:80:shrule sharelevel valor
El valor para sharelevel es executor o cluster. Sharelevel es un parámetro necesario en la norma de ancho de banda compartido.
Dispatcher permite asignar un ancho de banda específico a conjuntos de servidores dentro de la configuración mediante la norma de ancho de banda reservado. Si especifica un inicio y un final del rango puede controlar el rango de kilobytes entregados por un conjunto de servidores a los clientes. Cuando la norma ya no se evalúe como true (se excede el final del rango), se evaluará la norma con prioridad más baja siguiente. Si la norma de prioridad más baja siguiente es una norma "siempre cierta", se podría seleccionar un servidor para responder al cliente con una respuesta de "sitio ocupado".
Por ejemplo, suponga un grupo de tres servidores en el puerto 2222. Si el ancho de banda reservado se establece en 300, la cantidad máxima de kbytes por segundo es de 300, en un periodo de 60 segundos. Cuando esta velocidad se excede, la norma ya no se evaluará como true. Si ésta fuera la única norma, Dispatcher seleccionaría uno de los tres servidores para manejar la petición. Si hubiera una norma "siempre cierta" con prioridad más baja, la petición podría dirigirse a otro servidor y responderse con "sitio ocupado".
La norma de ancho de banda compartido puede proporcionar a los clientes acceso a servidores adicionales. En concreto, cuando se utiliza como una norma de prioridad más baja después de una norma de ancho de banda reservado, un cliente seguirá pudiendo acceder a un servidor incluso si se ha excedido el ancho de banda reservado.
Por ejemplo, si utiliza una norma de ancho de banda compartido después de una norma de ancho de banda reservado, puede permitir a los clientes que accedan a los tres servidores de una forma controlada. Mientras haya un ancho de banda compartido para utilizarse, la norma se evaluará como true y se otorgará el acceso. Si no hay ningún ancho de banda compartido disponible, la norma no es true y se evalúa la norma siguiente. Si a continuación hay una norma "siempre cierta", la petición puede redirigirse según sea necesario.
Si utiliza el ancho de banda reservado y compartido tal como se describe en el ejemplo anterior, se podrá ejercer una mayor flexibilidad al otorgar (o denegar) acceso a los servidores. Los servidores de un puerto específico pueden limitarse al uso de un ancho de banda, mientras que otros pueden utilizar un ancho de banda adicional mientras esté disponible.
Este tipo de norma sólo está disponible en el componente Selector de sitio.
Para la norma de toda la métrica, elija una métrica del sistema (cpuload, memload, o su propio script de métrica de sistema personalizado) y el Site Selector compara el valor de métrica del sistema (devuelto por el agente de Metric Server que reside en cada servidor con equilibrio de carga) con el inicio y el final del rango que se especifica en la norma. El valor de métrica del sistema actual para todos los servidores del conjunto de servidores debe estar dentro del rango para que se active la norma.
A continuación se muestra un ejemplo de adición a la configuración de una norma de toda la métrica:
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Este tipo de norma sólo está disponible en el componente Selector de sitio.
Para la regla de media de la métrica, elija una métrica del sistema (cpuload, memload, o su propio script de métrica de sistema personalizado) y el Site Selector compara el valor de métrica del sistema (devuelto por el agente de Metric Server que reside en cada servidor con equilibrio de carga) con el inicio y el final del rango que se especifica en la regla. La media de los valores de métrica del sistema actuales para todos los servidores del conjunto de servidores debe estar dentro del rango para que se active la norma.
A continuación se muestra un ejemplo de adición a la configuración de una norma de media de la métrica:
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
Este tipo de norma está disponible en el componente Dispatcher, CBR o Site Selector.
Puede crearse una norma que sea “siempre cierta.” Dicha norma siempre estará seleccionada, a menos que los servidores asociados estén inactivos. Por esta razón, habitualmente debe tener una prioridad más baja que las otras normas.
También puede tener varias normas “siempre cierta”, con un conjunto de servidores asociado a cada una de ellas. Se selecciona la primera norma true que tenga un servidor disponible. Por ejemplo, suponga que tiene seis servidores. Desea que dos de ellos controlen el tráfico en todas las circunstancias, a menos los dos estén inactivos. Si los dos primeros servidores están inactivos, se recomienda disponer de un segundo conjunto de servidores que controle el tráfico. Si los cuatro servidores están inactivos, se utilizarán los dos últimos servidores para manejar el tráfico. Puede establecer hasta tres normas “siempre cierta”. Así pues siempre se seleccionará el primer conjunto de servidores siempre y cuando haya uno activo como mínimo. Si los dos están inactivos, se optará por uno del segundo conjunto y así sucesivamente.
Otro ejemplo sería si deseara una norma “siempre cierta” para asegurarse de que no se atenderá a los clientes entrantes si estos no coinciden con ninguna de las normas establecidas. Puede crear una norma utilizando el mandato dscontrol rule como la siguiente:
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
Entonces no añadiría ningún servidor a la norma, lo que provocaría que los paquetes de clientes se dejaran sin respuesta.
Puede definir más de una norma “siempre cierta” y, a partir de ahí, ajustar cuál se ejecuta cambiando los niveles de prioridad.
Este tipo de norma está disponible en el componente CBR o el componente Dispatcher (cuando se utiliza el método de reenvío CBR de Dispatcher).
Se recomienda utilizar normas de tipo de contenido para enviar peticiones a conjuntos de servidores establecidos específicamente para manejar algún subconjunto del tráfico del sitio. Por ejemplo, si desea utilizar un conjunto de servidores para manejar todas las peticiones cgi-bin, otro conjunto para manejar todas las peticiones de audio de modalidad continua y un tercer conjunto para manejar las demás peticiones. Añada una norma con un patrón que coincida con la vía de acceso al directorio cgi-bin, otra que coincida con el tipo de archivo de los archivos de audio de modalidad continua y una tercera norma siempre cierta para manejar el resto del tráfico. A continuación, añada los servidores adecuados a cada una de las normas.
Importante: si desea ver ejemplos y casos de cómo utilizar la norma de contenido y la sintaxis de patrón válida para la norma de contenido, consulte el Apéndice B. Sintaxis de la norma de contenido (patrón).
Con la alteración temporal de afinidad entre puertos, puede alterar temporalmente la permanencia en memoria de un puerto para un servidor específico. Por ejemplo, si utiliza una norma para limitar la cantidad de conexiones para cada servidor de aplicaciones y tiene un servidor de desbordamiento con una norma siempre cierta que indica “por favor, inténtelo más adelante" para dicha aplicación. El puerto tiene un valor de permanencia en memoria de 25 minutos, por lo tanto no desea que el cliente sea permanente en memoria para dicho servidor. Con la alteración temporal de afinidad entre puertos, puede cambiar el servidor de desbordamiento para alterar temporalmente la afinidad que normalmente está asociada a dicho puerto. La próxima vez que el cliente emite una petición al clúster, se equilibra su carga con el mejor servidor de aplicaciones disponible, no el servidor de desbordamiento.
Consulte el apartado dscontrol server — configurar servidores, para obtener información detallada sobre la sintaxis del mandato de alteración temporal de afinidad entre puertos, utilizando la opción sticky del servidor .
Para añadir normas mediante el mandato dscontrol rule add, edite el archivo de configuración de ejemplo o utilice la interfaz gráfica de usuario (GUI). Puede añadir una o más normas a cada puerto definido.
Es un proceso de dos pasos: añadir la norma y definir qué servidores la atenderán si la norma es cierta. Por ejemplo, el administrador del sistema desea realizar un seguimiento del uso de los servidores proxy que realiza cada una de las secciones del sitio. Se han otorgado direcciones IP a cada sección. Cree el primerconjunto de normas basándose en la dirección IP de cliente para separar la carga de cada sección:
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
A continuación, añada un servidor distinto para cada norma y mida la carga en cada uno de los servidores para poder facturar correctamente a la sección por los servicios que está utilizando. Por ejemplo:
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
La opción de evaluación del servidor sólo está disponible en el componente Dispatcher.
En el mandato dscontrol rule hay una opción de evaluación del servidor para normas. Utilice la opción evaluate para optar por evaluar la condición de la norma en todos los servidores del puerto o evaluar la condición de la norma sólo en los servidores incluidos en la norma. (En versiones anteriores de Load Balancer, sólo se podía medir la condición de cada norma en todos los servidores del puerto).
A continuación se muestran ejemplos de la adición o definición de la opción de evaluación en una norma de ancho de banda reservado:
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate level dscontrol rule set 9.22.21.3:80:rbweval evaluate nivel
El nivel de la evaluación puede establecerse en port, rule o upserversonrule. El valor por omisión es port.
La opción de medir la condición de la norma en todos los servidores a los que se aplica le permite configurar dos normas con las siguientes características:
El resultado es que cuando el tráfico excede el umbral de los servidores a los que se aplica la primera norma, el tráfico se envía al servidor “sitio ocupado" al que se aplica la segunda norma. Cuando el tráfico está por debajo del umbral de los servidores en la primera regla, el tráfico nuevo continúa de nuevo en los servidores en la primera regla.
Si utiliza las dos normas del ejemplo anterior, si establece la opción de evaluación en port para la primera norma (evaluar condición de la norma en todos los servidores del puerto), cuando el tráfico excede el umbral de dicha norma, se envía al servidor “sitio ocupado" asociado a la segunda norma.
La primera norma mide todo el tráfico del servidor (incluido el servidor “sitio ocupado") en el puerto para determinar si el tráfico excede el umbral. Cuando la congestión disminuye en todos los servidores asociados a la primera norma, puede producirse un resultado involuntario en el que el tráfico sigue dirigiéndose al servidor “sitio ocupado" porque el tráfico en el puerto todavía supera el umbral de la primera norma.
Para los componentes Dispatcher y CBR: habilite la característica de afinidad cuando configure un puerto de clúster para que sea permanente en memoria. Si configura el puerto de un clúster de modo que sea permanente en memoria, permite que las peticiones de cliente subsiguientes se direccionen al mismo servidor. Esto se lleva a cabo estableciendo stickytime en el nivel de ejecutor, clúster o puerto en algunos segundos. Esta característica se inhabilita estableciendo el tiempo de permanencia en memoria (stickytime) en el valor cero.
Si está habilitando la afinidad entre puertos, los valores de tiempo de permanencia en memoria (stickytime) de los puertos compartidos deben ser valores iguales (no cero). Consulte el apartado Afinidad entre puertos para obtener más información.
Para el componente Site Selector: habilite la característica de afinidad cuando configure un nombre de sitio para que sea permanente en memoria. Si configura un nombre de sitio para que sea permanente en memoria, el cliente podrá utilizar el mismo servidor para varias peticiones del servicio de nombres. Esto se lleva a cabo estableciendo stickytime del nombre del sitio en algunos segundos. Esta característica se inhabilita estableciendo el tiempo de permanencia en memoria (stickytime) en el valor cero.
El período de permanencia en memoria es el intervalo entre el cierre de una conexión y la apertura de una conexión nueva, durante el cual un cliente se volverá a enviar al mismo servidor utilizado durante la primera conexión. Cuando caduca el tiempo de permanencia en memoria, el cliente puede enviarse a un servidor distinto del primero. El valor de tiempo de permanencia en memoria para un servidor se configura mediante los mandatos dscontrol, executor, port o cluster.
Con la característica de afinidad inhabilitada, siempre que se recibe una nueva conexión TCP de un cliente, Load Balancer elige el servidor correcto en dicho momento y le reenvía los paquetes. Si llega una conexión subsiguiente procedente del mismo cliente, Load Balancer la trata como si fuera una nueva conexión no relacionada y elige de nuevo el servidor apropiado para dicho momento.
Con la característica de afinidad habilitada, si se recibe una solicitud subsiguiente del mismo cliente, la solicitud se dirige al mismo servidor.
Con el tiempo, el cliente terminará el envío de transacciones y el registro de afinidad desaparecerá. De ahí el significado de "tiempo de permanencia en memoria." Cada registro de afinidad existe durante el "tiempo de permanencia en memoria" en segundos. Cuando se reciben conexiones subsiguientes dentro del tiempo de permanencia en memoria, el registro de afinidad seguirá siendo válido y la solicitud se dirigirá al mismo servidor. Si no se recibe una conexión subsiguiente dentro del tiempo de permanencia en memoria, el registro se depura; una conexión que se recibe después de dicho tiempo tendrá un nuevo servidor seleccionado para la misma.
El mandato server down (dscontrol server down) se utiliza para poner un servidor fuera de línea. El servidor pasará a estar inactivo una vez que caduque el valor de tiempo de permanencia en memoria (stickytime).
La afinidad entre puertos sólo se aplica a los métodos de reenvío MAC y NAT/NATP del componente Dispatcher.
La afinidad entre puertos es la característica de permanencia en memoria que se ha ampliado para cubrir varios puertos. Por ejemplo, si una petición de cliente se recibe primero en un puerto y la siguiente se recibe en otro puerto, la afinidad entre puertos permite a Dispatcher enviar la petición de cliente al mismo servidor. Para utilizar esta característica, los puertos deben:
Más de un puerto puede enlazar con el mismo crossport. Cuando llegan conexiones subsiguientes del mismo cliente al mismo puerto o a un puerto compartido, se accederá al mismo servidor. A continuación se muestra un ejemplo de cómo configurar varios puertos con una afinidad entre puertos para el puerto 10:
dscontrol port set clúster:20 crossport 10 dscontrol port set clúster:30 crossport 10 dscontrol port set clúster:40 crossport 10
Una vez que se ha establecido la afinidad entre puertos, tiene la flexibilidad de modificar el valor de tiempo de permanencia en memoria para el puerto. No obstante, se recomienda cambiar los valores de tiempo de permanencia en memoria para todos los puertos compartidos por el mismo valor; de lo contrario, pueden producirse resultados inesperados.
Para eliminar la afinidad entre puertos, establezca el valor de crossport de nuevo en el número de su propio puerto. Consulte el apartado dscontrol port — configurar puertos, para obtener información detallada sobre la sintaxis de mandato para la opción crossport.
La máscara de dirección de afinidad sólo se aplica al componente Dispatcher.
La máscara de dirección de afinidad es una mejora de la característica de permanencia en memoria para agrupar clientes basándose en las direcciones de subred comunes. Si especifica stickymask en el mandato dscontrol port se podrán ocultar los bits de orden superior comunes de la dirección IP de 32 bits. Si se configura esta característica, la primera vez que una petición de cliente realiza una conexión con el puerto, todas las peticiones subsiguientes procedentes de clientes con la misma dirección de subred (representada por la parte de la dirección que está enmascarada) se dirigirán al mismo servidor.
Por ejemplo, si desea que todas las peticiones de clientes entrantes con la misma dirección de Clase A de red se dirijan al mismo servidor, establezca el valor de stickymask en 8 (bits) para el puerto. Para agrupar peticiones de clientes con la misma dirección de Clase B de red , establezca el valor de stickymask en 16 (bits). Para agrupar peticiones de clientes con la misma dirección de Clase C de red , establezca el valor de stickymask en 24 (bits).
Para obtener los mejores resultados, establezca el valor stickymask la primera vez que inicie Load Balancer. Si cambia el valor de stickymask de forma dinámica, los resultados pueden ser imprevisibles.
Interacción con afinidad entre puertos: si está habilitando la afinidad entre puertos, los valores de stickymask de los puertos compartidos deben ser los mismos. Consulte el apartado Afinidad entre puertos para obtener más información.
Para habilitar la máscara de dirección de afinidad, emita un mandato dscontrol port parecido al siguiente:
dscontrol port set cluster:port stickytime 10 stickymask 8
Los posibles valores de stickymask son 8, 16, 24 y 32. El valor 8 especifica los 8 primeros bits de orden superior de la dirección IP (dirección de Clase A de red) se ocultará. El valor 16 especifica los 16 primeros bits de orden superior de la dirección IP (dirección de Clase B de red) se ocultará. El valor 24 especifica los 24 primeros bits de orden superior de la dirección IP (dirección de Clase C de red) se ocultará. Si especifica el valor 32, está ocultando toda la dirección IP que inhabilita de hecho la característica de máscara de dirección de afinidad. El valor por omisión de stickymask es 32.
Consulte el apartado dscontrol port — configurar puertos, para obtener información detallada sobre la sintaxis de mandato para stickymask (característica de máscara de dirección de afinidad).
Desactivar temporalmente el manejo se aplica a Dispatcher y componentes CBR.
Para eliminar un servidor de la configuración de Load Balancer por cualquier razón (actualizaciones, ampliaciones, servicio, etc.), puede utilizar el mandato dscontrol manager quiesce. El submandato quiesce permite que las conexiones existentes finalicen (sin ser atendidas) y sólo remite las nuevas conexiones posteriores del cliente al servidor desactivado temporalmente si la conexión se ha designado como de permanencia en memoria y el tiempo de permanencia en memoria no ha caducado. El submandato quiesce no deja que se realicen otras conexiones nuevas al servidor.
Utilice la opción quiesce “now" si ha fijado el tiempo de permanencia en memoria y desea enviar nuevas conexiones a otro servidor (en lugar de enviarlas al servidor desactivado temporalmente) antes de que caduque el tiempo de espera. A continuación se muestra un ejemplo de utilización de la opción now para desactivar temporalmente el servidor 9.40.25.67:
dscontrol manager quiesce 9.40.25.67 now
La opción now determina cómo se manejarán las conexiones de permanencia en memoria:
Esta es la forma progresiva y menos brusca de desactivar temporalmente los servidores. Por ejemplo, puede desactivar temporalmente un servidor de forma progresiva y luego esperar el momento en el que haya la mínima cantidad de tráfico (quizás de madrugada) para eliminar completamente el servidor de la configuración.
Puede especificar los siguientes tipos de afinidad en el mandato dscontrol rule:
La afinidad de cookies activos sólo se aplica al componente CBR.
Cookie pasivo se aplica al componente CBR y al método de reenvío CBR del componente Dispatcher.
La afinidad de URL se aplica al componente CBR y al método de reenvío CBR del componente Dispatcher.
El valor predeterminado para la opción affinity es "none." La opción stickytime en el mandato port debe ser cero (no habilitado) para poder establecer la opción affinity en el mandato rule para el cookie activo, cookie pasivo o URI. Cuando se establece la función de afinidad en la norma, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
El función de afinidad de cookies activos sólo se aplica al componente CBR.
Proporciona una forma para hacer que los clientes sean “permanentes” para un servidor particular. Esta función se habilita estableciendo la opción stickytime de una norma en un número positivo y estableciendo la opción affinity en “activecookie.” Esto puede llevarse a cabo cuando se añade la norma o se utiliza el mandato rule set. Consulte el apartado dscontrol rule — configurar normas para obtener información detallada sobre la sintaxis del mandato.
Cuando se habilita una norma para la afinidad de cookies activos, se equilibra la carga de nuevas peticiones de clientes utilizando algoritmos CBR estándar, mientras que las peticiones sucesivas del mismo cliente se envían al servidor elegido al principio. El servidor elegido se almacena en forma de cookie en la respuesta al cliente. Siempre y cuando las peticiones futuras del cliente contengan el cookie y lleguen dentro del intervalo de permanencia en memoria, el cliente mantendrá afinidad con el servidor inicial.
La afinidad de cookies activos se utiliza para asegurar que un cliente siga realizando el equilibrio de carga en el mismo servidor durante un periodo de tiempo. Esto se lleva a cabo enviando un cookie para que se almacene en el navegador de los clientes. El cookie contiene los valores clúster:puerto:norma que se utilizaron para tomar una decisión, el servidor en el que se realizó el equilibrio de carga y una indicación de la hora del tiempo de espera excedido para cuando la afinidad ya no es válida. El cookie tiene el siguiente formato: IBMCBR=clúster:puerto:norma+servidor-hora! La información clúster:puerto:norma y servidor está codificada para que no muestre la configuración de CBR.
Siempre que una norma indique que tiene activada la afinidad de cookies activos, se examinará el cookie enviado por el cliente.
Este nuevo cookie se insertará en las cabecera que se devuelven al cliente, y si el navegador del cliente se configura de forma que acepte cookies, devolverá peticiones subsiguientes.
Cada instancia de afinidad del cookie tiene una longitud de 65 bytes y termina con un signo de exclamación. Como resultado, un cookie de 4096 bytes puede mantener aproximadamente 60 normas de cookies activos individuales por dominio. Si el cookie se rellena completamente, se depuran todas las instancias de afinidad caducadas. Si todas las instancias siguen siendo válidas, se elimina la más antigua y se añaden las nuevas instancias para la norma actual.
La opción affinity de cookies activos, para el mandato rule, sólo puede establecerse en activecookie si la opción port stickytime es cero (no habilitada). Una vez que la afinidad de cookies activos está activa en una norma, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
Para habilitar la afinidad de cookies activos para una norma concreta, utilice el mandato rule set:
rule set clúster:puerto:regla stickytime 60 rule set clúster:puerto:norma affinity activecookie
Hacer que una norma sea permanente en memoria normalmente se utiliza para CGI o servlets que almacenan estado de cliente en el servidor. El estado lo identifica un ID de cookie (estos son cookies de servidor). El estado del cliente sólo está en el servidor seleccionado, de modo que el cliente necesita el cookie de dicho servidor para mantener dicho estado entre peticiones.
La afinidad de cookies activos tiene una hora de caducidad del servidor actual predeterminado, más el intervalo de tiempo de permanencia en memoria, más veinticuatro horas. Si las horas de los sistemas clientes (aquellos que envían peticiones a la máquina CBR) son incorrectas (por ejemplo, van un día por delante de la hora del servidor), los sistemas de estos clientes ignorarán los cookies de CBR porque el sistema dará por supuesto que los cookies ya han caducado. Para fijar una hora de caducidad posterior, modifique el script cbrserver. En el archivo script, edite la línea javaw añadiendo el siguiente parámetro después de LB_SERVER_KEYS: -DCOOKIEEXPIREINTERVAL=X donde X es el número de días que desea añadir a la hora de caducidad.
En sistemas AIX, Solaris y Linux, el archivo cbrserver está en el directorio /usr/bin.
En sistemas Windows, el archivo cbrserver está en el directorio \winnt\system32.
La afinidad de cookies pasivos se aplica al método de reenvío de CBR (Content Based Routing) del componente Dispatcher y al componente CBR. Consulte el apartado direccionamiento basado en contenido de Dispatcher (método de reenvío cbr) para obtener información sobre cómo configurar el método de reenvío de CBR de Dispatcher.
La afinidad de cookies pasivos proporcionan una forma para que los clientes sean permanentes en memoria para un servidor concreto. Cuando habilita la afinidad de una norma para "passivecookie", la afinidad de cookies pasivos le permite equilibrar la carga del tráfico Web con afinidad al mismo servidor, basándose en cookies que se identifican a sí mismos generados por los servidores. La afinidad de cookies pasivos se configura en el nivel de normas.
Cuando se activa la norma, si la afinidad de cookies pasivos está habilitada, Load Balancer seleccionará el servidor basándose en el nombre de cookie de la cabecera HTTP de la petición del cliente. Load Balancer empieza a comparar el nombre de cookie de la cabecera HTTP del cliente con el valor de cookie configurado para cada servidor.
La primera vez que Load Balancer encuentre un servidor cuyo valor de cookie contenga el nombre de cookie del cliente, Load Balancer selecciona dicho servidor para la petición.
Si el nombre de cookie en la petición de cliente no se encuentra o no coincide con ningún contenido de los valores de cookie de los servidores, el servidor se selecciona utilizando la selección del servidor existente o la técnica de turno rotativo sopesado.
Para configurar afinidad de cookies pasivos:
La opción affinity de cookies pasivos, para el mandato rule, sólo puede establecerse en passivecookie si la opción port stickytime es cero (no habilitada). Una vez que la afinidad de cookies pasivos está activa en una norma, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
La afinidad de URI se aplica al método de reenvío CBR de Dispatcher y el componente CBR. Consulte el apartado direccionamiento basado en contenido de Dispatcher (método de reenvío cbr) para obtener información sobre cómo configurar el método de reenvío CBR.
La afinidad de URI permite equilibrar la carga del tráfico Web para servidores Caching Proxy, lo que permitirá que el contenido exclusivo se almacene en la antememoria de cada servidor individual. Como resultado, se aumentará eficazmente la capacidad de la antememoria del sitio y se eliminará el almacenamiento en antememoria redundante de contenido en varias máquinas. Configure la afinidad de URI en el nivel de normas. Una vez que la norma se activa, la afinidad de URI se habilita y el mismo conjunto de servidores están activos y responden, Load Balancer remitirá nuevas peticiones de cliente entrantes con el mismo URI al mismo servidor.
Normalmente, Load Balancer puede distribuir peticiones a varios servidores que sirven contenido idéntico. Al utilizar Load Balancer con un grupo de servidores de antememoria, llegará un momento en que el contenido al que se suele acceder habitualmente estará almacenado en la antememoria de todos los servidores. Esto da soporte a una carga muy alta de clientes duplicando en varias máquinas el contenido idéntico almacenado en antememoria. Esto es de gran utilidad para sitios Web de alto volumen.
Sin embargo, si el sitio Web da soporte a un volumen moderado de tráfico de cliente para un contenido muy diverso, y si prefiere tener una antememoria más grande a lo largo de varios servidores, el sitio tendrá un mejor rendimiento si cada servidor de antememoria incluye contenido exclusivo y Load Balancer sólo distribuye la petición al servidor de antememoria con dicho contenido.
Con la afinidad de URI, Load Balancer le permite distribuir el contenido almacenado en antememoria a servidores individuales y elimina el almacenamiento en antememoria redundante del contenido en varias máquinas. Con esta mejora aumenta el rendimiento de sitios de servidores de contenido diverso que utilizan servidores Caching Proxy. Se enviarán peticiones idénticas al mismo servidor y de esta forma sólo se almacenará en antememoria el contenido en servidores individuales. El tamaño real de la antememoria irá aumentando con cada nueva máquina servidor añadida a la agrupación.
Para configurar la afinidad de URI:
La opción de afinidad de URI, para el mandato rule, sólo puede establecerse en URI si la opción port stickytime es cero (no habilitada). Cuando la afinidad de URI está activa en una norma, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
Esta característica sólo está disponible para el componente Dispatcher.
Si no utiliza el soporte de área amplia de Dispatcher y no utiliza el método de reenvío NAT de Dispatcher, una configuración de Dispatcher requiere que la máquina Dispatcher y todos sus servidores estén conectados al mismo segmento de LAN (consulte la Figura 32). La petición de un cliente llega a la máquina Dispatcher y se envía al servidor. Desde el servidor la respuesta se envía directamente al cliente.
La característica Dispatcher de área amplia añade soporte para servidores que están en otros sitios, llamados servidores remotos (consulte la Figura 33). Si no se da soporte a GRE en el sitio remoto y no está utilizando el método de reenvío NAT de Dispatcher, el sitio remoto debe constar de una máquina Dispatcher remota (Dispatcher 2) y de sus servidores conectados localmente (ServidorG, ServidorH y ServidorI). Se transferirán los paquetes del cliente desde Internet a la máquina Dispatcher inicial. Desde la máquina Dispatcher inicial, se transferirá entonces el paquete a una máquina Dispatcher remota geográficamente y a uno de sus servidores conectados localmente.
Todas las máquinas Dispatcher (local y remota) deben estar en el mismo tipo de sistema operativo y plataforma para ejecutar configuraciones de área amplia.
Esto permite que una dirección de clúster dé soporte a todas las peticiones de cliente mundiales a la vez que distribuye la carga por servidores situados en todo el mundo.
La máquina Dispatcher que recibe inicialmente el paquete aún puede tener conectados servidores locales y puede distribuir la carga entre sus servidores locales y los servidores remotos.
Para configurar el soporte del área amplia:
dscontrol server add clúster:puerto:servidor router dirección
Si desea más información sobre la palabra clave router, consulte el apartado dscontrol server — configurar servidores.
En Dispatchers de punto de entrada:
Un Dispatcher de punto de entrada tratará el nivel segundo de Dispatcher como servidor y supervisará su estado como servidor y une los resultados a la IP actual del Dispatcher.
En sistemas Dispatcher remotos: realice los siguientes pasos de configuración para cada dirección de clúster remoto. Para una configuración de alta disponibilidad en la ubicación del sistema Dispatcher remoto, debe llevar a cabo estos pasos en las dos máquinas.
Sistemas AIX
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
Sistemas HP-UX, Linux, Solaris y Windows
Este ejemplo se aplica a la configuración que se muestra en la Figura 34.
Aquí se muestra cómo configurar las máquinas Dispatcher para dar soporte a la dirección de clúster xebec en el puerto 80. LB1 se define como Load Balancer de "punto de entrada". Se da por supuesto una conexión Ethernet. Tenga en cuenta que LB1 tiene definidos cinco servidores: tres locales (ServidorA, ServidorB, ServidorC) y dos remotos (LB2 y LB3). Cada uno de los servidores LB2 y LB3 remotos tiene definido tres servidores locales.
En la consola de la primera máquina Dispatcher (LB1):
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
En la consola de la segunda máquina Dispatcher (LB2):
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
En la consola de la tercera máquina Dispatcher (LB3):
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
El encapsulamiento genérico de direccionamiento (GRE) es un Internet Protocolo especificado en RFC 1701 y RFC 1702. Si utiliza GRE, Load Balancer puede encapsular paquetes IP del cliente dentro de paquetes IP/GRE y remitirlos a plataformas de servidor como OS/390 que dan soporte a GRE. El soporte de GRE permite al componente Dispatcher equilibrar la carga de paquetes en varias direcciones de servidores asociadas a una dirección MAC.
Load Balancer implementa GRE como parte de su característica WAN. Esto permite que Load Balancer proporcione equilibrio de carga de área local directamente a todos los sistemas de servidor que puedan abrir los paquetes GRE. No es necesario que Load Balancer esté instado en el sitio remoto, si los servidores remotos dan soporte a paquetes GRE encapsulados. Load Balancer encapsula paquetes WAN con el campo clave GRE establecido en un valor decimal 3735928559.
En este ejemplo (Figura 35), para añadir el ServidorD remoto, que da soporte a GRE, defínalo dentro de la configuración de Load Balancer como si estuviera definiendo un servidor de WAN en la jerarquía clúster:puerto:servidor:
dscontrol server add clúster:puerto:ServidorD router Direccionador1
Los sistemas Linux tienen la capacidad nativa para excapsular GRE que permite a Load Balancer equilibrar la carga en las imágenes del servidor Linux para s/390, donde muchas imágenes de servidor comparten una dirección MAC. Esto permite que Load Balancer de punto de entrada equilibre la carga directamente en servidores WAN de Linux WAN, sin pasar a través de un sistema Load Balancer en el sitio remoto. También permite que los asesores del sistema Load Balancer de punto de entrada operen directamente con cada servidor remoto.
En el sistema Load Balancer de punto de entrada, configúrelo para WAN tal como se describe.
Para configurar cada servidor del programa de fondo Linux, emita los siguientes mandatos como usuario root. (Estos mandatos se pueden añadir al recurso de inicio del sistema para que los cambios se mantengan en los rearranques).
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add dirección_clúster dev gre-nd
En general, las funciones de equilibrio de carga de Dispatcher funcionan independientemente del contenido de los sitios en los que se utiliza el producto. Sin embargo, hay un ámbito donde el contenido de sitio puede ser importante y donde las decisiones tomadas respecto al contenido pueden tener un impacto significativo en la eficacia de Dispatcher. Se trata del área de direccionamiento de enlaces.
Si las páginas especifican enlaces que apuntan a servidores individuales del sitio, en realidad está forzando a un cliente a que vaya a una máquina específica y, por lo tanto, omitirá cualquier función de equilibrio de carga que podría estar aplicándose. Por esta razón, utilice siempre la dirección de Dispatcher en todos los enlaces contenidos en las páginas. Tenga en cuenta que es posible que el tipo de direccionamiento utilizado no sea siempre evidente, si el sitio utiliza programación automatizada que crea código HTML de forma dinámica. Para maximizar el equilibrio de carga, debe conocer bien todo el direccionamiento explícito y evitarlo cuando sea posible.
Puede configurar las máquinas Dispatcher y del servidor TCP utilizando una red privada. Esta configuración puede reducir el conflicto sobre la red pública o externa que puede afectar al rendimiento.
Para sistemas AIX, esta configuración también puede aprovechar las rápidas velocidades del Conmutador de alto rendimiento de SP si ejecuta Dispatcher y las máquinas de servidor TCP en nodos de una Trama SP.
Para crear una red privada, cada máquina debe tener cómo mínimo dos tarjetas de LAN y una de las tarjetas está conectada a la red privada. También debe configurar la segunda tarjeta de LAN en una subred distinta. La máquina Dispatcher enviará las solicitudes de cliente a las máquinas servidor TCP a través de la red privada.
Sistemas Windows: configure la dirección de no reenvío con el mandato executor configure.
Los servidores añadidos utilizando el mandato dscontrol server add se deben añadir utilizando las direcciones de red privadas; por ejemplo, en ejemplo de servidor de Apple de la Figura 36, se debe escribir el mandato del modo siguiente:
dscontrol server add dirección_clúster:80:10.0.0.1
no
dscontrol server add dirección_clúster:80:9.67.131.18
Si utiliza Selector de sitio para proporcionar información de carga en Dispatcher, debe configurar Selector de sitio de modo que notifique las cargas en las direcciones privadas.
La utilización de la configuración de red privada sólo se aplica al componente Dispatcher.
La utilización de clúster comodín para combinar configuraciones de servidor sólo se aplica al componente Dispatcher.
La palabra “comodín” hace referencia a la capacidad del clúster para emparejar varias direcciones IP (es decir, actúa como un comodín). La dirección del clúster 0.0.0.0 se utiliza para especificar un clúster comodín.
Si tiene muchas direcciones de clúster en las que se debe equilibrar la carga y las configuraciones de puerto/servidor son idénticas en todos los clústeres, puede combinar todos los clústeres en una configuración de clúster comodín.
Deberá configurar de forma explícita cada dirección de clúster en uno de los adaptadores de la red de la estación de trabajo de Dispatcher. Sin embargo, no debe añadir ninguna de las direcciones de clúster a la configuración de Dispatcher utilizando el mandato dscontrol cluster add.
Únicamente añada un clúster comodín (dirección =.0.0.0) y configure los puertos y servidores como se requiere para el equilibrio de carga. Se equilibra la carga de todo el tráfico que se dirija a cualquiera de las direcciones configuradas del adaptador utilizando la configuración del clúster comodín.
Una ventaja de este método es que, al determinar cuál es el mejor servidor al que dirigirse, se toma en cuenta el tráfico dirigido a todas las direcciones del clúster. Si un clúster recibe mucho tráfico y ha creado muchas conexiones activas en uno de los servidores, con esta información se equilibra la carga del tráfico que se dirige a otras direcciones del clúster.
Si tiene algunas direcciones de clúster con configuraciones de puerto/servidor exclusivas y algunas con configuraciones comunes, puede combinar el clúster comodín con clústeres reales. Se debe asignar cada una de las configuraciones exclusivas a una dirección de clúster real. Todas las configuraciones comunes pueden asignarse al clúster comodín.
La utilización de clúster comodín para equilibrar la carga de cortafuegos sólo se aplica al componente Dispatcher. La dirección del clúster 0.0.0.0 se utiliza para especificar un clúster comodín.
El clúster comodín puede utilizarse para equilibrar la carga del tráfico en direcciones que no están configuradas de forma explícita en ningún adaptador de red de la estación de trabajo de Dispatcher. Para que esto funcione, Dispatcher como mínimo debe poder ver todo el tráfico en el que se va a equilibrar la carga. La estación de trabajo de Dispatcher no verá el tráfico que se dirige a las direcciones que no se han configurado de forma explícita en uno de sus adaptadores de red, a menos que se configure como la ruta predeterminada para algún conjunto de tráfico.
Después de configurar Dispatcher como una ruta por omisión, la carga de todo el tráfico TCP o UDP que pase por la máquina Dispatcher se equilibra utilizando la configuración de clúster comodín.
Esto se aplica pare equilibrar la carga de cortafuegos. Puesto que los cortafuegos pueden procesar paquetes para cualquier dirección de destino y cualquier puerto de destino, es necesario poder equilibrar la carga del tráfico independientemente de la dirección y el puerto de destino.
Los cortafuegos se utilizan para manejar el tráfico de clientes no seguros a servidores seguros, y las respuestas de los servidores seguros, así como el tráfico de clientes que están en el lado seguro a servidores que están en el lado no seguro y las respuestas.
Debe configurar dos máquinas Dispatcher, una para equilibrar la carga del tráfico no seguro dirigido a las direcciones de cortafuegos no seguro y otra para equilibrar la carga del tráfico seguro dirigido a las direcciones del cortafuegos seguro. Puesto que los dos sistemas Dispatcher deben utilizar el clúster comodín y el puerto comodín con distintos conjuntos de direcciones de servidores, los dos sistemas Dispatcher deben estar en dos estaciones de trabajo separadas.
La utilización del clúster comodín con Proxy de memoria caché para el proxy transparente sólo se aplica al componente Dispatcher. La dirección del clúster 0.0.0.0 se utiliza para especificar un clúster comodín.
La función de clúster comodín también permite que Dispatcher se utilice para habilitar una función de proxy transparente para un servidor Proxy de memoria caché que resida en la misma máquina que Dispatcher. Esta característica sólo es de AIX, porque debe haber comunicación entre el componente Dispatcher y el componente TCP del sistema operativo.
Para habilitar esta característica, debe iniciar Proxy de memoria caché escuchando peticiones de cliente en el puerto 80. A continuación, configure un clúster comodín (0.0.0.0). En el clúster comodín, configure el puerto 80. En el puerto 80, configure la NFA de la máquina Dispatcher como el único servidor. Ahora, todo el tráfico de cliente dirigido a cualquier dirección del puerto 80 se entrega al servidor Proxy de memoria caché que se ejecuta en la estación de trabajo de Dispatcher. La petición de cliente se dirigirán a través del proxy de la forma habitual y la respuesta se devuelve de Proxy de memoria caché al cliente. En esta modalidad, el componente Dispatcher no realiza ningún equilibrio de carga.
Se puede utilizar un puerto comodín puede manejar el tráfico que no está destinado a ningún puerto configurado de forma explícita. Un uso de lo anterior es para el equilibrio de carga de cortafuegos. Un segundo uso es para asegurar que el tráfico destinado a un puerto no configurado se maneja de forma adecuada. Mediante la definición de un puerto comodín sin servidores, garantizará que se descarte cualquier solicitud destinada a un puerto que no se haya configurado en lugar de devolverse al sistema operativo. El número de puerto 0 (cero) se utiliza para especificar el puerto comodín, por ejemplo:
dscontrol port add clúster:0
Cuando se configura un clúster para manejar el FTP pasivo y el puerto comodín, el FTP pasivo predeterminado utiliza el rango completo de puertos TCP sin privilegios para las conexiones de datos. Esto significa que un cliente, con una conexión existente a través de un clúster de equilibrio de carga con un puerto de control FTP, tendrá las conexiones de control subsiguientes y las conexiones de puertos altos (puerto >1023) con el mismo clúster direccionadas automáticamente por Load Balancer al mismo servidor que el de la conexión de control FTP.
Si el puerto comodín y el puerto FTP del mismo clúster no tienen establecido el mismo servidor, es posible que las aplicaciones de puertos altos (puerto >1023) fallen cuando un cliente tenga una conexión de control FTP existente. Por lo tanto, no se recomienda configurar distintos conjuntos de servidores para los puertos FTP y comodín en el mismo clúster. Si se desea este escenario, se debe configurar el rango de puertos pasivos del daemon de FTP en la configuración de Load Balancer.
Esta característica sólo está disponible para el componente Dispatcher.
Dispatcher proporciona la capacidad de detectar ataques para "rechazo de servicio" (DoS) potenciales y notifica a los administradores mediante una alerta. Dispatcher lo lleva a cabo analizando las solicitudes entrantes para una cantidad llamativa de conexiones TCP medio abiertas en servidores, un rasgo común de los ataques simples para rechazo de servicio (DoS). En un ataque para rechazo de servicio (DoS), un sitio recibe una gran cantidad de paquetes SYN fabricados procedentes de un gran número de direcciones IP de origen y números de puerto de origen, pero el sitio no recibe paquetes posteriores para estas conexiones TCP. Esto resulta en un gran número de conexiones TCP medio abiertas en los servidores y, con el tiempo, los servidores pueden funcionar muy lentamente y no aceptar nuevas conexiones entrantes.
Load Balancer proporciona salidas de usuario que desencadenan scripts que se pueden personalizar y que avisan al administrador de un posible ataque de rechazo de servicio. Dispatcher proporciona archivos script de ejemplo en el directorio siguiente:
Están disponibles los siguientes scripts:
Para ejecutar los archivos, debe ponerlos en el directorio siguiente y eliminar la extensión de archivo ".sample":
Para implementar la detección del ataque DoS, establezca el parámetro maxhalfopen en el mandato dscontrol port tal como se indica a continuación:
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
En el ejemplo anterior, Dispatcher comparará el número total actual de conexiones medio abiertas (para todos los servidores que residen en el clúster 127.40.56.1 en el puerto 80) con el valor de umbral 1000 (especificado por el parámetro maxhalfopen). Si el número de conexiones medio abiertas actuales excede el umbral, se realiza una llamada al script de alerta (halfOpenAlert). Cuando el número de conexiones medio abiertas es inferior al umbral, se realiza una llamada a otro script de alerta (halfOpenAlertDone) para indicar que el ataque ha terminado.
Para determinar cómo establecer el valor maxhalfopen: ejecute periódicamente (quizás cada 10 minutos) un informe de conexiones medio abiertas (dscontrol port halfopenaddressreport clúster:puerto) cuando la cantidad de tráfico del sitio oscile de normal a elevada. El informe de conexiones medio abiertas devolverá el "total de conexiones medio abiertas recibidas" actuales. Debe establecer maxhalfopen en un valor entre un 50 y un 200% mayor que el número más alto de conexiones medio abiertas que se producen en el sitio.
Además de los datos estadísticos reportados, halfopenaddressreport también genera entradas en las anotaciones cronológicas (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) para todas las direcciones de cliente (hasta aproximadamente 8000 pares de direcciones) que han accedido a servidores que han resultado en conexiones medio abiertas.
Para proporcionar protección adicional de los ataques para rechazo de servicio (DoS) para servidores de programas de fondo, puede configurar puertos y clústeres comodín. En concreto, añada un puerto comodín sin servidores bajo cada clúster configurado. Añada también un clúster comodín con un puerto comodín y sin servidores. Esto provocará que se descarten todos los paquetes que no se dirijan a un clúster y puerto que no sea comodín. Para obtener información sobre los clústeres comodín y los puertos comodín, consulte Utilizar un clúster comodín para combinar configuraciones de servidor y Utilizar puerto comodín para dirigir tráfico de puerto no configurado.
La característica de registro cronológico en binario permite que la información de servidor se almacene en archivos binarios. Estos archivos pueden procesarse para analizar la información de servidor que se ha recopilado con el tiempo.
La siguiente información se ha almacenado en las anotaciones cronológicas en binario para cada servidor definido en la configuración.
Parte de esta información se recupera del ejecutor como parte del ciclo del gestor. Por lo tanto, para que la información se pueda anotar cronológicamente en las anotaciones cronológicas en binario, el gestor debe estar en ejecución.
Utilice el mandato dscontrol binlog establecido para configurar el registro cronológico en binario.
La opción start inicia el registro cronológico de la información de servidor en anotaciones cronológicas en binario en el directorio logs. Al inicio de cada hora se crea un archivo con la fecha y la hora como el nombre del archivo.
La opción stop detiene el registro cronológico de la información de servidor en las anotaciones cronológicas en binario. De manera predeterminada, el servicio de anotaciones cronológicas está detenido.
La opción set interval controla la frecuencia con la que información se escribe en las anotaciones cronológicas. Cada intervalo del gestor, éste enviará información de servidor al servidor de anotaciones cronológicas. La información se graba en las anotaciones cronológicas sólo cuando hayan transcurrido los segundos especificados en el intervalo de anotaciones cronológicas después de anotarse el último registro en las anotaciones cronológicas. De manera predeterminada, el intervalo de anotaciones cronológicas se establece en 60 segundos. Los valores del intervalo del gestor y del intervalo de anotaciones cronológicas están relacionados. Puesto que al servidor de anotaciones cronológicas se le proporciona información cómo máximo a la velocidad indicada por los segundos del intervalo del gestor, si se establece el intervalo de anotaciones cronológicas en un valor inferior al valor del intervalo del gestor en realidad se establece en el mismo valor que el intervalo del gestor. Esta técnica de registro cronológico permite captar información de servidor en cualquier granularidad. Puede captar todos los cambios realizados en la información del servidor detectados por el gestor para calcular pesos de servidor. No obstante, esta cantidad de información probablemente no es necesaria para analizar tendencias y utilización del servidor. Si se registra información del servidor cada 60 segundos, con el tiempo dispondrá de instantáneas de información del servidor. Si establece el intervalo de anotaciones cronológicas muy bajo puede generar enormes cantidades de datos.
La opción set retention controla cuánto tiempo se mantienen los archivos. El servidor de anotaciones cronológicas elimina los archivos de anotaciones cronológicas anteriores a las horas de retención especificadas. Esto sólo sucederá si el gestor está llamando al servidor de anotaciones cronológicas, por lo tanto, si detiene el gestor no se suprimirán los archivos de anotaciones cronológicas antiguos.
La opción de estado devuelve los valores actuales del servicio de anotaciones cronológicas. Estos valores indican si el servicio se ha iniciado, el intervalo y las horas de retención.
Se proporciona un programa y un archivo de mandatos Java en el directorio siguiente:
Este ejemplo muestra cómo recuperar toda la información de los archivos de anotaciones cronológicas e imprimirla en la pantalla. Puede personalizar realizar cualquier tipo de análisis que desea con los datos. Un ejemplo de la utilización del script proporcionado y el programa para Dispatcher sería:
dslogreport 2001/05/01 8:00 2001/05/01 17:00
para obtener un informe con la información de servidor del componente Dispatcher para el día 1 de mayo de 2001, de las 8:00 a las 17:00. (Para CBR, utilice cbrlogreport).
Sólo los sistemas Linux dan soporte a configuraciones en las que el cliente se encuentra en la misma máquina que Load Balancer.
Las configuraciones de cliente con ubicación compartida pueden no funcionar correctamente en otras plataformas porque Load Balancer utiliza distintas técnicas para examinar los paquetes de entrada en los diversos sistemas operativos a los que da soporte. En la mayoría de los casos, en sistemas que no sean Linux, Load Balancer no recibe paquetes que proceden de la máquina local. Sólo recibe paquetes que proceden de la red. Debido a ello, Load Balancer no recibirá las solicitudes realizadas desde la máquina local a la dirección de clúster y no podrá atenderlas