Características avanzadas para Dispatcher, CBR y Site Selector

Este capítulo explica cómo configurar los parámetros de equilibrio de carga y cómo configurar Load Balancer para funciones avanzadas.

Nota:
Al leer este capítulo, si no está utilizando el componente Dispatcher, sustituya "dscontrol" por lo siguiente:
Tabla 11. Tareas de configuración avanzadas para Load Balancer
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

Utilización de servidores 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.

Nota:
Un servidor con ubicación compartida compite por los recursos contra Load Balancer durante los periodos de mucho tráfico. Sin embargo, si no hay máquinas sobrecargadas, si se utiliza un servidor con ubicación compartida se reducirá el número total de máquinas necesarias para definir un sitio con equilibrio de carga.

Para el componente Dispatcher

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.

Configuración de la ubicación compartida del servidor con el reenvío NAT de Dispatcher

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:

Para el componente CBR

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.

Para el componente Site Selector

Site Selector da soporte a la ubicación compartida en plataformas AIX, HP-UX, Linux y Solaris sin que sea necesario realizar configuraciones adicionales.

Alta disponibilidad

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:

Nota:
Si desea obtener una ilustración y una descripción de una configuración de alta disponibilidad mutua , donde dos máquinas Dispatcher que comparten dos conjuntos de clústeres actúan como máquina de reserva entre sí, consulte el apartadoAlta disponibilidad mutua. La alta disponibilidad mutua es parecida a la alta disponibilidad aunque se basa específicamente en la dirección de clúster en lugar de basarse en una máquina Dispatcher como un todo. Las dos máquinas deben configurar de la misma forma sus conjuntos de clúster compartidos.

Configurar la alta disponibilidad

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.

  1. Cree archivos script de alias en cada una de las dos máquinas Dispatcher. Consulte Utilización de scripts.
  2. Inicie el servidor en las dos máquinas servidor Dispatcher.
  3. Inicie el ejecutor en las dos máquinas.
  4. Asegurarse de que la dirección de no reenvío (NFA) de cada máquina Dispatcher está configurada y que es una dirección IP válida para la subred de las máquinas Dispatcher.
  5. Añada la información de pulsos en las dos máquinas:
    dscontrol highavailability heartbeat add dirección_origen dirección_destino
    Nota:
    dirección_origen y dirección_destino son las direcciones IP (los nombres DNS o las direcciones IP) de las máquinas Dispatcher. Los valores se invertirán en cada máquina. Por ejemplo:
    Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8
    Backup  - highavailability heartbeat add 9.67.186.8 9.67.111.3
    Como 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.

  6. En las dos máquinas, configure la lista de direcciones IP que Dispatcher debe poder alcanzar para garantizar un servicio completo, utilizando el mandato reach add. Por ejemplo:
    dscontrol highavailability reach add 9.67.125.18
    Los 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.
  7. Añada la información de reserva en cada máquina:
    Nota:
    Seleccione un puerto no utilizado en las máquinas como puerto. El número de puerto entrado se utilizará como clave para asegurarse de que el paquete lo recibe el host correcto.
  8. Compruebe el estado de alta disponibilidad en cada máquina:
    dscontrol highavailability status
    Cada 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.
  9. Establezca la información de clúster, puerto y servidor en las dos máquinas.
    Nota:
    Para la configuración de alta disponibilidad mutua (Figura 14), por ejemplo, configure los conjuntos del clúster compartidos entre los dos sistema Dispatcher tal como se indica a continuación:
    • Para Dispatcher 1, emita:
      dscontrol cluster set clústerA primaryhost NFAdispatcher1
      dscontrol cluster set clústerB primaryhost NFAdispatcher2
    • Para Dispatcher 2, emita:
      dscontrol cluster set clústerB primaryhost NFAdispatcher2
      dscontrol cluster set clústerA primaryhost NFAdispatcher1
  10. Inicie el gestor y los asesores en las dos máquinas.
Notas:
  1. Para configurar una sola máquina Dispatcher para direccionar paquetes sin una máquina de reserva, no emita ninguno de los mandatos de alta disponibilidad durante el arranque.
  2. Para convertir dos máquinas Dispatcher configuradas para alta disponibilidad en una sola máquina, detenga el ejecutor en una de las máquinas y suprima las características de alta disponibilidad (los pulsos, alcance y reserva) de la otra.
  3. En los dos casos anteriores, debe utilizar direcciones de clúster para crear un alias para la tarjeta de interfaz de red, según sea necesario.
  4. Cuando dos máquinas Dispatcher se ejecutan en configuración de alta disponibilidad y están sincronizadas, entre todos los mandatos dscontrol (para actualizar la configuración) primero en la máquina en espera y, a continuación, en la máquina activa.
  5. Cuando se ejecutan dos máquinas Dispatcher en una configuración de alta disponibilidad, pueden producirse resultados inesperados si en las dos máquinas se establecen distintos valores en alguno de los parámetros para el ejecutor, puerto o servidor (por ejemplo, port stickytime).
  6. Para la alta disponibilidad mutua, considere el caso en que uno de las máquinas Dispatcher debe direccionar de forma activa paquetes para su clúster primario así como tomar el control del direccionamiento de paquetes para el clúster de reserva. Asegúrese que esto no exceda la capacidad de la producción en esta máquina.
  7. Para sistemas Linux, al configurar la alta disponibilidad y la ubicación compartida juntas cuando se utiliza el método de reenvío de puerto MAC del componente Dispatcher, consulte Alternativas de alias de bucle de retorno de Linux cuando se utiliza el reenvío MAC de Load Balancer.
  8. Si desea sugerencias que le ayuden a reducir los problemas que pueden surgir derivados de los problemas de configuración de alta disponibilidad, como por ejemplo: Consulte Problema: sugerencias para configurar la alta disponibilidad.

Capacidad de detección de anomalías utilizando pulsos y destino de alcance

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.

Nota:
Al configurar el destino de alcance, también debe iniciarse el asesor de alcance. El asesor de alcance se inicia automáticamente al iniciar la función de gestor. Para obtener más información sobre el asesor de alcance, consulte la página ***.

Estrategia de recuperación

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:

Automática
La máquina primaria reanuda el direccionamiento de paquetes tan pronto vuelve a estar en funcionamiento.
Manual
La máquina de reserva sigue direccionando paquetes incluso después de que la primaria pase a estar en funcionamiento. Para devolver la máquina primaria al estado activo y restablecer la máquina de reserva al estado en espera es necesario realizar una intervención manual.

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.

Nota:
Durante las situaciones de toma de control, es posible que se pierdan algunas actualizaciones de conexiones. Esto puede causar que se terminen conexiones de larga ejecución existentes (como Telnet) a las que se está accediendo cuando se lleva a cabo la toma de control.

Utilización de scripts

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.

Notas:
  1. Para una configuración de alta disponibilidad mutua, Dispatcher invoca cada script “go" con un parámetro que identifique la dirección del Dispatcher primario. El script debe consultar este parámetro y ejecutar los mandatos executor configure para dichas direcciones de clúster asociadas a dicho Dispatcher primario.
  2. Para configurar la alta disponibilidad para el método de reenvío NAT de Dispatcher, debe añadir a los archivos de script las direcciones de retorno.

Se pueden utilizar los siguientes scripts de ejemplo:

goActive
El script goActive se ejecuta cuando un Dispatcher pasa a estado activo y empieza el direccionamiento de paquetes.
goStandby
El script goStandby se ejecuta cuando Dispatcher pasa al estado en espera y supervisa el estado de la máquina activa, pero sin direccionar ningún paquete.
goInOp
El script goInOp se ejecuta cuando se detiene un ejecutor de Dispatcher.
goIdle
El script goIdle se ejecuta cuando un Dispatcher pasa a estado desocupado y empieza el direccionamiento de paquetes. Esto ocurre cuando no se han añadido las características de alta disponibilidad, como en una configuración autónoma. También sucede en una configuración de alta disponibilidad antes de añadir las características de alta disponibilidad o después de eliminarlas.
highavailChange
El script highavailChange se ejecuta siempre que cambia el estado de alta disponibilidad dentro de Dispatcher, como ocurre cuando se llama a los scripts "go". El parámetro único pasado a este script es el nombre del script "go" que acaba de ejecutar Dispatcher. Cree este script para utilizar información de cambio de estado, por ejemplo, para avisar a un administrador o para anotar el suceso.

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.

Configuración de equilibrio de carga basado en normas

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.

¿Cómo se evalúan 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:

  1. El predicado de la regla debe ser true. Es decir, el valor que está evaluando debe estar entre los rangos de inicio y fin, o el contenido debe coincidir con la expresión regular especificada en el patrón de la norma de contenido. Para las normas de tipo “true," el predicado siempre se satisface, independientemente de los rangos de inicio y fin.
  2. Si hay servidores asociados a esta norma, como mínimo debe haber uno con un peso mayor que 0 al que reenviar paquetes.

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.

Utilización de normas basadas en la dirección IP de cliente

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.

Utilización de normas basadas en el puerto de cliente

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.

Utilización de normas basadas en la hora del día

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.

Utilización de normas basadas en el tipo de servicio (TOS)

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

Utilización de normas basadas en las conexiones por segundo

Este tipo de norma está disponible en los componentes Dispatcher y CBR.

Nota:
El gestor debe estar en ejecución para que lo siguiente funcione.

Utilice reglas basadas en conexiones por segundo si necesita compartir algunos de los servidores con otras aplicaciones. Por ejemplo, puede establecer dos normas:

  1. Si el número de conexiones por segundo en el puerto 80 oscila entre 0 y 2000, utilice estos 2 servidores
  2. Si el número de conexiones por segundo en el puerto 80 es superior a 2000, utilice estos 10 servidores

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.

Utilización de normas basadas en el total de conexiones activas

Este tipo de norma está disponible en el componente Dispatcher o CBR.

Nota:
El gestor debe estar en ejecución para que lo siguiente funcione.

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.

Utilización de normas basadas en ancho de banda reservado y ancho de banda compartido

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.

Norma de ancho de banda reservado

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.

Norma de ancho de banda compartido

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.

Utilización de normas de ancho de banda reservado y 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.

Nota:
Dispatcher realiza un seguimiento del ancho de banda midiendo el tráfico del cliente, como "acks" de datos, que circulan hacia un servidor. Si por alguna razón Dispatcher no detecta este tráfico, al utilizar las normas de ancho de banda los resultados son imprevisibles.

Norma de toda la métrica

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.

Nota:
El script de métrica de sistema elegido debe estar en cada uno de los servidores con equilibrio de carga.

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

Norma de media de la métrica

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.

Nota:
El script de métrica de sistema elegido debe estar en cada uno de los servidores con equilibrio de carga.

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

Utilización de normas que son siempre ciertas

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.

Nota:
Al crear una norma siempre cierta no es necesario establecer un inicio de rango ni un final de rango.

Puede definir más de una norma “siempre cierta” y, a partir de ahí, ajustar cuál se ejecuta cambiando los niveles de prioridad.

Utilización de normas basadas en el contenido de peticiones

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).

Alteración temporal de la afinidad entre puertos

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 .

Adición de normas a la configuración

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

Opción de evaluación del servidor para normas

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).

Notas:
  1. La opción de evaluación del servidor sólo es válida para las normas que toman las decisiones basándose en las características de los servidores: norma de total de conexiones (por segundo), norma de conexiones activas y norma de ancho de banda reservado.
  2. La norma de tipo "conexión" tiene una opción de evaluación adicional que puede elegir, upserversonrule. Consulte el apartado Utilización de normas basadas en las conexiones por segundo para obtener más información.

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.

Evaluar servidores a los que se aplica la norma

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.

Evaluar servidores en el puerto

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.

Cómo funciona la característica de afinidad para Load Balancer

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.

Comportamiento cuando la afinidad está inhabilitada

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.

Comportamiento cuando la afinidad está habilitada

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).

Afinidad entre puertos

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.

Máscara de dirección de afinidad (stickymask)

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.

Nota:
Para poder habilitar skickymask, el valor stickytime debe ser un valor no cero.

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 de conexiones de servidor

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.

Desactivar temporalmente el manejo de conexiones de permanencia en memoria

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:

Opción de afinidad de la norma basada en el contenido de la petición de cliente

Puede especificar los siguientes tipos de afinidad en el mandato dscontrol rule:

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.

Afinidad de cookies activos

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.

Cómo funciona la afinidad de cookies activos

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.

Nota:
CBR sustituirá todas las apariciones de los cookies de IBMCBR con el formato antiguo a medida que aparezcan en el proxy.

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.

Cómo habilitar la afinidad de cookies activos

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

Por qué se utiliza la afinidad de cookies activos

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.

Alteración temporal de la hora de caducidad de la afinidad de cookies activos

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.

Afinidad de cookies pasivos

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.

Nota:
Load Balancer proporciona esta flexibilidad para manejar casos en los que el servidor podría generar un valor de cookie al que se ha añadido una parte estática a una parte variable. Por ejemplo, el valor de cookie del servidor podría ser el nombre de servidor (un valor estático) al que se ha añadido una indicación de la hora (un valor variable).

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.

Afinidad de URI

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:

Configurar soporte de Dispatcher de área amplia

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.

Figura 32. Ejemplo de una configuración que consta de un único segmento LAN
Único segmento LAN

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.

Figura 33. Ejemplo de configuración mediante servidores locales y remotos
Servidores locales y remotos

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.

Sintaxis de mandatos

Para configurar el soporte del área amplia:

  1. Añada los servidores. Al añadir un servidor a un sistema Dispatcher, debe definir si el servidor es local o remoto (vea arriba). Para añadir un servidor y definirlo como local, emita el mandato dscontrol server add sin especificar un direccionador. Es el valor predeterminado. Para definir el servidor como remoto, debe especificar el direccionador a través del que Dispatcher debe enviar el paquete para llegar al servidor remoto. El servidor debe ser otro sistema Dispatcher y la dirección del servidor debe ser una dirección de no reenvío del sistema Dispatcher. Por ejemplo, en la Figura 34, si añade LB 2 como servidor remoto bajo LB 1, debe definir direccionador 1 como la dirección del direccionador. Sintaxis general:
    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.

  2. Configure los alias. En la primera máquina Dispatcher (donde llega la petición de cliente desde Internet), debe crearse un alias de la dirección de clúster con el mandato executor configure. (En sistemas Linux o UNIX, puede utilizar el mandato executor configure o ifconfig). Sin embargo, en las máquinas Dispatcher remotas la dirección del clúster no tienen ningún alias asociado a la tarjeta de interfaz de red.

Utilización de asesores remotos con el soporte de área amplia de Dispatcher

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

Sistemas HP-UX, Linux, Solaris y Windows

Ejemplo de configuración

Figura 34. Configuración del ejemplo de área amplia con varios Load Balancer remotos
Configuración de área amplia con varios Load Balancer remotos

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):

  1. Inicia el ejecutor.

    dscontrol executor start

  2. Establezca la dirección de no reenvío de la máquina Dispatcher.

    dscontrol executor set nfa LB1

  3. Defina el clúster.

    dscontrol cluster add xebec

  4. Defina el puerto.

    dscontrol port add xebec:80

  5. Defina los servidores.
    1. dscontrol server add xebec:80:ServidorA
    2. dscontrol server add xebec:80:ServidorB
    3. dscontrol server add xebec:80:ServidorC
    4. dscontrol server add xebec:80:LB2 router Direccionador1
    5. dscontrol server add xebec:80:LB3 router Direccionador1
  6. Configure la dirección de clúster.

    dscontrol executor configure xebec

En la consola de la segunda máquina Dispatcher (LB2):

  1. Inicia el ejecutor.

    dscontrol executor start

  2. Establezca la dirección de no reenvío de la máquina Dispatcher.

    dscontrol executor set nfa LB2

  3. Defina el clúster.

    dscontrol cluster add xebec

  4. Defina el puerto.

    dscontrol port add xebec:80

  5. Defina los servidores.
    1. dscontrol server add xebec:80:ServidorD
    2. dscontrol server add xebec:80:ServidorE
    3. dscontrol server add xebec:80:ServidorF

En la consola de la tercera máquina Dispatcher (LB3):

  1. Inicia el ejecutor.

    dscontrol executor start

  2. Establezca la dirección de no reenvío de la máquina Dispatcher.

    dscontrol executor set nfa LB3

  3. Defina el clúster.

    dscontrol cluster add xebec

  4. Defina el puerto.

    dscontrol port add xebec:80

  5. Defina los servidores.
    1. dscontrol server add xebec:80:ServidorG
    2. dscontrol server add xebec:80:ServidorH
    3. dscontrol server add xebec:80:ServidorI

Notas

  1. En todos los servidores (A-I), cree el alias de la dirección de clúster con el bucle de retorno.
  2. Los clústeres y los puertos se añaden con dscontrol a todas las máquinas Dispatcher implicadas: el sistema Dispatcher de punto de entrada y todas las máquinas remotas.
  3. Consulte el apartado Utilización de asesores remotos con el soporte de área amplia de Dispatcher para obtener ayuda sobre cómo utilizar asesores remotos con soporte de área amplia.
  4. El soporte de área amplia no permite utilizar bucles de direccionamiento infinito. (Si una máquina Dispatcher recibe un paquete desde otra máquina Dispatcher, no se reenviará a una tercera máquina Dispatcher). El área amplia sólo da soporte a un nivel de sistemas remotos.
  5. El área amplia da soporte a UDP y a TCP.
  6. El área amplia funciona junto con alta disponibilidad: se puede hacer una copia de seguridad de cada sistema Dispatcher en una máquina en espera adyacente (en el mismo segmento LAN).
  7. El gestor y los asesores funcionan con red de área amplia y, si se utiliza, debe iniciarse en todas las máquinas Dispatcher implicadas.
  8. Load Balancer da soporte a WAN sólo en sistemas operativos iguales.

Soporte de GRE (Encapsulamiento genérico de direccionamiento)

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.

Figura 35. Configuración del ejemplo de área amplia con una plataforma de servidor que da soporte a GRE
Configuración de área amplia con una plataforma de servidor que da soporte a GRE

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

En sistemas Linux, configuración del excapsulamiento de GRE para WAN

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
Nota:
El servidor Linux configurado utilizando estas instrucciones no puede estar en el mismo elemento físico que el sistema Load Balancer de punto de entrada. Esto se debe a que el servidor Linux responderá a las peticiones "ARP who-has" para la dirección del clúster, lo que provocará que un estado de competición que llevará a un posible "corto circuito" en el que todo el tráfico de la dirección del clúster sólo se dirige al ganador de la competición ARP.

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.

Utilización de una configuración de red privada

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.

Figura 36. Ejemplo de una red privada que utiliza Dispatcher
Red privada

La utilización de la configuración de red privada sólo se aplica al componente Dispatcher.

Utilizar un clúster comodín para combinar configuraciones de servidor

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.

Utilizar un clúster comodín para equilibrar la carga de cortafuegos

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.

Utilizar un clúster comodín con Proxy de memoria caché para el proxy transparente

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.

Utilizar puerto comodín para dirigir tráfico de puerto no configurado

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

Puerto comodín para manejar el tráfico FTP

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.

Detección de ataque para rechazo de servicio

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.

Nota:
Debe haber tráfico entrante a través del clúster y del puerto a los que se ataca para que Dispatcher pueda determinar el fin del ataque para rechazo de servicio (DoS). Dispatcher no puede detectar que el ataque se ha detenido hasta que el tráfico empieza a circular de nuevo.

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.

Nota:
Existe una condición de excepción SNMP correspondiente a los scripts halfOpenAlert y halfOpenAlertDone. Si el subagente SNMP está configurado y en ejecución, las correspondientes condiciones de excepción se envían en las mismas condiciones que desencadenaron los scripts. Si desea más información sobre el subagente SNMP, consulte el apartado Utilización de Simple Network Management Protocol con el componente Dispatcher.

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.

Utilización del registro cronológico binario para analizar estadísticas de servidor

Nota:
La característica de registro cronológico en binario se aplica al componente Dispatcher y CBR.

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).

Utilización de un cliente con ubicación compartida

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