En este capítulo se explica cómo operar y gestionar Load Balancer y se incluyen los apartados siguientes:
Load Balancer proporciona dos modos distintos de ejecutar los programas de configuración en una máquina aparte de aquella en la que reside Load Balancer. La comunicación entre los programas de configuración (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) y el servidor (dsserver, cbrserver, etc.) se puede realizar utilizando uno de estos métodos:
La ventaja de la administración remota utilizando RMI es que el rendimiento es más rápido que la administración basada en la Web.
Las ventajas de utilizar la administración basada en la Web es que proporciona administración remota, autenticada y segura y se puede comunicar con la máquina Load Balancer aún cuando esté presente un cortafuegos. Además, este método de administración no requiere la instalación y el uso de claves de autenticación (lbkeys) en la máquina cliente remota que se comunica con la máquina Load Balancer.
Para RMI, el mandato para conectar con una máquina de Load Balancer para la administración remota es dscontrol host:sistema_principal_remoto.
Si la llamada a RMI procede de una máquina que no sea la máquina local, debe producirse una secuencia de autenticación de clave pública/privada antes de que sea aceptado el mandato de configuración.
La comunicación entre los programas de control que se ejecutan en la misma máquina que los servidores del componente no se autentica.
Utilice este mandato para generar claves públicas y privadas que se van a utilizar para autenticación remota:
lbkeys [create|delete]
Este mandato se ejecuta sólo en la misma máquina que Load Balancer.
Utilizando la opción create se crea una clave privada en el directorio de claves de servidores:
El script también crea claves públicas en el directorio de claves de administración para cada de componente de Load Balancer:
El nombre de archivo para la clave pública es: componente-DirecciónServidor-puertoRMI. Estas claves públicas deben transportarse entonces a los clientes remotos y colocarse en el subdirectorio keys del directorio admin.
Para una máquina de Load Balancer con la dirección de nombre de sistema principal 10.0.0.25 que utiliza el puerto RMI por omisión para cada componente, el mandato lbkeys create genera estos archivos:
El conjunto de archivos de administración se ha instalado en otra máquina. Los archivos de claves públicas deben ubicarse en el directorio siguiente de la máquina cliente remota:
Ahora se autorizará al cliente remoto para configurar Load Balancer en 10.0.0.25.
Se deben utilizar estas mismas claves en todos los clientes remotos que desea autorizar para configurar Load Balancer en 10.0.0.25.
Si fuera a ejecutar de nuevo el mandato lbkeys create, se generaría un nuevo conjunto de claves públicas/privadas. Esto significaría que todos los clientes remotos que intentaran conectar con las claves anteriores no serían autorizados. La nueva clave tendría que ubicarse en el directorio correcto de los clientes a los que deseara volver a autorizar.
El mandato lbkeys delete suprime las claves privadas y públicas en la máquina servidor. Si se suprimen estas claves, no se autorizará a ningún cliente remoto para conectarse con los servidores.
Para los dos mandatos: lbkeys create y lbkeys delete, hay una opción force. La opción force suprime las indicaciones del mandato que solicitan si desea sobrescribir o suprimir las claves existentes.
Después de establecer la conexión RMI, puede comunicar entre los programas de configuración utilizando los mandatos: dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard y sswizard desde un indicador de mandatos. También puede configurar Load Balancer mediante la GUI escribiendo lbadmin en un indicador de mandatos.
Para utilizar administración basada en la Web, se necesita lo siguiente en la máquina cliente que realiza la administración remota:
Se necesita lo siguiente en la máquina de sistema principal a la que accede para realizar la administración remota basada en la Web:
Para sistemas Windows —
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\ARCHIV~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\ARCHIV~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\ARCHIV~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\ARCHIV~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*donde idioma es el subdirectorio de idioma (por ejemplo, en_US)
Para sistemas operativos AIX, HP-UX, Linux y Solaris —
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/idioma/* /opt/ibm/edge/lb/documentation/idioma/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Para ejecutar la administración basada en la Web, debe iniciarse ésta en la máquina de sistema principal de Load Balancer: emita lbwebaccess en el indicador de mandatos de la máquina de sistema principal.
También se necesita el ID de usuario y la contraseña para la máquina de host a la que va a acceder de forma remota. El ID de usuario y la contraseña son los mismos que para la administración de Caching Proxy.
Para presentar la administración basada en la Web de Load Balancer, acceda a esta dirección URL en el navegador Web de la ubicación remota:
http://nombre_host/lb-admin/lbadmin.html
Donde nombre_sistema_principal es el nombre de la máquina a la que va a acceder para comunicarse con Load Balancer.
Una vez que se ha cargado la página Web, aparecerá la GUI de Load Balancer en la ventana del navegador para que realice la administración remota basada en la Web.
Desde la GUI de Load Balancer, también puede emitir mandatos de control de configuración. Para emitir un mandato desde la GUI:
Renovación de la configuración de forma remota
Con la administración remota basada en la Web, si hay varios administradores actualizando la configuración de Load Balancer desde otras ubicaciones, tendrá que renovar la configuración para consultar (por ejemplo) el clúster, el puerto o el servidor que otro administrador ha añadido (o suprimido). La GUI de administración remota basada en la Web proporciona una función de Renovar configuración y Renovar todas las configuraciones.
Desde la GUI basada en la Web, para renovar la configuración
Load Balancer coloca las entradas en unas anotaciones cronológicas de servidor, unas anotaciones cronológicas de gestor, unas anotaciones cronológicas de supervisor de métrica (anotación de comunicaciones con agentes de Metric Server) y unas anotaciones cronológicas para cada asesor que utilice.
Puede establecer el nivel de anotaciones para definir la expansividad de los mensajes grabados en el archivo de anotaciones cronológicas. Al nivel 0, se registran los errores y Load Balancer también registra las cabeceras y los registros de sucesos que sólo se producen una vez (por ejemplo un mensaje sobre un asesor que empieza a escribirse en las anotaciones cronológicas de servidor). El nivel 1 incluye la información en curso y, así sucesivamente, con el nivel 5 incluyendo todos los mensajes producidos para ayudar a depurar un problema si es necesario. El valor predeterminado para las anotaciones cronológicas de gestor, asesor, servidor o subagente es 1.
También puede establecer el tamaño máximo de unas anotaciones cronológicas. Cuando se establece un tamaño máximo para el archivo de anotaciones cronológicas, el texto del archivo vuelve al principio; es decir, cuando el archivo alcanza el tamaño especificado, las entradas subsiguientes se anotarán al principio del archivo y se grabarán encima de las entradas de anotaciones cronológicas anteriores. No puede establecer el tamaño de archivo de anotaciones cronológicas en un valor que sea menor que el actual. Las entradas de anotación cronológica tienen la indicación de fecha y hora de modo que puede saber el orden en que se han escrito.
Cuanto más alto establezca el nivel de anotaciones, debería escoger con más cuidado el tamaño de archivo de anotaciones cronológicas. En el nivel 0, probablemente sea seguro dejar el tamaño de archivo de anotaciones cronológicas con el valor predeterminado de 1 MB; no obstante, cuando realiza las anotaciones a nivel 3 y superior, limite el tamaño sin hacerlo demasiado pequeño para que resulte de utilidad.
De forma predeterminada, las anotaciones cronológicas generadas por Load Balancer se almacenan en el directorio logs de la instalación de Load Balancer. Para cambiar esta vía de acceso, establezca la variable lb_logdir en el script dsserver.
Sistemas AIX, HP-UX, Linux y Solaris: El script dsserver se encuentra en el directorio /usr/bin. En este script, la variable lb_logdir está establecida en el directorio predeterminado. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
LB_LOGDIR=/víaAcceso/a/mis/anotaciones/
Sistemas Windows: el archivo dsserver se encuentra en el directorio <raíz_instalación>ibm\edge\lb\bin. En el archivo dsserver, la variable lb_logdir está establecida en el directorio predeterminado. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
set LB_LOGDIR=c:\víaAcceso\a\mis\anotaciones\
Para todos los sistemas operativos, asegúrese de que no haya espacios a ambos lados del signo igual y que la vía de acceso finaliza con una barra inclinada o invertida ("/" o "\") según sea adecuado.
Registro cronológico en binario
La característica de registro cronológico en binario de Load Balancer utiliza el mismo directorio de anotaciones cronológicas que los demás archivos de anotaciones cronológicas. Consulte Utilización del registro cronológico binario para analizar estadísticas de servidor.
Puede establecer el nivel de anotaciones para definir la expansividad de los mensajes grabados en el archivo de anotaciones cronológicas. En el nivel 0, se anotan los errores y Load Balancer anota también las cabeceras y los registros de sucesos que suceden sólo una vez (por ejemplo, un mensaje sobre un asesor que se empieza a grabar en el archivo de anotaciones cronológicas del consultor). El nivel 1 incluye la información en curso y, así sucesivamente, con el nivel 5 incluyendo todos los mensajes producidos para ayudar a depurar un problema si es necesario. El valor predeterminado para los archivos de anotaciones cronológicas es 1.
También puede establecer el tamaño máximo de unas anotaciones cronológicas. Si establece un tamaño máximo para el archivo de anotaciones cronológicas, el archivo se envolverá; cuando el archivo alcance el tamaño especificado, las entradas subsiguientes se grabarán al principio del archivo, sobrescribiendo las entradas del archivo de anotaciones cronológicas anteriores. No puede establecer el tamaño de archivo de anotaciones cronológicas en un valor que sea menor que el actual. Las entradas de anotación cronológica tienen la indicación de fecha y hora de modo que puede saber el orden en que se han escrito.
Cuanto más alto establezca el nivel de anotaciones, debería escoger con más cuidado el tamaño de archivo de anotaciones cronológicas. En el nivel 0, probablemente sea seguro dejar el tamaño de archivo de anotaciones cronológicas con el valor por omisión de 1MB; no obstante, cuando realiza las anotaciones a nivel 3 y superior, limite el tamaño sin hacerlo demasiado pequeño para que resulte de utilidad.
Controlador Cisco CSS y Controlador Nortel Alteon tienen anotaciones cronológicas como se detalla a continuación:
A continuación figura un ejemplo de cómo configurar el nivel de anotaciones y el tamaño máximo de las anotaciones cronológicas para el archivo de anotaciones cronológicas del supervisor de métrica que anota las comunicaciones con agentes Metric Server:
xxxcontrol metriccollector set IDconsultor:IDservicio:nombreMétrica loglevel x logsize y
Por omisión, las anotaciones cronológicas generadas por los controladores se almacenarán en el directorio logs de la instalación del controlador. Para cambiar esta vía de acceso, establezca la variable xxx_logdir en el script xxxserver.
Sistemas AIX, HP-UX, Linux y Solaris: el script xxxserver se encuentra en el directorio /usr/bin. En este script, la variable xxx_logdir está establecida en el directorio por omisión. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
xxx_LOGDIR=/víaAcceso/a/mis/anotaciones/
Sistemas Windows: el archivos xxxserver se encuentra en el directorio <raíz_instalación>ibm\edge\lb\bin. En el archivo xxxserver, la variable xxx_logdir está establecida en el directorio por omisión. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
set xxx_LOGDIR=c:\víaAcceso\a\mis\anotaciones\
Para todos los sistemas operativos, asegúrese de que no haya espacios a ambos lados del signo igual y que la vía de acceso finaliza con una barra inclinada o invertida ("/" o "\") según sea adecuado.
Registro cronológico en binario
La característica de registro cronológico en binario de Load Balancer utiliza el mismo directorio de anotaciones cronológicas que los demás archivos de anotaciones cronológicas. Consulte Utilización del registro cronológico binario para analizar estadísticas de servidor.
En este apartado se describe cómo operar y gestionar el componente Dispatcher.
Para Load Balancer, se considera que las conexiones están inactivas cuando no ha habido actividad en esa conexión durante el número de segundos especificado en el tiempo de espera sin actividad. Cuando se haya excedido el número de segundos sin actividad, Load Balancer eliminará ese registro de conexión de las tablas y se descartará el tráfico subsiguiente para esa conexión.
A nivel de puerto, por ejemplo, puede especificar el valor de tiempo de espera sin actividad en el mandato dscontrol port set staletimeout.
El tiempo de espera sin actividad se puede establecer a nivel de ejecutor, clúster y puerto. A nivel de ejecutor y de clúster, el valor por omisión son 300 segundos y se filtra hasta el puerto. A nivel de puerto, el valor por omisión depende del puerto. Algunos puertos bien definidos tienen valores distintos de tiempo de espera sin actividad. Por ejemplo, el puerto telnet 23 tiene un valor por omisión de 259,200 segundos.
Algunos servicios también pueden tener valores de tiempo de espera sin actividad (staletimeout) propios. Por ejemplo, LDAP (Lightweight Directory Access Protocol) tiene un parámetro de configuración denominado idletimeout. Cuando se han superado idletimeout segundos, se forzará el cierre de una conexión de cliente desocupado. También se puede establecer idletimeout en 0, lo que significa que nunca se forzará el cierre de la conexión.
Se pueden producir problemas de conectividad si el valor de tiempo de espera sin actividad de Load Balancer es menor que el valor de tiempo de espera del servicio. En el caso de LDAP, el valor de tiempo de espera sin actividad de Load Balancer toma por omisión 300 segundos. Si no hay actividad en la conexión durante 300 segundos, Load Balancer eliminará el registro de conexión de sus tablas. Si el valor de idletimeout es mayor que 300 segundos (o está establecido en 0), el cliente todavía cree que tiene una conexión con el servidor. Cuando el cliente envíe paquetes, Load Balancer los descartará. Esto provocará que se cierre la comunicación de LDAP cuando se realice una solicitud al servidor. Para evitar este problema, establezca el tiempo de espera sin actividad de LDAP en un valor distinto de cero que sea igual o menor que el valor de tiempo de espera sin actividad de Load Balancer.
Un cliente envía un paquete FIN después de que ha enviado todos sus paquetes, para que el servidor sepa que ha finalizado la transacción. Cuando Dispatcher recibe el paquete FIN, marca la transacción de estado activo a estado FIN. Cuando una transacción se marca como FIN, se puede borrar la memoria reservada para la conexión.
Con el fin de mejorar el rendimiento de la asignación y reutilización del registro de conexión, utilice el mandato executor set fintimeout para controlar el período durante el cual Dispatcher conservará conexiones en el estado FIN, activas en las tablas de Dispatcher y aceptando tráfico. Cuando una conexión en el estado FIN supera el tiempo de espera de conexiones finalizadas, se eliminará de las tablas de Dispatcher y estará preparada para reutilizarse. Puede cambiar el tiempo de espera de FIN utilizando el mandato dscontrol executor set fincount.
Utilice el mandato dscontrol executor set staletimeout con el fin de controlar el período durante el que Dispatcher debería conservar conexiones en el estado de establecidas, cuando no se haya visto tráfico activo en las tablas de Dispatcher ni aceptar tráfico. Consulte el apartado Utilización del valor de tiempo de espera sin actividad para obtener más información.
Se pueden mostrar distintos diagramas según la información del ejecutor y transmitirse al gestor. (La opción de menú Supervisar de la GUI requiere que la función de gestor esté en ejecución):
Un sistema de gestión de red es un programa que se ejecuta continuamente y se utiliza para supervisar, reflejar el estado y controlar una red. El conocido protocolo SNMP (Protocolo simple de gestión de red) para comunicarse con dispositivos en red, es el estándar de gestión de red actual. Los dispositivos de red normalmente tienen un agente SNMP y uno o más subagentes. El agente SNMP se comunica con la estación de gestión de red o responde a las peticiones SNMP de línea de mandatos. El subagente SNMP recupera y actualiza datos y proporciona esos datos al agente SNMP para comunicarse de nuevo con el solicitante.
Dispatcher proporciona una Management Information Base (ibmNetDispatcherMIB) SNMP y un subagente SNMP. Esto permite utilizar cualquier sistema de gestión de red, como -- Tivoli NetView, Tivoli Distributed Monitoring o HP OpenView -- para supervisar el estado, el rendimiento y la actividad de Dispatcher. Los datos MIB describen el Dispatcher que se va a gestionar y reflejan el estado actual de Dispatcher. MIB se instala en el subdirectorio ..lb/admin/MIB.
El sistema de gestión de red utiliza mandatos GET SNMP para detectar valores de MIB en otras máquinas. Luego el sistema puede notificarle si se han superado los valores de umbral especificados. Usted puede entonces influir en el rendimiento de Dispatcher, modificando los datos de configuración de Dispatcher, para ajustar de forma proactiva o corregir problemas de Dispatcher antes de que se conviertan en caídas de Dispatcher o del servidor Web.
El sistema suele proporcionar un agente SNMP para cada estación de gestión de red. El usuario envía un mandato GET al agente SNMP. A cambio, este agente SNMP envía un mandato GET para recuperar los valores de la variable MIB especificada de un subagente encargado de esas variables MIB.
Dispatcher proporciona un subagente que actualiza y recupera datos MIB. El subagente responde con los datos MIB adecuados cuando el agente SNMP envía un mandato GET. El agente SNMP comunica los datos a la estación de gestión de red. La estación de gestión de red puede notificarle si se han superado los valores de umbral especificados.
El soporte SNMP de Dispatcher incluye un subagente SNMP que utiliza la posibilidad DPI (Distributed Program Interface). DPI es una interfaz entre un agente SNMP y sus subagentes. El sistema operativo Windows utiliza el agente de ampliación de Windows como una interfaz entre el agente SNMP y sus subagentes.
Los sistemas AIX proporcionan un agente SNMP que utiliza el protocolo SMUX (SNMP Multiplexer) y proporciona DPID2, que es un ejecutable adicional que funciona como un conversor entre DPI y SMUX.
En sistemas HP-UX, debe obtener un agente SNMP que sea compatible con SMUX puesto que HP-UX no proporciona ninguno. Load Balancer proporciona DPID2 para sistemas HP-UX.
Los sistemas Linux proporcionan un agente SNMP que utiliza SMUX. La mayoría de las versiones Linux (por ejemplo, Red Hat) vienen con un paquete UCD SNMP. UCD SNMP versión 4.1 o posteriores tienen agentes compatibles con SMUX. Load Balancer proporciona DPID2 para sistemas Linux.
En sistemas Solaris, debe obtener un agente SNMP que sea compatible con SMUX puesto que Solaris no proporciona ninguno. Load Balancer proporciona DPID2 para sistemas Solaris. en el directorio /opt/ibm/edge/lb/servers/samples/SNMP.
El agente DPI debe ejecutarse como un usuario root. Antes de ejecutar el daemon de DPID2, actualice el archivo /etc/snmpd.peers y /etc/snmpd.conf como se detalla a continuación:
En sistemas AIX y Solaris:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
En sistemas Linux:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_passwordAdemás, debe poner como comentario todas las líneas del archivo snmpd.conf que comienzan por estas palabras: com2sec, group, view o access.
Para instalar el soporte de SNMP de HP-UX:
Para utilizar SNMP de Load Balancer con sistemas SuSE Linux, debe realizar lo siguiente:
Renueve snmpd (si aún está en ejecución) para que vuelva a leer el archivo snmpd.conf:
refresh -s snmpd
Inicie el DPID SMUX del igual:
dpid2
Los daemons deben iniciarse en el orden siguiente:
Para instalar el soporte de SNMP de Solaris:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
En el sitio Web http://sunfreeware.com/, los nombres tienen una extensión de .gz, por lo tanto no utilice gunzip/untar con éstos. En su lugar, utilice pkgadd nombrePaquete.
Para instalar el soporte de SNMP de Windows:
Con el ejecutor en ejecución, utilice el mandato dscontrol subagent start [nombrecomunidad] para definir el nombre de comunidad utilizado entre el agente de extensión del SO Windows y el agente SNMP.
IMPORTANTE: En Windows 2003, por omisión SNMP no responde a ningún nombre de comunidad presentado. En tal caso, el subagente SNMP no responderá a ninguna petición SNMP. Para asegurarse de que el subagente SNMP responderá al nombre de comunidad, debe establecer las propiedades del servicio SNMP con el nombre de comunidad adecuado y el sistema o los sistemas principales de destino. Configure las propiedades de seguridad SNMP como se detalla a continuación:
SNMP se comunica enviando y recibiendo condiciones de excepción, mensajes enviados por dispositivos gestionados para informar de condiciones de excepción o de la aparición de sucesos significativos, como un umbral alcanzado.
El subagente utiliza estas condiciones de excepción:
La condición de excepción indHighAvailStatus anuncia que el valor de la variable de estado de alta disponibilidad (hasState) ha cambiado. Los valores posibles de hasState son:
La condición de excepción indSrvrGoneDown anuncia que el peso del servidor especificado por la parte csID (ID de clúster), psNum (número de puerto) y ssID (ID de servidor) del identificador de objeto ha alcanzado cero. El último número conocido de conexiones activas del servidor se envía en la condición de excepción. Esta condición de excepción indica que, en lo que puede determinar Dispatcher, se ha quedado inactivo el servidor especificado.
La condición de excepción indDOSAttack indica que numhalfopen, el número de conexiones medio abiertas que constan sólo de paquetes SYN, ha superado el umbral maxhhalfopen del puerto especificado por la parte csID (ID de clúster) y psNum (número de puerto) del identificador de objeto. El número de servidores configurados en el puerto se envía en la condición de excepción. Esta condición de excepción indica que Load Balancer puede estar experimentando un ataque para rechazo de servicio.
La condición de excepción indDOSAttackDone indica que numhalfopen, el número de conexiones medio abiertas que constan sólo de paquetes SYN, ha caído por debajo del umbral maxhalfopen del puerto especificado por la parte csID y psNum del identificador de objeto. El número de servidores configurados en el puerto se envía en la condición de excepción. Cuando Load Balancer determina que ha finalizado el posible ataque para rechazo de servicio, se enviará esta condición de excepción después de que se envíe una condición de excepción indDOSAttack.
Para sistemas operativos AIX, HP-UX, Linux y Solaris, debido a una limitación en la API de SMUX, el identificador de empresa del que se informa en condiciones de excepción del subagente ibmNetDispatcher podría ser el identificador de empresa de dpid2, en lugar del identificador de empresa de ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. No obstante, los programas de utilidad de gestión de SNMP podrán determinar el origen de la condición de excepción porque los datos contendrán un identificador de objeto desde dentro del MIB de ibmNetDispatcher.
El mandato dscontrol subagent start activa el soporte de SNMP. El mandato dscontrol subagent stop desactiva el soporte de SNMP.
Si desea más información sobre el mandato dscontrol, consulte el apartado dscontrol subagent — configurar subagente SNMP.
En el kernel de Linux hay un recurso de cortafuegos incorporado denominado ipchains. Cuando Load Balancer e ipchains se ejecutan simultáneamente, Load Balancer detecta primero los paquetes, seguidos de ipchains. Esto permite el uso de ipchains para proteger una máquina Load Balancer de Linux, que puede ser, por ejemplo, una máquina de Load Balancer que se utiliza para equilibrar la carga de los cortafuegos.
Cuando se configuran ipchains o iptables como totalmente restringidos (no se permite tráfico de entrada o de salida), la parte de reenvío de paquetes de Load Balancer continúa funcionando normalmente.
Recuerde que no pueden utilizarse ipchains e iptables para filtrar el tráfico de entrada antes de que se equilibre de carga.
Se debe permitir tráfico adicional para que todo Load Balancer funcione correctamente. Algunos ejemplos de esta comunicación son:
En general, una estrategia de ipchains adecuada para las máquinas de Load Balancer es no permitir todo el tráfico, excepto que sea hacia o desde los servidores de fondo, el Load Balancer de asociados de alta disponibilidad, los destinos de alcance o los hosts de configuración.
No s recomienda activar iptables cuando se ejecuta Load Balancer en el kernel de Linux versión 2.4.10.x. La activación en esta versión de kernel de Linux puede producir con el tiempo la degradación del rendimiento.
Para desactivar iptables, enumere los módulos (lsmod) con el fin de comprobar qué módulo utilizan ip_tables e ip_conntrack, luego elimínelas emitiendo rmmod ip_tables y rmmod ip_conntrack. Cuando reinicie la máquina estos módulos se añadirán de nuevo, de modo que tendrá que repetir este paso cada vez que reinicie la máquina.
Para obtener más información, consulte Problema: en sistemas Linux, iptables puede impedir el direccionamiento de paquetes.
En este apartado se describe cómo operar y gestionar el componente CBR de Load Balancer.
CBR y Caching Proxy colaboran utilizando la API del plug-in de Caching Proxy para gestionar peticiones HTTP y HTTPS (SSL). Caching Proxy debe ejecutarse en la misma máquina para que CBR comience a equilibrar la carga de los servidores. Configure CBR y Caching Proxy como se describe en el apartado Ejemplo de configuración CBR.
Después de iniciar CBR, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por CBR son similares a los que se utilizan en Dispatcher. Para obtener más información, consulte el apartado Utilización de anotaciones cronológicas de Load Balancer.
En releases anteriores, para CBR podía cambiar la vía de acceso al directorio de archivos de anotaciones cronológicas en el archivo de configuración de Proxy de memoria caché. Ahora puede cambiar la vía de acceso al directorio donde se almacena el archivo de anotaciones cronológicas en el archivo cbrserver. Consulte el apartado Cambio de las vías de acceso del archivo de anotaciones cronológicas.
Después de iniciar Site Selector, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por Site Selector son similares a los que se utilizan en Dispatcher. Para obtener una mayor descripción, consulte el apartado Utilización de anotaciones cronológicas de Load Balancer.
Después de iniciar Controlador Cisco CSS, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por Controlador Cisco CSS son similares a los que se utilizan en Dispatcher. Para obtener una mayor descripción, consulte el apartado Utilización de anotaciones cronológicas de Load Balancer.
Después de iniciar Controlador Nortel Alteon, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por Controlador Nortel Alteon son similares a los que se utilizan en Dispatcher. Para obtener una mayor descripción, consulte el apartado Utilización de anotaciones cronológicas de Load Balancer.
Metric Server proporciona información de carga de servidor a Load Balancer. Metric Server reside en cada uno de los servidores de los que se está equilibrando la carga.
Sistemas Linux y UNIX:
Sistemas Windows:
Pulse Inicio > Panel de control > Herramientas administrativas > Servicios. Pulse con el botón derecho del ratón IBM Metric Server y seleccione Inicio. Para detener el servicio, efectúe los mismos pasos y seleccione Detener.
Cambie el nivel de anotaciones en el script de inicio de Metric Server. Puede especificar un rango de nivel de anotaciones cronológicas de 0 a 5, similar al rango de nivel de anotaciones cronológicas de Load Balancer. Esto generará un archivo de anotaciones cronológicas agente en el directorio ...ms/logs.