Resolución de problemas comunes—Dispatcher

Problema: Dispatcher no se ejecuta

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.

Problema: Dispatcher y el servidor no responden

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.

Problema: Las solicitudes de Dispatcher no se equilibran

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:

  1. ¿Ha configurado la dirección de no reenvío, los clústeres, los puertos y los servidores para el direccionamiento? Compruebe el archivo de configuración.
  2. ¿Se ha creado un alias de la tarjeta de interfaz de red con la dirección del clúster? Para sistemas operativos AIX, HP-UX, Linux y Solaris, utilice netstat -ni para realizar la comprobación.
  3. ¿Tiene el dispositivo de bucle de retorno de cada servidor establecido el alias en la dirección del clúster? Para sistemas operativos AIX, HP-UX, Linux y Solaris, utilice netstat -ni para realizar la comprobación.
  4. ¿Se ha suprimido la ruta adicional? Para sistemas operativos AIX, HP-UX, Linux y Solaris, utilice netstat -nr para realizar la comprobación.
  5. Utilice el mandato dscontrol cluster status para comprobar la información para cada clúster que ha definido. Asegúrese de que tiene definido un puerto para cada clúster.
  6. Utilice el mandato dscontrol server report :: para asegurarse de que ninguno de los servidores esté inactivo ni tenga establecido su peso en cero.

Para Windows y otras plataformas, consulte también Configuración de máquinas de servidor para el equilibrio de carga.

Problema: La función de alta disponibilidad de Dispatcher no funciona

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:

  1. Recopile un informe emitiendo los mandatos netstat -an y ifconfig -a en la máquina
  2. Ejecute el script goActive
  3. Ejecute el script goStandby
  4. Una vez más, recopile un informe emitiendo los mandatos netstat -an y ifconfig -a

Los dos informes serán idénticos si se han configurado correctamente los scripts.

Problema: No se puede añadir pulso (plataforma Windows)

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.

Problema: Los asesores no funcionan correctamente

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.

Problema: en un servidor de programa de fondo de Windows Server 2008, el programa memload.exe se cuelga

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

Problema: Dispatcher, Microsoft IIS y SSL no funcionan (plataforma Windows)

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.

Problema: Conexión de Dispatcher a una máquina remota

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.

Problema: El mandato dscontrol o lbadmin falla

  1. El mandato dscontrol devuelve: Error: el servidor no responde. O bien, el mandato lbadmin devuelve: Error: no es posible acceder al servidor RMI. Estos errores pueden producirse si su máquina tiene una pila con SOCKS. Para corregir este problema, edite el archivo socks.cnf para incluir las líneas siguientes:
    EXCLUDE-MODULE java
    EXCLUDE-MODULE javaw
  2. Las consolas de administración para las interfaces de Load Balancer (línea de mandatos, interfaz gráfica de usuario y asistentes) se comunican con dsserver utilizando la RMI (invocación de método remoto). La comunicación predeterminada utiliza tres puertos; cada puerto se establece en el script de inicio de dsserver:

    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.

  3. También se pueden producir estos errores si aún no ha iniciado dsserver.
  4. Si hay varios adaptadores en la máquina, debe designar qué adaptador debe utilizar ese dsserver añadiendo lo siguiente en el script de dsserver:java.rmi.server.hostname=<nombre_host o dirección_IP>

    Por ejemplo: java -Djava.rmi.server.hostname="10.1.1.1"

Problema: Aparece el mensaje de error “No se puede encontrar el archivo..." al intentar ver la Ayuda en línea (plataforma Windows)

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:

  1. Pulse Mi PC, a continuación Herramientas, seleccione Opciones de carpeta y pulse la pestaña Tipos de archivo
  2. Seleccione “Documento de hipertexto de Netscape"
  3. Pulse el botón Opciones avanzadas, seleccione open, pulse el botón Editar
  4. Entre NSShell en el campo Aplicación: (no en el campo Aplicación utilizada para realizar la acción:) y pulse Aceptar

Problema: la GUI (interfaz gráfica de usuario) no se inicia correctamente

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.

Problema: error al ejecutar Dispatcher con Proxy de memoria caché instalado

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:

  1. Desinstale Proxy de memoria caché.
  2. Desinstale Load Balancer.
  3. Vuelva a instalar Load Balancer y Proxy de memoria caché.

Problema: la GUI (interfaz gráfica de usuario) no se muestra correctamente

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.

Problema: En la plataforma Windows, a veces las ventanas de ayuda desaparecen detrás de otras ventanas abiertas

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.

Problema: Load Balancer no puede procesar y reenviar una trama

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

Problema: Se visualiza una pantalla azul al inciiar el ejecutar de Load Balancer

En la plataforma Windows, debe tener instalada y configurada una tarjeta de red antes de iniciar el ejecutor.

Problema: La vía de acceso a Discovery impide el tráfico de retorno con Load Balancer

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:

/usr/sbin/no -p -o udp_pmtu_discover=0
/usr/sbin/no -p -o tcp_pmtu_discover=0

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.

Problema: La alta disponibilidad en modalidad de área amplia de Load Balancer no funciona

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:

  1. Defina un clúster adicional en el Dispatcher remoto. No es necesario definir puertos o servidores para este clúster.
  2. Añada esta dirección del clúster a los scripts goActive y goStandy.
  3. En el Dispatcher local, defina esta dirección del clúster como un servidor, en lugar de la dirección NFA del Dispatcher primario remoto.

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.

Problema: se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño

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

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.

Problema: lbadmin se desconecta del servidor después de actualizar la configuración

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.

Problema: las direcciones IP no se resuelven correctamente en la conexión remota

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.

Problema: La interfaz de Load Balancer coreana muestra fonts solapados o no deseados en sistemas AIX y Linux

Para corregir fonts solapados o no deseados en la interfaz de Load Balancer coreana:

Problema: En sistemas Windows, se devuelve la dirección de alias en lugar de la dirección local al emitir mandatos como hostname

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:

  1. Pulse Inicio > Configuración > Conexiones de red y de acceso telefónico
  2. En la opción de menú Opciones avanzadas, seleccione Configuración Avanzada...
  3. Asegúrese de que se enumera en primer lugar Conexión de área local en el recuadro Conexiones
  4. Si es necesario, utilice los botones de ordenación a la derecha para desplazar hacia arriba o abajo las entradas en la lista

Problema: En la plataforma Windows, comportamiento inesperado de la GUI al utilizar tarjetas de vídeo Matrox AGP

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.

Problema: Comportamiento inesperado al ejecutar "rmmod ibmlb" (sistemas Linux)

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.

Problema: tiempo de respuesta lento cuando se ejecutan mandatos en la máquina de Dispatcher

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.

Problema: el asesor SSL o HTTPS no registra cargas del servidor (cuando se utiliza el reenvío mac)

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.

Problema: se produce una desconexión del host si se cambia el tamaño de la ventana del navegador Netscape cuando se utiliza la administración Web

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.

Problema: En sistemas Windows, aparecen caracteres nacionales Latin-1 corruptos en la ventana de indicador de mandatos

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:

  1. Pulse en el icono en la esquina superior izquierda de la ventana de indicador de mandatos
  2. Seleccione Propiedades, luego pulse la pestaña Fuente
  3. El font predeterminado es Fuentes de mapa de bits; cambie este valor por Lucida Console y pulse Aceptar

Problema: En HP-UX, se produce un error de falta de memoria o hebra de Java

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:

  1. En la línea de mandatos, escriba: sam
  2. Seleccione Kernel Configuration (Configuración de kernel) > Configurable Parameters (Parámetros configurables)
  3. En la barra de desplazamiento, seleccione max_thread_proc
  4. Pulse la barra espaciadora para resaltar max_thread_proc
  5. Pulse el tabulador una vez y, a continuación, pulse la tecla de flecha a la derecha hasta que seleccione Actions (Acciones)
  6. Pulse Intro para mostrar el menú Actions (Acciones), luego pulse M para seleccionar Modify Configurable Parameter (Modificar parámetro configurable). Si no aparece esta opción, resalte max_thread_proc)
  7. Pulse la tecla tabuladora hasta que seleccione el campo Formula/Value (Formato/valor)
  8. Entre un valor de 256 o superior.
  9. Pulse OK (Aceptar)
  10. Pulse el tabulador una vez y, a continuación, seleccione Actions
  11. Pulse K para Process New Kernel (Procesar nuevo kernel)
  12. Seleccione Yes (Sí)
  13. Rearranque el sistema

Problema: En los sistemas Windows, los asesores y los destinos de alcance marcan todos los servidores como inactivos

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:

Problema: En la plataforma Windows, se resuelve la dirección IP en el nombre de host cuando se ha configurado más de una dirección en un adaptador

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:

  1. Inicie Regedit
  2. Modifique estos nombres de valor como se detalla a continuación:
  3. Rearranque el equipo
  4. Compruebe que el nombre de host se resuelve con la dirección IP correcta. Por ejemplo, ejecute ping SuNombreSistemaPrpal.

Problema: En sistemas Windows, después de una caída de la red, los asesores no funcionan en una configuración de alta disponibilidad

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:

  1. Utilice el Editor del Registro (regedit o regedit32) para abrir el registro.
  2. Consulte la clave siguiente del registro:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
  3. Añada este valor del registro: Nombre de valor: DisableDHCPMediaSense Tipo de valor: REG_DWORD.
  4. Después de que se añade la clave, edite el valor y establézcalo en 1.
  5. Rearranque la máquina para que el cambio entre en vigor.
Nota:
Esto influye en la memoria caché ARP independientemente del valor de DHCP.

Problema: En sistemas Linux, no utilice el mandato "IP address add" cuando cree alias para varios clústeres en el dispositivo de bucle de retorno

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.

Problema: mensaje de error "dirección del direccionador no especificada o no válida para el método del puerto"

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.

Problema: en sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de terminal desde la que se han iniciado

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.

Problema: Se produce un retardo mientras se carga una configuración de Load Balancer

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.

Problema: en sistemas Windows, aparece un mensaje de error de conflicto de dirección IP

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.

Problema: las dos máquinas, primaria y de reserva, están activas en una configuración de alta disponibilidad

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.

Problema: no se pueden realizar las solicitudes del cliente cuando el sistema intenta devolver respuestas de páginas de gran tamaño

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.

Problema: en sistemas Windows, se produce el error "el servidor no responde" cuando se emite dscontrol o lbadmin

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.

Problema: es posible que las máquinas de Dispatcher de alta disponibilidad no se puedan sincronizar en sistemas Linux para S/390 en controladores qeth

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.

Problema: sugerencias para configurar la alta disponibilidad

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.

Nota:
Para obtener información sobre cómo configurar la característica de alta disponibilidad, consulte Alta disponibilidad.

Problema: en Linux, limitaciones cuando se utilizan servidores zSeries o S/390 que disponen de tarjetas OSA (Open System Adapter)

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.

Nota:
Los túneles, como los dispositivos de canal a canal (CTC) o el vehículo de comunicación entre usuarios (IUCV) suelen recibir soporte. Sin embargo, Load Balancer debe reenviar a través del túnel directamente al destino final, no puede ser un túnel de red a red.

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.

  1. Utilizando características de plataforma

    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.

  2. Utilización de la característica GRE de Load Balancer

    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
    Nota:
    No defina la dirección de clúster en el bucle de retorno de los servidores de programa de fondo. Cuando se utilizan servidores de programa de fondo z/OS, se deben utilizar mandatos específicos de z/O2 para configurar los servidores para realizar la excapsulación GRE.

Problema: en algunas versiones de Linux, se produce una pérdida de memoria al ejecutar Dispatcher configurado con el gestor y los asesores

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

Problema: en SUSE Linux Enterprise Server 9, Dispatcher reenvía paquetes, pero los paquetes no llegan al servidor de programa de fondo

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:

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.

Nota:
Con sólo tratar de listar las reglas configuradas en una tabla se carga el módulo correspondiente; por ejemplo, iptables -t nat -L. Asegúrese de no ejecutar este mandato después de haber eliminado los módulos.

Problema: en sistemas Windows, se muestra un mensaje de conflicto de dirección IP durante la toma de control de alta disponibilidad

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

Problema: en sistemas Linux, iptables puede impedir el direccionamiento de paquetes

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

Actualización del conjunto de archivos Java con la instalación de Load Balancer

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.

Problema: pueden cerrarse conexiones permanentes durante la toma de control de alta disponibilidad

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.