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_password
Ademá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.