Este problema se puede producir cuando otra aplicación está utilizando uno de los puertos utilizados por Dispatcher. Para obtener más información, consulte el apartado Comprobación de números de puerto de Dispatcher.
Este problema se produce cuando se utiliza otra dirección que no es la dirección especificada. Cuando utiliza una ubicación compartida para el Dispatcher y el servidor, asegúrese de que la dirección del servidor utilizada en la configuración es la dirección NFA o que se configura como ubicación compartida. Además, compruebe si el archivo de host tiene la dirección correcta.
Este problema tiene síntomas, por ejemplo, de conexiones de máquinas cliente no atendidas o de tiempo de espera de conexiones superado. Compruebe lo siguiente para diagnosticar este problema:
Para Windows y otras plataformas, consulte también Configuración de máquinas de servidor para el equilibrio de carga.
Este problema aparece cuando se configura un entorno de alta disponibilidad de Dispatcher y las conexiones de las máquinas cliente no están siendo atendidas o exceden el tiempo de espera. Compruebe lo siguiente para corregir o diagnosticar el problema:
Los pasos siguientes son un modo eficaz de probar que los scripts de alta disponibilidad funcionan correctamente:
Los dos informes serán idénticos si se han configurado correctamente los scripts.
Este error de la plataforma Windows se produce cuando la dirección de origen no está configurada en un adaptador. Compruebe lo siguiente para corregir o diagnosticar el problema.
dscontrol executor configure <dirección ip>
Si está utilizando soporte de área amplia y parece que los asesores no funcionan correctamente, asegúrese de que se inician en el Dispatcher local y en el remoto.
Se emite un mandato ping de ICMP a los servidores antes de la solicitud del asesor. Si existe un cortafuegos entre Load Balancer y los servidores, asegúrese de que se admiten los mandatos ping en el cortafuegos. Si esta configuración posee un riesgo de seguridad para la red, modifique la sentencia java en dsserver para desactivar todos los mandatos ping a los servidores añadiendo la propiedad java:
LB_ADV_NO_PING="true"
java -DLB_ADV_NO_PING="true"
Consulte el apartado Utilización de asesores remotos con el soporte de área amplia de Dispatcher.
Cuando Load Balancer se conecta a un servidor de programa de fondo que ejecuta Windows Server 2008, las características de recopilación de métrica podrían hacer que la aplicación memload.exe deje de ejecutarse inesperadamente.
Esta anomalía se produce porque es posible que el registro de Windows Server 2008 no cuente con las claves de rendimiento que estas herramientas necesitan. Debería informar de esta anomalía desde la aplicación cpuload.
Consulte en el tema siguiente de la base de información de Microsoft los pasos sobre cómo resolver este problema: http://support.microsoft.com/kb/300956
Cuando se utilizan Dispatcher, Microsoft IIS y SSL, si no funcionan juntos, es posible que haya un problema con la habilitación de la seguridad SSL. Para obtener más información sobre cómo generar un par de claves, adquirir un certificado, instalar un certificado con un par de claves y configurar un directorio para solicitar SSL, consulte la documentación Microsoft Information and Peer Web Services.
Dispatcher utiliza claves para permitirle conectar a una máquina remota y configurarla. Las claves especifican un puerto RMI para la conexión. Es posible cambiar el puerto RMI por motivos de seguridad o conflictos. Cuando cambia los puertos RMI, el nombre de archivo de la clave es distinto. Si tiene más de una clave en el directorio de claves para la misma máquina remota y las claves especifican puertos RMI distintos, la línea de mandatos sólo intentará la primera que encuentre. Si es incorrecta, se rechazará la conexión. No se realizará la conexión a no ser que suprima la clave incorrecta.
EXCLUDE-MODULE java
EXCLUDE-MODULE javaw
Esto puede producir problemas si una de las consolas de administración se ejecuta en la misma máquina que un cortafuegos o a través de un cortafuegos. Por ejemplo, cuando Load Balancer se ejecuta en la misma máquina que un cortafuegos y se emiten mandatos dscontrol, es posible que aparezcan errores como Error: el servidor no responde.
Para impedir este problema, edite el archivo de scripts dsserver para establecer el puerto utilizado por RMI para el cortafuegos (u otra aplicación). Cambie la línea: LB_RMISERVERPORT=10199 por LB_RMISERVERPORT=suPuerto. Donde suPuerto es otro puerto.
Cuando haya terminado, reinicie dsserver y abra el tráfico para los puertos: 10099, 10004, 10199 y 10100 o para el puerto seleccionado para la dirección del host desde donde se ejecutará la consola de administración.
Por ejemplo: java -Djava.rmi.server.hostname="10.1.1.1"
Para plataformas Windows, cuando se utiliza Netscape como navegador predeterminado, puede aparecer el siguiente mensaje de error: “No se puede encontrar el archivo '<nombre_archivo>.html' (o uno de sus componentes). Asegúrese de que la vía de acceso y el nombre de archivo sean correctos y de que están disponibles todas las bibliotecas necesarias".
El problema se debe a un valor incorrecto de la asociación de archivo HTML. Esta es la solución:
La GUI (interfaz gráfica de usuario), que es lbadmin, requiere una cantidad de espacio de paginación suficiente para funcionar correctamente. Si no hay disponible suficiente espacio para paginación, quizá la GUI no se inicie completamente. Si ocurriera esto, compruebe el espacio de paginación y auméntelo si es necesario.
Si desinstala Load Balancer para volver a instalar otra versión y obtiene un error al intentar iniciar el componente Dispatcher, compruebe si está instalado Proxy de memoria caché. Proxy de memoria caché tiene una dependencia en uno de los archivos de Dispatcher; este archivo se desinstalará sólo cuando se desinstale Proxy de memoria caché.
Para evitar este problema:
Si surge un problema con la apariencia de la GUI de Load Balancer, compruebe el valor de la resolución de escritorio del sistema operativo. La GUI se visualiza mejor con una resolución de 1024x768 píxeles.
En la plataforma Windows, cuando se abren por primera vez las ventanas de ayuda, a veces éstas desaparecen en el fondo detrás de ventanas existentes. Si esto sucediera, pulse en la ventana para traerla de nuevo al frente.
En Solaris cada adaptador de red tiene la misma dirección MAC predeterminada. Esto funciona correctamente si cada adaptador se encuentra en una subred IP distinta; no obstante, en un entorno conmutado, cuando varias NIC con la misma dirección MAC y la misma dirección de subred IP se comunican con el mismo conmutador, el conmutador envía todo el tráfico enlazado para la dirección MAC única (y las dos IP) al mismo cable. Sólo el adaptador que incluyó por última vez una trama en el cable detecta los paquetes IP enlazados para los dos adaptadores. Solaris podría descartar paquetes para una dirección IP válida que llegaran en la interfaz "incorrecta".
Si no se designan todas las interfaces de red para Load Balancer como configuradas en ibmlb.conf y si la NIC que no está definida en ibmlb.conf recibe una trama, Load Balancer no tiene la posibilidad de procesar y reenviar la trama.
Para evitar este problema, debe alterar temporalmente el valor predeterminado y establecer una dirección MAC única para cada interfaz. Utilice este mandato:
ifconfig interfaz ether macAddr
Por ejemplo:
ifconfig eri0 ether 01:02:03:04:05:06
En la plataforma Windows, debe tener instalada y configurada una tarjeta de red antes de iniciar el ejecutor.
El sistema de operativo AIX contiene un parámetro de red denominado descubrimiento de MTU de vía de acceso. Durante una transacción con un cliente, si el sistema operativo determina que debe utilizar una unidad de transmisión máxima (MTU) más pequeña para los paquetes de salida, el descubrimiento de MTU de vía de acceso hace que AIX cree una ruta para recordar esos datos. La nueva ruta es para esa dirección IP del cliente específica y graba la MTU necesaria para llegar a ella.
Cuando se crea la ruta, podría aparecer un problema en los servidores provocado por el clúster del que se crea un alias en el bucle de retorno. Si la dirección de pasarela para la ruta está dentro de la subred del clúster/máscara de red, los sistemas AIX crean la ruta en el bucle de retorno. Esto sucede porque esa era la última interfaz con alias con esa subred.
Por ejemplo, si el clúster es 9.37.54.69, se utiliza una máscara de red 255.255.255.0 y la pasarela prevista es 9.37.54.1, los sistemas AIX utilizan el bucle de retorno para la ruta. Esto provoca que las respuestas del servidor nunca abandonen la máquina y que el cliente supere el tiempo de espera. El cliente suele detectar una respuesta del clúster, luego se crea la ruta y el cliente ya no recibe nada más.
Para resolver este problema, emita el mandato siguiente:
Esta mandato hará que los valores sean permanantes, y los valores se aplicarán tanto a valores actuales como a los valores futuros de rearranque.
Cuando se configura un Load Balancer de área amplia, se debe definir el Dispatcher remoto como un servidor de un clúster en el Dispatcher local. Normalmente, puede utilizar la dirección de no reenvío (NFA) del Dispatcher remoto como la dirección de destino del servidor remoto. Si hace esto y configura la alta disponibilidad en el Dispatcher remoto, dará un error. Esto sucede porque el Dispatcher local siempre señala a la máquina primaria en el lado remoto cuando utiliza su dirección NFA para acceder a ésta.
Para solucionar este problema:
Cuando aparece el Dispatcher primario remoto, creará un alias de esta dirección en su adaptador, que le permite aceptar tráfico. Si se produce una anomalía, la dirección se desplaza a la máquina de reserva y ésta sigue aceptando el tráfico de esa dirección.
Cuando se utiliza lbadmin o la administración Web (lbwebaccess) para cargar un archivo de configuración de gran tamaño (200 o más mandatos add aproximadamente), la GUI puede colgarse o mostrar un comportamiento inesperado, como responder a los cambios de pantalla a una velocidad extremadamente lenta.
Esto se produce porque Java™ no tiene acceso a suficiente memoria para gestionar una configuración de tan gran tamaño.
Hay una opción en el entorno de ejecución que se puede especificar para aumentar la agrupación de asignaciones de memoria disponible para Java.
La opción es -Xmxn donde n es el tamaño máximo, en bytes, para la agrupación de asignaciones de memoria. n debe ser múltiplo de 1024 y ser mayor que 2 MB. El valor n debe ir seguido de k o K para indicar kbytes o de m o M para indicar megabytes. Por ejemplo, -Xmx128M y -Xmx81920k son dos valores válidos. El valor predeterminado son 64 M.
Por ejemplo, para añadir esta opción, edite el archivo de scripts lbadmin, modificando "javaw" con "javaw -Xmxn" como se detalla a continuación. (Para sistemas AIX, cambie "java" por "java -Xmxn"):
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH%
%LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
No hay ningún valor recomendado para n, pero debería ser mayor que la opción predeterminada. Un buen punto de partida sería el doble del valor predeterminado.
Si la administración de Load Balancer (lbadmin) se desconecta del servidor después de actualizar la configuración, compruebe la versión de dsserver en el servidor que está intentando configurar y asegúrese de que es la misma versión que la de lbadmin o dscontrol.
Cuando se utiliza un cliente remoto en una implementación de SOCKS segura, quizá los nombres de dominio o de host plenamente cualificados no se resuelvan con la dirección IP correcta en notación de dirección IP. La implementación de SOCKS podría añadir datos específicos, relacionados con SOCKS a la resolución de DNS.
Si una dirección IP no se resuelve correctamente en la conexión remota, especifique la dirección IP en el formato de notación de dirección IP.
Para corregir fonts solapados o no deseados en la interfaz de Load Balancer coreana:
-Monotype-TimesNewRomanWT-medium-r-normal
--*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal
--*-%d-75-75-*-*-ksc5601.1987-0
-monotype-
timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
En sistemas Windows, después de crear un alias del adaptador MS Loopback, cuando emita determinados mandatos como hostname, el sistema operativo responderá incorrectamente con la dirección de alias en lugar de la dirección local. Para corregir este problema, en la lista de conexiones de red, el alias recién añadido debe enumerarse bajo la dirección local. Esto asegurará que se accede a la dirección local antes que al alias de bucle de retorno.
Para comprobar la lista de conexiones de red:
En la plataforma Windows, cuando se utiliza una tarjeta Matrox AGP, puede producirse un comportamiento inesperado en la GUI de Load Balancer. Cuando pulsa el ratón, podría dañarse un bloque de espacio ligeramente mayor que el puntero del ratón provocando una posible inversión del resaltado o un desplazamiento de imágenes fuera del lugar de la pantalla. Las tarjetas Matrox anteriores no han mostrado este comportamiento. No hay un fix pack conocido cuando se utilizan tarjetas Matrox AGP.
En sistemas Linux, si dsserver aún está en ejecución durante la eliminación manual del módulo de kernel de Load Balancer, se puede producir un comportamiento inesperado, por ejemplo javacores o que el sistema se cuelgue. Cuando elimina manualmente el módulo kernel de Load Balancer, primero debe detener dsserver.
Si no funciona "dsserver stop", detenga el proceso java con SRV_KNDConfigServer. Para detener el proceso encuentre su identificador de proceso utilizando el mandato ps -ef | grep SRV_KNDConfigServer y finalice el proceso utilizando el mandato kill id_proceso.
Puede ejecutar de manera segura el mandato "rmmod ibmlb" para eliminar el módulo Load Balancer del kernel.
Si ejecuta el componente Dispatcher para el equilibrio de carga, es posible sobrecargar el sistema con tráfico del cliente. El módulo kernel de Load Balancer tiene la máxima prioridad y, si gestiona constantemente paquetes del cliente, el resto del sistema podría quedarse sin respuesta. La ejecución de mandatos en el espacio de usuario puede llevar mucho tiempo completarse o puede que nunca se complete.
Si esto sucede, debería comenzar a reestructurar su configuración para impedir la sobrecarga de la máquina de Load Balancer con tráfico. Entre las alternativas se incluye distribuir la carga entre varias máquinas de Load Balancer o sustituir la máquina con un sistema más consistente y más rápido.
Cuando intente determinar si el tiempo de respuesta lento en la máquina se debe a un alto volumen de tráfico del cliente, considere si esto se produce durante los momentos de tráfico máximo del cliente. Los sistemas mal configurados que provocan bucles de direccionamiento también pueden provocar los mismos síntomas. Pero antes de cambiar la configuración de Load Balancer, determine si los síntomas pueden deberse a un gran volumen de carga del cliente.
Cuando se utiliza el método de reenvío mac, Load Balancer enviará paquetes a los servidores utilizando la dirección del clúster de la que se ha creado un alias en el bucle de retorno. Algunas aplicaciones servidor (como SSL) requieren que la información de configuración (como los certificados) sea según la dirección IP. La dirección IP debe ser la dirección del clúster que se configura en el bucle de retorno para que corresponda al contenido de los paquetes de entrada. Si no se utiliza la dirección IP del clúster cuando se configura la aplicación servidor, no se reenviará correctamente la solicitud del cliente al servidor.
Si utiliza la administración Web remota para configurar Load Balancer, no cambie el tamaño (Minimizar, Maximizar, Restaurar minimizando, etc.) de la ventana del navegador Netscape en la que aparece la GUI de Load Balancer. Dado que Netscape vuelve a cargar una página cada vez que se cambia el tamaño de la ventana del navegador, esto provocará una desconexión del host. Tendrá que volver a conectar con el host cada vez que cambie el tamaño de la ventana. Si está realizando administración Web remota en una plataforma Windows, utilice Internet Explorer.
En una ventana de indicador de mandatos del sistema operativo Windows, es posible que algunos caracteres nacionales de la familia Latin-1 aparezcan corruptos. Por ejemplo, la letra "a" con una tilde podría mostrarse como el símbolo pi. Para corregir esto, debe cambiar las propiedades de font de la ventana de línea de mandatos. Para cambiar el font, realice lo siguiente:
Algunas instalaciones de HP-UX 11i están preconfiguradas para sólo permitir 64 hebras por proceso. No obstante, algunas configuraciones de Load Balancer requieren una cantidad mayor. Para sistemas HP-UX, establezca las hebras por proceso en un mínimo de 256. Para aumentar este valor, utilice el programa de utilidad "sam" para establecer el parámetro de kernel max_thread_proc. Si se espera un uso masivo, puede ser necesario aumentar max_thread_proc por encima de 256.
Para aumentar el parámetro max_thread_proc, haga lo siguiente:
Cuando configura el adaptador en una máquina de Load Balancer, debe asegurarse de que los dos valores siguientes son correctos para que el asesor funcione:
En la plataforma Windows, cuando se configura un adaptador con más de una dirección IP, configure la dirección IP que desea afiliar al nombre de host primero del registro.
Puesto que Load Balancer depende de InetAddress.getLocalHost() en muchas instancias (por ejemplo, lbkeys create), varias direcciones IP que tienen un alias con un sólo adaptador podrían provocar problemas. Para impedir este problema, enumere la dirección IP con la que desea que se resuelva la dirección IP primero en el registro. Por ejemplo:
De forma predeterminada, cuando el sistema operativo Windows detecta una caída de la red, borra la memoria caché ARP (protocolo de resolución de direcciones), incluidas todas las entradas estáticas. Cuando la red está disponible, la memoria caché ARP se vuelve a rellenar con solicitudes ARP enviadas en la red.
Con una configuración de alta disponibilidad, cuando una pérdida de conectividad de red influye en uno o los dos servidores, éstos se hacen con el control de las operaciones primarias. Cuando se envía la solicitud ARP para rellenar la memoria caché ARP, los dos servidores responden, lo que provoca que la memoria caché ARP marque la entrada como no válida. Por lo tanto, los asesores no pueden crear un socket para los servidores finales.
Para solucionar este problema, evite que el sistema operativo Windows borre la memoria caché ARP cuando haya una pérdida de conectividad. Microsoft ha publicado un artículo que explica cómo llevar a cabo esta tarea. Este artículo está en el sitio Web de Microsoft, ubicado en la base de información de Microsoft, artículo número 239924: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.
A continuación se proporciona un resumen de los pasos, descritos en el artículo de Microsoft, para evitar que el sistema borre la memoria caché ARP:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Se deben tener en cuenta determinadas consideraciones al utilizar servidores Linux kernel 2.4.x y el método de reenvío MAC de Dispatcher. Si el servidor tiene una dirección del clúster configurada en el dispositivo de bucle de retorno utilizando el mandato ip address add, sólo se puede crear un alias de clúster de dirección.
Cuando cree un alias de varios clústeres con el dispositivo de bucle de retorno utilice el mandato ifconfig, por ejemplo:
ifconfig lo:núm direcciónClúster netmask 255.255.255.255 up
Además, hay incompatibilidades entre los métodos ifconfig e ip de configurar interfaces. El procedimiento recomendado sugiere que un sitio seleccione un método y utilice ese método de forma exclusiva.
Cuando añade servidores a la configuración de Dispatcher, puede producirse este mensaje de error: "Error: dirección del direccionador no especificada o no válida para el método del puerto".
Utilice la lista de comprobación para determinar el problema:
El valor predeterminado del parámetro de direccionador (router) es 0, que indica que el servidor es local. Si establece la dirección del direccionador del servidor en un valor distinto de 0, esto indica que es un servidor remoto, en una subred distinta. Para obtener más información sobre el parámetro de direccionador del mandato de adición de servidor, consulte dscontrol server — configurar servidores.
Si el servidor que añade se ubica en una subred distinta, el parámetro de direccionador debería ser la dirección del direccionador que se va a utilizar en la subred local para comunicarse con el servidor remoto.
En sistemas Solaris, después de iniciar scripts de Load Balancer (como dsserver o lbadmin) desde una ventana de terminal, si sale de esa ventana, también sale el proceso de Load Balancer.
Para solucionar este problema, inicie los scripts de Load Balancer con el mandato nohup. Por ejemplo: nohup dsserver. Este mandato impide que los procesos iniciados desde la sesión de terminal reciban una señal de cierre de comunicación del sistema del terminal cuando sale, que permite a los procesos continuar incluso después de que haya finalizado la sesión de terminal. Utilice el mandato nohup delante de cualquier script de Load Balancer que desee seguir procesando cuando haya terminado la sesión de terminal.
La configuración de Load Balancer puede tardar mucho en cargarse debido a las llamadas al Sistema de nombres de dominio (DNS) que se realizan para resolver y verificar la dirección de servidor.
Si el DNS de la máquina de Load Balancer se configura incorrectamente o si el DNS en general tarda mucho tiempo, esto producirá una ralentización de la carga de la configuración debido a los procesos Java que envían solicitudes de DNS en la red.
Una solución para esto es añadir las direcciones del servidor y los nombres de host al archivo /etc/hosts local.
Si se configura la alta disponibilidad, podrían configurarse direcciones del clúster en las dos máquinas por un breve período y provocar este mensaje de error: Hay un conflicto de dirección IP con otro sistema en la red. En este caso, puede ignorar el mensaje con seguridad. Es posible que una dirección del clúster se configure brevemente en las dos máquinas de alta disponibilidad a la vez, especialmente durante el inicio de cualquiera de las máquinas o cuando se ha iniciado la toma del control.
Compruebe los scripts go* para asegurarse de que configuran y desconfiguran correctamente direcciones del clúster. Si ha invocado un archivo de configuración y tiene scripts go* instalados, asegúrese de que no tiene ninguna sentencia de mandato "executor configure" para las direcciones del clúster en el archivo de configuración, porque esto entrará en conflicto con los mandatos configure y unconfigure de los scripts go*.
Para obtener más información sobre los scripts go* al configurar la alta disponibilidad, consulte Utilización de scripts.
Este problema podría producirse cuando no se ejecutan los scripts go en alguna de las máquinas primaria o de reserva. Los scripts go no pueden ejecutarse si no se ha iniciado dsserver en las dos máquinas. Compruebe las dos máquinas y asegúrese de que dsserver está en ejecución.
Las solicitudes del cliente que producen unas respuestas de páginas de gran tamaño superan el tiempo de espera si la unidad de transmisión máxima (MTU) no se establece correctamente en la máquina de Dispatcher. Para los métodos de reenvío cbr y nat del componente Dispatcher, esto puede suceder porque Dispatcher toma de manera predeterminada el valor de la MTU, en lugar de negociar el valor.
La MTU se establece en cada sistema operativo basándose en el tipo de soporte de comunicaciones (por ejemplo, Ethernet). Los direccionadores del segmento local podrían tener establecida una MTU de menor tamaño si se conectan con un tipo de soporte de comunicaciones distinto. En condiciones de tráfico normal de TCP, se produce una negociación de la MTU durante la configuración de la conexión y se utiliza la MTU de menor tamaño para enviar datos entre máquinas.
Dispatcher no admite la negociación de la MTU para el método de reenvío cbr o nat de Dispatcher porque interviene activamente como un punto final para conexiones TCP. Para el reenvío cbr y nat, Dispatcher toma por omisión el valor de MTU de 1500. Este valor es el tamaño de la MTU típico para Ethernet estándar, de manera que la mayoría de los clientes no tienen que ajustar este valor.
Cuando se utiliza el método de reenvío cbr o nat de Dispatcher, si tiene un direccionador al segmento local que tiene una MTU de menor tamaño, debe establecer la MTU en la máquina de Dispatcher para que coincida con la MTU de menor tamaño.
Para resolver este problema, utilice el mandato siguiente para establecer el valor del tamaño de segmento máximo (mss): dscontrol executor set mss nuevo_valor
Por ejemplo:
dscontrol executor set mss 1400
El valor por omisión de mss es 1460.
El valor de mss no se aplica para el método de reenvío mac de Dispatcher ni para ningún otro componente no Dispatcher de Load Balancer.
Cuando existe más de una dirección IP en un sistema Windows y el archivo hosts no especifica la dirección que se va a asociar al nombre de host, el sistema operativo selecciona la dirección de menor tamaño para asociarla al nombre de host.
Para resolver este problema, actualice el archivo c:\Windows\system32\drivers\etc\hosts con el nombre de host de su máquina y la dirección IP que desee asociar al nombre de host.
IMPORTANTE: la dirección IP no puede ser una dirección del clúster.
Cuando utiliza la característica de alta disponibilidad en máquinas Linux para S/390 con el controlador de red qeth, puede que los Dispatcher activo y en espera no se sincronicen. Este problema podría limitarse a Linux Kernel 2.6.
Si aparece este problema, utilice este método alternativo:
Defina un dispositivo de red de canal a canal (CTC) entre las imágenes de Dispatcher activa y en espera y añada pulsos entre las dos direcciones IP de punto final de CTC.
Con la función de alta disponibilidad de Load Balancer, una máquina asociada puede tomar el control del equilibrio de carga si la máquina asociada primaria sufre una anomalía o se apaga. Para mantener conexiones entre las máquinas asociadas de alta disponibilidad, se pasan entre ellas registros de conexión. Cuando la máquina asociada en espera toma el control de la función de equilibrio de carga, la dirección IP de clúster se suprime de la máquina en espera y se añade a la nueva máquina primaria. Esta operación de toma de control puede verse afectada por muchos factores de tiempo y configuración.
Las sugerencias que se detallan en este apartado puede ayudarle a reducir la cantidad de problemas derivados de los problemas de configuración de alta disponibilidad, como por ejemplo:
Las siguientes sugerencias le ayudarán a configurar correctamente la característica de alta disponibilidad de las máquinas de Load Balancer.
Ejemplos de mandatos de alta disponibilidad son:
dscontrol highavailability heartbeat add ...
dscontrol highavailability backup add ...
dscontrol highavailability reach add ...
En la mayoría de los casos, debe colocar las definiciones de alta disponibilidad al final del archivo. Las sentencias de clúster, puerto y servidor se deben colocar antes de las sentencias de alta disponibilidad. Esto se debe a que al sincronizar la alta disponibilidad, busca las definiciones de clúster, puerto y servidor cuando se recibe un registro de conexión.
Si el clúster, puerto y servidor no existen, se elimina el registro de conexión. Si se produce una toma de control y el registro de conexión no se ha duplicado en la máquina asociada, la conexión falla.
La excepción a esta regla es cuando se utilizan servidores con ubicación compartida que configurados con el método de reenvío MAC. En este caso, las sentencias de alta disponibilidad deben indicarse antes de las sentencias de servidor con ubicación compartida. Si las sentencias de alta disponibilidad no se indican antes de las sentencias de servidor con ubicación compartida, Load Balancer recibe una solicitud para el servidor con ubicación compartida, pero parece la misma que una solicitud entrante para el clúster y se equilibra la carga. Esto lleva a una repetición en bucle de los paquetes de la red y a un tráfico excesivo. Cuando las sentencias de alta disponibilidad se colocan antes del servidor con ubicación compartida, Load Balancer sabe que no debe reenviar tráfico entrante a menos que esté en estado ACTIVO.
Para corregir este comportamiento, añada un retardo de inactividad en el script goActive. El intervalo de tiempo de inactividad necesario depende del despliegue. Se recomienda iniciar con un tiempo de demora de inactividad de 10.
De manera predeterminada, las máquinas intentan comunicarse entre sí cada medio segundo y detectarán una anomalía después de cuatro intentos fallidos. Si hay mucha actividad en la máquina, esto puede producir casos de sustitución por anomalía cuando el sistema en realidad sigue funcionando correctamente. Puede aumentar el número de veces hasta que se produce la anomalía emitiendo:
dscontrol executor set hatimeout <valor>
Para llevarlo a cabo, las conexiones antiguas no deben permanecer en la memoria durante un periodo de tiempo largo. En concreto, han habido problemas con los puertos LDAP y grandes periodos staletimeout (más de un un día). Si se establece un periodo staletimeout grande las conexiones antiguas permanecerán en memoria, lo que provocará que se pasen más registros de conexión durante la sincronización así como más uso de memoria en las dos máquinas.
Si la sincronización sufre una anomalía con un periodo staletimeout razonable, puede aumentar el tiempo de espera de sincronización emitiendo el mandato:
e xm 33 5 new_timeout
Este mandato no se almacena en el archivo de configuración cuando se guarda, por lo tanto tendrá que añadirlo manualmente al archivo de configuración si desea que el valor se conserve después de cada conclusión.
El valor de tiempo de espera se almacena en mitad de segundos; por lo tanto, el valor predeterminado de nuevo_tiempo es 100 (50 segundos).
En general, cuando se utiliza el método de reenvío MAC, los servidores de la configuración de Load Balancer deben estar todos en el mismo segmento de red misma, independientemente de la plataforma. Los dispositivos de red activos como el direccionador, los puentes y los cortafuegos dificultan el funcionamiento de Load Balancer. Esto se debe a las funciones de Load Balancer, como un direccionador especializado, que sólo modifican las cabeceras de capa de enlace para su salto siguiente y final. Cualquier topología de red en la que el salto siguiente no sea el último salto no es válida para Load Balancer.
Se trata de una limitación para los servidores zSeries y S/390 que comparten la tarjeta OSA, porque este adaptador opera de forma distinta a la mayoría de las tarjetas de red. La tarjeta OSA dispone de una implementación de capa de enlace propia, que no tiene nada que ver con Internet, que se muestra a los hosts Linux y z/OS por detrás. En efecto, las tarjetas OSA se comunican como si fueran sistemas de Ethernet a Ethernet (no como hosts OSA) y los hosts que la utilizan responderán como si fueran Ethernet.
La tarjeta OSA también lleva a cabo algunas funciones que se relacionan directamente con la capa IP. Un ejemplo de la función que realiza es responder a solicitudes ARP (Address Resolution Protocol). Otra función es que la tarjeta OSA compartida direcciona los paquetes IP en base a la dirección IP de destino, en lugar de una dirección Ethernet como un conmutador de capa 2. En efecto, la tarjeta OSA es en sí un segmento de red con puente.
Load Balancer ejecutándose en un host S/390 Linux o zSeries Linux puede efectuar reenvíos a hosts en el mismo OSA o a hosts en Ethernet. Todos los hosts que comparten OSA están en efecto en el mismo segmento.
Load Balancer puede reenviar fuera de una tarjeta OSA compartida debido a la naturaleza del puente de OSA. El puente reconoce el puerto OSA propietario de la dirección IP de clúster. El puente reconoce la dirección MAC de los hosts conectados directamente con el segmento Ethernet. Por lo tanto, Load Balancer puede utilizar el reenvío MAC a través de un puente OSA.
Sin embargo, Load Balancer no puede realizar reenvíos a una tarjeta OSA compartida. Esto incluye Load Balancer en un sistema S/390 Linux cuando el servidor de activar está en una tarjeta OSA distinta de la de Load Balancer. La tarjeta OSA correspondiente al servidor de servidor anuncia la dirección MAC de OSA para la dirección IP del servidor, pero cuando llega un paquete con la dirección de destino Ethernet de la tarjeta OSA del servidor y la dirección IP del clúster, la tarjeta OSA del servidor no sabe cuál de los hosts, si hay alguno, debe recibir dicho paquete. Los mismos principios que permiten que el reenvío MAC de OSA a Ethernet funcione fuera de una tarjeta OSA compartida no se aplican al intentar el reenvío a una tarjeta OSA compartida.
Método alternativo:
En configuraciones de Load Balancer que utilizan servidores zSeries o S/390 que tienen tarjetas OSA; hay dos enfoques que puede utilizar para resolver temporalmente el problema descrito.
Si los servidores de la configuración de Load Balancer están en el mismo tipo de plataforma zSeries o S/390, puede definir conexiones de punto a punto (CTC o IUCV) entre Load Balancer y cada servidor. Configurar los puntos finales con direcciones IP privadas. La conexión de punto a punto sólo se utiliza para el tráfico de Load Balancer a servidor. A continuación, añada los servidores con la dirección IP del punto final de servidor del túnel. Con esta configuración, el tráfico de clúster atraviesa la tarjeta OSA de Load Balancer y se reenvía a través de la conexión punto a punto donde el servidor responde mediante su propia ruta predeterminada. La respuesta utiliza la tarjeta OSA del servidor para enviarse, que puede o no ser la misma tarjeta.
Si los servidores de la configuración de Load Balancer no están en el mismo tipo de plataforma zSeries o S/390, o si no es posible definir una conexión de punto a punto entre Load Balancer y cada servidor, se recomienda utilizar la característica GRE (encapsulamiento genérico de direccionamiento) de Load Balancer, que es un protocolo que permite a Load Balancer realizar reenvíos a través de direccionadores.
Al utilizar GRE, Load Balancer recibe el paquete de IP cliente->clúster encapsulado y lo envía al servidor. En el servidor, el paquete IP de cliente a clúster original se excapsula y el servidor responde directamente al cliente. La ventaja de utilizar GRE es que Load Balancer sólo detecta el tráfico de cliente a servidor, no detecta el tráfico de servidor a cliente. La desventaja es que reduce el tamaño de segmento máximo (MSS) de la conexión TCP debido a la carga adicional de encapsulamiento.
Para configurar Load Balancer para realizar reenvíos con encapsulación GRE, añada los servidores utilizando el siguiente mandato:
dscontrol server add dir_clúster:puerto:servidor_programa_fondo router
servidor_programa_fondo
Donde router backend_server es válido si Load Balancer y el servidor de programa de fondo están en la misma subred IP. De lo contrario, especifique como direccionador la dirección IP válida del salto siguiente.
Para configurar sistemas Linux para realizar la excapsulación GRE nativa, para cada servidor de programa de fondo, emita los siguientes mandatos:
modprobe ip_gre
ip tunnel add grelb0 mode gre ikey 3735928559
ip link set grelb0 up
ip addr add cluster_addr dev grelb0
En algunas versiones de Linux Red Hat, cuando se ejecuta Load Balancer configurado con las características de gestor y asesor, pueden producirse pérdidas de memoria importantes. La pérdida de memoria Java aumenta si configura un valor pequeño de intervalo de tiempo para el asesor.
Las versiones de la MVM de SDK Java de IBM y la biblioteca de hebras POSIX nativa (NPTL) que se entregan con algunas distribuciones Linux, como Red Hat Enterprise Linux 3.0, pueden hacer que se produzca la pérdida de memoria. La biblioteca de hebras mejorada NPTL se proporciona con algunas distribuciones de sistemas Linux, como Red Hat Enterprise Linux 3.0, que soportan NPTL.
Consulte http://www.ibm.com/developerworks/java/jdk/linux/tested.html para obtener la última información sobre sistemas Linux y el SDK Java de IBM que se entrega con estos sistemas.
Como herramienta de determinación de problemas, utilice el mandato vmstat o ps para detectar pérdidas de memoria.
Para corregir la pérdida de memoria, emita el siguiente mandato antes de ejecutar la máquina Load Balancer para así inhabilitar la biblioteca NPTL:
export LD_ASSUME_KERNEL=2.4.10
En SuSe Linux Enterprise Server 9, cuando se utiliza el método de reenvío MAC, el informe de Dispatcher puede indicar que se ha reenviado el paquete (la cuenta de paquetes aumenta); sin embargo, el paquete nunca llega al servidor de programa de fondo.
Cuando aparece este problema, puede observar uno de estos comportamientos o ambos:
ip_finish_output2: No hay caché de cabecera ni vecina
ICMP No se puede alcanzar la fragmentación: es necesaria la fragmentación
Este problema puede deberse al módulo NAT de tablas ip que se carga. En SLES 9, hay un posible error, aunque sin confirmar, que provoca un comportamiento extraño al interactuar con Dispatcher.
Solución:
Descargue el módulo NAT de iptables y el módulo de seguimiento de conexiones.
Por ejemplo:
# lsmod | grep ip
iptable_filter 3072 0
iptable_nat 22060 0
ip_conntrack 32560 1 iptable_nat
ip_tables 17280 2
iptable_filter,iptable_nat
ipv6 236800 19
# rmmod iptable_nat
# rmmod ip_conntrack
Elimine los módulos en el orden de utilización. De manera específica, puede eliminar un módulo sólo si la cuenta de referencia (la última columna de la salida lsmod) es cero. Si ha configurado alguna regla en iptables, debe eliminarla. Por ejemplo: iptables -t nat -F.
El módulo iptable_nat utiliza ip_conntrack, por lo que primero se debe eliminar el módulo iptable_nat y, a continuación, el módulo ip_conntrack.
En sistemas Windows, si ejecuta la característica de alta disponibilidad de Load Balancer, los scripts go* se utilizan para configurar la dirección IP de clúster en el sistema activo de Load Balancer y para desconfigurar la dirección IP de clúster del sistema de reserva cuando se produce una toma de control. Si se ejecuta el script go* que configura la dirección IP de clúster de la máquina activa antes de ejecutar el script go* para desconfigurar la dirección IP de clúster de la máquina en espera, pueden surgir problemas. Es posible que aparezca una ventana emergente que le indique que el sistema ha detectado un conflicto entre direcciones IP. Si ejecuta el mandato ipconfig \all, también puede ver que aparece una dirección IP 0.0.0.0 de la máquina.
Solución:
Emita el mandato siguiente para desconfigurar manualmente la dirección IP de clúster de la máquina primaria:
dscontrol executor unconfigure IP_clúster
De esta manera se elimina la dirección 0.0.0.0 de la pila IP de Windows.
Una vez que la máquina asociada de alta disponibilidad libera la dirección IP de clúster, emita el siguiente mandato para volver a añadir manualmente la dirección IP de clúster:
dscontrol executor configure clusterIP
Después de emitir este mandato, busque de nuevo la dirección IP de clúster en la pila IP de Windows emitiendo el siguiente mandato:
ipconfig /all
iptables en Linux pueden dificultar el equilibrio de carga y debe estar inhabilitado en la máquina de Dispatcher.
Emita el mandato siguiente para determinar si se han cargado iptables:
lsmod | grep ip_tables
La salida del mandato anterior puede ser parecida a la siguiente:
ip_tables 22400 3
iptable_mangle,iptable_nat,iptable_filter
Emita el siguiente mandato para cada iptable que aparece en la salida para visualizar las reglas de las tablas:
iptables -t <nombre_abreviado> -L
Por ejemplo:
iptables -t mangle -L
iptables -t nat -L
iptables -t filter -L
Si iptable_nat se ha cargado, se debe descargar. Puesto que iptable_nat tiene una dependencia en iptable_conntrack, también se debe eliminar iptable_conntrack. Emita el mandato siguiente para descargar estos dos iptables:
rmmod iptable_nat iptable_conntrack
Durante el proceso de instalación de Load Balancer, también se instala un conjunto de archivos Java. Load Balancer será la única aplicación que utilice la versión Java que se instala con el producto. No debe actualizar esta versión del conjunto de archivos Java sin ayuda especializada. Si hay un problema que requiera una actualización del conjunto de archivos Java, debe notificarlo al servicio de IBM para actualizar al nivel de arreglo oficial el conjunto de archivos Java que se envía con Load Balancer.
En sistemas operativos Microsoft Windows, pueden cerrarse conexiones permanentes durante una toma de control de alta disponibilidad. Este problema se produce sólo cuando dispone de un servidor compartido que utiliza el método de reenvío MAC.
Cuando se suprime la dirección IP del clúster, ya sea desde la interfaz Ethernet o la interfaz de bucle de retorno, se liberan todas las conexiones de esta dirección IP. Cuando el sistema operativo recibe un paquete en una conexión que se ha liberado, envía una respuesta RST al cliente y termina la conexión.
Si no puede tolerar que se cierren conexiones durante una toma de control de alta disponibilidad, no debe utilizar un servidor con ubicación compartida en sistemas operativos Windows cuando se utiliza el método de reenvío MAC.