Utilice la información proporcionada para ayudar a solucionar problemas que pueden producirse en direccionador basado en contenido.
Síntoma | Causa posible |
---|---|
Dispatcher no se ejecuta correctamente | Números de puerto en conflicto |
Conexiones de máquinas cliente no atendidas o que han superado el tiempo de espera |
|
Dispatcher, Microsoft IIS y SSL no funcionan o no continuarán | No se han podido enviar datos cifrados entre protocolos |
El mandato dscontrol o lbadmin ha dado un error e indica el mensaje ‘El servidor no responde' o ‘No es posible acceder al servidor RMI' |
|
Los asesores no funcionan correctamente | Los asesores no se están ejecutando |
Mensaje de error “No se encuentra el archivo..." al ejecutar Netscape como navegador predeterminado para ver ayuda en línea (plataforma Windows) | Valor incorrecto para la asociación de archivo HTML |
La interfaz gráfica de usuario no se inicia correctamente | Espacio de paginación insuficiente |
La interfaz gráfica de usuario no se muestra correctamente. | La resolución es incorrecta. |
Los paneles de ayuda a veces desaparecen detrás de otras ventanas | Limitación de Java™ |
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. | Java no tiene acceso a suficiente memoria para manejar un cambio tan grande en la GUI |
La interfaz coreana de Load Balancer muestra fonts que se solapan o no deseados en los sistemas AIX y Linux | Se deben cambiar los fonts predeterminados |
Comportamiento inesperado de la GUI al utilizar la plataforma Windows emparejada con la tarjeta de vídeo Matrox AGP | Se produce un problema cuando se utilizan tarjetas de vídeo Matrox AGP al ejecutar la GUI de Load Balancer |
Tiempo de respuesta lento cuando se ejecutan mandatos en la máquina de Dispatcher | El tiempo de respuesta lento puede deberse a una sobrecarga de la máquina por un alto volumen de tráfico del cliente |
El asesor SSL o HTTPS no registra cargas del servidor | Se produce el problema porque la aplicación servidor SSL no se ha configurado con la dirección IP del clúster |
En la plataforma Windows, aparecen en el indicador de mandatos caracteres nacionales Latin-1 dañados | Cambie las propiedades de font de la ventana de indicador de mandatos |
En la plataforma Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores | No está inhabilitada Task Offload (Descarga de tareas) o quizá tenga que habilitarse ICMP. |
En la plataforma Windows, los asesores no funcionan en una configuración de alta disponibilidad después de una caída de red | Cuando el sistema detecta una caída de la red, borra la memoria caché ARP (Address Resolution Protocol) |
En sistemas Linux, el mandato "IP address add" y varios alias de bucle de retorno de clúster son incompatibles | Cuando cree alias para más de una dirección en el dispositivo de bucle de retorno, debería utilizar el mandato ifconfig, no ip address add |
En sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de la sesión de terminal desde la que se han iniciado | Utilice el mandato nohup para impedir que los procesos que ha iniciado reciban una señal de cierre de comunicación cuando sale de la sesión de terminal. |
Se produce una ralentización cuando se cargan configuraciones de Load Balancer | El retardo puede deberse a llamadas al Sistema de nombres de dominio (DNS) que se realizan para resolver y verificar la dirección de servidor. |
En sistemas Windows, aparece este mensaje de error: Hay un conflicto de dirección IP con otro sistema en la red | Si se configura la alta disponibilidad, podrían configurarse direcciones del clúster en las dos máquinas por un breve período lo que produce que aparezca este mensaje de error. |
En sistemas Windows, se produce el error "El servidor no responde" cuando se emite un mandato dscontrol o lbadmin | Cuando existe más de una dirección IP en un sistema Windows y el archivo de host no especifica la dirección que se va a asociar al nombre de host. |
Limitaciones de configuración de reenvío MAC de Dispatcher con las plataformas zSeries y S/390 | En Linux, existen limitaciones al utilizar servidores zSeries o S/390 que tienen tarjetas OSA (Open System Adapter). Se proporcionan soluciones alternativas posibles. |
En sistemas Linux, iptables puede interferir con el direccionamiento de paquetes | iptables en Linux pueden dificultar el equilibrio de carga y debe estar inhabilitado en la máquina de Load Balancer. |
En sistemas Solaris, al intentar configurar un servidor IPv6 en la máquina Dispatcher, aparece un mensaje indicando que no se puede añadir servidor | Esto se puede producir por la forma en que el sistema operativo Solaris maneja la solicitud de ping para una dirección IPv6. |
Actualización del conjunto de archivos Java que se proporciona con las instalaciones de Load Balancer | Si se detecta un problema con el conjunto de archivos Java, debe notificarlo al servicio de IBM® para así poder recibir una actualización para el conjunto de archivos Java que se proporcionó con la instalación de Load Balancer. |
No se pueden realizar las peticiones del cliente al reenviar a los servidores HP-UX finales | Después de configurar Load Balancer para IPv6 en el sistema operativo HP-UX, las peticiones del cliente a la dirección de clúster producen un error. Este error es una consecuencia de la interacción entre la función de descubrimiento cercano para el sistema operativo y el Load Balancer. |
El componente Load Balancer para IPv4 e IPv6 entra en conflicto con la seguridad IP (IPsec) | Si está utilizando Load Balancer para IPv4 e IPv6 con la seguridad IP (IPsec) habilitada, los paquetes de salida podrían ser incorrectos y la información de configuración de Dispatcher podría mostrarse incorrectamente en la interfaz de línea de mandatos y en la consola administrativa de WebSphere Application Server. Load Balancer informa que se reenvían conexiones, pero los clientes no reciben repuestas. |
Podría ejecutarse el script serverUp al emitir mandatos para Load Balancer que afectan el estado de los servidores | Podría sufrir problemas si ejecuta un mandato que afecta el estado de un servidor, como los mandatos dscontrol manager unquiesce y dscontrol manager quiesce, después de que un ciclo del gestor ya ha recuperado los pesos de los servidores. Si ejecuta estos mandatos, podría sobrescribir los valores que se guardan durante el ciclo del gestor y provocar que el script serverUp se ejecute inesperadamente. |
Este problema puede producirse si otra aplicación utiliza uno de los puertos utilizados por Load Balancer. Para obtener más información, lea el tema configuración de la máquina de Load Balancer.
Utilice netstat
-ni para realizar la comprobación.
Utilice netstat
-nr para realizar la comprobación.
Cuando utiliza Dispatcher, Microsoft IIS y SSL, si no funcionan juntos, quizá 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.
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 emite mandatos dscontrol, podrían aparecer 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"
LB_ADV_NO_PING="true"
java -DLB_ADV_NO_PING="true"
Para las plataformas Windows, al utilizar Netscape como navegador predeterminado, puede aparecer el mensaje de error siguiente: "No se encuentra 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".
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 experimenta problemas con la apariencia de la GUI de Load Balancer, compruebe el valor de la resolución del escritorio del sistema operativo. La GUI se visualiza mejor con una resolución de 1024x768 píxeles.
En la plataforma Windows, cuando se abren ventanas de ayuda por primera vez, a veces desaparecen en el fondo detrás de ventanas existentes. Si esto sucediera, pulse en la ventana para traerla de nuevo al frente.
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.
Existe una opción en el tiempo de ejecución que puede especificarse para aumentar la agrupación de asignación de memoria disponible en 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. Solaris 8 tiene un valor máximo de 4000 M.
java -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.
-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 la plataforma Windows, al utilizar una tarjeta Matrox AGP, puede aparecer 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.
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.
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 petición del cliente al servidor.
De forma predeterminada, cuando el sistema operativo Windows detecta una caída de la red, borra su memoria caché ARP (Address Resolution Protocol), 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.
Este problema se soluciona si se impide 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 realizar esta tarea. Este artículo está en el sitio web de Microsoft y se encuentra en la Base de conocimientos de Microsoft, número de artículo 239924: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Se deben tener en cuenta determinadas consideraciones al utilizar los servidores Linux kernel 2.4.x. 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.
ifconfig lo:núm dirección_clú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.
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 lleva mucho tiempo, esto originará 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.
Para resolver este problema, actualice el nombre de sistema principal de su archivo c:\Windows\system32\drivers\etc\hosts con el nombre de host de la máquina y la dirección IP que desee asociar al nombre de host.
dscontrol host@@<dirección_ip o nombre_host> <mandato>
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 fondo está en una tarjeta OSA diferente de la de Load Balancer. La tarjeta OSA para el servidor de fondo anuncia la dirección OSA MAC para el IP de servidor, pero cuando llega un paquete con la dirección de destino ethernet de OSA del servidor y el IP del clúster, la tarjeta OSA del servidor no sabe cuál de los hosts, si existen, debe recibir ese 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:
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 encapsulamiento de Load Balancer, que es un protocolo que permite a Load Balancer realizar reenvíos a través de direccionadores.
Al utilizar encapsulamiento, Load Balancer recibe el paquete de IP cliente-> a 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.
Consulte el tema Uso del reenvío de encapsulamiento para reenviar tráfico a través de segmentos de red para obtener más información acerca de cómo configurar Load Balancer para reenviar con encapsulamiento.
iptables en Linux pueden dificultar el equilibrio de carga y debe estar inhabilitado en la máquina de Dispatcher.
lsmod | grep ip_tables
La salida del mandato anterior podría similar a esta:
ip_tables 22400 3
iptable_mangle,iptable_nat,iptable_filter
Emita el mandato siguiente para cada iptable enumerada en la salida para mostrar
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 estas dos iptables:
rmmod iptable_nat iptable_conntrack
n sistemas Solaris, al intentar configurar un servidor IPv6 en una instalación de Websphere Load Balancer para IPv4 y IPv6 puede recibir el mensaje no se puede añadir el servidor. Esto se puede producir por la forma en que el sistema operativo Solaris maneja la petición de ping para una dirección IPv6.
Cuando se añade un servidor a la configuración, Load Balancer intenta comunicarse con un mandato ping con el servidor para obtener la dirección MAC del servidor. La máquina Solaris puede elegir una dirección de clúster configurada como la dirección de origen de la solicitud ping, en lugar de utilizar la dirección NFA de la máquina. Si la dirección de clúster se ha configurado en el bucle de retorno del servidor, la respuesta al mandato ping no se recibe en la máquina de Load Balancer; por lo tanto, no añade el servidor a la configuración.
La solución es configurar otra dirección IPv6 en la máquina de Load Balancer antes o después de configurar la dirección de clúster IPv6. Esta dirección debe ser una dirección que no tenga un alias en el bucle de retorno del servidor de programa de fondo que se trata de añadir a la configuración de Load Balancer. A continuación, añada el servidor a la configuració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 debería actualizar a esta versión del conjunto de archivos Java usted solo. 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.
Después de configurar Load Balancer para IPv6 en el sistema operativo HP-UX, las peticiones del cliente a la dirección de clúster producen un error. Este error es una consecuencia de la interacción entre la función de descubrimiento cercano para el sistema operativo y el Load Balancer.
Al añadir un servidor final a la configuración, Load Balancer intenta comunicarse con un mandato ping con el nuevo servidor para obtener la dirección MAC. El servidor HP-UX puede elegir una dirección de clúster configurada como la dirección de origen de la petición ping, en lugar de utilizar la dirección de no reenvío (NFA, nonforwarding address) de la máquina. En este caso, se crea una nueva entrada para la dirección de clúster en la tabla de direccionamiento del servidor HP-UX de fondo además de la entrada de bucle de retorno local. La entrada nueva tiene una prioridad de direccionamiento mayor que el bucle de retorno local. Así, las peticiones de cliente que alcanzan el servidor final se redirigen luego de nuevo al servidor de Load Balancer, que no responde.
Para solucionar este problema, después de que se configura completamente Load Balancer, configure el alias de bucle de retorno en el servidor final como paso final. Si se asigna un alias a la dirección de clúster en el bucle de retorno cuando se carga la configuración de Load Balancer, elimine completamente el alias de bucle de retorno del clúster en el servidor final y vuelva a asignarlo un alias. Para desactivar el alias del bucle de retorno, utilice el mandato ifconfig lo0:1 inet6 desde la ventana de terminal. Vuelva a asignar un alias al bucle de retorno.
Si está utilizando Load Balancer con la seguridad IP (IPsec) habilitada, los paquetes de salida podrían ser incorrectos y la información de configuración de Dispatcher podría mostrarse incorrectamente en la interfaz de línea de mandatos y en la consola administrativa de WebSphere Application Server. Load Balancer informa que se reenvían conexiones, pero los clientes no reciben repuestas.
Si utiliza la función de Load Balancer y la seguridad IP en el mismo host, podría haber problemas de comunicación entre Load Balancer y el servidor de aplicaciones. El componente Load Balancer no es completamente compatible con las características de IPsec y transmite los datos desde los dos lados de la capa de seguridad. Load Balancer recibe los paquetes bajo IPsec y, a raíz de ello, recibe los paquetes cifrados que no descifra. Cuando se envían datos, Load Balancer los transmite en IPsec, de modo que envía paquetes sin cifrar al servidor de aplicaciones que los cifra en el otro extremo IPsec. El servidor de aplicaciones, por lo tanto, recibe datos cifrados que no se pueden utilizar.
dscontrol manager quiesce servidor
dscontrol manager unquiesce servidor
Si se produce el mandato unquiesce después de que el
gestor ha recuperado los pesos, la función ejecutor sobrescribe el peso
utilizado para determinar si el estado del servidor ha cambiado. Este proceso no produce ningún efecto secundario
a no ser que el servidor esté desactivado temporalmente también.Las oportunidades de experimentar este problema aumentan con configuraciones de mayor tamaño porque el ciclo del gestor lleva más tiempo ejecutarse. Además, hay una probabilidad mayor de que el ciclo del gestor esté en curso cuando se emite el mandato unquiesce.