Versión 2.0
Document Number GC10-3180-04
Nota |
---|
Antes de utilizar esta información y el producto al que se refiere, lea la información general del Apéndice I, Avisos. |
Quinta edición (setiembre de 2001)
(C) Copyright International Business Machines Corporation. Reservados todos los derechos.
Nota para los usuarios del gobierno de los EE.UU. -- Documentación relacionada con derechos restringidos. -- El uso, duplicación o divulgación están sujetos a las restricciones establecidas en el contrato GSA ADP Schedule con IBM Corporation.
Instalación de Network Dispatcher
Presentación de Network Dispatcher
Planificación del componente Dispatcher
Configuración del componente Dispatcher
Planificación del componente Content Based Routing
Configuración del componente Content Based Routing
Planificación para el componente Mailbox Locator
Configuración del componente Mailbox Locator
Planificación para el componente Site Selector
Configuración del componente Site Selector
Planificación para el componente Consultant para Cisco CSS Switches
Configuración del componente Consultant para Cisco CSS Switches
Funciones avanzadas de Network Dispatcher
Utilización y gestión de Network Dispatcher
Apéndice A. Cómo leer un diagrama de sintaxis
Apéndice B. Consulta de mandatos para Dispatcher, CBR y Mailbox Locator
Apéndice C. Sintaxis de la norma de contenido (patrón):
Apéndice D. Consulta de mandatos de Site Selector
Apéndice E. Consulta de mandatos de Consultant para Cisco CSS Switches
Apéndice F. Ejemplos de archivos de configuración
Este manual explica la forma de planificar, instalar, configurar, utilizar y resolver problemas de IBM(R) WebSphere Edge Server Network Dispatcherpara AIX, Linux, Solaris y Windows 2000. Anteriormente, este producto se llamaba SecureWay Network Dispatcher, eNetwork Dispatcher e Interactive Network Dispatcher.
En el sitio Web de WebSphere Edge Server hallará la versión más reciente del presente manual en formato HTML y PDF. Para acceder a la publicación en línea, vaya al URL siguiente:
http://www.ibm.com/software/webservers/edgeserver/library.html
En el sitio Web de WebSphere Edge Server encontrará la información detallada más reciente referente a la manera de utilizar Network Dispatcher, a fin de aumentar al máximo el rendimiento de los servidores. Se incluyen casos prácticos y ejemplos de configuración. Para acceder a este sitio Web, vaya al URL siguiente:
http://www.ibm.com/software/webservers/edgeserver
Para obtener las actualizaciones más recientes y consejos sobre la utilización de Network Dispatcher, visite la página Web de soporte de WebSphere Edge Server y pulse Search for Network Dispatcher hints and tips. Para acceder a esta página Web, vaya al URL siguiente:
http://www.ibm.com/software/webservers/edgeserver/support.html
La información que nos proporcione nos ayuda a mejorar la precisión y la calidad de la información. Si desea realizar comentarios sobre este manual o cualquier otro documento de WebSphere Edge Server:
¿Con qué rapidez puede hacer que Network Dispatcher trabaje para usted? Considere lo siguiente:
Supongamos que usted es el administrador del sitio Web de Intersplash Corporation. Se encarga de gestionar un sitio Wel local con dos servidores HTTP. Ha estado utilizando un método rotatorio para gestionar el tráfico de los dos servidores, pero el negocio ha crecido recientemente y los clientes comienzan a quejarse de que no pueden acceder al sitio Web. ¿Qué puede hacer?
Diríjase a http://www.ibm.com/software/webservers/edgeserver y baje la última versión de Network Dispatcher. Este producto tiene cinco componentes: Dispatcher, Content Based Routing (CBR), Mailbox Locator, Site Selector y Consultant para Cisco CSS Switches (Cisco Consultant). De momento, sólo trataremos el componente Dispatcher.
Figura 1. Configuración local simple de Dispatcher
Este ejemplo de iniciación rápida muestra cómo configurar tres estaciones de trabajo conectadas localmente utilizando el método de reenvío MAC del componente Dispatcher para repartir el tráfico Web entre dos servidores Web. La configuración debe ser fundamentalmente la misma para distribuir cualquier otro tráfico de aplicación TCP o UDP sin estados.
Para el ejemplo de iniciación rápida, necesitará tres estaciones de trabajo y cuatro direcciones IP. Una estación de trabajo se utilizará como Dispatcher; las otras dos estaciones de trabajo se utilizarán como servidores Web. Cada servidor Web necesita una sola dirección IP. La estación de trabajo de Dispatcher necesita una dirección real y una dirección para repartir el tráfico.
Estación de trabajo | Nombre | Dirección IP |
---|---|---|
1 | servidor1.intersplash.com | 9.67.67.101 |
2 | servidor2.intersplash.com | 9.67.67.102 |
3 | servidor3.intersplash.com | 9.67.67.103 |
Máscara de red = 255.255.255.0 |
Cada una de las estaciones de trabajo contiene solamente una tarjeta de interfaz de red Ethernet estándar.
Nombre= www.intersplash.com IP=9.67.67.104
Añada un alias para www.intersplash.com a la interfaz de bucle de retorno en servidor2.intersplash.com y en servidor3.intersplash.com.
ifconfig lo0 alias www.intersplash.com netmask 255.255.255.0
ifconfig lo0:1 www.intersplash.com 127.0.0.1 up
Ya ha realizado todos los pasos de configuración necesarios en las dos estaciones de trabajo de servidor Web.
Con Dispatcher, puede crear una configuración mediante la línea de mandatos, el asistente para la configuración o la interfaz gráfica de usuario (GUI).
Si está utilizando la línea de mandatos, siga estos pasos:
ndcontrol executor start
ndcontrol cluster add www.intersplash.com
ndcontrol port add www.intersplash.com:80
ndcontrol server add www.intersplash.com:80:servidor2.intersplash.com
ndcontrol server add www.intersplash.com:80:servidor3.intersplash.com
ndcontrol cluster configure www.intersplash.com
ndcontrol manager start
Dispatcher comenzará a realizar el reparto del tráfico basándose en el rendimiento del servidor.
ndcontrol advisor start http 80
Dispatcher se asegurará ahora de que las peticiones de los clientes no se envíen a un servidor Web anómalo.
Ha finalizado la configuración básica con servidores conectados localmente.
Si está utilizando el asistente para configuración, siga estos pasos:
ndserver
El asistente le guía paso a paso a través del proceso de creación de una configuración básica para el componente Dispatcher. Se le harán preguntas acerca de su red. Se le guiará a través de la configuración de un cluster para que Dispatcher reparta el tráfico entre un grupo de servidores.
Con el asistente para configuración, verá los siguientes paneles:
Figura 2. La interfaz gráfica de usuario (GUI)
Para iniciar la interfaz gráfica de usuario, siga estos pasos:
ndserver
El lado izquierdo del panel muestra una estructura en árbol con Network Dispatcher en el nivel superior y Dispatcher, Content Based Routing, Mailbox Locator, Site Selector y Cisco Consultant como componentes. Consulte Figura 2.
Todos los componentes se pueden configurar desde la GUI. Puede seleccionar elementos de la estructura en árbol pulsando el botón uno del ratón (normalmente el izquierdo) y visualizar menús emergentes pulsando el botón dos del ratón (normalmente el derecho). También puede accederse a los menús emergentes de los elementos del árbol desde la barra de menús situada en la parte superior del panel.
Pulse sobre los signos más o menos para ampliar o contraer los elementos de la estructura en árbol.
En el lado derecho del panel se muestran las pestañas de los indicadores de estado para el elemento seleccionado actualmente.
Puede acceder a la Ayuda pulsando el signo de interrogación, situado en la esquina superior derecha de la ventana de Network Dispatcher.
Compruebe si la configuración es funcional.
Existen muchas formas de configurar Network Dispatcher para dar soporte a su sitio Web. Si el sitio Web tiene un solo nombre de sistema principal al que se conectan todos los clientes, se puede definir un único cluster de servidores. Para cada uno de estos servidores, configure un puerto a través del cual se comunica Network Dispatcher. Consulte Figura 3.
Figura 3. Ejemplo de Dispatcher configurado con un cluster individual y 2 puertos
En este ejemplo del componente Dispatcher, un cluster está definido en www.productworks.com. Este cluster tiene dos puertos: el puerto 80 para HTTP y el puerto 443 para SSL. El cliente que haga una petición a http://www.productworks.com (puerto 80) irá a un servidor diferente del que irá el visitante que solicite https://www.productworks.com (puerto 443).
Si el sitio Web es muy grande y tiene muchos servidores dedicados a cada uno de los protocolos soportados, otra forma de configurar Network Dispatcher resultaría más adecuada. En este caso, le interesaría definir un cluster para cada protocolo con un único puerto pero con varios servidores, tal y como se muestra en la Figura 4.
Figura 4. Ejemplo de Dispatcher configurado con 2 clusters, cada uno con 1 puerto
En este ejemplo del componente Dispatcher, hay 2 clusters definidos: www.productworks.com para el puerto 80 (HTTP) y www.testworks.com para el puerto 443 (SSL).
Sería necesaria una tercera forma de configurar Network Dispatcher si el sitio Web realiza hospedaje de contenidos para varias empresas o departamentos y cada uno de ellos accede al sitio Web con un URL diferente. En este caso, podría definir un cluster para cada empresa o departamento y luego definir varios puertos para las conexiones entrantes de cada URL, tal como se muestra en la Figura 5.
Figura 5. Ejemplo de Dispatcher configurado con 2 clusters, cada uno con 2 puertos
En este ejemplo del componente Dispatcher, hay 2 clusters definidos: www.productworks.com con el puerto 80 (para HTTP) y www.testworks.com con el puerto 23 (para Telnet).
Este capítulo describe los requisitos de hardware y la instalación de Network Dispatcher en AIX, Linux, Solaris y Windows 2000. Siga estas instrucciones empezando en:
Notas:
Para asegurarse de que los componentes de Network Dispatcher utilicen la versión correcta de Java cuando hay instaladas varias versiones, realice las acciones siguientes:
Edite los archivos de script de cada componente de Network Dispatcher que desee actualizar. Los archivos de script de cada componente son:
Por ejemplo, en Windows 2000, si Java 1.3 se ha instalado en C:\Archivos de programa\IBM\Java13\jre\bin, cambie la línea de ndserver.cmd:
IBM AIX 4.3.3.10 junto con los APAR (para dar soporte a Java 1.3). Consulte el archivo README de IBM AIX Developer Kit para obtener una lista de los APAR de AIX necesarios.
La Tabla 1 lista las imágenes installp de Network Dispatcher para
AIX.
Tabla 1. Imágenes installp de AIX
Dispatcher (componente, administración, licencia y mensajes) | intnd.nd.driver intnd.nd.rte intnd.msg.nd.<language>.nd intnd.admin.rte intnd.msg.<idioma>.admin |
Administración (sólo) | intnd.admin.rte intnd.msg.<idioma>.admin |
Documentación | intnd.doc.rte |
Licencia | intnd.nd.license |
Metric Server | intnd.ms.rte |
donde <idioma> es uno de los siguientes:
Si baja del sitio Web una copia de evaluación del producto, utilice las instrucciones de instalación de (http://www.ibm.com/software/webservers/edgeserver/downloads/html).
Cuando instala el producto, puede instalar cualquiera de los elementos siguientes o todos ellos:
Siga estos pasos para instalar Network Dispatcher para AIX:
Utilización de SMIT:
Cuando finalice el mandato, pulse Hecho y, a continuación, seleccione Salir de Smit en el menú Salir o pulse F12. Si utiliza SMITTY, pulse F10 para salir del programa.
Con la línea de mandatos:
Si realiza la instalación desde CD, debe entrar los mandatos siguientes para montar el CD:
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Consulte la tabla siguiente para determinar qué mandato o mandatos deben
entrarse para instalar los paquetes de Network Dispatcher para AIX que
desee:
Tabla 2. Mandatos de instalación de AIX
Network Dispatcher (con mensajes). Comprende: Dispatcher, CBR, Mailbox Locator, Site Selector y Cisco Consultant | installp -acXgd dispositivo intnd.nd.rte intnd.admin.rte intnd.nd.driver intnd.msg.<idioma>.nd intnd.msg.<idioma>.admin |
Documentos | installp -acXgd dispositivo intnd.doc.rte intnd.msg.<idioma>.doc |
Administración (sólo) | installp -acXgd dispositivo intnd.admin.rte intnd.msg.<idioma>.admin |
Licencia | installp -acXgd dispositivo intnd.nd.license |
Metric Server | installp -acXgd dispositivo intnd.ms.rte intnd.msg.<idioma>.admin |
donde dispositivo es:
Asegúrese de que en la columna de resultado se indica la instalación satisfactoria de cada uno de los componentes de Network Dispatcher que se están instalando (aplicando). No siga hasta que todos los componentes que desee instalar se hayan aplicado satisfactoriamente.
installp -ld dispositivo
donde dispositivo es:
Para desmontar el CD, teclee:
unmount /cdrom
lslpp -h | grep intnd
Si ha instalado todo el producto, este mandato devuelve lo siguiente:
intnd.admin.rte intnd.doc.rte intnd.ms.rte intnd.msg.en_US.admin.rte intnd.msg.en_US.doc intnd.msg.en_US.nd.rte intnd.nd.driver intnd.nd.license intnd.nd.rte
Las rutas de instalación de Network Dispatcher son las siguientes:
Esta sección describe cómo instalar Network Dispatcher en Red Hat Linux o SuSe Linux utilizando el CD del producto o la copia de evaluación del producto que se puede bajar del sitio Web. Puede obtener instrucciones de instalación en el sitio Web (http://www.ibm.com/software/webservers/edgeserver/download.html).
Antes de comenzar el procedimiento de instalación, asegúrese de que tiene la autorización de usuario root para instalar el software.
Para instalar Network Dispatcher:
La imagen de instalación es un archivo con el formato ndlinux-versión.tar.
Lo siguiente es una lista de los paquetes RPM que se pueden instalar:
El mandato para instalar los paquetes se debe emitir desde el mismo directorio donde residen los archivos RPM. Emita el mandato siguiente para instalar cada paquete: rpm -i paquete.rpm.
rpm -i --nodeps paquete.rpm
rpm -qa | grep ibmnd
Instalar todo el producto genera un listado similar a este:
Para Solaris 8, Netscape Navigator 4.07 (o superior) o Netscape Communicator 4.61 (o superior) para visualizar la Ayuda en línea
Esta sección describe cómo instalar Network Dispatcher en Solaris utilizando el CD del producto. Si baja de Internet una copia de evaluación del producto, utilice las instrucciones que se proporcionan en el sitio Web (http://www.ibm.com/software/webservers/edgeserver/download.html).
Antes de comenzar el procedimiento de instalación, asegúrese de que tiene la autorización de usuario root para instalar el software.
Para instalar Network Dispatcher:
En el indicador de mandatos, entre pkgadd -d vía de acceso, donde -d vía de acceso es el nombre del dispositivo de la unidad de CD-ROM o el directorio del disco duro donde se encuentra el paquete; por ejemplo pkgadd -d /cdrom/cdrom0/.
Se mostrará una lista de los paquetes que puede instalar. Estos paquetes son:
Si desea instalar todos los paquetes, simplemente escriba "all" y pulse Intro. Si desea instalar algunos de los componentes, escriba los números correspondientes a los paquetes, separados por un espacio o una coma y pulse Intro. Se le pedirá si desea modificar permisos sobre directorios o archivos existentes. Simplemente pulse Intro o responda " yes". Tendrá que instalar paquetes necesarios (pues se instalan por orden alfabético, no por orden de dependencia). Si responde "all", luego sólo debe responder "yes" a todas las preguntas y la instalación se efectuará satisfactoriamente.
Todos los paquetes dependen del paquete común, ibmndadm. Este paquete común debe instalarse junto con cualquiera de los demás paquetes.
Si desea instalar el producto Network Dispatcher completo, debe instalar cinco elementos: ibmdsp, ibmdsplic, ibmndadm, ibmnddoc y ibmndms. Si desea instalar la administración remota, sólo es necesario instalar un elemento: ibmndadm.
Los componentes de Network Dispatcher residen en el directorio de instalación /opt/nd/servers.
pkginfo | grep ibm.
Si ha instalado el producto completo, debe obtener un listado similar al siguiente:
Debe bajar los paquetes instalables del Developer Kit y de Runtime Environment para poder ejecutar el programa InstallShield. (Si desea información sobre la ejecución de varias versiones de Java, consulte la Nota número (JVER).)
Esta sección describe cómo instalar Network Dispatcher en Windows 2000 utilizando el CD del producto. Si baja del sitio Web una copia de evaluación del producto, utilice las instrucciones de instalación de (http://www.ibm.com/software/webservers/edgeserver/downloads/html).
Se le mostrarán los paquetes que puede instalar.
Estos paquetes son:
La versión para Windows 2000 de Network Dispatcher está soportada en:
Restricciones: La versión para Windows 2000 de Network Dispatcher no se puede instalar en la misma máquina junto con IBM Firewall.
Antes de empezar el procedimiento de instalación, asegúrese de que se ha conectado como administrador o con un perfil de usuario que tenga privilegios de administrador.
Si tiene instalada una versión anterior, deberá desinstalarla para poder instalar la versión actual. Para desinstalar utilizando la opción Agregar o quitar programas, haga lo siguiente:
Para instalar Network Dispatcher:
E:\setup
Las rutas de instalación de Network Dispatcher son las siguientes:
Este capítulo ofrece una visión general de Network Dispatcher y comprende las secciones siguientes:
Network Dispatcher es una solución de software para distribuir el tráfico entre servidores. Aumenta el rendimiento de los servidores encaminando las peticiones de sesión TCP/IP hacia distintos servidores dentro de un grupo de ellos; de esta forma, reparte las peticiones entre todos los servidores. El reparto del tráfico es transparente a los usuarios y a otras aplicaciones. Network Dispatcher resulta útil para aplicaciones tales como servidores de correo electrónico, servidores WWW (World Wide Web), consultas a bases de datos paralelas distribuidas y otras aplicaciones TCP/IP.
Utilizado con servidores, Network Dispatcher contribuye a maximizar el potencial de su sitio Web al ofrecer una solución potente, flexible y escalable a los problemas de picos de demanda. Si los visitantes de un sitio Web no pueden acceder a él en las horas de mayor demanda, Network Dispatcher busca automáticamente el servidor óptimo para gestionar las peticiones entrantes, con lo que aumenta la satisfacción de los usuarios y la rentabilidad.
Network Dispatcher consta de cinco componentes que se pueden utilizar por separado o juntos para lograr un mejor reparto del tráfico:
Para el protocolo HTTP, puede también utilizar el encaminamiento por contenido del Dispatcher para repartir el tráfico basándose en el contenido de la petición del cliente. El servidor elegido es el resultado de comparar el URL con una norma especificada.
Para obtener más información sobre los componentes Dispatcher, CBR, Mailbox Locator, Site Selector y Consultant para Cisco CSS Switches, consulte ¿Cuáles son los componentes de Network Dispatcher?.
El número de usuarios y de redes conectadas a Internet crece de forma exponencial. Este crecimiento origina problemas de escala que pueden restringir el acceso de los usuarios a los sitios Web más populares.
En la actualidad, los administradores de red utilizan diversos métodos para intentar ampliar al máximo el acceso. Algunos de estos métodos permiten a los usuarios elegir aleatoriamente un servidor distinto si el seleccionado anteriormente resulta lento o no responde. Esta forma de abordar la cuestión es incómoda, molesta e ineficaz. Otro método es el rotatorio estándar, en el que el servidor de nombres de dominio selecciona los servidores por turnos para que manejen las peticiones. Este método es mejor, pero sigue siendo poco eficiente, pues el tráfico se reenvía a ciegas sin tomar en cuenta la carga de trabajo de los servidores. Además, aunque falle un servidor, se siguen enviando peticiones a él.
La necesidad de una solución más eficaz ha dado lugar a Network Dispatcher. Este producto ofrece numerosas ventajas con respecto a soluciones anteriores:
A medida que aumenta el número de peticiones de los clientes, puede añadir servidores de forma dinámica, con lo que se puede dar soporte a decenas de millones de peticiones al día en decenas, o incluso cientos, de servidores.
El reparto del tráfico asegura que cada grupo de servidores utilice el hardware de forma óptima gracias a que se minimizan las zonas de actividad continua que se producen habitualmente con un método rotatorio estándar.
Network Dispatcher utiliza protocolos TCP/IP estándar. Se puede añadir a la red existente sin tener que realizar cambios físicos en ella. Resulta sencillo de instalar y configurar.
Gracias a la utilización de un método de reenvío simple a nivel MAC, Dispatcher sólo necesita observar los flujos entrantes de cliente a servidor. No necesita observar los flujos salientes de servidor a cliente. Esto reduce significativamente el efecto que tiene sobre la aplicación en comparación con otros métodos y puede originar una mejora del rendimiento de la red.
Dispatcher ofrece una función incorporada de alta disponibilidad, ya que utiliza una máquina de reserva que permanece lista para asumir el control en caso de producirse una anomalía en la máquina Dispatcher principal. Dispatcher también ofrece la característica de alta disponibilidad mutua que permite que dos máquinas estén activas y en espera entre sí. Consulte el apartado Acerca de la alta disponibilidad.
En combinación con Caching Proxy, el componente CBR tiene la capacidad de reenviar peticiones HTTP y HTTPS (SSL) hacia servidores determinados basándose en el contenido de las páginas solicitadas. Por ejemplo, si una petición contiene la cadena de caracteres "/cgi-bin/" en la porción del URL correspondiente al directorio y el nombre del servidor es un servidor local, CBR puede dirigir la petición hacia el servidor más apropiado de un grupo de servidores que están asignados específicamente para gestionar peticiones de cgi.
El componente Dispatcher también proporciona encaminamiento basado en el contenido, pero no necesita que el Caching Proxy esté instalado. Debido a que el encaminamiento basado en contenido del componente Dispatcher se realiza en el kernel a medida que se reciben los paquetes, el componente Dispatcher puede proporcionar un encaminamiento basado en contenido más rápido que el componente CBR. El componente Dispatcher realiza encaminamiento por contenido para HTTP (utilizando la norma de tipo "content") y HTTPS (utilizando la afinidad del ID de sesión de SSL).
Network Dispatcher para IBM WebSphere Edge Server Versión 2.0 contiene varias funciones nuevas. A continuación se listan las más importantes.
Esta función es aplicable a todos los componentes de Network Dispatcher.
Network Dispatcher ahora da soporte a una versión más reciente de AIX: AIX v5.1. En Requisitos para AIX hallará más información.
Esta función es aplicable a todos los componentes de Network Dispatcher.
Network Dispatcher ahora da soporte a SuSE Linux v7.1 (versión de kernel 2.4.0-4GB). Anteriormente, Network Dispatcher sólo daba soporte a Red Hat Linux. En Requisitos para Red Hat Linux o SuSe Linux hallará más información.
Esta función es aplicable a todos los componentes de Network Dispatcher.
Network Dispatcher ahora da soporte a una versión más reciente de RedHat Linux: Red Hat Linux v7.1. (versión de kernel 2.4.2-2). En Requisitos para Red Hat Linux o SuSe Linux hallará más información.
Esta función es aplicable a todos los componentes de Network Dispatcher.
En los sistemas operativos Linux y Solaris, Network Dispatcher proporciona soporte de idioma nacional para los países del Grupo 1.
Esta función es aplicable a todos los componentes de Network Dispatcher.
Network Dispatcher proporciona soporte de idioma nacional para el nuevo estándar GB 18030 del chino.
Esta función es un nuevo componente de Network Dispatcher.
El trabajo conjunto con Cisco y su Content Distribution Network (CDN) ha originado el desarrollo de un componente adicional de Network Dispatcher: Cisco Consultant. Este componente (que primero se presentó como Avance autónomo) permite a Network Dispatcher generar valores de ponderación y tomar decisiones sobre el reparto del tráfico para Cisco CSS Switch.
Consulte el Planificación para el componente Consultant para Cisco CSS Switches y el Configuración del componente Consultant para Cisco CSS Switches para obtener más información.
Esta función es un nuevo componente de Network Dispatcher.
El componente Site Selector reparte el tráfico entre un grupo de servidores seleccionando la dirección IP del servidor "apropiado" para una petición de servicio de nombres. Este permite que el cliente se conecte directamente con el servidor para todas sus comunicaciones. Site Selector sustituye a Interactive Session Support (ISS), que en releases anteriores era un componente de Network Dispatcher. Site Selector proporciona funciones similares a las de ISS, pero necesita menos pasos para configurar el reparto del tráfico de DNS.
Consulte el Planificación para el componente Site Selector y el Configuración del componente Site Selector para obtener más información.
Esta función es aplicable a todos los componentes de Network Dispatcher.
Metric Server proporciona a Network Dispatcher información sobre el tráfico de los servidores en forma de métrica específica del sistema. El agente de Metric Server es un componente de Network Dispatcher que puede instalarse y ejecutarse en los servidores para los que Network Dispatcher realice el reparto del tráfico. Metric Server sustituye a System Monitoring Agent (SMA), que en releases anteriores estaba soportado en Linux. Metric Server está soportado en todas las plataformas. Es recomendable utilizar Metric Server junto con el componente Site Selector.
En Metric Server hallará más información.
Esta función es un nuevo componente de Network Dispatcher.
Anteriormente el componente Mailbox Locator era una función dentro del componente CBR que repartía el tráfico entre servidores de correo IMAP y POP3 basándose en el ID de usuario y la contraseña. Separar CBR en dos componentes permite ejecutar Mailbox Locator (antes denominado "CBR para IMAP/POP3") y CBR con Caching Proxy en la misma máquina.
Consulte el Planificación para el componente Mailbox Locator y el Configuración del componente Mailbox Locator para obtener más información.
Se ha simplificado la definición del archivo de configuración de Caching Proxy (ibmproxy.conf) para utilizar CBR y se ha mejorado CBR para poder ejecutar simultáneamente varias instancias de Caching Proxy en la misma máquina mientras se interactúa con CBR. Para obtener más información sobre cómo configurar CBR con Caching Proxy, consulte Configuración de la máquina CBR.
Esta función es aplicable al componente Dispatcher.
Gracias a NAT/NAPT ya no es necesario que los servidores de fondo estén situados en una red conectada localmente. También permite que Dispatcher reparta el tráfico de las peticiones TCP del cliente hacia varios daemons de servidor que se ejecutan en la misma máquina física. Existen dos maneras de configurar servidores con varios daemons. Con NAT, puede configurar varios daemons de servidor para responder a peticiones dirigidas a diferentes direcciones IP. Esto se denomina vincular un daemon de servidor con una dirección IP. Con NAPT, puede configurar varios daemons de servidor para recibir las peticiones en diferentes números de puerto.
La ventana del método de reenvío nat de Dispatcher es que se configura a nivel de puerto, lo que ofrece mucho mejor granularidad.
En Método de reenvío nat del Dispatcher hallará más información.
Esta función es aplicable al componente Dispatcher.
En versiones anteriores de Network Dispatcher, el encaminamiento por contenido sólo podía utilizarse al usar el componente CBR en combinación con Caching Proxy. Ahora el componente Dispatcher permite realizar encaminamiento por contenido para HTTP (utilizando la norma de tipo "content") y para HTTPS (utilizando la afinidad del ID de sesión de SSL), sin tener que utilizar Caching Proxy. Para el tráfico de HTTP y HTTPS, el componente Dispatcher puede proporcionar un encaminamiento por contenido más rápido que el componente CBR.
Consulte Encaminamiento por contenido mediante Dispatcher (método de reenvío cbr) para obtener más información sobre el uso de la norma de contenido y la afinidad del ID de sesión de SSL.
Esta función es aplicable al encaminamiento por contenido del componente Dispatcher (método de reenvío CBR) y al componente CBR.
La afinidad pasiva de cookie le permite repartir el tráfico Web con afinidad por un mismo servidor basándose en los cookies autodefinidos generados por los servidores. En Afinidad pasiva de cookie hallará más información.
Esta función es aplicable al encaminamiento por contenido del componente Dispatcher (método de reenvío CBR) y al componente CBR.
La afinidad de URI le permite repartir el tráfico Web hacia servidores caching-proxy y aumentar de forma efectiva el tamaño de la antememoria. En Afinidad de URI hallará más información.
Esta función es aplicable a todos los componentes de Network Dispatcher.
En versiones anteriores, se utilizaba la función del gestor para definir la proporción de importancia (asignado a conexiones activas, conexiones nuevas, puertos y métricas del sistema) y realizar el reparto del tráfico. Estas proporciones se aplicaban a cada cluster de la configuración para el componente. Todos los clusters se evaluaban utilizando las mismas proporciones, con independencia del sitio Web donde se hacía el reparto del tráfico.
Gracias a esta mejora, la proporción de importancia se puede definir para cada cluster (o sitio Web). En Grado de importancia dado a la información de estado hallará más información.
Esta función es aplicable a todos los componentes de Network Dispatcher.
Ahora Network Dispatcher proporciona la capacidad de particionar un servidor físico en varios servidores lógicos. Esto permite, por ejemplo, consultar un determinado servicio de la máquina para detectar si un motor de servlet o petición de base de datos se está ejecutando más rápidamente o no se está ejecutando. Esta mejora permite repartir el tráfico de una forma más precisa, de acuerdo con el servicio. En Particionamiento del servidor: servidores lógicos configurados para un solo servidor físico (dirección IP) hallará más información.
Esta función es aplicable a los componentes Dispatcher y CBR.
Con esta mejora para el asesor HTTP, puede evaluar el estado de servicios individuales dentro de un servidor. Para cada servidor lógico del puerto HTTP, puede especificar un URL exclusivo para un cliente HTTP, que sea específico del servicio que desea consultar en el servidor. En Opción de petición/respuesta del asesor HTTP (URL) hallará más información.
Esta función es aplicable a todos los componentes de Network Dispatcher.
Network Dispatcher le permite iniciar varios asesores en un mismo puerto, pero que están configurados en clusters (sitios Web) diferentes. Por ejemplo, esta función le permite utilizar un asesor HTTP en el puerto 80 para un cluster (sitio Web) y un asesor personalizado en el puerto 80 para otro cluster (sitio Web). En Inicio y detención de un asesor hallará más información.
Esta función es aplicable al componente Dispatcher.
Con esta mejora, Dispatcher permite detectar posibles ataques de denegación de servicio y avisar al administrador mediante una alerta. Para ello, Dispatcher comprueba si las peticiones entrantes contienen un volumen importante de conexiones semiabiertas, lo cual es una característica habitual de los ataques simples de denegación de servicio.
En Detección de ataques de denegación de servicio hallará más información.
Esta función se aplica a todos los componentes excepto a Consultant para Cisco CSS Switches y Site Selector.
Network Dispatcher proporciona nuevas salidas de usuario que provocan la ejecución de scripts, los cuales puede personalizar. Puede crear scripts para realizar acciones automatizadas, tales como iniciar la sesión cuando cambie un estado de alta disponibilidad o avisar al administrador cuando se detecte un servidor fuera de servicio. Network Dispatcher proporciona los nuevos archivos de script siguientes:
Esta función es aplicable al componente Dispatcher.
Dispatcher proporciona un asesor DB2 que se comunica con los servidores DB2. En Lista de asesores hallará más información sobre el asesor DB2.
Los cinco componentes de Network Dispatcher son: Dispatcher, Content Based Routing (CBR), Mailbox Locator, Site Selector y Consultant para Cisco CSS Switches. Network Dispatcher le proporciona la flexibilidad de utilizar estos componentes por separado o juntos, dependiendo de la configuración de su sitio Web. Esta sección proporciona una visión general de estos componentes.
El componente Dispatcher reparte el tráfico entre los servidores mediante una combinación exclusiva de software de gestión y de reparto del tráfico. Dispatcher también puede detectar un servidor anómalo y reenviar el tráfico hacia otros servidores. Dispatcher da soporte a HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, y a cualquier aplicación basada en TCP o UDP sin estados.
Todas las peticiones de los clientes enviadas a la máquina Dispatcher se dirigen al "mejor" servidor, según los pesos que se establecen de forma dinámica. Se pueden utilizar los valores por omisión de dichos pesos o cambiarlos durante el proceso de configuración.
Dispatcher proporciona tres métodos de reenvío (especificados para el puerto):
El componente Dispatcher es la clave para conseguir una gestión eficiente y estable de una red grande y escalable de servidores. Con Dispatcher, puede enlazar muchos servidores y crear lo que en apariencia es un único servidor virtual. De esta forma, el sitio Web aparece como una sola dirección IP para el entorno. Dispatcher trabaja de forma independiente del servidor de nombres de dominio; todas las peticiones se envían a la dirección IP de la máquina Dispatcher.
Dispatcher aporta ventajas claras al repartir el tráfico hacia servidores agrupados en cluster, lo que da como resultado una gestión estable y eficaz del sitio Web.
La Figura 6 muestra una representación física del sitio Web con una configuración de red Ethernet. La máquina Dispatcher puede instalarse sin necesidad de realizar ningún cambio físico en la red. Después de que Dispatcher encamina la petición de un cliente hacia el servidor óptimo, la respuesta se envía directamente del servidor al cliente sin la intervención de Dispatcher si se utiliza el método de reenvío MAC.
Figura 7. Ejemplo de sitio Web que utiliza Dispatcher y Metric Server para gestionar servidores
La Figura 7 muestra un sitio Web en el que todos los servidores están en una red local. Se utiliza el componente Dispatcher para reenviar peticiones y Metric Server para proporcionar información sobre el tráfico del sistema a la máquina Dispatcher.
En este ejemplo, el daemon de Metric Server está instalado en cada servidor de fondo. Puede utilizar Metric Server con el componente Dispatcher o con cualquiera de los demás componentes de Network Dispatcher.
El soporte de área amplia de Dispatcher le permite utilizar servidores tanto locales como remotos (servidores situados en subredes diferentes). La Figura 8 muestra una configuración donde un Dispatcher local (Dispatcher 1) sirve como punto de entrada para todas las peticiones. Este Dispatcher reparte las peticiones entre sus propios servidores locales (ServidorA, ServidorB, ServidorC) y el Dispatcher remoto, el cual reparte el tráfico entre sus servidores locales (ServidorG, ServidorH, ServidorI).
Cuando se utiliza el método de reenvío NAT o el soporte de GRE de Dispatcher, también se puede conseguir el soporte de área amplia con Dispatcher sin utilizar un Dispatcher en el sitio remoto (donde residen ServidorD, ServidorE y ServidorF). Consulte Método de reenvío nat del Dispatcher y Soporte de GRE (Generic Routing Encapsulation) para obtener más información.
CBR trabaja con Caching Proxy para encaminar las peticiones de los clientes hacia servidores HTTP o HTTPS (SSL) especificados. CBR le permite manipular datos de la gestión de antememoria para lograr una recuperación más rápida de documentos Web con pocos requisitos respecto al ancho de banda de red. CBR junto con Caching Proxy examina las peticiones HTTP utilizando los tipos de normas especificados.
CBR le permite especificar un conjunto de servidores que manejen una petición basándose en la comparación expresiones regulares del contenido de la petición. Puesto que CBR le permite especificar varios servidores para cada tipo de petición, se puede repartir el tráfico de las peticiones para optimizar la respuesta al cliente. CBR también detectará si falla un servidor de un grupo y detendrá el encaminamiento de peticiones hacia ese servidor. El algoritmo de reparto del tráfico utilizado por el componente CBR es idéntico al algoritmo comprobado utilizado por el componente Dispatcher.
Cuando Caching Proxy recibe una petición, ésta se compara con las normas que se han definido en el componente CBR. Si se encuentra una coincidencia, se elige uno de los servidores asociados con esa norma para atender la petición. A continuación, Caching Proxy realiza su proceso normal para encaminar la petición hacia el servidor elegido.
CBR tiene las mismas funciones que Dispatcher, a excepción de la alta disponibilidad, el subagente, el área amplia y otros mandatos de configuración.
Caching Proxy debe estar en ejecución para que CBR pueda comenzar a repartir las peticiones de los clientes.
Figura 9. Ejemplo de sitio Web que utiliza CBR para gestionar servidores locales
La Figura 9 muestra una representación lógica de un sitio Web en el que se utiliza CBR para dirigir al proxy parte del contenido de los servidores locales. El componente CBR utiliza Caching Proxy para reenviar las peticiones de los clientes (HTTP o HTTPS) hacia los servidores basándose el contenido del URL.
Mailbox Locator puede proporcionar un único punto de presencia para varios servidores IMAP o POP3. Cada servidor puede tener un subconjunto de todos los servicios de correo de usuario para los que ofrece servicio el punto de presencia. Para el tráfico de IMAP y POP3 traffic, Mailbox Locator es un proxy que elige un servidor adecuado basándose en el ID de usuario y la contraseña proporcionados por el cliente. Mailbox Locator no da soporte al reparto del tráfico basado en normas.
Figura 10. Ejemplo de sitio Web que utiliza Mailbox Locator para gestionar servidores locales
La Figura 10 muestra una representación lógica de un sitio Web donde se utiliza Mailbox Locator para encaminar las peticiones de los clientes (protocolo IMAP o POP3) hacía el servidor apropiado, basándose en el ID de usuario y la contraseña.
Site Selector actúa como un servidor de nombres que funciona junto con otros servidores de nombres en un sistema de nombres de dominio para distribuir el tráfico entre un grupo de servidores utilizando medidas y pesos recopilados. Puede crear una configuración de sitio Web para poder repartir el tráfico entre un grupo de servidores basándose en el nombre de dominio utilizado para la petición de un cliente.
Un cliente envía una petición para resolver un nombre de dominio en un nombre de servidor dentro de su red. El servidor de nombres reenvía la petición a la máquina de Site Selector. A continuación, Site Selector resuelve el nombre de dominio y obtiene la dirección IP de uno de los servidores que se ha configurado en el nombre de sitio. Site Selector devuelve la dirección IP del servidor seleccionado al servidor de nombres. El servidor de nombres devuelve la dirección IP al cliente.
Metric Server es un componente de Network Dispatcher, para la supervisión del sistema, que se debe instalar en cada servidor de la configuración hacia el que se reparte el tráfico. Mediante Metric Server, Site Selector puede supervisar el nivel de actividad de un servidor, detectar el servidor con menos tráfico y los servidores anómalos. El tráfico es una medida de la intensidad con que trabaja un servidor. Mediante la personalización de archivos de script de métricas del sistema, el usuario puede controlar el tipo de mediciones utilizadas para medir el tráfico. Se puede configurar Site Selector de acuerdo con el entorno, teniendo en cuenta factores tales como la frecuencia del acceso, el número total de usuarios y los tipos de acceso (por ejemplo, consultas breves, consultas de larga duración o cargas de datos que exigen un alto consumo de CPU).
La Figura 11 muestra un sitio Web donde se utiliza el componente Site Selector para responder a las peticiones. Servidor1, Servidor2 y Servidor3 son locales. Servidor4, Servidor5 y Servidor6 son remotos.
Un cliente envía una petición para resolver un nombre de dominio en un servidor de nombres dentro de su red. El servidor de nombres del cliente reenvía la petición a través del DNS a la máquina Site Selector (Ruta 1). A continuación, Site Selector resuelve el nombre de dominio y obtiene la dirección IP de uno de los servidores. Site Selector devuelve la dirección IP del servidor seleccionado al servidor de nombres del cliente. El servidor de nombres devuelve la dirección IP al cliente.
Después de recibir la dirección IP del servidor, el cliente envía las peticiones subsiguientes directamente al servidor seleccionado (Ruta 2).
Consultant para Cisco CSS Switches constituye una solución complementaria que actúa en combinación con la serie de conmutadores Cisco CSS 11000. Esta solución combinada integra los recursos de reenvío de paquetes y encaminamiento por contenido de la serie CSS 11000 con los complejos algoritmos de detección de Network Dispatcher para determinar información sobre la disponibilidad y la carga de trabajo de servidores de fondo, aplicaciones y bases de datos. La función de Cisco Consultant utiliza los asesores estándar, personalizados y del gestor de Network Dispatcher, y Metric Server para determinar las métricas, el estado y la carga de los servidores de fondo, aplicaciones y bases de datos. Con esta información, Cisco Consultant genera métricas de ponderación de servidores, la cual la envía a Cisco CSS Switch para seleccionar el servidor óptimo, optimizar el tráfico y habilitar la tolerancia a errores.
Cisco CSS Switch realiza decisiones sobre el reparto del tráfico basándose en criterios especificados por el usuario.
Cisco Consultant hace un seguimiento de muchos criterios, tales como:
Cuando Cisco CSS Switch, sin la utilización de Cisco Consultant, determina el estado de un servidor de contenidos, utiliza los tiempos de respuesta de las peticiones de contenido u otras medidas de la red. Cuando se utiliza Cisco Consultant, esas actividades se trasladan desde Cisco CSS Switch a Cisco Consultant. Cisco Consultant influye en la capacidad del servidor para atender las peticiones de contenido (el "peso" del servidor), y activa o detiene un servidor según convenga, cuando el servidor recupera o pierde su disponibilidad.
Cisco Consultant:
Los pesos se aplican a todos los servidores de un puerto. Para un puerto determinado cualquiera, las peticiones se reparten entre los servidores según el peso relativo de los servidores. Por ejemplo, si un servidor tiene establecido un peso de 10 y otro tiene un peso 5, el servidor con peso 10 debe obtener el doble de peticiones que el servidor con peso 5. Estos pesos se proporcionan a Cisco CSS Switch utilizando SNMP. A medida que el peso de un servidor cualquiera se establece en un valor más alto, más peticiones envía Cisco CSS Switch hacia ese servidor.
Cisco Consultant, junto con Cisco CSS Switch, proporciona una solución que combina la conmutación de contenidos con métodos complejos de identificación de aplicaciones, tolerancia a errores y optimización del tráfico de servidores. Cisco Consultant forma parte de una solución global complementaria entre Cisco CSS Switch y el producto WebSphere Edge Server de IBM.
Consulte el Instalación de Network Dispatcher para obtener una lista de los requisitos de Cisco Consultant.
El componente Dispatcher ofrece una función integrada de alta disponibilidad. Esta función supone el uso de una segunda máquina Dispatcher, cuya finalidad es supervisar a la máquina principal y estar a la espera para hacerse cargo del reparto del tráfico si falla la máquina principal. El componente Dispatcher también proporciona alta disponibilidad mutua, que permite que dos máquinas sean al mismo tiempo la máquina principal y la máquina de reserva la una respecto de la otra. Consulte Configurar la característica de alta disponibilidad.
Cuando utiliza una configuración de dos niveles con un Dispatcher que reparte el tráfico hacia dos o más servidores donde está instalado CBR, Mailbox Locator o Site Selector, puede conseguir un alto nivel de disponibilidad para estos componentes de Network Dispatcher.
En este capítulo se describen los aspectos que debe tener en cuenta la persona encargada de planificar la red antes de proceder a la instalación y configuración del componente Dispatcher.
Este capítulo incluye las siguientes secciones:
Requisitos de plataforma:
Dispatcher consta de las siguientes funciones:
El uso del gestor es opcional. No obstante, si no se utiliza un gestor, el reparto del tráfico se realiza utilizando una planificación rotatoria ponderada basada en los pesos actuales de los servidores, y no podrán utilizarse asesores.
Dispatcher también proporciona asesores que no intercambian información específica del protocolo, tales como el asesor para DB2, que informa sobre el estado de los servidores DB2, y el asesor Ping, que notifica si el servidor responde a un mandato ping. Para obtener una lista completa de los asesores, vea Lista de asesores.
También tiene la opción de escribir sus propios asesores (consulte Creación de asesores personalizados (personalizables)).
El uso de asesores es opcional, pero recomendable.
Las tres funciones clave de Dispatcher (el ejecutor, los asesores y el gestor) interactúan para repartir y asignar las peticiones entrantes entre los servidores. Además de repartir el tráfico de peticiones, el ejecutor supervisa el número de conexiones nuevas, conexiones activas y conexiones finalizadas. El ejecutor también recoge los datos sobrantes procedentes de conexiones finalizadas y proporciona esta información al gestor.
El gestor recoge información procedente del ejecutor, los asesores y un programa de supervisión del sistema, tal como Metric Server. Basándose en la información recibida, el gestor ajusta los valores de ponderación asignados a los servidores en cada puerto y proporciona al ejecutor la nueva ponderación para que la utilice en el reparto de conexiones nuevas.
Los asesores supervisan cada uno de los servidores del puerto asignado con el fin de determinar cuál es el tiempo de respuesta y la disponibilidad del servidor y, a continuación, facilitan esta información al gestor. También controlan si un servidor está activo o inactivo. Sin el gestor y los asesores, el ejecutor realiza una planificación rotatoria tomando como base el peso actual de los servidores.
Figura 13. Ejemplo de Dispatcher utilizando la alta disponibilidad simple
La característica de alta disponibilidad conlleva la utilización de una segunda máquina Dispatcher. La primera máquina Dispatcher realiza el reparto del tráfico del tráfico de clientes del mismo modo que lo haría en una configuración de un único Dispatcher. La segunda máquina Dispatcher supervisa la "salud" de la primera y se ocupa de la tarea de reparto del tráfico si detecta alguna anomalía en la primera máquina Dispatcher.
A cada una de estas dos máquinas se le asigna una función específica: principal o de reserva. La máquina principal envía datos de conexión a la máquina de reserva constantemente. Mientras la máquina principal está activa (reparte el tráfico), la máquina de reserva está en estado de espera, actualizándose continuamente y lista para tomar el control si fuera necesario.
Las sesiones de comunicación entre ambas máquinas se denominan pulsos. Los pulsos permiten a cada máquina supervisar la "salud" de la otra.
Si la máquina de reserva detecta que la máquina activa ha fallado, asumirá el control y empezará el reparto del tráfico. En ese momento se invierten los estados de ambas máquinas: la de reserva pasa a ser la activa y la principal pasa a estar en espera.
En la configuración de alta disponibilidad, las máquinas principal y de reserva deben estar en la misma subred.
Si desea obtener información sobre la configuración de la característica de alta disponibilidad, consulte el apartado Alta disponibilidad.
Figura 14. Ejemplo de Dispatcher utilizando la alta disponibilidad mutua
La característica de alta disponibilidad mutua conlleva la utilización de dos máquinas Dispatcher. Ambas máquinas realizan activamente el reparto del tráfico del tráfico de clientes y actúan como máquinas de reserva entre sí. En una configuración de alta disponibilidad simple, sólo una máquina se ocupa del reparto del tráfico. En una configuración de alta disponibilidad mutua, ambas máquinas comparten el reparto del tráfico del tráfico de clientes.
Para la alta disponibilidad mutua, el tráfico de clientes se asigna a cada máquina Dispatcher en base a una dirección de cluster. Cada cluster se puede configurar con la NFA (dirección de no reenvío) del Dispatcher primario. Por lo general, la máquina Dispatcher principal realiza el reparto del tráfico para dicho cluster. En caso de que se produzca una anomalía, la otra máquina se ocupa del reparto del tráfico correspondiente tanto a su cluster como al cluster del Dispatcher anómalo.
En la Figura 14 se muestra una ilustración de una configuración de alta disponibilidad mutua con el "conjunto A de clusters" compartidos y el "conjunto B de clusters" compartidos. Cada Dispatcher puede encaminar activamente paquetes destinados al cluster principal. Si cualquiera de los dos Dispatcher fallara y ya no pudiera encaminar paquetes para el cluster principal, el otro Dispatcher podría hacerse cargo del encaminamiento de paquetes para el cluster de reserva.
Para obtener más información sobre la configuración de la alta disponibilidad y de la alta disponibilidad mutua, consulte el apartado Alta disponibilidad.
El reenvío MAC es el método de reenvío por omisión mediante el cual el Dispatcher reparte el tráfico de peticiones entrantes del servidor y el servidor devuelve la respuesta directamente al cliente, sin ninguna intervención del Dispatcher. Cuando se utiliza este método de reenvío, Dispatcher sólo necesita observar el tráfico entrante que fluye desde el cliente al servidor. No necesita observa el tráfico saliente que circula desde el servidor al cliente. Esto reduce significativamente el efecto que tiene sobre la aplicación y puede mejorar el funcionamiento de la red.
El método de reenvío se puede seleccionar al añadir un puerto con el mandato ndcontrol port add cluster:puerto method valor. El método de reenvío por omisión es mac. Puede especificar el parámetro "method" solamente al añadir el puerto. Después de añadir el puerto, no puede cambiar el valor del método de reenvío. En ndcontrol port -- configurar puertos hallará más información.
Cuando se utiliza el recurso NAT (Network Address Translation) o NAPT (Network Address Port Translation) de Dispatcher ya no es necesario que los servidores sujetos a reparto del tráfico estén situados en una red conectada localmente. Si desea tener servidores en ubicaciones remotas, puede utilizar el método de reenvío NAT en lugar de la técnica de encapsulación GRE/WAN. Puede también utilizar la función NAPT para acceder a varios daemons que residen en cada servidor sujeto a reparto del tráfico, en donde cada daemon está a la escucha en un puerto exclusivo.
Existen dos maneras de configurar servidores con varios daemons:
Esta aplicación es efectiva con protocolos de aplicación de nivel superior, tales como HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, etc.
Limitaciones:
Para implementar NAT/NAPT:
ndcontrol server add cluster:puerto:servidor mapport valor returnaddress dirección_retorno router dirección_retorno
Correlaciona el número del puerto de destino de la petición del cliente con el número de puerto que Dispatcher utiliza para repartir el tráfico de la petición del cliente.. Mapport permite que Network Dispatcher reciba la petición de un cliente en un puerto y la envíe a un puerto diferente del servidor. Mediante mapport, puede repartir el tráfico de las peticiones de un cliente hacia un servidor donde se pueden estar ejecutando varios daemons de servidor. El valor por omisión para mapport es el número del puerto de destino de la petición del cliente.
La dirección de retorno es una dirección exclusiva o nombre de sistema principal que el usuario configura en la máquina de Dispatcher. Dispatcher utiliza la dirección de retorno como dirección de origen cuando reparte el tráfico de la petición del cliente hacia el servidor. De esta forma se asegura que el servidor devuelva el paquete a Dispatcher, en lugar de enviar el paquete directamente al cliente. ((Seguidamente, Dispatcher reenvía el paquete IP al cliente). Debe especificar la dirección de retorno (returnaddress) cuando añada el servidor. Para cambiar la dirección de retorno debe primero eliminar el servidor y luego añadirlo de nuevo. La dirección de retorno no puede ser la misma que la dirección de cluster, la dirección de servidor ni la dirección NFA.
La dirección del encaminador que conduce al servidor remoto.
En versiones anteriores de Network Dispatcher, el encaminamiento por contenido sólo podía utilizarse al usar el componente CBR en combinación con Caching Proxy. Ahora el componente Dispatcher permite realizar encaminamiento por contenido para HTTP (utilizando la norma de tipo "content") y para HTTPS (utilizando la afinidad del ID de sesión de SSL), sin tener que utilizar Caching Proxy. Para el tráfico de HTTP y HTTPS, el componente Dispatcher puede proporcionar un encaminamiento por contenido más rápido que el componente CBR.
Para HTTP: La selección de servidor, para el encaminamiento por contenido del Dispatcher, se basa en el contenido de un URL o una cabecera HTTP. Se configura utilizando la norma de tipo "content". Cuando configure la norma de contenido, especifique la cadena de búsqueda y un conjunto de servidores para la norma. Cuando se procesa una nueva petición entrante, esta norma compara la cadena especificada con el URL del cliente o con la cabecera HTTP especificada en la petición del cliente.
Si Dispatcher encuentra la cadena en la petición del cliente, Dispatcher reenvía la petición a uno de los servidores comprendidos en la norma. Seguidamente, Dispatcher reenvía la respuesta desde el servidor al cliente (método de reenvío "cbr").
Si Dispatcher no encuentra la cadena en la petición del cliente, Dispatcher no selecciona un servidor de entre el grupo de servidores comprendidos en la norma.
Para HTTPS (SSL): El direccionamiento basado en contenido de Dispatcher reparte el tráfico basándose en el campo de ID de sesión SSL contenido en la petición del cliente. Cuando se utiliza SSL, la petición de un cliente contiene el ID de sesión SSL de una sesión anterior y los servidores mantienen una antememoria de sus conexiones SSL anteriores. La función de afinidad del Dispatcher para el ID de sesión SSL permite establecer una nueva conexión entre el cliente y el servidor utilizando los parámetros de seguridad de la conexión anterior con el servidor. Debido a que no se tienen que volver a negociar los parámetros de seguridad de SSL, tales como claves compartidas y algoritmos de cifrado, los servidores ahorran ciclos de CPU y el cliente obtiene una respuesta más rápida. Para habilitar la afinidad de ID de sesión de SSL, puerto stickytime debe tener un valor distinto de cero. Una vez transcurrido el tiempo de persistencia, la petición del cliente se puede enviar a un servidor diferente del anterior.
Para implementar el encaminamiento por contenido del Dispatcher (método de reenvío cbr):
ndcontrol server add cluster:puerto:servidor mapport valor returnaddress dirección_retorno router dirección_retorno
ndcontrol rule 125.22.22.03:80:contentRule1 type content pattern patrón
Donde patrón especifica el patrón que debe utilizarse para la norma de tipo content. Para obtener más información sobre el tipo de norma content, vea Utilización de normas basadas en el contenido de la petición. Para conocer las expresiones válidas para patrón, vea Apéndice C, Sintaxis de la norma de contenido (patrón):.
Para HTTPS (SSL): Para configurar la afinidad del ID de sesión de SSL. establezca el parámetro stickytime del puerto en un valor distinto de cero. Para obtener más información sobre stickytime en el mandato port, consulte ndcontrol rule -- configurar normas.
Antes de seguir los pasos indicados en este capítulo, lea el Planificación del componente Dispatcher. Este capítulo explica cómo crear una configuración básica para el componente Dispatcher de Network Dispatcher.
Tabla 3. Tareas de configuración de la función Dispatcher
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina Dispatcher. |
Instalar la configuración de reparto del tráfico.
| Configurar la máquina Dispatcher |
Configurar máquinas para el reparto del tráfico. | Crear un alias para el dispositivo de bucle de retorno, comprobar si existe alguna ruta sobrante y suprimir las rutas sobrantes que existan. | Configuración de las máquinas servidor para el reparto del tráfico |
Existen cuatro métodos básicos para la configuración de Dispatcher:
Este es el medio más directo para configurar el Dispatcher. Los valores de los parámetros de mandatos se deben escribir en caracteres ingleses. Las únicas excepciones son los nombres de sistema principal (utilizados en los mandatos para clusters y servidores y en la modalidad de alta disponibilidad) y los nombres de archivo (utilizados en los mandatos sobre archivos).
Para iniciar Dispatcher desde la línea de mandatos:
Puede especificar una versión abreviada de los parámetros de los mandatos ndcontrol. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede entrar ndcontrol he f en lugar de ndcontrol help file.
Para iniciar la interfaz de línea de mandatos, emita ndcontrol para visualizar un indicador de mandatos de ndcontrol.
Para cerrar la interfaz de línea de mandatos, emita exit o quit.
Los mandatos para configurar el Dispatcher se pueden entrar en un archivo script de configuración para que se ejecuten conjuntamente. Consulte Archivos de configuración de ejemplo para Network Dispatcher.
ndcontrol file appendload miscript
ndcontrol file newload miscript
Para ver un ejemplo de la interfaz gráfica de usuario (GUI), consulte la Figura 2.
Para iniciar la GUI, siga estos pasos
ndserver
Para configurar el componente Dispatcher desde la GUI, debe seleccionar primero Dispatcher en la estructura en árbol. Puede arrancar el ejecutor y el gestor cuando esté conectado a un sistema principal. También puede crear clusters que contengan puertos y servidores e iniciar asesores para el gestor.
La GUI se puede utilizar para realizar las mismas acciones que con el mandato ndcontrol. Por ejemplo, para definir un cluster desde la línea de mandatos, especifique el mandato ndcontrol cluster add cluster. Para definir un cluster desde la GUI, pulse el botón derecho del ratón sobre Ejecutor, y en el menú emergente pulse el botón izquierdo sobre Añadir cluster. Escriba la dirección del cluster en la ventana emergente, a continuación pulse Aceptar.
Los archivos de configuración preexistentes de Dispatcher se pueden cargar utilizando las opciones Cargar nueva configuración (para sustituir totalmente la configuración actual) y Añadir a configuración actual (para actualizar la configuración actual); estas opciones aparecen en el menú emergente Sistema principal. Debe guardar periódicamente la configuración de Dispatcher en un archivo, mediante la opción Guardar archivo de configuración como también del menú emergente Sistema principal. El menú Archivo, situado en la parte superior de la GUI, le permitirá guardar las conexiones actuales del sistema principal en un archivo o restaurar las conexiones de los archivos existentes en todos los componentes Network Dispatcher.
Los mandatos de configuración también se pueden ejecutar remotamente. Para obtener más información, consulte Administración autenticada remota.
Puede acceder a la Ayuda pulsando el icono de signo de interrogación, situado en la esquina superior derecha de la ventana de Network Dispatcher.
Para obtener más información acerca de la utilización de la GUI, consulte Instrucciones generales para la utilización de la GUI.
Para obtener más información acerca de la utilización del asistente de configuración, consulte Configuración mediante el asistente para configuración.
Para configurar la máquina Dispatcher, debe ser el usuario root (en AIX, Linux o Solaris) o el administrador en Windows 2000.
En AIX, Linux y Solaris, Network Dispatcher puede tener un servidor con ubicación compartida. Esto simplemente significa que Network Dispatcher puede residir físicamente en una máquina servidor para la que realiza reparto del tráfico.
Necesitará al menos dos direcciones IP válidas para la máquina Dispatcher:
Esta dirección IP es la dirección IP principal de la máquina Dispatcher y se denomina dirección de no reenvío (NFA). Esta dirección es por omisión la misma que devuelve el mandato hostname. Utilice esta dirección para conectarse a la máquina con fines administrativos, como por ejemplo efectuar una configuración remota por medio de Telnet o acceder al subagente SNMP. Si la máquina Dispatcher ya puede realizar una operación ping con otras máquinas de la red, no es necesario hacer nada más para configurar la dirección de no reenvío.
Una dirección de cluster es una dirección que está asociada con un nombre de sistema principal (como www.suempresa.com). Esta dirección IP la utilizan los clientes para conectarse a los servidores de un cluster. Esta es la dirección cuyo tráfico es repartido por Dispatcher.
Sólo Solaris:
Por ejemplo, si planea utilizar adaptadores Ethernet de 100 Mbps, el archivo ibmnd.conf debe contener una sola línea que especifique el dispositivo hme. Si prevé utilizar un adaptador Ethernet de 10 Mbps y un adaptador Ethernet de 100 Mbps, el archivo ibmnd.conf contendrá dos líneas: una que especificará el dispositivo le y otra que especificará el dispositivo hme.
El archivo ibmnd.conf proporciona datos de entrada para el mandato autopush de Solaris y debe ser compatible con este mandato.
Por ejemplo, si los clusters X e Y están configurados para que los utilice el componente Mailbox Locator en cualquiera de los adaptadores que se muestran en ibmnd.conf, los clusters X e Y están desconfigurados cuando se emiten los mandatos ndcontrol executor start o ndcontrol executor stop. Puede que éste no sea el resultado que desea. Cuando los clusters X e Y se configuren en el script goAliases, los clusters volverán a configurarse automáticamente después de que el ejecutor de Dispatcher se inicie o se detenga.
Sólo para Windows 2000: Asegúrese de que el reenvío de IP no está habilitado para el protocolo TCP/IP. (Consulte la configuración de TCP/IP para Windows 2000).
La Figura 15 muestra un ejemplo de Dispatcher configurado con un solo cluster, dos puertos y tres servidores.
Figura 15. Ejemplo de las direcciones IP que se necesitan para la máquina Dispatcher
Si desea obtener ayuda sobre los mandatos utilizados en este procedimiento, consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator.
Si desea ver un archivo de configuración de ejemplo, consulte Archivos de configuración de ejemplo para Network Dispatcher.
AIX, Linux y Solaris: Para iniciar la función del servidor, escriba ndserver.
Windows 2000: La función del servidor se inicia automáticamente como un servicio.
Para iniciar la función del ejecutor, entre el mandato ndcontrol executor start. También puede cambiar diversos valores del ejecutor en este momento. Consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator.
La dirección de no reenvío sirve para conectarse a la máquina con fines administrativos, como por ejemplo, utilizar Telnet o SMTP en esta máquina. Por omisión, esta dirección es el nombre del sistema principal.
Para definir la dirección de no reenvío, entre el mandato ndcontrol executor set nfa dirección_IP o edite el archivo de configuración de ejemplo. Dirección_IP es el nombre simbólico o la dirección decimal con puntos.
Dispatcher repartirá las peticiones enviadas a la dirección de cluster hacia los servidores correspondientes configurados en los puertos de ese cluster.
El cluster es el nombre simbólico, la dirección decimal con puntos o la dirección 0.0.0.0 especial que define un cluster comodín. Para definir un cluster, emita el mandato ndcontrol cluster add. Para establecer opciones de cluster, emita el mandato ndcontrol cluster set; también puede utilizar la GUI para emitir mandatos. Se pueden utilizar clusters comodín para que coincidan con varias direcciones IP para paquetes entrantes cuyo tráfico se desea repartir. Consulte Utilizar el cluster comodín para combinar configuraciones de servidores, Utilizar el cluster comodín para repartir el tráfico de los cortafuegos y Utilización del cluster comodín con Caching Proxy para proxy transparente para obtener más información.
Una vez definido el cluster, generalmente deberá configurar la dirección del cluster en una de las tarjetas de interfaz de red de la máquina Dispatcher. Para ello, emita el mandato ndcontrol cluster configure dirección_cluster. De esta forma se buscará un adaptador con una dirección existente que pertenezca a la misma subred que la dirección de cluster. Luego emitirá el mandato de configuración del adaptador del sistema operativo para la dirección de cluster, utilizando el adaptador encontrado y la máscara de red para la dirección existente que se ha encontrado en el adaptador. Por ejemplo:
ndcontrol cluster configure 204.67.172.72
No se configurará la dirección de cluster en las siguientes circunstancias: para los clusters añadidos a un servidor en espera en modalidad de alta disponibilidad, y para los clusters añadidos a un dispatcher de área amplia que actúe como un servidor remoto. Tampoco es necesario que ejecute el mandato cluster configure si utiliza el script goIdle de ejemplo en modalidad autónoma. Para obtener información sobre el script goIdle, consulte Utilización de scripts.
En raros casos es posible que tenga una dirección de cluster que no coincida con ninguna subred de las direcciones existentes. Si así fuera, utilice el segundo formato del mandato cluster configure y proporcione explícitamente el nombre de interfaz y la máscara de red. Utilice ndcontrol cluster configure dirección_cluster nombre_interfaz máscara_red.
A continuación se muestran algunos ejemplos:
ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (AIX) ndcontrol cluster configure 204.67.172.72 eth0:1 255.255.0.0 (Linux) ndcontrol cluster configure 204.67.172.72 le0:1 255.255.0.0 (Solaris 7) ndcontrol cluster configure 204.67.172.72 le0 255.255.0.0 (Solaris 8) ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (Windows 2000)
Para utilizar el segundo formato del mandato de configuración del cluster en Windows 2000, debe determinar el nombre de interfaz que se debe utilizar.
Si tiene una sola tarjeta Ethernet en la máquina, el nombre de interfaz será en0. De igual forma, si tiene una sola tarjeta de Red en Anillo en la máquina, el nombre de interfaz será tr0. Si tiene varias tarjetas de cualquiera de los dos tipos, tendrá que determinar cuál es la correlación de las tarjetas. Siga estos pasos:
Debajo de Network Cards figuran los adaptadores de interfaz de red. Pulse en ellos para determinar si se trata de una interfaz Ethernet o de Red en Anillo. El tipo de interfaz figura en la columna Description. Los nombres asignados por ndconfig están correlacionados con los tipos de interfaz. Por ejemplo, ndconfig asigna la primera interfaz Ethernet de la lista a en0, la segunda a en1, etcétera; la primera interfaz de Red en Anillo se asigna a tr0, la segunda a tr1, etcétera.
Una vez obtenida esta información sobre correlaciones, puede crear un alias en la interfaz de red para la dirección de cluster.
El mandato "cluster configure" meramente ejecuta mandatos ifconfig (o ndconfig en Windows 2000), por lo que el usuario puede seguir usando los mandatos ifconfig (ndconfig) si lo desea.
El mandato ndconfig se suministra con el componente Dispatcher para configurar los alias de cluster utilizando la línea de mandatos. El mandato ndconfig tiene la misma sintaxis que el mandato ifconfig de UNIX.
ndconfig en0 alias 204.67.172.72 netmask 255.255.0.0
Para determinar el nombre de interfaz, utilice la misma técnica que para el segundo formato del mandato cluster configure.
Cuando utilice aplicaciones de servidores de vinculación específica que se vinculen con una lista de direcciones IP que no contienen el valor IP del servidor, utilice el mandato arp publish en lugar de ifconfig para establecer dinámicamente una dirección IP en la máquina Network Dispatcher. Por ejemplo:
arp -s <cluster> <dirección MAC Network Dispatcher> pub
Para definir un puerto, entre el mandato ndcontrol port add cluster:puerto, edite el archivo de configuración de ejemplo o utilice la GUI. Cluster es el nombre simbólico o la dirección decimal con puntos. Puerto es el número del puerto utilizado para el protocolo. También puede cambiar diversos valores de puerto en este momento. Debe definir y configurar todos los servidores de un puerto. Consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator.
El número de puerto 0 (cero) se utiliza para especificar un puerto comodín. Este puerto aceptará tráfico para un puerto que no está destinado a ninguno de los puertos definidos en el cluster. El puerto comodín se utilizará para configurar las normas y los servidores para cualquier puerto. Esta función también se podría utilizar si tiene una configuración de servidor/norma idéntica para varios puertos. El tráfico de un puerto afectaría luego a las decisiones de reparto del tráfico para el tráfico de otros puertos. Consulte Utilización del puerto comodín para dirigir el tráfico de puertos no configurados para obtener más información acerca de cuándo se utiliza un puerto comodín.
Para definir una máquina servidor con reparto del tráfico, escriba el mandato ndcontrol server add cluster:puerto:servidor, edite el archivo de configuración de ejemplo o utilice la GUI. Cluster y servidor son el nombre simbólico o la dirección decimal con puntos. Puerto es el número del puerto utilizado para el protocolo. Debe definir más de un servidor para un puerto en un cluster para realizar el reparto del tráfico.
Servidores de vinculación específica: Si el componente Dispatcher va a repartir el tráfico para servidores de vinculación específica, los servidores deben estar configurados para vincularse con la dirección de cluster. Puesto que Dispatcher reenvía los paquetes sin cambiar la dirección IP de destino, cuando los paquetes alcancen el servidor, todavía contendrán la dirección de cluster como destino. Si un servidor se ha configurado para vincularse con una dirección IP distinta de la dirección de cluster, el servidor no podrá aceptar paquetes/peticiones destinados al cluster.
Ubicación compartida con diferentes direcciones: En una configuración con ubicación compartida, la dirección del servidor con ubicación compartida no es necesario que sea idéntica a la dirección de no reenvío (NFA). Puede utilizar otra dirección si la máquina se ha definido con varias direcciones IP. Para el componente Dispatcher, la máquina servidor con ubicación compartida se debe definir como collocated mediante el mandato ndcontrol server. Para obtener más información acerca de los servidores con ubicación compartida, consulte Utilización de servidores de ubicación compartida.
Para obtener más información sobre la sintaxis del mandato ndcontrol server, consulte ndcontrol server -- configurar servidores.
La función gestor mejora el reparto del tráfico. Para arrancar el gestor, especifique el mandato ndcontrol manager start, edite el archivo de configuración de ejemplo o utilice la GUI.
Los asesores facilitan al gestor más información sobre la capacidad de las máquinas servidor con reparto del tráfico para responder a las peticiones. Cada asesor es específico de un protocolo. Por ejemplo, para iniciar el asesor HTTP, emita el mandato siguiente:
cbrcontrol advisor start http puertoPara obtener una lista de los asesores junto con sus puertos por omisión, consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator. Si desea ver una descripción de cada asesor, consulte la sección Lista de asesores.
Si inicia asesores, puede modificar la proporción de importancia que se asigna a la información del asesor utilizada para las decisiones sobre reparto del tráfico. Para establecer las proporciones del cluster, emita el mandato ndcontrol cluster set cluster proportions. Para obtener más información, consulte Grado de importancia dado a la información de estado.
Si el servidor es de ubicación compartida (Dispatcher reside en la misma máquina para la cual reparte el tráfico) o si utiliza los métodos de reenvío nat o cbr, no utilice los procedimientos indicados a continuación.
Si utiliza el método de reenvío mac, Dispatcher sólo es efectivo con los servidores de fondo que permiten configurar el adaptador de bucle de retorno con una dirección IP adicional, para la cual el servidor de fondo no responderá nunca a las peticiones ARP (protocolo de resolución de direcciones). Siga los pasos de esta sección para configurar las máquinas servidor con reparto del tráfico.
Para que las máquinas servidor con reparto del tráfico funcionen, debe asignar el dispositivo de bucle de retorno (normalmente denominado lo0) a la dirección de cluster (o preferiblemente crear un alias para el dispositivo). Si utiliza el método de reenvío mac, el componente Dispatcher no cambia la dirección IP de destino del paquete TCP/IP antes de reenviar el paquete a una máquina servidor TCP. Si asigna el dispositivo de bucle de retorno a la dirección de cluster o crea un alias para el dispositivo, las máquinas servidor de reparto del tráfico aceptarán los paquetes dirigidos a la dirección de cluster.
Si su sistema operativo permite la creación de un alias para interfaces de red (tal como AIX, Linux, Solaris o Windows 2000), es conveniente que cree un alias del dispositivo de bucle de retorno para la dirección de cluster. La ventaja de utilizar un sistema operativo que dé soporte a los alias es que puede configurar máquinas servidor con reparto del tráfico para atender a varias direcciones de cluster.
Para las versiones 2.2.14 o superiores del kernel de Linux, emita los mandatos siguientes antes de ejecutar el mandato ifconfig:
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden echo 1 > /proc/sys/net/ipv4/conf/all/hidden
Si su servidor tiene un sistema operativo que no admite el uso de alias, como HP-UX y OS/2, debe establecer el dispositivo de bucle de retorno en la dirección de cluster.
Utilice el mandato para su sistema operativo como se muestra en la Tabla 4 para establecer o unir mediante un alias el dispositivo de
bucle de retorno.
En algunos sistemas operativos puede que se cree una ruta por omisión, la cual debe eliminarse.
route print
netstat -nr
Ejemplo para Windows 2000:
Rutas activas: Direc. red Máscara subred Direc. pasarela Interfaz Métrica 0.0.0.0 0.0.0.0 9.67.128.1 9.67.133.67 1 9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1 9.67.128.0 255.255.248.0 9.67.133.67 9.67.133.67 1 9.67.133.67 255.255.255.255 127.0.0.1 127.0.0.1 1 9.67.133.158 255.255.255.255 127.0.0.1 127.0.0.1 1 9.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 9.67.133.158 9.67.133.158 1 224.0.0.0 224.0.0.0 9.67.133.67 9.67.133.67 1 255.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1
9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1
Debe eliminar la ruta sobrante. Para eliminarla, utilice el mandato correspondiente a su sistema operativo, que aparece en la Tabla 5.
Ejemplo: para eliminar la ruta sobrante mostrada en la tabla de ejemplo "Rutas activas" para el Paso 2, especifique lo siguiente:
route delete 9.0.0.0 9.67.133.158
Tabla 5. Mandatos para eliminar rutas sobrantes para Dispatcher
Si utilizamos el ejemplo de la Figura 15 y se configura una máquina servidor en la que se ejecuta AIX, el mandato sería:
route delete -net 204.0.0.0 204.67.172.72
Para comprobar si un servidor de fondo está configurado debidamente, realice los pasos siguientes desde una máquina diferente de la misma subred cuando Dispatcher no esté en ejecución y cluster no esté configurado:
arp -d cluster
ping cluster
No debería producirse ninguna respuesta. Si existe una respuesta al mandato ping, compruebe que no ejecutó ifconfig para asignar la dirección de cluster a la interfaz. Compruebe que no haya ninguna máquina que tenga una entrada "published arp" para la dirección de cluster.
Para las versiones 2.2.14 o superiores del kernel de Linux, compruebe que existe un "1" en /proc/sys/net/ipv4/conf/lo/hidden y /proc/sys/net/ipv4/conf/all/hidden.
arp -a
La salida del mandato debe mostrar la dirección MAC del servidor. Emita el mandato:
arp -s cluster dirección_mac_servidor
arp -d cluster
En el caso de los servidores Linux únicamente, para crear un alias para el dispositivo de bucle de retorno es necesario un parche determinado (que depende de la versión del kernel de Linux).
El parche asegura que la respuesta a ARP sólo se enviará desde un puerto de adaptador de red que tenga la dirección IP solicitada en la petición ARP. Sin este parche, Linux emitirá respuestas a ARP en la red para los alias de bucle de retorno. El parche también corrige una condición de actualización de ARP cuando varios puertos de adaptador de red con direcciones IP diferentes se encuentran en la misma red física.
Debe instalar el parche si se dan las condiciones siguientes:
Si utiliza el kernel 2.2.12 ó 2.2.13 en un servidor de fondo.
Notas:
El parche del kernel no es necesario para todas las configuraciones. Debe instalar un parche para las versiones 2.4.x del kernel de Linux en las condiciones siguientes:
Es posible descargar este parche desde el sitio Web siguiente: http://oss.software.ibm.com/developerworks/opensource/cvs/naslib.
Seleccione "CVS Tree" en la lista de descarga.
Para aplicar el parche:
cd /usr/src/linux-2.4/net/ipv4 patch -p0 -l < arp.c.2.4.0.patch
make dep;make clean;make bzImage;make modules;make modules_install cd arch/i386/boot cat bzImage > /boot/vmlinuz-2.4.2-2-arppatch cd /usr/src/linux-2.4 cp System.map /boot/System.map-2.4.2-2-arppatch cd /etc
Es necesario instalar un parche para las versiones 2.2.12 y 2.2.13 del kernel de Linux en los servidores donde se utilice el método de reenvío MAC. Puede obtener este parche en este sitio Web: http://www.ibm.com/developer/linux.
Para aplicar el parche:
patch -p0< archivo_parche
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_invisible
El efecto de este mandato sólo durará hasta que la máquina se apague. Cuando se vuelva a arrancar será necesario seguir de nuevo este paso y los pasos siguientes.
ifconfig lo:1 cluster netmask 255.255.255.255 up
Este capítulo describe lo que debe tener en cuenta el planificador de la red antes de instalar y configurar el componente CBR con Caching Proxy.
Este capítulo incluye las secciones siguientes:
El componente CBR le permite repartir el tráfico HTTP y SSL utilizando Caching Proxy para encaminar la petición
CBR es muy similar a Dispatcher en la estructura de sus componentes. CBR consta de las funciones siguientes:
El uso del gestor es opcional. No obstante, si no se utiliza un gestor, el reparto del tráfico se realiza utilizando una planificación rotatoria ponderada basada en los pesos actuales de los servidores, y no podrán utilizarse asesores.
Las tres funciones clave de CBR (el ejecutor, los asesores y el gestor) interactúan para repartir las peticiones entrantes entre los servidores. Además de repartir el tráfico de peticiones, el ejecutor supervisa el número de conexiones nuevas y activas y proporciona esta información al gestor.
El componente CBR le permite especificar un conjunto de servidores que manejen una petición basándose en la comparación de expresiones regulares del contenido de la petición. CBR permite hacer una partición del sitio para que diferentes servidores de aplicación o de contenido puedan dar servicio a conjuntos de servidores distintos. Esta partición será transparente para los clientes que accedan a su sitio Web. Puesto que CBR le permite especificar varios servidores para cada tipo de petición, se puede repartir el tráfico de las peticiones para optimizar la respuesta al cliente. Al permitir la asignación de varios servidores a cada tipo de contenido, estará protegido cuando falle una estación de trabajo o un servidor. CBR detectará el error y repartirá el tráfico de peticiones de los clientes hacia los demás servidores del grupo.
Una forma de dividir el sitio Web es asignar algunos servidores para que manejen sólo peticiones cgi y otro conjunto de servidores para manejar todas las demás peticiones. De esta forma los scripts cgi que requieren gran potencia de proceso no reducirán la velocidad de los servidores para el tráfico de html normal, lo que permitirá a los clientes un tiempo de respuesta global mejor. Al utilizar este esquema, podría asignar estaciones de trabajo más potentes a las peticiones normales. Esto daría a los clientes un tiempo de respuesta mejor sin tener que invertir en la actualización de todos los servidores.También podría asignar estaciones de trabajo más potentes a las peticiones cgi.
Otra posibilidad para realizar una partición en el sitio Web sería dirigir hacia un conjunto de servidores a los clientes que accedan a páginas con necesidad de un registro y todas las demás peticiones hacia un segundo conjunto de servidores. De esta forma los navegadores casuales del sitio Web no bloquearán recursos que podrían utilizar los clientes comprometidos con su registro. También le permitirá utilizar estaciones de trabajo más potentes para dar servicio a los clientes que se han registrado.
Por supuesto, también se pueden combinar los métodos anteriores con el fin de obtener mayor flexibilidad y un servicio mejorado.
Caching Proxy se comunica con CBR mediante su interfaz. Caching Proxy debe estar instalado en la misma máquina. Ahora pueden existir varias instancias de Caching Proxy ejecutándose en la misma máquina que se comuniquen simultáneamente con CBR. En versiones anteriores del producto, sólo podía haber una sola instancia de Caching Proxy en comunicación con CBR.
CBR, junto con Caching Proxy, examina las peticiones HTTP utilizando los tipos de normas especificados. Cuando está en ejecución, Caching Proxy acepta peticiones de clientes y consulta al componente CBR para saber cuál es el servidor más apropiado. Después de esta consulta, CBR compara la petición con un grupo de normas clasificadas por prioridades. Cuando una norma coincide, se elige un servidor adecuado de un conjunto de servidores preconfigurados. Finalmente, CBR informa a Caching Proxy sobre qué servidor se ha elegido y la petición se reenvía hacia allí.
Cuando haya definido un cluster para que tenga reparto del tráfico, debe asegurarse de que todas las peticiones hechas a ese cluster tengan una norma para seleccionar un servidor. Si no se encuentra ninguna norma que coincida con una petición concreta, el cliente recibirá una página de error de Caching de Proxy. La forma más fácil de asegurar que todas las peticiones coincidan con alguna norma es crear una norma "siempre cierta" con un valor de prioridad muy alto. Asegúrese de que todos los servidores utilizados por esta norma puedan atender todas las peticiones no gestionadas explícitamente por las normas que tienen valores de prioridad menores. (Nota: las normas con un valor de prioridad menor se evalúan primero.)
CBR, junto con Caching Proxy, puede recibir transmisión SSL desde el cliente y reenviarla al proxy (extremo cliente-proxy) y también encaminar la transmisión desde el proxy al servidor (extremo proxy-servidor). Puede definir un puerto SSL en un servidor de la configuración CBR para recibir la petición procedente del cliente; esto le permite mantener un sitio Web totalmente seguro y utilizar CBR para repartir el tráfico entre servidores SSL seguros.
Se tiene que añadir una sentencia de configuración al archivo ibmproxy.conf correspondiente a IBM Caching Proxy para habilitar el cifrado SSL en el extremo proxy-cliente. El formato debe ser:
proxy patrón_uri patrón_url dirección
donde patrón_uri es un patrón con el que hay que coincidir (por ejemplo: /secure/*), patrón_url es un URL de sustitución (por ejemplo: https://clusterA/secure/*) y dirección es la dirección del cluster (por ejemplo: clusterA).
CBR, junto con Caching Proxy, puede también recibir la transmisión SSL procedente del cliente y descifrar la petición SSL antes de reenviarla a un servidor HTTP. Para poder utilizar las comunicaciones de cliente a proxy bajo SSL y las comunicaciones de proxy a servidor bajo HTTP, existe la palabra clave opcional mapport del mandato cbrcontrol. Utilice esta palabra clave cuando necesite indicar que el puerto del servidor es diferente que el puerto de entrada del cliente. El ejemplo siguiente añade un puerto utilizando la palabra clave mapport; el puerto del cliente es 443 (SSL) y el puerto del servidor es 80 (HTTP):
cbrcontrol server add cluster:443 mapport 80
El número de puerto utilizado para mapport puede ser un valor entero positivo. El número de puerto por omisión es el puerto de entrada del cliente.
Debido a que CBR debe poder asesorar sobre las peticiones HTTP destinadas a un servidor configurado en el puerto 443 (SSL), se proporciona un asesor especial: ssl2http Este asesor se inicia su ejecución en el puerto 443 (puerto de entrada del cliente) e informa sobre los servidores configurados para ese puerto. Si hay dos clusters configurados y cada cluster tiene configurado el puerto 443 y servidores con un valor diferente de mapport, entonces una instancia individual del asesor puede abrir el puerto apropiado según convenga. El ejemplo siguiente muestra dicha clase de configuración:
Ejecutor Cluster1 Puerto:443 Servidor1 mapport 80 Servidor2 mapport 8080 Cluster2 Puerto:443 Servidor3 mapport 80 Servidor4 mapport 8080 Gestor Asesor ssl2http 443
Antes de seguir los pasos indicados en este capítulo, consulte el Planificación del componente Content Based Routing. Este capítulo explica cómo crear una configuración básica para el componente CBR de Network Dispatcher.
Tabla 6. Tareas de configuración para el componente CBR
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina CBR. | Determinar los requisitos. | Configuración de la máquina CBR |
Configurar máquinas para el reparto del tráfico. | Preparar la configuración del reparto del tráfico. | Paso 7. Definir las máquinas servidor sujetas a reparto del tráfico |
Para crear una configuración básica para el componente CBR de Network Dispatcher, existen cuatro métodos básicos:
Para poder utilizar CBR, debe estar instalado Caching Proxy.
Este es el medio más directo para configurar CBR. Los valores de los parámetros de mandatos se deben escribir en caracteres ingleses. Las únicas excepciones son los nombres de sistema principal (utilizados, por ejemplo, en los mandatos para clusters y servidores) y los nombres de archivos.
Para iniciar CBR desde la línea de mandatos:
Puede entrar los parámetros del mandato cbrcontrol en su forma abreviada. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede entrar cbrcontrol he f en lugar de cbrcontrol help file.
Para iniciar la interfaz de línea de mandatos, emita el mandato cbrcontrol para visualizar un indicador de mandatos de cbrcontrol.
Para cerrar la interfaz de línea de mandatos, emita exit o quit.
Notas:
( ), paréntesis derecho e izquierdo
&, ampersand
|, barra vertical
! signo de exclamación
*, asterisco
El shell del sistema operativo puede interpretar estos signos como caracteres especiales y convertirlos en texto alternativo antes de que cbrcontrol los evalúe.
Los caracteres especiales de la lista anterior son caracteres opcionales en el mandato cbrcontrol rule add y se utilizan cuando se especifica un patrón para una norma de contenido. Por ejemplo, el mandato siguiente puede ser válido solamente cuando se utiliza el indicador cbrcontrol>>.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern client=181.0.153.222&uri=http://10.1.203.4/nipoek/*
Para que este mismo mandato funcione en el indicador del sistema operativo, el patrón debe encerrarse entre comillas dobles (""), de la forma siguiente:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "client=181.0.153.222&uri=http://10.1.203.4/nipoek/*"
Si no se utilizan las comillas, puede truncarse parte del patrón cuando se guarde la norma en CBR. Tenga en cuenta que las comillas no están soportadas cuando se utiliza el indicador de mandatos cbrcontrol>>.
Los mandatos para configurar CBR se pueden entrar en un archivo de script de configuración y ejecutarlos juntos.
cbrcontrol file appendload miscript
cbrcontrol file newload miscript
Para ver un ejemplo de la interfaz gráfica de usuario (GUI), consulte la Figura 2.
Para iniciar la GUI, siga estos pasos
Para configurar el componente CBR desde la GUI, debe seleccionar primero Content Based Routing en la estructura en árbol. Puede arrancar el gestor una vez que esté conectado a un sistema principal. También puede crear clusters que contengan puertos y servidores e iniciar asesores para el gestor.
La GUI se puede utilizar para realizar cualquier acción que se desee llevar a cabo con el mandato cbrcontrol. Por ejemplo, para definir un cluster desde la línea de mandatos, escriba el mandato cbrcontrol cluster add cluster. Para definir un cluster desde la GUI, pulse el botón derecho del ratón sobre Ejecutor, y en el menú emergente pulse el botón izquierdo sobre Añadir cluster. Escriba la dirección del cluster en la ventana emergente, a continuación pulse en Aceptar.
Los archivos de configuración CBR preexistentes se pueden cargar utilizando las opciones Cargar nueva configuración (para sustituir totalmente la configuración actual) y Añadir a configuración actual (para actualizar la configuración actual); estas opciones aparecen en el menú emergente Sistema principal. Debe guardar periódicamente la configuración CBR en un archivo, mediante la utilización de la opción Guardar archivo de configuración como mostrada también en el menú emergente Sistema principal. El menú Archivo, situado en la parte superior de la GUI, le permitirá guardar las conexiones actuales del sistema principal en un archivo, o restaurar las conexiones de archivos existentes a través de los componentes de Network Dispatcher.
Puede acceder a la Ayuda pulsando el icono de signo de interrogación, situado en la esquina superior derecha de la ventana de Network Dispatcher.
Para obtener más información acerca de la utilización de la GUI, consulte Instrucciones generales para la utilización de la GUI.
Si está utilizando el asistente para configuración, siga estos pasos:
Puede iniciar el asistente desde el indicador de mandatos emitiendo cbrwizard. O, si lo prefiere, seleccione Asistente de configuración desde el menú del componente CBR que aparece en la GUI.
Para AIX, Linux o Solaris: Para iniciar Caching Proxy, especifique ibmproxy
Para Windows 2000: Para iniciar Caching Proxy, vaya al panel Servicios: Inicio-> Configuración-> Panel de control -> Herramientas administrativas -> Servicios
El asistente CBR le guía paso a paso a través del proceso de creación de una configuración básica para el componente CBR. Le mostrará preguntas acerca de la red y le guiará durante la configuración de un cluster que permite que CBR lleve a cabo el reparto del tráfico del tráfico entre un grupo de servidores.
Con el asistente para la configuración de CBR, verá los siguientes paneles:
Antes de configurar la máquina CBR, debe ser el usuario root (para AIX, Linux o Solaris) o el administrador en Windows 2000.
Necesitará una dirección IP para cada cluster de servidores que se van a configurar. Una dirección de cluster es una dirección que está asociada con un nombre de sistema principal (como www.company.com). Esta dirección IP la utilizan los clientes para conectarse a los servidores de un cluster. De forma específica, esta dirección se encuentra en la petición URL del cliente. CBR reparte el tráfico de todas las peticiones realizadas a la misma dirección de cluster.
Sólo para Solaris: Antes de utilizar el componente CBR, deben modificarse los valores por omisión del sistema de IPC (Inter-process Communication). Es necesario aumentar el tamaño máximo de un segmento de memoria compartida y el número de identificadores de semáforo. A fin de ajustar el sistema de forma que dé soporte a CBR, edite el archivo /etc/system del sistema para añadir las sentencias siguientes y luego rearranque:
set shmsys:shminfo_shmmax=0x02000000 set semsys:seminfo_semmap=750 set semsys:seminfo_semmni=30 set semsys:seminfo_semmns=750 set semsys:seminfo_semmnu=30 set semsys:seminfo_semume=30
Si no aumenta el segmento de memoria compartida a los valores mostrados anteriormente, el mandato cbrcontrol executor start no será efectivo.
Para poder utilizar CBR, debe estar instalado Caching Proxy.
Debe realizar las siguiente modificaciones en el archivo de configuración de Caching Proxy (ibmproxy.conf):
Cambie la directiva de URL entrante CacheByIncomingUrl para especificar "on".
Hay cuatro entradas que deben editarse para el Plug-in de CBR:
A continuación se muestran las adiciones específicas que deben hacerse al archivo de configuración para AIX, Linux, Solaris y Windows 2000.
Figura 16. Archivo de configuración CBR para AIX
ServerInit /usr/lpp/nd/servers/lib/libndcbr.so:ndServerInit PreExit /usr/lpp/nd/servers/lib/libndcbr.so:ndPreExit PostExit /usr/lpp/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /usr/lpp/nd/servers/lib/libndcbr.so:ndServerTerm
Figura 17. Archivo de configuración de CBR para Linux
ServerInit /opt/nd/servers/lib/libndcbr.so:ndServerInit PreExit /opt/nd/servers/lib/libndcbr.so:ndPreExit PostExit /opt/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/servers/lib/libndcbr.so:ndServerTerm
Figura 18. Archivo de configuración de CBR para Solaris
ServerInit /opt/nd/servers/lib/libndcbr.so:ndServerInit PreExit /opt/nd/servers/lib/libndcbr.so:ndPreExit PostExit /opt/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/servers/lib/libndcbr.so:ndServerTerm
Figura 19. Archivo de configuración de CBR para Windows 2000
Vía de acceso común de directorio de instalación:
ServerInit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndServerInit PreExit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndPreExit PostExit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndPostExit ServerTerm c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndServerTerm
Vía de acceso nativa de directorio de instalación:
ServerInit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndServerInit PreExit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndPreExit PostExit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndPostExit ServerTerm c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndServerTerm
Para iniciar la función del servidor CBR, escriba cbrserver en la línea de mandatos.
Automáticamente se cargará un archivo de configuración por omisión (default.cfg) cuando inicie cbrserver. Si el usuario decide guardar la configuración de CBR en default.cfg, todo lo que esté guardado en este archivo se cargará automáticamente la próxima vez que se inicie cbrserver.
Para iniciar la función del ejecutor, escriba el mandato cbrcontrol executor start. También puede cambiar diversos valores del ejecutor en este momento. Consulte ndcontrol executor -- controlar el ejecutor.
CBR repartirá las peticiones enviadas a la dirección de cluster entre los servidores correspondientes configurados en los puertos de ese cluster.
La dirección del cluster es un nombre simbólico o una dirección decimal con puntos. Esta dirección se encuentra en la porción del URL correspondiente al sistema principal.
Para definir un cluster, emita el mandato siguiente:
cbrcontrol cluster add cluster
Para establecer las opciones de cluster, emita el mandato siguiente:
cbrcontrol cluster set cluster opción valor
Para obtener más información, consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator.
Si desea ejecutar Caching Proxy configurado como proxy inverso, a la hora de repartir el tráfico para varios sitios Web, deberá añadir la dirección de cluster de cada sitio Web a, como mínimo, una de las tarjetas de interfaz de red del sistema de Network Dispatcher. En caso contrario, este paso puede omitirse.
Para AIX, Linux o Solaris: Para añadir la dirección del
cluster a la interfaz de red, utilice el mandato ifconfig. Utilice el
mandato del sistema operativo tal como se muestra en la Tabla 7.
Tabla 7. Mandatos para unir el NIC por medio de un alias
AIX | ifconfig nombre_interfaz alias dirección_cluster netmask máscara_red |
Linux | ifconfig nombre_interfaz dirección_cluster netmask máscara_red up |
Solaris 7 | ifconfig nombre_interfaz dirección_cluster netmask máscara_red up |
Solaris 8 | ifconfig addif nombre_interfaz dirección_cluster netmask máscara_red up |
Para Windows: Para añadir la dirección del cluster a la interfaz de red, haga lo siguiente:
El número de puerto es el puerto donde las aplicaciones de servidor están a la escucha. Para CBR con Caching Proxy y tráfico HTTP, suele ser el puerto 80.
Para definir un puerto para el cluster que definió en el paso anterior, emita lo siguiente:
cbrcontrol port add cluster:puerto
Para establecer las opciones de puerto, emita el mandato siguiente:
cbrcontrol port set cluster:puerto opción valor
Para obtener más información, consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator.
Las máquinas servidor son las máquinas donde se ejecutan las aplicaciones cuyo tráfico desea repartir. El servidor es el nombre simbólico o dirección decimal con puntos de la máquina servidor. Para definir un servidor en el cluster y puerto, emita el siguiente mandato:
cbrcontrol server add cluster:puerto:servidor
Para realizar el reparto del tráfico debe definir más de un servidor por puerto en un cluster.
Este es el paso clave al configurar CBR con Caching Proxy. Una norma define cómo se identificará una petición URL y se enviará hacia uno de los conjuntos de servidores adecuados. El tipo de norma especial utilizado por CBR se denomina norma de contenido. Para definir una norma de contenido, emita el mandato siguiente:
cbrcontrol rule add cluster:puerto:norma type content pattern=patrón
El valor de patrón es la expresión regular que se comparará con el URL de cada petición del cliente. Para obtener más información sobre cómo configurar el patrón, consulte Apéndice C, Sintaxis de la norma de contenido (patrón):.
Algunos de los demás tipos de norma definidos en Dispatcher también se pueden utilizar en CBR. Para obtener más información, consulte Configurar el reparto del tráfico basado en normas.
Cuando una norma concuerda con la petición de un cliente, se consulta el conjunto de servidores de la norma para averiguar qué servidor es mejor. El conjunto de servidores de la norma es un subconjunto de los servidores definidos en el puerto. Para añadir servidores al conjunto de servidores de una norma, emita el mandato siguiente:
cbrcontrol rule useserver cluster:puerto:norma servidor
La función del gestor mejora el reparto del tráfico. Para iniciar el gestor, emita el mandato siguiente:
cbrcontrol manager start
Los asesores proporcionan al gestor más información acerca de la capacidad de los servidores sujetos a reparto del tráfico para responder a las peticiones. Cada asesor es específico de cada protocolo. Por ejemplo, para iniciar el asesor HTTP, emita el mandato siguiente:
cbrcontrol advisor start http puerto
Si inicia asesores, puede modificar la proporción de importancia que se asigna a la información del asesor utilizada para las decisiones sobre reparto del tráfico. Para establecer las proporciones para el cluster, emita el mandato cbrcontrol cluster set cluster proportions. Para obtener más información, consulte Grado de importancia dado a la información de estado.
/usr/lpp/nd/servers/lib
/opt/nd/servers/lib
Vía de acceso común de directorio de instalación:
c:\Archivos de programa\IBM\edge\nd\servers\lib
Vía de acceso nativa de directorio de instalación:
c:\Archivos de programa\IBM\nd\servers\lib
En el nuevo entorno, inicie Caching Proxy: desde el indicador de mandatos, emita ibmproxy
Para configurar CBR, siga estos pasos:
En este capítulo se describen los aspectos que debe tener en cuenta la persona encargada de planificar la red antes de proceder a la instalación y configuración del componente Mailbox Locator.
Este capítulo incluye las siguientes secciones:
El componente Mailbox Locator le permite reenviar el tráfico de IMAP y POP3 basándose en el ID de usuario y la contraseña de la petición del cliente.
Mailbox Locator es muy similar a Dispatcher en su estructura de componentes. Mailbox Locator consta de las siguientes funciones:
El uso del gestor es opcional. No obstante, si no se utiliza un gestor, el reparto del tráfico se realiza utilizando una planificación rotatoria ponderada basada en los pesos actuales de los servidores, y no podrán utilizarse asesores.
Las tres funciones clave de Mailbox Locator(el ejecutor, los asesores y el gestor) interactúan para repartir el tráfico y distribuir entre los servidores las peticiones entrantes. Además de repartir el tráfico de peticiones, el ejecutor supervisa el número de conexiones nuevas y activas y proporciona esta información al gestor.
Para iniciar Mailbox Locator, emita el mandato mlserver desde el indicador de mandatos.
Mailbox Locator puede proporcionar un único punto de presencia para varios servidores IMAP o POP3. Cada servidor puede tener un subconjunto de todos los servicios de correo para los que ofrece servicio el punto de presencia. Para IMAP y POP3, Mailbox Locator es un proxy que elige un servidor adecuado basándose en el ID de usuario y la contraseña proporcionados por el cliente.
El siguiente método de ejemplo distribuye peticiones basándose en el ID de usuario de los clientes. Si tiene dos (o más) servidores POP3, puede dividir los buzones de correo alfabéticamente según el ID de usuario. Las peticiones de los clientes cuyos ID de usuario empiecen por las letras de la A a la I se pueden repartir hacia el servidor 1. Las peticiones de los clientes cuyos ID de usuario empiecen por las letras de la J a la R se pueden repartir hacia el servidor 2 y así sucesivamente.
También puede elegir que cada buzón se represente en más de un servidor. En este caso, el contenido de cada buzón debe estar disponible para todos los servidores de dicho buzón. En caso de que se produzca una anomalía en el servidor, habrá otro servidor que podrá acceder al buzón.
Para tener una sola dirección que represente varios servidores de correo POP3, puede configurar Mailbox Locator con una sola dirección de cluster que se convierta en la dirección de servidor de correo POP3 para todos los clientes. Los mandatos para configurarlo son los siguientes:
mlcontrol cluster add servidorCorreoPop3 mlcontrol port add servidorCorreoPop3:110 protocol pop3 mlcontrol server add servidorCorreoPop3:110:servidor1Pop3+servidor2Pop3+servidor3Pop3
En este ejemplo, ServidorCorreoPop3 representa la dirección de cluster. El Puerto 110 con el protocolo proxy POP3 se añade a ServidorCorreoPop3. Servidor1Pop3, Servidor2Pop3 y Servidor3Pop3 representan los servidores de correo de POP3 que se añaden al puerto. Con esta configuración, puede configurar las peticiones POP3 de entrada de los clientes de correo con la dirección de cluster ServidorCorreoPop3.
Cuando la petición de POP3 o IMAP llega al proxy, éste intenta contactar con todos los servidores configurados para el puerto utilizando la contraseña y el ID de usuario del cliente. La petición del cliente se dirige al primer servidor que responde. Debe utilizar la función de afinidad/persistencia junto con Mailbox Locator para los servidores IMAP o POP3. La función de afinidad permite que las peticiones subsiguientes procedentes del mismo ID de usuario del cliente se envíen al mismo servidor. Establezca el tiempo de persistencia (stickytime) del puerto en un valor mayor que cero para habilitar la función de afinidad. Para obtener más información sobre la función de afinidad, consulte La función de afinidad de Network Dispatcher.
El temporizador de desconexión automática por inactividad para los protocolos POP3 e IMAP es, como mínimo, de 10 minutos y 30 minutos respectivamente. Este tiempo de espera es el número de segundos durante los cuales puede haber ausencia de actividad en una conexión antes de que dicha conexión se elimine. Para optimizar el rendimiento, Mailbox Locator altera el valor del tiempo de espera de inactividad para que sea de 60 segundos. Para cambiar el tiempo de espera de inactividad, cambie el valor staletimeout (tiempo de inactividad) en el mandato mlcontrol cbrcontrol port. Para obtener más información sobre la configuración de este mandato, consulte el apartado ndcontrol port -- configurar puertos.
Antes de seguir los pasos indicados en este capítulo, consulte el Planificación para el componente Mailbox Locator.Este capítulo explica cómo crear una configuración básica para el componente Mailbox Locator de Network Dispatcher.
Tabla 8. Tareas de configuración para el componente Mailbox Locator
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina Mailbox Locator. | Determinar los requisitos. | Configuración de la máquina Mailbox Locator |
Configurar máquinas para el reparto del tráfico. | Preparar la configuración del reparto del tráfico. | Paso 4. Definir servidores de reparto del tráfico |
Para crear una configuración básica para el componente Mailbox Locator de Network Dispatcher, existen cuatro métodos básicos:
Este es el medio más directo para configurar Mailbox Locator. Los valores de los parámetros de mandatos se deben escribir en caracteres ingleses. Las únicas excepciones son los nombres de sistema principal (utilizados, por ejemplo, en los mandatos para clusters y servidores) y los nombres de archivos.
Para iniciar Mailbox Locator desde la línea de mandatos:
Puede especificar una versión abreviada de los parámetros de los mandatos mlcontrol. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede entrar mlcontrol he f en lugar de mlcontrol help file.
Para iniciar la interfaz de línea de mandatos, emita el mandato mlcontrol para visualizar un indicador de mandatos de mlcontrol.
Para cerrar la interfaz de línea de mandatos, emita exit o quit.
Los mandatos para configurar Mailbox Locator se pueden entrar en un archivo de script de configuración y ejecutarlos juntos.
mlcontrol file appendload miscript
mlcontrol file newload miscript
Para ver un ejemplo de la GUI, consulte la Figura 2.
Para iniciar la GUI, siga estos pasos
Para poder configurar el componente Mailbox Locator desde la GUI, antes debe seleccionar Mailbox Locator en la estructura en árbol. Puede arrancar el gestor una vez que esté conectado a un sistema principal. También puede crear clusters que contengan puertos y servidores e iniciar asesores para el gestor.
La GUI se puede utilizar para realizar las mismas acciones que pueden efectuarse con el mandato mlcontrol. Por ejemplo, para definir un cluster desde la línea de mandatos, escriba el mandato mlcontrol cluster add cluster. Para definir un cluster desde la GUI, pulse el botón derecho del ratón sobre Ejecutor, y en el menú emergente pulse el botón izquierdo sobre Añadir cluster. Escriba la dirección del cluster en la ventana emergente, a continuación pulse en Aceptar.
Los archivos de configuración preexistentes de Mailbox Locator se pueden cargar utilizando las opciones Cargar nueva configuración (para sustituir totalmente la configuración actual) y Añadir a configuración actual (para actualizar la configuración actual); estas opciones aparecen en el menú emergente Sistema principal. Debe guardar periódicamente la configuración de Mailbox Locator en un archivo, mediante la opción Guardar archivo de configuración como del menú emergente Sistema principal. El menú Archivo, situado en la parte superior de la GUI, le permitirá guardar las conexiones actuales del sistema principal en un archivo o restaurar las conexiones de archivos existentes a través de los componentes de Network Dispatcher.
Puede acceder a la Ayuda pulsando el icono de signo de interrogación, situado en la esquina superior derecha de la ventana de Network Dispatcher.
Para obtener más información acerca de la utilización de la GUI, consulte el apartado Instrucciones generales para la utilización de la GUI.
Si está utilizando el asistente para configuración, siga estos pasos:
Puede iniciar este asistente desde el indicador de mandatos emitiendo mlwizard. O bien, seleccione Asistente de configuración en el menú del componente Mailbox Locator que aparece en la GUI.
El asistente de Mailbox Locator le guía paso a paso en el proceso de creación de una configuración básica para el componente Mailbox Locator. El asistente le hará preguntas acerca de la red y le guiará mientras configura un cluster que permite que Mailbox Locator reparta el tráfico entre un grupo de servidores.
Cuando se utiliza el asistente de configuración de Mailbox Locator se muestran estos paneles:
Para configurar la máquina Mailbox Locator, debe ser el usuario root (en AIX, Linux o Solaris) o el administrador en Windows 2000.
Necesitará una dirección IP para cada cluster de servidores que se van a configurar. Una dirección de cluster es una dirección que está asociada con un nombre de sistema principal (como www.suempresa.com). Esta dirección IP la utilizan los clientes para conectarse a los servidores de un cluster. Mailbox Locator reparte el tráfico de todas las peticiones realizadas a la misma dirección de cluster.
Para iniciar la función del servidor, escriba mlserver en la línea de mandatos.
Mailbox Locator repartirá las peticiones enviadas a la dirección de cluster entre los servidores correspondientes configurados en los puertos de ese cluster.
La dirección del cluster es un nombre simbólico o una dirección decimal con puntos.
Para definir un cluster, emita el siguiente mandato:
mlcontrol cluster add cluster
Para establecer las opciones de cluster, emita el siguiente mandato:
mlcontrol cluster set cluster opción valor
Para obtener más información, consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator.
El número de puerto es el puerto donde las aplicaciones de servidor están a la escucha. Para el tráfico de IMAP, suele ser el puerto 143. Y para el tráfico de POP3, suele ser el puerto 110.
Para definir un puerto para el cluster que definió en el paso anterior, emita lo siguiente:
mlcontrol port add cluster:puerto protocol [pop3|imap]
Para establecer las opciones de puerto, emita el siguiente mandato:
mlcontrol port set cluster:puerto opción valor
Para obtener más información, consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator.
Los servidores de correo son las máquinas donde se ejecutan las aplicaciones cuyo tráfico se desea repartir. El servidor es el nombre simbólico o dirección decimal con puntos de la máquina servidor. Para definir un servidor en el cluster y puerto del paso 3, emita el siguiente mandato:
mlcontrol server add cluster:puerto:servidor
Para realizar el reparto del tráfico debe definir más de un servidor por puerto en un cluster.
La función del gestor mejora el reparto del tráfico. Para iniciar el gestor, emita el siguiente mandato:
mlcontrol manager start
Los asesores proporcionan al gestor más información acerca de la capacidad de los servidores de reparto del tráfico para responder a las peticiones. Cada asesor es específico de un protocolo. Network Dispatcher proporciona asesores para IMAP y POP3. Por ejemplo, para iniciar el asesor de IMAP, emita el mandato siguiente:
mlcontrol advisor start imap puertoPara obtener una lista de los asesores junto con sus puertos por omisión, consulte el Apéndice B, Consulta de mandatos para Dispatcher, CBR y Mailbox Locator. Si desea ver una descripción de cada asesor, consulte la sección Lista de asesores.
Si inicia asesores, puede modificar la proporción de importancia que se asigna a la información del asesor utilizada para las decisiones sobre reparto del tráfico. Para establecer las proporciones del cluster, emita el mandato mlcontrol cluster set cluster proportions. Para obtener más información, consulte Grado de importancia dado a la información de estado.
En este capítulo se describen los aspectos que debe tener en cuenta la persona encargada de planificar la red antes de proceder a la instalación y configuración del componente Site Selector.
Este capítulo incluye las siguientes secciones:
Site Selector actúa conjuntamente con un servidor de nombres de dominio para repartir el tráfico entre un grupo de servidores, utilizando medidas y valores de ponderación (pesos) recogidos. Puede crear una configuración de sitio Web para poder repartir el tráfico entre un grupo de servidores basándose en el nombre de dominio utilizado para la petición de un cliente.
Figura 20. Ejemplo de un entorno DNS
Cuando se configura un subdominio para Site Selector dentro del entorno DNS, Site Selector debe tener autorización sobre su propio subdominio. Por ejemplo, (consulte la Figura 20), se ha asignado a su empresa autorización sobre el dominio company.com. Dentro de la empresa, hay varios subdominios. Site Selector tendría autorización para siteload.company.com, mientras que el servidor o servidores DNS mantendrían autorización para atlanta.company.com y boston.company.com.
Para que el servidor de nombres de la empresa pueda reconocer que Site Selector tiene autorización para el subdominio siteload, se tiene que añadir una entrada del servidor de nombres en su archivo de datos con nombre. Por ejemplo, en AIX, una entrada del servidor de nombres sería parecida a la siguiente:
siteload.company.com. IN NS siteselector.company.com.
Donde siteselector.company.com es el nombre de sistema principal de la máquina Site Selector. En otros archivos de bases de datos con nombre se tendrían que añadir entradas equivalentes para que las utilizaran los servidores DNS.
Un cliente envía una petición para resolver un nombre de dominio en un nombre de servidor dentro de su red. El servidor de nombres reenvía la petición a la máquina de Site Selector. A continuación, Site Selector resuelve el nombre de dominio y obtiene la dirección IP de uno de los servidores que se ha configurado en el nombre de sitio. Site Selector devuelve la dirección IP del servidor seleccionado al servidor de nombres. El servidor de nombres devuelve la dirección IP al cliente. (Site Selector actúa como servidor de nombres no recursivo (nodo terminal) y devuelve un error si no resuelve la petición de nombre de dominio).
Consulte la Figura 11, que muestra un sitio Web en el que se utiliza Site Selector junto con un sistema DNS para repartir el tráfico entre servidores locales y remotos.
Site Selector consta de las siguientes funciones:
El uso del gestor es opcional. No obstante, si no se utiliza un gestor, el reparto del tráfico se realiza utilizando una planificación rotatoria ponderada basada en los pesos actuales de los servidores, y no podrán utilizarse asesores.
Mediante Metric Server, Site Selector puede supervisar el nivel de actividad de un servidor, detectar el servidor con menos tráfico y los servidores anómalos. El tráfico es una medida de la intensidad con que trabaja el servidor. El administrador de Site Selector del sistema controla el tipo de medida utilizada para medir el tráfico. Se puede configurar Site Selector para adaptarlo al entorno, tomando en cuenta factores como la frecuencia de acceso, el número total de usuarios y los tipos de acceso (por ejemplo, consultas breves, consultas de larga duración o cargas de datos que exigen un alto consumo de CPU).
El reparto del tráfico está basado en pesos (valores de ponderación) de los servidores. Para Site Selector, existen cuatro proporciones que el gestor utiliza para determinar los pesos:
Metric Server suministra los valores de CPU y memoria. Por tanto, es recomendable utilizar Metric Server cuando se utiliza el componente Site Selector.
En Metric Server hallará más información.
Las cuatro funciones clave de Site Selector (servidor de nombres, gestor, Metric Server y asesores) interactúan para repartir las peticiones entrantes entre los servidores.
Para utilizar la distribución de tráfico basada en DNS la colocación en antememoria de resoluciones de nombres tiene que estar inhabilitada. El valor TTL (tiempo de vida) determina la eficacia de la distribución de tráfico basada en DNS. TTL determina cuánto tiempo otro servidor de nombres mantendrá en antememoria la respuesta resuelta. Valores de TTL pequeños permiten llevar a cabo pequeños cambios en el servidor o en el tráfico de la red con mayor rapidez. Sin embargo, para inhabilitar la colocación en antememoria los clientes tienen que ponerse en contacto con el servidor de nombres con autorización para cada petición de resolución de nombre, lo que potencialmente aumenta el tiempo de latencia del cliente. Cuando se elige un valor de TTL, hay que tener en cuenta el efecto que tiene sobre un entorno la inhabilitación de la colocación en antememoria. También hay que tener en cuenta que la distribución de tráfico basada en DNS está potencialmente limitada por la colocación en antememoria en el extremo del cliente de las resoluciones de nombres.
TTL se puede configurar utilizando el mandato sscontrol sitename [add | set] . Consulte sscontrol sitename -- configurar un nombre de sitio para obtener más información.
La proximidad en la red es el cálculo del grado de cercanía de cada servidor respecto al cliente solicitante. Para determinar la proximidad en la red, el agente de Metric Server (el cual debe residir en cada servidor sujeto a reparto del tráfico) envía un mandato ping a la dirección IP del cliente y devuelve el tiempo de respuesta a Site Selector. Site Selector utiliza la respuesta de proximidad en las decisiones sobre reparto del tráfico. Site Selector combina el valor de la respuesta de proximidad en la red con el peso obtenido del gestor para crear un valor de ponderación final para el servidor.
La utilización de la función de proximidad en la red junto con Site Selector es opcional.
Site Selector proporciona las opciones siguientes de proximidad en la red que se pueden definir para cada nombre de sitio:
Si este parámetro se establece en sí, Metric Server emite un mandato ping al cliente para obtener el tiempo de respuesta de proximidad. El servidor de nombres espera a que respondan todos los Metric Servers o hasta que se sobrepase el tiempo de espera. Luego, para cada servidor, el servidor de nombres combina el tiempo de respuesta de proximidad con el peso calculado por el gestor y crea un valor de "peso combinado" para cada servidor. Site Selector proporcionará al cliente la dirección IP del servidor que tenga el mejor peso combinado. (Se espera que la mayoría de los servidores de nombres de cliente tengan un tiempo de espera de 5 segundos. Site Selector intenta responder antes de que se sobrepase ese tiempo de espera.)
Si este parámetro se establece en no, se proporcionará una resolución de nombres al cliente basada en los pesos actuales calculados por el gestor. A continuación, Metric Server emite un mandato ping al cliente para obtener el tiempo de respuesta de proximidad. El servidor de nombres coloca en antememoria el tiempo de respuesta que recibe de Metric Server. Cuando el cliente emite una segunda petición, el servidor de nombres combina, para cada servidor, el peso actual (calculado por el gestor) con el tiempo de respuesta (guardado en antememoria) y obtiene el servidor con el mejor "peso combinado". Site Selector devuelve la dirección IP de ese servidor al cliente para la segunda petición de este último.
Las opciones de proximidad en la red pueden establecerse en el mandato sscontrol sitename [add | set]. En el Apéndice D, Consulta de mandatos de Site Selector hallará más información.
Antes de seguir los pasos indicados en este capítulo, consulte el Planificación para el componente Site Selector.Este capítulo explica cómo crear una configuración básica para el componente Site Selector de Network Dispatcher.
Tabla 9. Tareas de configuración para el componente Site Selector
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina Site Selector. | Determinar los requisitos. | Configuración de la máquina Site Selector |
Configurar máquinas para el reparto del tráfico. | Preparar la configuración del reparto del tráfico. | Paso 4. Definir servidores de reparto del tráfico |
A fin de crear una configuración básica del componente Site Selector de Network Dispatcher, existen cuatro métodos básicos de configuración para este componente:
Este es el medio más directo para configurar Site Selector. Los valores de los parámetros de mandatos se deben escribir en caracteres ingleses. Las únicas excepciones son los nombres de sistema principal (utilizados, por ejemplo, en los mandatos para nombres de sitio y servidores) y los nombres de archivos.
Para iniciar Site Selector desde la línea de mandatos:
Puede especificar una versión abreviada de los parámetros de los mandatos sscontrol. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede entrar sscontrol he f en lugar de sscontrol help file.
Para iniciar la interfaz de línea de mandatos, emita sscontrol para visualizar un indicador de mandatos de sscontrol.
Para cerrar la interfaz de línea de mandatos, emita exit o quit.
Los mandatos para configurar Site Selector se pueden entrar en un archivo de script de configuración y ejecutarlos juntos.
sscontrol file appendload myscript
sscontrol file newload myscript
Para ver un ejemplo de la GUI, consulte la Figura 2.
Para iniciar la GUI, siga estos pasos
Para poder configurar el componente Site Selector desde la GUI, antes debe seleccionar Site Selector en la estructura en árbol. Puede arrancar el gestor una vez que esté conectado a un sistema principal. También puede crear nombres de sitio que contengan puertos y servidores e iniciar asesores para el gestor.
La GUI se puede utilizar para realizar las mismas acciones que con el mandato sscontrol. Por ejemplo, para definir un nombre de sitio desde la línea de mandatos, entre el mandato sscontrol sitename add nombresitio. Para definir un nombre de sitio de la GUI, pulse el botón derecho del ratón sobre Nombre de servidor, y en el menú emergente pulse el botón izquierdo sobre Añadir nombre de sitio. Indique el nombre de sitio en la ventana emergente y pulse Aceptar.
Los archivos de configuración preexistentes de Site Selector se pueden cargar utilizando las opciones Cargar nueva configuración (para sustituir totalmente la configuración actual) y Añadir a configuración actual (para actualizar la configuración actual); estas opciones aparecen en el menú emergente Sistema principal. Debe guardar periódicamente la configuración de Site Selector en un archivo, mediante la opción Guardar archivo de configuración como del menú emergente Sistema principal. El menú Archivo, situado en la parte superior de la GUI, le permitirá guardar las conexiones actuales del sistema principal en un archivo o restaurar las conexiones de archivos existentes a través de los componentes de Network Dispatcher.
Puede acceder a la Ayuda pulsando el icono de signo de interrogación, situado en la esquina superior derecha de la ventana de Network Dispatcher.
Para obtener más información acerca de la utilización de la GUI, consulte el apartado Instrucciones generales para la utilización de la GUI.
Si está utilizando el asistente para configuración, siga estos pasos:
Puede iniciar este asistente desde el indicador de mandatos emitiendo sswizard. O bien, seleccione Asistente de configuración en el menú del componente Site Selector que aparece en la GUI.
El asistente de Site Selector le guía paso a paso en el proceso de creación de una configuración básica para el componente Site Selector. El asistente le hará preguntas acerca de la red y le guiará mientras configura un nombre de sitio que permitirá que Site Selector reparta el tráfico entre un grupo de servidores.
Cuando se utiliza el asistente de configuración de Site Selector se muestran estos paneles:
Para configurar la máquina Site Selector, debe ser el usuario root (en AIX, Linux o Solaris) o el administrador en Windows 2000.
Necesitará un nombre de sistema principal DNS que no se pueda resolver, para utilizarlo como nombre de sitio para el grupo de servidores que defina. El nombre de sitio es el nombre que los clientes utilizan para acceder al sitio Web (por ejemplo, www.empresa.com). Site Selector utilizará DNS para repartir el tráfico de ese nombre de sitio entre el grupo de servidores.
AIX, Linux y Solaris: Para iniciar la función del servidor, escriba ssserver.
Para iniciar el servidor de nombres, emita el mandato sscontrol nameserver start.
Opcionalmente, inicie el servidor de nombres utilizando la palabra clave bindaddress para crear una vinculación únicamente con la dirección especificada.
Site Selector repartirá las peticiones enviadas al nombre de sitio entre los servidores correspondientes configurados para el nombre de sitio.
El nombre de sitio es un nombre de sistema principal que no se puede resolver y que el cliente solicitará. El nombre de sitio debe ser un nombre de dominio totalmente calificado (por ejemplo, www.dnsdownload.com). Cuando un cliente solicita este nombre de sitio, se devuelve una de las direcciones IP de servidor asociadas al nombre de sitio.
Para definir un nombre de sitio, emita el mandato siguiente:
sscontrol sitename add nombresitio
Para establecer las opciones de nombre de sitio, emita el mandato siguiente:
sscontrol sitename set valor opción nombresitio
Para obtener más información, consulte Apéndice D, Consulta de mandatos de Site Selector.
Las máquinas servidor son las máquinas donde se ejecutan las aplicaciones cuyo tráfico desea repartir. El servidor es el nombre simbólico o dirección decimal con puntos de la máquina servidor. Para definir un servidor en el nombre de sitio del paso 3, emita el mandato siguiente:
sscontrol server add nombresitio:servidor
Para repartir el tráfico debe definir más de un servidor para un nombre de sitio.
La función del gestor mejora el reparto del tráfico. Antes de iniciar la función del gestor, asegúrese de que el servidor de métricas esté instalado en todas las máquinas de reparto de tráfico.
Para iniciar el gestor, emita el siguiente mandato:
sscontrol manager start
Los asesores facilitan al gestor más información acerca de la capacidad de las máquinas servidor del reparto del tráfico para responder a las peticiones. Cada asesor es específico de cada protocolo. Network Dispatcher proporciona diversos asesores. Por ejemplo, para iniciar el asesor HTTP correspondiente a un nombre de sitio específico, emita el siguiente mandato:
sscontrol advisor start http nombresitio:puerto
Consulte Metric Server para obtener información sobre el uso de métricas del sistema y Metric Server.
Si inicia asesores, puede modificar la proporción de importancia que se asigna a la información del asesor (puerto) utilizada para las decisiones sobre reparto del tráfico. Para establecer las proporciones del nombre de sitio, emita el mandato sscontrol sitename set nombresitio proportions. Para obtener más información, consulte Grado de importancia dado a la información de estado.
Es recomendable utilizar Metric Server con el componente Site Selector. Consulte Metric Server para conocer cómo configurar Metric Server en todos los servidores para los que Site Selector reparte el tráfico.
En este capítulo se describen los aspectos que debe tener en cuenta la persona encargada de planificar la red antes de proceder a la instalación y configuración del componente Consultant para Cisco CSS Switches.
Este capítulo incluye estos temas:
La configuración de Cisco Consultant depende de la configuración de Cisco CSS Switch (vea Tabla 10). Después de realizar la planificación y configuración de Cisco CSS Switch, puede configurar y utilizar Cisco Consultant. Consulte la documentación de Cisco CSS Switch para obtener instrucciones sobre la planificación y configuración.
El componente Consultant consta de lo siguiente:
Los asesores obtienen información sobre los servidores y analizan los resultados para cada protocolo antes de invocar al gestor para que defina los pesos apropiados. Actualmente, Cisco Consultant proporciona asesores tales como HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3 (y otros). También tiene la opción de escribir sus propios asesores (consulte Creación de asesores personalizados (personalizables)). La utilización de asesores es opcional, pero recomendable.
Metric Server proporciona información a Consultant sobre el tráfico existente en los servidores, en forma de métricas específicas del sistema, y notifica el estado de los servidores. El gestor consulta al Metric Server que reside en cada servidor y asigna pesos para el reparto del tráfico utilizando las métricas recogidas por los agentes. Los resultados se colocan en el informe del gestor.
El gestor recoge información a partir del Cisco CSS Switch, los asesores y Metric Server. De acuerdo con la información que el gestor recibe, el gestor ajusta el valor de ponderación para los servidores de cada puerto y proporciona a Cisco CSS Switch la nueva ponderación para que la utilice en el reparto de conexiones nuevas. Cuando el gestor detecta que un servidor está inactivo, le asigna un peso 0 y el servidor se detiene. A partir de este momento, Cisco CSS Switch deja de reenviar tráfico hacia ese servidor.
Los asesores supervisan cada servidor del puerto asignado para determinar el tiempo de respuesta y la disponibilidad del servidor y luego proporcionan esta información al gestor. También controlan si un servidor está activo o inactivo.
Para configurar Consultant debidamente, la configuración debe corresponderse con la configuración de Cisco CSS Switch. Primero, consulte el manual Cisco Services Switch Getting Started Guide para configurar Cisco CSS Switch. Compruebe que Cisco Switch funciona correctamente y luego configure Consultant.
La configuración de Cisco CSS Switch consta de propietarios, normas de
contenido y servicios que están en correspondencia con una configuración de
Consultant, de esta manera:
Tabla 10. Términos de configuración de Consultant y Cisco CSS Switch
Cisco CSS Switch | Consultant |
---|---|
dirección IP virtual (VIP) de una o más de las normas de contenido del propietario | cluster |
puerto contenido en la norma de contenido | puerto |
servicio | servidor |
El árbol de configuración de Consultant consta de:
Figura 21. Ejemplo de Consultant configurado con 2 clusters, cada uno con 3 puertos
En la Figura 21:
Cuando configure el ejecutor, la dirección del ejecutor y el nombre de
comunidad SNMP deben concordar con los atributos correspondientes de Cisco CSS
Switch. Vea lbccontrol executor -- controlar el ejecutor para obtener información sobre cómo configurar el
ejecutor.
Configuración de Cisco CSS Switch | Configuración de Consultant |
---|---|
username admin superuser snmp community comunidad private read-write |
lbccontrol executor set address 10.10.20.1 lbccontrol executor set communityname comunidad |
content rule1 port 80 balance weightedrr add service servidor1 add service servidor2 vip address 9.67.154.35 active |
lbccontrol cluster add 9.67.154.35 lbccontrol port add 9.67.154.35:80 |
content rule 2 protocol tcp port 443 balance weightedrr add service servidor3 add service servidor4 vip address 9.67.154.35 active |
lbccontrol port add 9.67.154.35:443 |
service servidor1 ip address 10.10.20.2 port 80 weight 4 active |
lbccontrol server add 9.67.154.35:80:servidor1 address 10.10.20.2 |
service servidor3 ip address 10.10.20.4 port 443 weight 4 active |
lbccontrol server add 9.67.154.35:443:servidor3 address 10.10.20.4 |
Antes de seguir los pasos indicados en este capítulo, consulte el Planificación para el componente Consultant para Cisco CSS Switches.Este capítulo explica cómo crear una configuración básica para el componente Consultant para Cisco CSS Switches de Network Dispatcher.
Antes de comenzar cualquiera de las tareas de configuración de este capítulo:
Tabla 12. Tareas de configuración para el componente Consultant para Cisco CSS Switches
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina Consultant para Cisco CSS Switches. | Determinar los requisitos | Configuración de la máquina Consultant para Cisco CSS Switches |
Probar la configuración | Comprobar que la configuración es funcional | Comprobación de la configuración |
Dispone de tres métodos para crear una configuración básica para el componente Consultant para Cisco CSS Switches de Network Dispatcher:
Este es el medio más directo para configurar Cisco Consultant.Los procedimientos de este manual presuponen que se utiliza la línea de mandatos. Los valores de los parámetros de mandatos se deben escribir en caracteres ingleses. Las únicas excepciones son los nombres de sistema principal (utilizados, por ejemplo, en los mandatos para clusters y servidores) y los nombres de archivos.
Para iniciar Cisco Consultant desde la línea de mandatos:
Puede entrar los parámetros del mandato lbccontrol en su forma abreviada. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede escribir lbccontrol he f en lugar de lbccontrol help file.
Para arrancar la interfaz de línea de mandatos, emita lbccontrol con el fin de recibir un indicador de mandatos de lbccontrol.
Para cerrar la interfaz de línea de mandatos, emita exit o quit.
Los mandatos para configurar Consultant para Cisco CSS Switches se pueden entrar en un archivo de script de configuración y ejecutarse juntos.
lbccontrol file appendload miscript
lbccontrol file newload miscript
Para ver un ejemplo de la interfaz gráfica de usuario (GUI), consulte la Figura 2.
Para iniciar la GUI, siga estos pasos
lbcserver.
Para configurar el componente Cisco Consultant desde la GUI:
Puede utilizar la GUI para realizar cualquier acción que podría efectuar con el mandato lbccontrol. Por ejemplo, para definir un cluster desde la línea de mandatos, escriba el mandato lbccontrol cluster add cluster. Para definir un cluster desde la GUI, pulse el botón derecho del ratón sobre Ejecutor y luego seleccione Añadir cluster. Escriba la dirección del cluster en la ventana emergente, a continuación pulse en Aceptar.
Los archivos de configuración de Cisco Consultant preexistentes se pueden cargar utilizando las opciones Cargar nueva configuración (para sustituir totalmente la configuración actual) y Añadir a configuración actual (para actualizar la configuración actual); estas opciones aparecen en el menú emergente Sistema principal. Seleccione la opción Guardar archivo de configuración como para salvar periódicamente la configuración de Cisco Consultant en un archivo. Pulse Archivo, en la barra de menús, para guardar las conexiones actuales de sistema principal en un archivo, o para restaurar las conexiones de archivos existentes en todos componentes de Network Dispatcher.
Para acceder a la Ayuda, pulse el icono de signo de interrogación, situado en la esquina superior derecha de la ventana de Network Dispatcher.
Para obtener más información acerca de la utilización de la GUI, consulte Instrucciones generales para la utilización de la GUI.
Para configurar la máquina Consultant para Cisco CSS Switches, debe ser el usuario root (en AIX, Linux o Solaris) o el administrador en Windows 2000.
Consultant debe poder conectar con Cisco CSS Switch como administrador de Cisco CSS Switch.
Cuando configure el executor, la dirección del ejecutor y el nombre de comunidad SNMP deben concordar con los atributos correspondientes de Cisco CSS Switch.
Si desea obtener ayuda sobre los mandatos utilizados en este procedimiento, consulte el Apéndice E, Consulta de mandatos de Consultant para Cisco CSS Switches.
Si lbcserver no está ya en ejecución, inícielo ahora ejecutando el mandato siguiente como usuario root:
lbcserver
Debe configurar una dirección para el ejecutor y un nombre de comunidad SNMP. Estos valores deben concordar con los atributos correspondientes de Cisco CSS Switch.
Cluster es un nombre que se puede resolver o una dirección decimal con puntos. El cluster corresponde a la dirección IP virtual de Cisco CSS Switch contenida en una norma de contenido para un propietario.
Para definir un cluster, escriba lbccontrol cluster add cluster. Para establecer opciones para el cluster, escriba lbccontrol cluster set.
Para definir un puerto, escriba lbccontrol port add cluster:puerto. El puerto corresponde al puerto configurado en la norma de contenido de Cisco CSS Switch para el propietario.
Puerto es el número del puerto utilizado para el protocolo, tal como especifica la norma de contenido de Cisco CSS Switch para el propietario. En lbccontrol port -- configurar puertos hallará más información.
Puede configurar varias instancias del mismo servidor dentro de cualquier cluster y puerto. (Recuerde que la dirección y el nombre de comunidad SNMP deben concordar con los atributos correspondientes de Cisco CSS Switch). Si configura varias instancias del mismo servidor, podrá definir servidores de aplicaciones diferentes que residen en la misma máquina física y tienen la misma dirección IP en el mismo puerto.
Para definir un servidor con reparto del tráfico, escriba:
lbccontrol server add cluster:puerto:servidor address x.x.x.x | nombre_sistema_principal
El servidor corresponde al nombre del servicio de Cisco CSS Switch.
Debe definir más de un servidor para un puerto de un cluster para realizar el reparto del tráfico, de lo contrario el tráfico se dirigirá a un solo servidor. Consulte Particionamiento del servidor: servidores lógicos configurados para un solo servidor físico (dirección IP).
Para obtener más información sobre la sintaxis del mandato "lbccontrol server", consulte lbccontrol server -- configurar servidores.
Para iniciar el gestor, escriba el mandato lbccontrol manager start. En lbccontrol manager -- controlar el gestor hallará más información.
Los asesores facilitan al gestor más información sobre la capacidad de las máquinas servidor con reparto del tráfico para responder a las peticiones. Cada asesor es específico de un protocolo. Por ejemplo, para iniciar el asesor HTTP, emita el mandato siguiente:
lbccontrol advisor start http puertoSi desea obtener una lista de los asesores junto con sus puertos por omisión, consulte el lbccontrol advisor -- controlar el asesor. Si desea ver una descripción de cada asesor, consulte la sección Lista de asesores.
Si inicia cualquier asesor, debe cambiar las proporciones del cluster para que la información procedente del asesor se utilice en la toma de decisiones sobre reparto del tráfico. Para ello utilice el mandato lbccontrol cluster proportions. Consulte Grado de importancia dado a la información de estado.
En Metric Server hallará información sobre el uso de Metric Server.
Efectúe unas pruebas para comprobar que la configuración funciona.
Este capítulo describe cómo configurar los parámetros de reparto del tráfico de Network Dispatcher y cómo configurar Network Dispatcher para funciones avanzadas.
Tabla 13. Tareas avanzadas de configuración para Network Dispatcher
Tarea | Descripción | Información asociada |
---|---|---|
Opcionalmente, cambiar los valores de reparto del tráfico |
Puede cambiar los valores de reparto del tráfico siguientes:
| Optimización del reparto del tráfico proporcionado por Network Dispatcher |
Utilizar scripts para generar una alerta o registrar un error de servidor cuando el gestor marca un servidor como inactivo/activo | Network Dispatcher proporciona salidas de usuario que provocan la ejecución de scripts personalizables cuando el gestor marca un servidor como inactivo/activo | Utilización de scripts para generar una alerta o registrar un error de servidor |
Utilizar asesores y crear asesores personalizados | Describe los asesores y cómo escribir sus propios asesores personalizados para informar sobre estados determinados de los servidores | Asesores Creación de asesores personalizados (personalizables) |
Utilizar el asesor de Workload Manager (WLM) | El asesor de WLM proporciona información sobre el tráfico del sistema a Network Dispatcher | Asesor de Workload Manager |
Utilizar el agente de Metric Server | Metric Server proporciona información sobre el tráfico del sistema a Network Dispatcher | Metric Server |
Utilizar el particionamiento del servidor | Defina servidores lógicos para repartir el tráfico basándose en los servicios proporcionados | Particionamiento del servidor: servidores lógicos configurados para un solo servidor físico (dirección IP) |
Utilizar la opción de petición/respuesta del asesor (URL) | Defina un URL exclusivo para un cliente HTTP, que sea específico del servicio que desea consultar en la máquina. | Opción de petición/respuesta del asesor HTTP (URL) |
Instalar Network Dispatcher en la máquina donde realiza reparto del tráfico | Configure un máquina de Network Dispatcher de ubicación compartida. | Utilización de servidores de ubicación compartida |
Configurar el soporte de Dispatcher para una zona geográfica amplia | Configure un Dispatcher remoto para repartir el tráfico en una red de área amplia. O bien, reparta el tráfico en una red de área amplia (sin un Dispatcher remoto) utilizando una plataforma de servidor que dé soporte a GRE. | Configurar el soporte de Dispatcher para área amplia |
Configurar la modalidad de alta disponibilidad o de alta disponibilidad mutua | Configure una segunda máquina Dispatcher para proporcionar una unidad de reserva. | Alta disponibilidad |
Configurar el reparto del tráfico basado en normas | Defina las condiciones para las que se utilizará un subconjunto de los servidores. | Configurar el reparto del tráfico basado en normas |
Utilizar enlaces explícitos | Evite eludir el Dispatcher en los enlaces. | Utilización de enlaces explícitos |
Utilizar una red privada | Configure el Dispatcher para repartir el tráfico de los servidores en una red privada. | Utilización de una configuración de red privada |
Utilizar un cluster comodín para combinar configuraciones de servidores habituales | Las direcciones que no están configuradas explícitamente utilizarán el cluster comodín como medio para repartir el tráfico. | Utilizar el cluster comodín para combinar configuraciones de servidores |
Utilizar el cluster comodín para repartir el tráfico de los cortafuegos | Todo el tráfico se repartirá hacia los cortafuegos. | Utilizar el cluster comodín para repartir el tráfico de los cortafuegos |
Utilizar el cluster comodín con Caching Proxy para el proxy transparente | Permite utilizar Dispatcher para habilitar un proxy transparente. | Utilización del cluster comodín con Caching Proxy para proxy transparente |
Utilizar el puerto comodín para gestionar el tráfico no configurado de los puertos | Gestiona el tráfico que no está configurado para ningún puerto específico. | Utilización del puerto comodín para dirigir el tráfico de puertos no configurados |
Utilizar la función de persistencia para configurar un puerto de cluster que sea persistente | Permite dirigir las peticiones de los clientes hacia el mismo servidor. | La función de afinidad de Network Dispatcher |
Utilizar la API de SDA (Server Directed Affinity) | Proporciona una API que permite a un agente externo influir en el comportamiento de afinidad de Dispatcher | API de afinidad dirigida por el servidor (SDA) para controlar la afinidad cliente-servidor |
Utilizar la afinidad entre puertos para que la función de persistencia (afinidad) abarque varios puertos | Permite dirigir hacia el mismo servidor las peticiones de los clientes procedentes de puertos diferentes. | Afinidad entre puertos |
Utilizar la máscara de dirección de afinidad para designar una dirección de subred IP común | Permite dirigir hacia el mismo servidor las peticiones de los clientes procedentes de la misma subred. | Máscara de dirección de afinidad |
Utilizar la alteración temporal de afinidad de norma para que un servidor pueda alterar temporalmente la función de persistencia del puerto | Permite que un servidor altere temporalmente el valor de persistencia para su puerto. | Alteración temporal de afinidad de norma |
Utilizar la afinidad de cookie activa con el objeto de repartir el tráfico de los servidores para CBR | Es una opción de norma que permite que una sesión mantenga la afinidad para un servidor determinado. | Afinidad activa de cookie |
Utilizar la afinidad de cookie pasiva para repartir el tráfico de servidores para el encaminamiento por contenido de Dispatcher y el componente CBR | Es una opción de norma que permite que una sesión mantenga la afinidad para un servidor determinado basándose en el nombre de cookie/valor de cookie. | Afinidad pasiva de cookie |
Utilizar la afinidad de URI para repartir el tráfico entre servidores Caching Proxy, con contenido exclusivo que se debe almacenar en cada servidor | Es una opción de norma que permite que una sesión mantenga la afinidad para un servidor determinado basándose en el URI. | Afinidad de URI |
Utilizar la detección de "ataques de denegación de servicio" para informar al administrador (mediante una alerta) sobre posibles ataques. | Dispatcher comprueba si las peticiones entrantes contienen una cantidad importante de conexiones TCP semiabiertas en los servidores. | Detección de ataques de denegación de servicio |
Utilizar las anotaciones en binario para analizar datos estadísticos de servidores | Permite almacenar información sobre servidores en archivos binarios y recuperarla de ellos. | Utilizar las anotaciones en binario para analizar las estadísticas del servidor |
Utilizar Cisco Consultant (información adicional) | Cómo Cisco Consultant interactúa con Cisco CSS Switch e información adicional sobre la configuración de pesos. | Información adicional sobre las funciones avanzadas de Cisco Consultant |
La función de gestor de Network Dispatcher realiza reparto del tráfico basándose en los valores siguientes:
Se pueden cambiar estos valores para optimizar el reparto del tráfico de la red.
El gestor puede utilizar algunos o todos los factores externos siguientes en sus decisiones ponderadas:
O bien
Cpu: porcentaje de CPU en uso en cada máquina servidor sujeta a reparto del tráfico (datos de entrada procedentes del agente de Metric Server). Para Site Selector solamente, esta proporción sustituye a la columna de la proporción de conexiones activas.
O bien
Memoria: porcentaje de memoria ocupada en cada servidor de reparto del tráfico (información procedentes del agente de Metric Server). Para Site Selector solamente, esta proporción aparece en lugar de la columna de proporción para conexiones nuevas.
Junto con el peso actual de cada servidor e información de otro tipo necesaria para realizar cálculos, el gestor obtiene los dos primeros valores (conexiones activas y conexiones nuevas) a partir del ejecutor. Dichos valores están basados en la información que genera y almacena internamente el ejecutor.
Puede cambiar la proporción de importancia relativa de los cuatro valores para cada cluster (o nombre de sitio). Considere las proporciones como porcentajes; la suma de las proporciones relativas debe ser igual a 100%. La proporción por omisión es 50/50/0/0, que no tiene en cuenta la información de los asesores ni del sistema. En su entorno, puede ser necesario probar diferentes proporciones para encontrar la que produzca los mejores resultados.
Cuando se añade el asesor WLM, si la proporción de métrica del sistema es 0, el gestor aumenta este valor a 1. Debido a que la suma de las proporciones relativas debe ser igual a 100, el valor más alto se reduce en 1.
El número de conexiones activas depende del número de clientes, así como de por cuánto tiempo se necesita utilizar los servicios que ofrecen las máquinas servidor de reparto del tráfico. Si las conexiones de los clientes son rápidas (como por ejemplo, las realizadas a páginas Web pequeñas con HTTP GET), el número de conexiones activas será bastante bajo. Si las conexiones de los clientes son más lentas (como por ejemplo, una consulta de base de datos), el número de conexiones activas será más elevado.
Evite establecer valores demasiado bajos para las proporciones de conexiones activas y conexiones nuevas. Inhabilitará las funciones de reparto del tráfico y corrección de medidas de Dispatcher a menos que estos dos primeros valores sean 20 como mínimo, cada uno.
Para establecer la proporción de valores de importancia, utilice el mandato ndcontrol cluster set cluster proportions. En ndcontrol cluster -- configurar clusters hallará más información.
El gestor establece pesos basándose en contadores internos del ejecutor, en información recibida de los asesores y en información procedente de un programa de supervisión del sistema, tal como Metric Server. Si desea establecer pesos manualmente mientras ejecuta el gestor, especifique la opción fixedweight en el mandato "ndcontrol server". Para obtener una descripción de la opción fixedweight, consulte Pesos fijos del gestor.
Los pesos se aplican a todos los servidores de un puerto. En un puerto determinado, las peticiones se distribuirán entre los servidores según el peso relativo que tengan entre sí. Por ejemplo, si un servidor tiene establecido 10 como peso y otro tiene 5, el servidor con 10 debe obtener el doble de peticiones que el servidor con 5.
Para especificar el peso máximo que puede tener un servidor, emita el mandato ndcontrol port set weightbound. Este mandato afecta a la diferencia que puede existir entre el número de peticiones que recibirá cada servidor. Si establece el peso máximo en 1, todos los servidores pueden tener 1 como peso, 0 si están detenidos o -1 si están marcados como inactivos. Cuanto más alto sea este número, mayor será la diferencia de pesos para los servidores. Con un peso máximo de 2, un servidor podría recibir el doble de peticiones que otro. Con un peso máximo de 10, un servidor podría recibir diez veces más peticiones que otro. El peso máximo por omisión es 20.
Si un asesor detecta que un servidor está fuera de servicio, informa al gestor y éste asigna el peso 0 al servidor. Como resultado, el ejecutor no enviará más conexiones a ese servidor mientras el peso siga siendo 0. Si había alguna conexión activa con el servidor antes de que cambiase el peso, se dejará que finalice con normalidad.
Si no se utiliza el gestor, no se pueden ejecutar asesores y no pueden detectar si un servidor está inactivo. Si decide ejecutar los asesores, pero no desea que el gestor actualice el peso que ha definido para un servidor determinado, utilice la opción fixedweight en el mandato "ndcontrol server". Por ejemplo:
ndcontrol server set cluster:puerto:servidor fixedweight yes
Después de establecer fixedweight en "yes", utilice el mandato ndcontrol server set weight para establecer el peso en el valor que desee. El valor de peso del servidor permanecerá fijo mientras se ejecute el gestor hasta que emita otro mandato "ndcontrol server" con fixedweight establecido en "no". Para obtener más información, consulte ndcontrol server -- configurar servidores.
Para optimizar el rendimiento global, se restringe la frecuencia con que el gestor puede interactuar con el ejecutor. Se pueden realizar cambios en este intervalo entrando los mandatos ndcontrol manager interval y ndcontrol manager refresh.
El intervalo de gestor especifica con qué frecuencia actualizará el gestor los pesos de los servidores que utiliza el ejecutor para encaminar las conexiones. Si es demasiado bajo, puede producir un bajo rendimiento, como resultado de las constantes interrupciones que sufre el ejecutor por parte del gestor. Si es demasiado alto, puede ser que el encaminamiento de las peticiones que efectúa el ejecutor no esté basado en una información precisa y actualizada.
Por ejemplo, para establecer 1 segundo como intervalo de gestor, entre el mandato siguiente:
ndcontrol manager interval 1
El ciclo de renovación del gestor especifica con qué frecuencia pedirá el gestor información de estado al ejecutor. El ciclo de renovación está basado en los intervalos.
Por ejemplo, para establecer 3 como ciclo de renovación del gestor, entre el mandato siguiente:
ndcontrol manager refresh 3
Con ello se consigue que el gestor espere por espacio de 3 intervalos antes de pedir el estado al ejecutor.
Network Dispatcher proporciona otros métodos para que pueda optimizar el reparto del tráfico para los servidores. Para trabajar a pleno rendimiento, los pesos de los servidores sólo se actualizan si han cambiado significativamente. Actualizar de forma constante los pesos si no se produce apenas ningún cambio, o ninguno, en el estado del servidor, aumenta de forma innecesaria el volumen de actividad general. Cuando el porcentaje de cambios en el peso total de todos los servidores de un puerto es superior al umbral de sensibilidad, el gestor actualiza los pesos que el ejecutor utiliza para distribuir las conexiones. Por ejemplo, suponga que el peso total cambia de 100 a 105. El cambio es del 5%. Con el umbral de sensibilidad establecido en 5, el gestor no actualizará los pesos utilizados por el ejecutor, ya que el porcentaje de cambio no es superior al umbral. Sin embargo, si el peso total cambia de 100 a 106, el gestor actualizará los pesos. Para establecer el valor del umbral de sensibilidad del gestor en un valor diferente al valor por omisión (por ejemplo 6), entre el siguiente mandato:
ndcontrol manager sensitivity 6
En la mayoría de casos, no necesitará cambiar este valor.
El gestor calcula el peso de los servidores de forma dinámica. Como resultado, un peso actualizado puede diferir bastante del anterior. En la mayoría de los casos, eso no significa ningún problema. Sin embargo, esto puede provocar ocasionalmente un efecto de oscilación en la manera en que se reparte el tráfico de peticiones. Por ejemplo, un servidor puede acabar recibiendo la mayoría de las peticiones debido a un peso alto. El gestor verá que el servidor tiene un número elevado de conexiones activas y que responde con lentitud. Trasladará entonces el peso a los servidores libres y se producirá el mismo efecto en ellos, lo que desemboca en un uso no eficaz de los recursos.
Para aliviar este problema, el gestor utiliza un índice de corrección. El índice de corrección limita cuánto puede cambiar el peso de un servidor, con lo que se corrige de forma efectiva el cambio en la distribución de las peticiones. Cuanto más alto sea el índice de corrección, menos radicalmente cambiarán los pesos de los servidores. Cuanto más bajo sea el índice de corrección, más radicalmente cambiarán los pesos de los servidores. El valor por omisión del índice de corrección es 1,5. Con 1,5, los pesos de los servidores pueden ser bastante dinámicos. Si el índice es 4 ó 5, los pesos serán más estables. Por ejemplo, para establecer 4 como índice de corrección, entre el mandato siguiente:
ndcontrol manager smoothing 4
En la mayoría de casos, no necesitará cambiar este valor.
Network Dispatcher proporciona salidas de usuario que provocan la ejecución de scripts personalizables. Puede crear estos scripts para realizar acciones automatizadas, tales como avisar al administrador cuando el gestor marque un servidor como inactivo o simplemente registrar el evento del error. El directorio de instalación ...nd/servers/samples contiene scripts de ejemplo que puede personalizar. Para poder ejecutar los archivos de script, debe trasladarlos al directorio ...nd/servers/bin y eliminar la extensión de archivo ".sample". Se proporcionan los scripts de ejemplo siguientes:
Los asesores son agentes dentro de Network Dispatcher. Su finalidad es evaluar el estado y el tráfico de los servidores. Esto lo llevan a cabo mediante un intercambio de datos proactivo similar al existente entre un servidor y un cliente. Los asesores pueden considerarse clientes ligeros de los servidores de aplicaciones.
El producto proporciona varios asesores de protocolos específicos para los protocolos más comunes. Sin embargo, no es útil utilizar para cada componente de Network Dispatcher todos los asesores proporcionados. (Por ejemplo, no es aconsejable utilizar el asesor Telnet con el componente CBR). Network Dispatcher también da soporte al concepto de "asesor personalizado", que permite al usuario escribir sus propios asesores.
Limitación para las aplicaciones del servidor de vinculación específica en Linux: Para Linux, Network Dispatcher no da soporte al uso de asesores cuando se distribuye el tráfico de servidores con aplicaciones del servidor de vinculación específica (incluidos otros componentes de Network Dispatcher como Mailbox Locator o Site Selector) que se vinculan a la dirección IP del cluster.
Los asesores abren periódicamente una conexión TCP con cada servidor y envían un mensaje de petición al servidor. El contenido del mensaje es específico del protocolo que se ejecuta en el servidor. Por ejemplo, el asesor HTTP envía una petición "HEAD" de HTTP al servidor.
Los asesores esperan entonces una respuesta del servidor. Después de obtener la respuesta, el asesor hace una valoración del servidor. Para calcular este valor de "tráfico", la mayoría de asesores miden el tiempo que tarda el servidor en responder, y después utilizan este valor (en milisegundos) como valor de tráfico.
Entonces, los asesores informan del valor de tráfico a la función del gestor, donde aparece en la columna "Puerto" en el informe del gestor. El gestor calcula entonces los valores de peso agregados a partir de todas sus fuentes de datos, según sus proporciones, y establece estos valores de peso en la función del ejecutor. El Ejecutor utilizará entonces estos pesos para el reparto del tráfico de nuevas conexiones entrantes de clientes.
Si el asesor determina que un servidor está activo y en buen estado, se lo notificará al gestor con un número de tráfico positivo sin ceros. Si el asesor determina que un servidor no está activo, devolverá un valor de tráfico especial de uno negativo (-1). El Gestor y el Ejecutor no reenviarán las posibles conexiones a ese servidor.
Puede iniciar un asesor para un determinado puerto en todos los clusters (asesor de grupo). O puede ejecutar asesores diferentes para el mismo puerto, pero en clusters diferentes (asesor específico de cluster/sitio). Por ejemplo, si ha definido Network Dispatcher con tres clusters (clusterA, clusterB, clusterC), con el puerto 80 en cada uno, puede hacer lo siguiente:
ndcontrol advisor start http clusterA:80Este mandato inicia el asesor http en el puerto 80 del clusterA. El asesor http informará sobre todos los servidores conectados al puerto 80 de clusterA.
ndcontrol advisor start ADV_custom 80Este mandato inicia el asesor ADV_custom en el puerto 80 de clusterB y clusterC. Este asesor personalizado informará sobre todos los servidores conectados al puerto 80 de clusterB y clusterC . (Para obtener más información sobre los asesores personalizados, consulte Creación de asesores personalizados (personalizables)).
En el ejemplo anterior de configuración del asesor de grupo, puede elegir detener el asesor personalizado ADV_custom para el puerto 80 de uno solo de los clusters o de ambos (clusterB y clusterC).
ndcontrol advisor stop ADV_custom clusterB:80
ndcontrol advisor stop ADV_custom 80
El intervalo de asesor establece con qué frecuencia pregunta un asesor el estado a los servidores del puerto que está supervisando y, a continuación, notifica los resultados al gestor. Si es demasiado bajo, puede producir un bajo rendimiento, como resultado de las constantes interrupciones que sufren los servidores por parte de los asesores. Si es demasiado alto, puede ser que las decisiones que tome el gestor en lo que respecta a los pesos no estén basadas en una información precisa y actualizada.
Por ejemplo, para establecer 3 segundos como intervalo del asesor HTTP para el puerto 80, entre el mandato siguiente:
ndcontrol advisor interval http 80 3
No es útil especificar un intervalo de asesor que sea menor que el intervalo de gestor. El intervalo de gestor por omisión es siete segundos.
Para asegurarse de que el gestor no utilice información obsoleta en sus decisiones referentes al reparto del tráfico, el gestor no utiliza información procedente de un asesor cuya indicación horaria exceda la hora de caducidad del informe del asesor. El intervalo de caducidad del informe del asesor debe ser mayor que el intervalo de sondeo del asesor. Si el intervalo es menor, el gestor no tendrá en cuenta los informes que por lógica deberían utilizarse. Por omisión, los informes del asesor no caducan; es decir, su intervalo de caducidad predeterminado es ilimitado.
Por ejemplo, para establecer en 30 segundos el intervalo de caducidad del asesor HTTP para el puerto 80, entre este mandato:
ndcontrol advisor timeout http 80 30
Para obtener más información sobre cómo definir el intervalo de caducidad del informe del asesor, consulte ndcontrol advisor -- controlar el asesor.
En Network Dispatcher, puede definir los tiempos de espera para los que el asesor detecta si un servidor ha fallado. Los tiempos de espera para servidores anómalos (connecttimeout y receivetimeout) determinan cuánto tiempo espera un asesor antes de notificar que ha fallado una operación de conexión o recepción.
Si desea que la detección de servidores anómalos sea lo más rápida posible, establezca los tiempos de espera de conexión y recepción en el valor más bajo (1 segundo), y haga lo mismo para el intervalo de tiempo del asesor y del gestor.
Por ejemplo, para establecer en 9 segundos los valores connecttimeout y receivetimeout para el asesor HTTP en el puerto 80, escriba este mandato:
ndcontrol advisor connecttimeout http 80 9 ndcontrol advisor receivetimeout http 80 9
Los tiempos de espera de conexión y recepción predefinidos son 3 veces el valor especificado para el intervalo del asesor.
El asesor personalizado (personalizable) es una pequeña parte de código Java, que se puede proporcionar como un archivo de clases, llamado por el código base. El código base proporciona todos los servicios administrativos, como iniciar y parar una instancia del asesor personalizado, proporcionar el estado e informes y registrar información de historial en un archivo de anotaciones. También informa de los resultados al componente del gestor. El código base realizará periódicamente un ciclo asesor, donde evalúa individualmente todos los servidores y su configuración. Empieza abriendo una conexión con una máquina servidor. Si el socket se abre, el código base llamará al método (función) "getLoad" en el asesor personalizado. El asesor personalizado realiza entonces los pasos necesarios para evaluar la salud del servidor. Generalmente, enviará al servidor un mensaje definido por el usuario y después esperará una respuesta. (El acceso al socket abierto lo proporciona el asesor personalizado). El código base cierra entonces el socket con el servidor y proporciona al Gestor la información de tráfico.
El código base y el asesor personalizado pueden funcionar en modalidad normal o de sustitución. La elección de la modalidad de funcionamiento se especifica en el archivo del asesor personalizado como parámetro en el método del constructor.
En la modalidad normal, el asesor personalizado intercambia datos con el servidor, y el código base del asesor calcula el tiempo del intercambio y el valor del tráfico. El código base informa entonces al gestor de este valor del tráfico. El asesor personalizado sólo tiene que devolver un cero (en caso satisfactorio) o uno negativo (en caso de error). Para especificar la modalidad normal, el distintivo de sustitución del constructor se establece en falso.
En la modalidad de sustitución, el código base no realiza ninguna medición del tiempo. El código del asesor personalizado realiza las operaciones deseadas para sus requisitos, y a continuación devuelve un número de tráfico real. El código base aceptará el número y se lo notificará al gestor. Para obtener mejores resultados, normalice el valor de tráfico entre 10 y 1000, donde 10 representa un servidor rápido y 1000 representa un servidor lento. Para especificar la modalidad de sustitución, el distintivo de sustitución del constructor se establece en verdadero.
Con esta característica, se pueden escribir asesores propios que proporcionarán la información precisa que se necesite acerca de los servidores. Junto con el producto Network Dispatcher se proporciona con asesor personalizado de ejemplo, ADV_sample.java. Después de instalar Network Dispatcher, puede encontrar el código de ejemplo en el directorio de instalación ...nd/servers/samples/CustomAdvisors.
Los directorios de instalación por omisión son:
El directorio de instalación de Network Dispatcher contiene los archivos de ejemplo específicos para el asesor WebSphere Application Server.
Los archivos de ejemplo del asesor WebSphere Application Server residen en el mismo directorio de ejemplos que el archivo ADV_sample.java.
El nombre del archivo del asesor personalizado debe tener el formato "ADV_myadvisor.java." Debe empezar por el prefijo" ADV_" en mayúsculas. Todos los caracteres siguientes deben estar en minúsculas.
Al igual que para convenios Java, el nombre de la clase definida en el archivo debe coincidir con el nombre del archivo. Si copia el código de ejemplo, asegúrese de modificar todas las apariciones de "ADV_sample" del interior del archivo por su nuevo nombre de clase.
Los asesores personalizados están escritos en lenguaje Java. Debe obtener e instalar un compilador Java 1.3 para su máquina. Durante la compilación se utilizan estos archivos:
La vía de clases debe apuntar al archivo del asesor personalizado y al archivo de clase base durante la compilación.
Para Windows 2000, el mandato de compilación puede ser similar al siguiente:
javac -classpath <install_dir>\nd\servers\lib\ibmnd.jar ADV_fred.java
donde:
El resultado de la compilación es un archivo de clase, por ejemplo
ADV_fred.class
Antes de iniciar el asesor, copie el archivo de clase en el directorio ...nd/servers/lib/CustomAdvisors donde Network Dispatcher está instalado.
Para AIX, Linux y Sun, la sintaxis es similar.
Para ejecutar el asesor personalizado, primero debe copiar el archivo de clase en el subdirectorio apropiado de Network Dispatcher:
.../nd/servers/lib/CustomAdvisors/ADV_fred.class
Configure el componente, inicie su gestor y emita el mandato para iniciar el asesor personalizado:
ndcontrol advisor start fred 123
donde:
Al igual que todos los asesores, un asesor personalizado extiende la función del asesor base, llamado ADV_Base. El asesor base es el que ejecuta realmente la mayoría de las funciones del asesor, como informar del tráfico al gestor, para que dicha información se utilice en el algoritmo de ponderación del gestor. El asesor base también realiza las operaciones de conexión y cierre de socket, además de proporcionar los métodos de envío y recepción para que el asesor los utilice. El asesor en sí solamente se utiliza para recibir y enviar datos desde y hacia el puerto del servidor que se asesora. Los métodos TCP incluidos en el asesor base están temporizados para calcular el tráfico. Si se desea, un indicador dentro del constructor en el ADV_base sobrescribe el tráfico existente con el nuevo tráfico devuelto por el asesor.
Estos son los métodos de clase base:
Network Dispatcher examina primero la lista de asesores nativos que ese producto proporciona. Si no encuentran un asesor determinado en esa lista, entonces Dispatcher Dispatcher examina la lista de asesores personalizados del usuario.
/usr/lpp/nd/servers/lib/CustomAdvisors/
/opt/nd/servers/lib/CustomAdvisors/
/opt/nd/servers/lib/CustomAdvisors/
Vía de acceso común de directorio de instalación:
C:\Archivos de programa\IBM\edge\nd\servers\lib\CustomAdvisors
Vía de acceso nativa de directorio de instalación:
C:\Archivos de programa\IBM\nd\servers\lib\CustomAdvisors
El listado de programa para un asesor de ejemplo se incluye en Asesor de ejemplo. Después de la instalación, este asesor de ejemplo se encuentra en el directorio ...nd/servers/samples/CustomAdvisors.
WLM es el código que se ejecuta en sistemas principales MVS. Se puede consultar para preguntar sobre el tráfico en la máquina MVS.
Cuando MVS Workload Management se ha configurado en el sistema OS/390, Dispatcher puede aceptar la información de capacidad de WLM y utilizarla en el proceso de reparto del tráfico. Mediante la utilización del asesor WLM, Dispatcher abrirá periódicamente conexiones a través del puerto WLM, en cada servidor de la tabla de sistemas principales de Dispatcher y aceptará los enteros de capacidad devueltos. Puesto que estos enteros representan el volumen de capacidad que sigue estando disponible y Dispatcher espera valores que representen los tráficos de cada máquina, el asesor invierte los enteros de capacidad y los normaliza a valores de tráfico (es decir, un entero de gran capacidad pero con un valor de tráfico pequeño representa un servidor con un mejor estado). Los tráficos resultantes se colocan en la columna Sistema del informe del gestor.
Hay varias diferencias importantes entre el asesor WLM y los demás asesores de Dispatcher:
Al igual que Metric Server, el agente WLM genera informes sobre sistemas servidores considerados como un todo, en lugar de hacerlo para daemons de servidor individuales específicos del protocolo. Metric Server y WLM colocan sus resultados en la columna Sistema del informe del gestor. Como consecuencia de esto, no se puede ejecutar el asesor WLM y Metric Server al mismo tiempo.
Esta función se puede utilizar para todos los componentes de Network Dispatcher.
Metric Server proporciona información a Network Dispatcher sobre el tráfico de servidores en forma de métricas específicas del sistema y genera informes sobre el estado de los servidores. El gestor de Network Dispatcher consulta al agente de Metric Server que reside en cada servidor y asigna pesos al proceso de reparto del tráfico utilizando las métricas recogidas por los agentes. Los resultados se colocan en el informe del gestor.
Para ver un ejemplo de configuración, consulte la Figura 11.
Al igual que el asesor WLM, el Metric Server genera informes sobre los sistemas servidores considerados como un todo, en lugar de hacerlo para daemons de servidor individuales específicos del protocolo. Tanto WLM como Metric Server colocan sus resultados en la columna Sistema del informe del gestor. Como consecuencia de esto, no se puede ejecutar el asesor WLM y Metric Server al mismo tiempo.
El agente de Metric Server debe estar instalado y en ejecución en los servidores para los que Network Dispatcher realiza el reparto del tráfico.
A continuación, se indican los pasos para configurar Metric Server para Dispatcher. Pueden utilizarse pasos similares en la configuración de Metric Server para los otros componentes de Network Dispatcher.
puerto es el puerto RMI seleccionado para ejecutar todos los agentes de Metric Server. El puerto RMI por omisión que está establecido en el archivo metricserver.cmd es 10004.
systemMetric es el nombre del script (que reside en el servidor de fondo) que debe ejecutarse en cada servidor de la configuración del cluster (o nombre de sitio) especificado. Se proporcionan dos scripts para el usuario: cpuload y memload. O bien, el usuario puede crear scripts personalizados de métricas del sistema. El script contiene un mandato que debe devolver un valor numérico comprendido entre 0 y 100. Este valor numérico debe representar una medición de carga, no un valor de disponibilidad.
Limitación: Para Windows 2000, si el nombre del script de métricas del sistema tiene una extensión diferente de ".exe", debe especificar el nombre completo del archivo (por ejemplo, "mysystemscript.bat"). Esto es debido a una limitación de Java.
Opcionalmente, el usuario puede escribir sus propios archivos personalizados de script de métricas para definir el mandato que Metric Server emitirá para las máquinas servidores. Asegúrese de que los scripts personalizados sean ejecutables y estén situados en el directorio ...nd/ms/script. Los scripts personalizados deben devolver un valor de carga numérico en el rango de 0 a 100.
Para que Metric Server se ejecute en una dirección que no sea la del sistema principal local, tiene que editar el archivo metricserver en la máquina servidor de distribución de tráfico. Detrás de "java" en el archivo metricserver, inserte lo siguiente:
-Djava.rmi.server.hostname=OTRA_DIRECCIÓN
Además, antes de las sentencias "if" del archivo metricserver añada la siguiente línea:hostname OTRA_DIRECCIÓN.
Para Windows 2000: También tiene unir mediante alias OTRA_DIRECCIÓN en la pila de Microsoft. Para unir mediante un alias una dirección en la pila de Microsoft, consulte la página ***.
Cuando define un servidor en la configuración de Network Dispatcher, puede distribuir el tráfico basándose en el estado del servidor considerado en conjunto (utilizando el agente de Metric Server) o el estado de cualquier aplicación para un puerto determinado (utilizando la función del asesor).
Gracias al particionamiento del servidor, puede distinguir mejor entre los URL individuales y sus aplicaciones específicas. Por ejemplo, un servidor Web individual puede servir páginas JSP, páginas HTML, atender peticiones de base de datos, etc. Ahora Network Dispatcher proporciona la capacidad de particionar un servidor de un cluster y un puerto determinado en varios servidores lógicos. Esto le permite informar sobre un determinado servicio de la máquina para detectar si un motor de servlet o petición de base de datos se está ejecutando más rápidamente o no se está ejecutando.
El particionamiento del servidor permite, por ejemplo, que Network Dispatcher detecte que el servicio HTML está sirviendo páginas rápidamente, pero que la conexión con la base de datos se ha desactivado. Esto permite al usuario repartir el tráfico de una forma más precisa, de acuerdo con el servicio, en lugar de hacerlo basándose solamente en el servidor.
Dentro de la configuración de Network Dispatcher, puede representar un servidor físico o un servidor lógico utilizando la jerarquía cluster:puerto:servidor. El servidor puede ser una dirección IP exclusiva de la máquina (servidor físico) expresada en forma de nombre simbólico o en el formato decimal con puntos. O bien, si configura el servidor como servidor particionado, debe proporcionar un dirección de servidor que se pueda resolver para el servidor físico en el parámetro address del mandato ndcontrol server add. En ndcontrol server -- configurar servidores hallará más información.
El ejemplo siguiente muestra el particionamiento de servidores físicos en servidores lógicos para gestionar diferentes tipos de peticiones.
Cluster: 1.1.1.1 Puerto: 80 Servidor: A (dirección IP 1.1.1.2) servidor html Servidor: B (dirección IP 1.1.1.2) servidor gif Servidor: C (dirección IP 1.1.1.3) servidor html Servidor: D (dirección IP 1.1.1.3) servidor jsp Servidor: E (dirección IP 1.1.1.4) servidor gif Servidor: F (dirección IP 1.1.1.4) servidor jsp Norma1: \*.htm Servidor: A Servidor: C Norma2: \*.jsp Servidor: D Servidor: F Norma3: \*.gif Servidor: B Servidor: E
En este ejemplo, el servidor 1.1.1.2 está particionado según 2 servidores lógicos: A (que gestiona las peticiones html) y B (que gestiona la peticiones gif) El servidor 1.1.1.3 está particionado según 2 servidores lógicos: C (que gestiona las peticiones html) y D (que gestiona las peticiones jsp). El servidor 1.1.1.4 está particionado según 2 servidores lógicos: E (que gestiona las peticiones gif) y F (que gestiona las peticiones jsp).
La opción de URL del asesor HTTP puede utilizarse con los componentes Dispatcher y CBR.
Después de iniciar un asesor HTTP, puede definir un URL exclusivo para un cliente HTTP, que sea específico del servicio que desea consultar en el servidor. Esto permite que el asesor evalúe el estado de cada servicio de un servidor. Para ello, defina servidores lógicos que tengan un nombre de servidor exclusivo y la misma dirección física IP. En Particionamiento del servidor: servidores lógicos configurados para un solo servidor físico (dirección IP) hallará más información.
Para cada servidor lógico definido del puerto HTTP, puede especificar un URL exclusivo para un cliente HTTP, que sea específico del servicio que desea consultar en el servidor. El asesor HTTP utiliza la serie de caracteres advisorrequest para consultar el estado de los servidores. El valor por omisión es HEAD / HTTP/1.0. La cadena de texto advisorresponse es la respuesta de asesor que el asesor HTTP busca en la respuesta HTTP. El asesor HTTP utiliza la cadena de texto advisorresponse para compararla con la respuesta real recibida del servidor. El valor por omisión es null.
Importante: Si la serie del URL HTTP contiene un blanco:
server set cluster:puerto:servidor advisorrequest "head / http/2.0" server set cluster:puerto:servidor advisorresponse "HTTP 200 OK"
ndcontrol server set cluster:puerto:servidor advisorrequest "\"head / http/2.0\"" ndcontrol server set cluster:puerto:servidor advisorresponse "\"HTTP 200 OK\""
Network Dispatcher puede residir en la misma máquina que un servidor para el que está repartiendo el tráfico de peticiones. Esto se denomina compartimiento de la ubicación con un servidor. La ubicación compartida es aplicable a los componentes Dispatcher, Site Selector, Mailbox Locator y Cisco Consultant. La ubicación compartida también está soportada para CBR, pero sólo al utilizar servidores Web de vinculación específica y Caching Proxy de vinculación específica.
Red Hat Linux v7.1 (kernel de Linux versión 2.4.2-2) o SuSE Linux v7.1 (kernel de Linux versión 2.4.0-4 GB): Para poder configurar al mismo tiempo la ubicación compartida y la modalidad de alta disponibilidad, cuando ejecute el componente Dispatcher utilizando el método de reenvío mac, debe instalar un parche de kernel de Linux. Para obtener más información sobre la instalación del parche, consulte Instalación del parche del kernel de Linux (para suprimir las respuestas a arp en la interfaz de bucle de retorno). Cuando siga esas instrucciones, debe omitir el paso referente a la creación de un alias para el adaptador de bucle de retorno. Para crear el alias del adaptador de bucle de retorno, debe añadir la instrucción ifconfig al archivo de script para la alta disponibilidad, goStandby, que se ejecuta cuando un Dispatcher pasa al estado de espera.
Solaris: Existe una limitación: no puede configurar asesores WAND cuando el Dispatcher de punto de entrada es de ubicación compartida. Consulte Utilización de asesores remotos con soporte de área amplia.
En versiones anteriores, la dirección especificada para el servidor de ubicación compartida debía ser igual que la dirección de no reenvío (NFA) de la configuración. Esta restricción se ha eliminado.
Para configurar un servidor de ubicación compartida, el mandato ndcontrol server proporciona una opción denominada collocated (ubicación compartida) cuyo valor puede ser sí o no. El valor por omisión es no. La dirección del servidor debe ser una dirección IP válida correspondiente a una tarjeta de interfaz de red de la máquina.
Puede configurar un servidor de ubicación compartida en una de las maneras siguientes:
Consulte ndcontrol server -- configurar servidores para obtener más información sobre la sintaxis del mandato de servidor ndcontrol.
CBR da soporte al compartimiento de ubicación en todas las plataformas sin necesidad de llevar a cabo tareas adicionales de configuración. Sin embargo, los servidores Web y Caching Proxy que utilice deben ser de vinculación específica.
Mailbox Locator permite el compartimiento de ubicación en todas las plataformas. Pero el servidor debe estar asociado a una dirección diferente de la de Network Dispatcher para que ello sea efectivo. Para situar un servidor POP3 o IMAP en la misma máquina, debe estar asociado a una dirección IP diferente de la dirección del cluster. Esto se puede conseguir utilizando la dirección de bucle de retorno.
Site Selector permite el compartimiento de ubicación en todas las plataformas, sin ser necesarias tareas adicionales de configuración.
Cisco Consultant permite el compartimiento de ubicación en todas las plataformas, sin ser necesarias tareas adicionales de configuración.
Esta característica sólo está disponible para el componente Dispatcher.
Si no desea utilizar el soporte de área amplia de Dispatcher ni el método de reenvío nat de Dispatcher, una configuración de Dispatcher requiere que la máquina Dispatcher y sus servidores estén conectados al mismo segmento de LAN (consulte la Figura 22). El paquete de un cliente llega a la máquina Network Dispatcher y se envía al servidor, y luego desde el servidor se devuelve directamente al cliente.
Figura 22. Ejemplo de configuración formada por un sólo segmento de LAN
La mejora de Dispatcher para área amplia añade soporte para servidores situados fuera de las oficinas, conocidos como servidores remotos (consulte la Figura 23). Si GRE no recibe soporte en el sitio remoto y no utiliza el método de reenvío nat de Dispatcher, el sitio remoto debe constar de una máquina Dispatcher remota (Dispatcher 2) y sus servidores conectados localmente (ServerG, ServerH y ServerI). Todas las máquinas Dispatcher deben utilizar el mismo sistema operativo. Ahora, el paquete de un cliente puede ir desde Internet a una máquina Dispatcher, desde allí a una máquina Dispatcher geográficamente remota a uno de sus servidores conectados localmente.
Figura 23. Ejemplo de configuración utilizando servidores locales y remotos
Esto permite que una dirección de cluster dé soporte a todas las peticiones de clientes de cualquier zona geográfica y las distribuya entre servidores repartidos por todo el mundo.
La máquina Dispatcher que recibe inicialmente los paquetes puede seguir teniendo servidores locales conectados a ella y puede distribuir el tráfico entre los servidores locales y los remotos.
Los mandatos de área amplia no son complicados. Para configurar el soporte de área amplia:
ndcontrol server add cluster:puerto:servidor router dirección
Para obtener más información sobre la palabra clave "router", consulte ndcontrol server -- configurar servidores.
En los Dispatchers de punto de entrada, los asesores funcionarán correctamente sin ninguna configuración especial en la mayoría de plataformas.
Linux: Hay una limitación sobre el uso de asesores remotos con configuraciones con soporte de área amplia. Los asesores específicos del protocolo, como el asesor HTTP, que se ejecutan en la máquina Dispatcher de punto de entrada no asesoran correctamente sobre el estado de las máquinas servidor del sitio remoto. Para solucionar este problema, lleve a cabo una de las siguientes acciones:
Cualquiera de estas opciones permitirá que el asesor se ejecute en la máquina Dispatcher de punto de entrada con asesoramiento del estado de la máquina Dispatcher remota.
Solaris: En los Network Dispatchers de punto de entrada, debe utilizar el método de configuración arp (en lugar de los métodos de configuración ifconfig o cluster). Por ejemplo:
arp -s <dirección_cluster> <dirección_mac> pub
En los Dispatchers remotos, debe seguir los siguientes pasos de configuración para cada dirección de cluster remoto. Para configurar la modalidad de alta disponibilidad en el Network Dispatcher remoto, debe seguir estos pasos en las dos máquinas.
AIX
ifconfig lo0 alias 9.67.34.123 netmask 255.255.255.255
Linux
ifconfig lo:1 9.67.34.123 netmask 255.255.255.255 up
Solaris
Windows 2000
ndconfig en0 alias 9.55.30.45 netmask 255.255.240.0
arp -a
arp -d 9.67.34.123
y busque la dirección de la máquina.
route add 9.67.34.123 mask 255.255.255.255 9.55.30.45
Figura 24. Ejemplo de configuración de área amplia con Network Dispatchers remotos
Este ejemplo es aplicable a la configuración mostrada en la Figura 24.
A continuación se muestra cómo se deben configurar las máquinas Dispatcher para que den soporte a la dirección de cluster xebec en el puerto 80. ND1 se define como "punto de entrada". Se presupone que se utiliza una conexión Ethernet. Observe que ND1 tiene 5 servidores definidos: 3 locales (ServidorA, ServidorB, ServidorC) y 2 remotos (ND2 y ND3). Los servidores ND2 y ND3 tienen definidos tres servidores locales cada uno de ellos.
En la consola del primer Dispatcher (ND1), haga lo siguiente:
ndcontrol executor start
ndcontrol executor set nfa ND1
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND1 y configure también xebec como la dirección del cluster.
ndcontrol cluster configure xebec
En la consola del segundo Dispatcher (ND2):
ndcontrol executor start
ndcontrol executor set nfa ND2
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND2
En la consola del tercer Dispatcher (ND3):
ndcontrol executor start
ndcontrol executor set nfa ND3
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND3
Generic Routing Encapsulation (GRE) es un protocolo de interred cuyas especificaciones están contenidas en los documentos RFC 1701 y RFC 1702. Mediante GRE, el Network Dispatcher puede encapsular paquetes IP de los clientes dentro de paquetes IP/GRE y reenviarlos a plataformas de servidor, tales como OS/390, que dan soporte a GRE. El soporte de GRE permite que el componente Dispatcher reparta el tráfico de paquetes hacia varias direcciones de servidor asociadas a una sola dirección MAC.
Network Dispatcher utiliza GRE como parte de su función WAND (Network Dispatcher de área amplia). Esto permite que Network Dispatcher reparta el tráfico de una área amplia directamente hacia cualquier servidor que pueda desencapsular los paquetes GRE. No es necesario instalar Network Dispatcher en la ubicación remota si los servidores remotos dan soporte a los paquetes GRE encapsulados. Network Dispatcher encapsula los paquetes WAND utilizando el valor decimal 3735928559 para el campo de clave de GRE.
Figura 25. Ejemplo de configuración de área amplia con plataforma de servidor que da soporte a GRE
A los efectos de este ejemplo (Figura 25), para añadir el servidor remoto ServidorD, que da soporte a GRE, defínalo dentro de la configuración de Network Dispatcher como si estuviera definiendo un servidor WAND en la jerarquía cluster:puerto:servidor:
ndcontrol server add cluster:puerto:ServidorD router Router1
El asesor self se puede utilizar en el componente Dispatcher.
En una configuración WAND de dos niveles, Network Dispatcher proporciona un asesor self que recoge información sobre el estado del tráfico en los servidores de fondo.
Figura 26. Ejemplo de configuración WAND de dos niveles con utilización del asesor self
En este ejemplo, el asesor self y Metric Server residen en dos máquinas Dispatcher cuyo tráfico se reparte mediante el nivel superior de Network Dispatcher. El asesor self mide específicamente la tasa de conexiones por segundo en los servidores de fondo del Dispatcher a nivel de ejecutor.
El asesor self escribe los resultados en el archivo ndloadstat. Network Dispatcher también proporciona una métrica externa llamada ndload, la cual es invocada por el agente de Metric Server de cada máquina Dispatcher. El script ndload extrae una cadena de texto del archivo ndloadstat y la devuelve al agente de Metric Server. Después, cada agente de Metric Server (de cada Dispatcher) devuelve el valor de estado del tráfico al Network Dispatcher de dos niveles, que lo utiliza para determinar a qué Dispatcher debe reenviar las peticiones de los clientes.
El ejecutable ndload reside en el directorio .../nd/ms/script de Network Dispatcher.
La característica de alta disponibilidad sólo puede utilizarse con el componente Dispatcher.
Para mejorar la disponibilidad de Dispatcher, la función de alta disponibilidad de Dispatcher utiliza los mecanismos siguientes:
Si es posible, se recomienda que, como mínimo, uno de los pares de pulsos esté en una subred separada del tráfico regular del cluster. Mantener diferenciado el tráfico de pulsos ayudará a impedir falsas tomas de control durante las cargas de red de gran intensidad y también mejorará los tiempos de recuperación completa después de una anomalía.
La sintaxis completa de ndcontrol highavailability se encuentra en ndcontrol highavailability -- controlar la alta disponibilidad.
Si desea obtener una explicación más completa de la mayoría de las tareas indicadas a continuación, consulte Configurar la máquina Dispatcher.
Sólo para Windows 2000: Configure también todas las direcciones de no reenvío con el mandato ndconfig. Por ejemplo:
ndconfig en0 dirección_nfa netmask máscara_red
ndcontrol cluster set clusterA primaryhost dispatcherNFA1 ndcontrol cluster set clusterB primaryhost dispatcherNFA2
ndcontrol cluster set clusterB primaryhost dispatcherNFA2 ndcontrol cluster set clusterA primaryhost dispatcherNFA1
ndcontrol highavailability heartbeat add dirección_origen dirección_destino
Principal - highavailability heartbeat add 9.67.111.3 9.67.186.8 Reserva - highavailability heartbeat add 9.67.186.8 9.67.111.3Como mínimo debe haber un par de pulsos cuyas direcciones de no reenvío sean la dirección origen y de destino.
Si es posible, se recomienda que, como mínimo, uno de los pares de pulsos esté en una subred separada del tráfico regular del cluster. Mantener diferenciado el tráfico de pulsos ayudará a impedir falsas tomas de control durante las cargas de red de gran intensidad y también mejorará los tiempos de recuperación completa después de una anomalía.
ndcontrol highavailability reach add 9.67.125.18Se recomienda utilizar destinos de acceso aunque éstos no son necesarios. Consulte el apartado Posibilidad de detección de anomalías mediante pulsos y el destino de acceso para obtener más información.
ndcontrol highavailability backup add primary [auto | manual] puerto
ndcontrol highavailability backup add backup [auto | manual] puerto
ndcontrol highavailability backup add both [auto | manual] puerto
ndcontrol highavailability statusCada una de las máquinas debe tener la función correcta (máquina de reserva, máquina principal o ambas) y los estados y subestados correctos. La principal debe estar activa y sincronizada; la de reserva debe estar en modalidad de espera y debe quedar sincronizada en un corto plazo de tiempo. Las estrategias deben ser idénticas.
Notas:
Además del criterio básico de detección de errores (pérdida de conectividad entre los Dispatchers activo y de reserva, detectada a través de los mensajes de pulsos), existe otro mecanismo de detección de errores denominado criterio de accesibilidad. Cuando configure el Dispatcher, puede proporcionar una lista de sistemas principales a los que cada Dispatcher debe poder acceder para funcionar correctamente.
Debe elegir al menos un sistema principal para cada subred que utilice la máquina Dispatcher. Los sistemas principales pueden ser encaminadores, servidores IP u otros tipos de sistemas principales. El asesor de acceso averigua la accesibilidad del sistema principal enviándole mensajes de prueba. El relevo tiene lugar si los mensajes de prueba no pueden establecer conexión, o si los criterios de accesibilidad los cumple en mayor grado el Dispatcher de reserva que el Dispatcher principal. Para tomar la decisión basándose en toda la información disponible, el Dispatcher activo envía con regularidad al Dispatcher de reserva sus capacidades de acceso. El Dispatcher de reserva compara entonces estas capacidades con la suya propia y decide si ha de tomar el relevo.
Se configuran dos máquinas Dispatcher: la máquina principal y una segunda máquina llamada de reserva. Al arrancar, la máquina principal envía todos los datos de conexión a la máquina de reserva, hasta que ésta queda sincronizada. La máquina principal pasa a estar activa, es decir, comienza a repartir el tráfico. Mientras tanto, la máquina de reserva supervisa el estado de la máquina principal y se dice que está en estado de espera.
Si la máquina de reserva detecta en cualquier momento que la máquina principal ha fallado, toma el control de las funciones de reparto del tráfico de la máquina principal y se convierte en la máquina activa. Cuando la máquina principal vuelve a ser funcional, el comportamiento de las máquinas depende de cómo haya configurado el usuario la estrategia de recuperación. Existen dos tipos de estrategia:
El parámetro de estrategia debe ser el mismo para ambas máquinas.
La estrategia de recuperación manual permite forzar el encaminamiento de paquetes a una máquina en concreto, utilizando el mandato de relevo. La recuperación manual resulta útil cuando se realiza el mantenimiento en la otra máquina. La estrategia de recuperación automática está pensada para el funcionamiento normal desatendido.
En una configuración de alta disponibilidad mutua, no puede haber una anomalía para un solo cluster. Si se produce un problema en una de las máquinas, incluso si solo afecta a uno de los clusters, la otra máquina tomará el control de ambos clusters.
Para que Dispatcher encamine paquetes, cada dirección de cluster debe estar unida a un dispositivo de interfaz de red por medio de un alias.
Puesto que las máquinas Dispatcher cambian de estado cuando se detecta una anomalía, los mandatos anteriores deben emitirse de forma automática. Dispatcher ejecutará scripts creados por el usuario para hacerlo. Puede encontrar scripts de ejemplo en el directorio ...nd/servers/samples y debe trasladarlos al directorio ...nd/servers/bin para ejecutarlos.
Se pueden utilizar los scripts de ejemplo siguientes:
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
En goStandby y en GoInOp, el alias se tiene que eliminar. Por ejemplo:
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
Si hay varios NIC en la máquina, primero compruebe qué interfaz debe utilizar emitiendo en siguiente mandato en el indicador de mandatos: netsh interface ip show address. Este mandato devolverá una lista de las interfaces actualmente configuradas y numerará "Local Area Connection" (por ejemplo, "Local Area Connection 2") de modo que pueda determinar cuál debe utilizar.
Se puede utilizar el reparto del tráfico basado en normas para ajustar cuándo y cómo se envían los paquetes y a qué servidores. Network Dispatcher revisa las normas añadidas por el usuario desde la prioridad más alta hasta la más baja, deteniéndose en la primera norma que encuentre que sea cierta y, después, reparte el de contenido entre los servidores asociados a la norma. El tráfico ya se ha repartido según el destino y el puerto, pero la utilización de normas amplía la capacidad para distribuir conexiones.
En la mayoría de los casos, al configurar normas, es conveniente definir una norma por omisión always true para recoger las peticiones no atendidas por las demás normas de mayor prioridad. Esto puede adoptar la forma de una respuesta del tipo "El sitio Web está actualmente fuera de servicio; pruebe más tarde", cuando todos los demás servidores no atienden la petición del cliente.
Debe utilizar el reparto del tráfico basado en normas junto con Dispatcher y Site Selector cuando desee utilizar un subconjunto de servidores por alguna razón. Debe siempre utilizar normas para el componente CBR.
Puede utilizar los siguientes tipos de normas:
Antes de empezar a añadir normas a la configuración, se recomienda planificar la lógica que desea que sigan las normas.
Todas las normas tienen un nombre, tipo, prioridad, y pueden tener un inicio de rango y un final de rango, junto con un grupo de servidores. Además, la norma de tipo de contenido del componente CBR tiene asociada una expresión regular. (Para conocer ejemplos y casos prácticos de cómo utilizar la norma de contenido y la sintaxis válida de la expresión regular para dicha norma, consulte Apéndice C, Sintaxis de la norma de contenido (patrón):.)
Las normas se evalúan por orden de prioridad. Es decir, una norma con prioridad 1 se evaluará antes que una norma con prioridad 2. Se utilizará la primera norma que se cumpla. Una vez que se satisface una norma, las normas posteriores no se evalúan.
Para que se satisfaga una norma, debe cumplir dos condiciones:
Si una norma no tiene servidores asociados, la norma sólo necesita cumplir la primera condición para que sea cierta. En este caso, Dispatcher eliminará la petición de conexión, Site Selector devolverá la petición del servidor de nombres junto con un error y CBR hará que Caching Proxy devuelva una página de error.
Si no se cumple ninguna norma, Dispatcher seleccionará un servidor del conjunto total de servidores disponibles en el puerto, Site Selector seleccionará un servidor de entre los disponibles en el nombre de sitio y CBR hará que Caching Proxy devuelva una página de error.
Este tipo de norma se puede utilizar en el componente Dispatcher, CBR o Site Selector.
Puede que desee utilizar las normas basadas en la dirección IP del cliente si desea examinar los clientes y asignar recursos según su procedencia.
Por ejemplo, puede detectar que la red recibe gran cantidad de tráfico no deseado que procede de un determinado conjunto de direcciones IP, asignadas a diversos clientes morosos. Puede crear una norma por medio del mandato ndcontrol rule, por ejemplo:
ndcontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
Esta norma "ni" rechazaría cualquier conexión procedente de clientes IBM. A continuación podría añadir a la norma los servidores accesibles por los clientes de IBM; si no añade ningún servidor a la norma, las peticiones procedentes de las direcciones 9.x.x.x no las atenderá ningún servidor.
Este tipo de norma se puede utilizar en el componente Dispatcher, CBR o Site Selector.
Puede que desee utilizar normas basadas en la hora del día por motivos de planificación de los recursos. Por ejemplo, si su sitio Web recibe más visitas a las mismas horas del día, puede que desee dedicar cinco servidores a HTTP durante todo el día y añadir cinco más en las horas punta.
Otra razón por la que podría utilizar una norma basada en la hora del día es que desee desactivar varios servidores todos los días a medianoche para mantenimiento, en cuyo caso podría establecer una norma que excluyese estos servidores durante el período de mantenimiento necesario.
Este tipo de norma se puede utilizar en el componente Dispatcher y CBR.
Puede que desee utilizar normas basadas en las conexiones por segundo de un puerto si necesita compartir algunos servidores con otras aplicaciones. Por ejemplo, puede establecer dos normas:
O puede que esté utilizando Telnet y desee reservar dos de los cinco servidores para Telnet, excepto cuando las conexiones por segundo se incrementen por encima de cierto nivel. De esta manera, el Dispatcher podría repartir el tráfico entre los cinco servidores en las horas punta.
Este tipo de norma se puede utilizar en el componente Dispatcher y CBR.
Puede que desee utilizar normas basadas en el total de conexiones activas de un puerto si los servidores están sobrecargados y comienzan a descartar paquetes. Ciertos servidores Web continuarán aceptando conexiones, aunque no tengan subprocesos suficientes para responder a la petición. Como resultado, las peticiones de los clientes agotan el tiempo de espera y el cliente que accede al sitio Web no resulta atendido. Para repartir el tráfico entre una agrupación de servidores, se pueden utilizar normas basadas en las conexiones activas.
Por ejemplo, usted sabe por experiencia que sus servidores dejarán de atender a los clientes después de haber aceptado 250 conexiones. Puede crear una norma utilizando el mandato ndcontrol rule o el mandato cbrcontrol rule, por ejemplo:
ndcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 o bien cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
A continuación podría añadir a la norma los servidores actuales, además de algunos servidores adicionales que de otra manera se utilizarían para otros procesos.
Este tipo de norma sólo está disponible en el componente Dispatcher.
Puede que desee utilizar normas basadas en el puerto del cliente si los clientes están utilizando algún tipo de software que solicita un puerto TCP/IP determinado cuando realiza las peticiones.
Por ejemplo, podría crear una norma que especifique que cualquier petición con el puerto cliente 10002 utilizará un conjunto especial de servidores rápidos, ya que las peticiones que llegan por ese puerto proceden de clientes preferentes.
Este tipo de norma sólo está disponible en el componente Dispatcher.
Es posible que desee utilizar normas basadas en el contenido del campo "tipo de servicio" (TOS) de la cabecera IP. Por ejemplo, si se recibe una petición de cliente con un valor de TOS que indica que se trata de un servicio normal, la petición se puede encaminar hacia un grupo de servidores. Si se recibe una petición de cliente diferente con un valor de TOS diferente que indica que se trata de un servicio de prioridad más alta, la petición se puede encaminar hacia un grupo de servidores diferente.
La norma TOS le permite configurar completamente cada uno de los bits del byte TOS utilizando el mandato ndcontrol rule. Para los bits significativos que desea que coincidan con el byte TOS, utilice 0 ó 1. De lo contrario, se utiliza el valor x. El siguiente es un ejemplo de cómo añadir una norma TOS:
ndcontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
La utilización de capacidad y las normas de ancho de banda sólo se pueden utilizar en el componente Dispatcher.
Mediante la utilización de capacidad, Dispatcher mide el volumen de datos entregados por cada servidor. Dispatcher hace un seguimiento de la capacidad a nivel de servidor, norma, puerto, cluster y ejecutor. Para cada uno de estos niveles existe un nuevo valor contador de bytes: los kilobytes transferidos por segundo. Esta tasa (kilobytes transferidos por segundo) se calcula para un intervalo de 60 segundos. Puede visualizar estos valores de capacidad desde la GUI o en la salida de un informe de línea de mandatos.
Dispatcher le permite asignar un ancho de banda especificado a grupos de servidores de la configuración utilizando la norma de ancho de banda reservado. Cuando el tráfico excede el valor umbral de ancho de banda reservado, el usuario tiene opciones:
El uso combinado de las normas de ancho de banda reservado y ancho de banda compartido, tal como se describieron anteriormente, le permite ofrecer a clientes determinados un mejor acceso al servidor y por tanto optimizar el rendimiento de las transacciones. Por ejemplo, mediante el uso del ancho de banda compartido para adquirir ancho de banda no utilizado, puede permitir que los clientes que realizan transacciones comerciales en clusters de servidores reciban un mayor acceso que los clientes que utilizan otros clusters de servidores para el análisis de inversiones.
Tenga en cuenta lo siguiente para determinar si las normas de ancho de banda pueden ayudarle a gestionar el volumen del tráfico de respuesta que circula desde los servidores a los clientes:
Este tipo de norma sólo está disponible en el componente Dispatcher.
La norma del ancho de banda reservado le permite repartir el tráfico basándose en el número de kilobytes por segundo entregados por un grupo de servidores. Puede definir un valor umbral (asignando un rango de ancho de banda especificado) para cada grupo de servidores de la configuración, y de esta forma controlar y asegurar el ancho de banda utilizado por cada combinación cluster-puerto. Lo siguiente es un ejemplo de cómo añadir una norma de ancho de banda reservado (reservedbandwidth):
ndcontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
El inicio de rango y el final de rango se especifican en kilobytes por segundo.
Este tipo de norma sólo está disponible en el componente Dispatcher.
Si el volumen de datos transferidos supera el límite definido por la norma del ancho de banda reservado, la norma del ancho de banda compartido le permite adquirir ancho de banda no utilizado que esté disponible en el sitio Web. Puede configurar esta norma para compartir ancho de banda a nivel de cluster o de ejecutor. El ancho de banda compartido a nivel de cluster permite el uso compartido de un ancho de banda máximo por varios puertos (aplicaciones/protocolos) dentro del mismo cluster. El ancho de banda compartido a nivel de ejecutor permite el uso compartido de un ancho de banda máximo por varios clusters dentro de la configuración completa de Dispatcher.
Antes de configurar la norma del ancho de banda compartido, debe especificar el ancho de banda máximo (kilobytes por segundo) que se puede compartir a nivel de ejecutor o de cluster, utilizando el mandato ndcontrol executor o ndcontrol cluster con la opción sharedbandwidth. A continuación se muestran ejemplos de la sintaxis de los mandatos:
ndcontrol executor set sharedbandwidth tamaño ndcontrol cluster [add | set] 9.12.32.9 sharedbandwidth tamaño
El valor tamaño para ancho de banda compartido (sharedbandwidth) es un valor entero (kilobytes por segundo). El valor por omisión es 0. Si el valor es 0, no se puede compartir el ancho de banda. Debe especificar un ancho de banda compartido máximo que no exceda el ancho de banda total disponible (capacidad total del servidor).
Los ejemplos siguientes muestran cómo añadir o definir una norma de ancho de banda compartido (sharedbandwidth):
ndcontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel valor ndcontrol rule set 9.20.34.11:80:shrule sharelevel valor
El valor para el nivel de compartimiento (sharelevel) es executor o cluster. Sharelevel es un parámetro obligatorio de la norma de ancho de banda compartido.
Este tipo de norma sólo puede utilizarse en el componente Site Selector.
Para la norma de la métrica total, el usuario selecciona una métrica del sistema (cpuload, memload o un script personalizado de métricas del sistema) y Site Selector compara el valor de métrica del sistema (devuelto por el agente de Metric Server que reside en cada servidor con reparto del tráfico) con el inicio y final de rango especificados en la norma. El valor actual de la métrica del sistema para todos los servidores del grupo debe estar dentro del rango para que se aplique la norma.
El ejemplo siguiente muestra cómo añadir una norma de métrica total a la configuración:
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Este tipo de norma sólo puede utilizarse en el componente Site Selector.
Para la norma de la métrica promedio, el usuario selecciona una métrica del sistema (cpuload, memload o un script personalizado de métricas del sistema) y Site Selector compara el valor de métrica del sistema (devuelto por el agente de Metric Server que reside en cada servidor con reparto del tráfico) con el inicio y final de rango especificados en la norma. El promedio de los valores actuales de métricas del sistema para todos los servidores del grupo debe estar dentro del rango para que se aplique la norma.
El ejemplo siguiente muestra cómo añadir una norma de métrica promedio a la configuración:
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
Este tipo de norma se puede utilizar en el componente Dispatcher, CBR o Site Selector.
Se puede crear una norma que sea "siempre cierta". Dicha norma se seleccionará siempre, a no ser que todos los servidores asociados a ella se encuentren desactivados. Por esta razón, debe tener generalmente una prioridad más baja que las demás normas.
Incluso se pueden tener varias normas "siempre ciertas", cada una de ellas asociada a un conjunto de servidores. Se selecciona la primera norma con un servidor disponible. Por ejemplo, supongamos que usted tiene seis servidores. Desea que dos de ellos manejen el tráfico en todas las circunstancias, a no ser que ambos estén desactivados. Si los dos servidores están desactivados, desea que un segundo conjunto de dos servidores se encargue de manejar el tráfico. Si estos cuatro servidores están desactivados, se utilizarán los dos servidores restantes para manejar el tráfico. Podría establecer tres normas "siempre ciertas". De esta manera se seleccionará el primer par de servidores, siempre que al menos uno de ellos esté activado. Si ambos están desactivados, se seleccionará uno de los servidores del segundo par, y así sucesivamente.
Otro ejemplo: puede que desee una norma "siempre cierta" para garantizar que no se atienda a los clientes entrantes si no cumplen ninguna de las normas establecidas. Se podría crear una norma por medio del mandato ndcontrol rule de una manera semejante a esta:
ndcontrol rule add 130.40.52.153:80:jamais type true priority 100
A continuación, podría no añadir ningún servidor a la norma, lo que ocasionaría que los paquetes de los clientes se desechasen sin respuesta.
Puede definir más de una norma "siempre cierta" y designar posteriormente cuál de ellas se ejecutará por medio de la modificación de sus respectivos niveles de prioridad.
Este tipo de norma se puede utilizar en el componente Dispatcher y CBR.
Es aconsejable utilizar normas de tipo de contenido para enviar peticiones a conjuntos de servidores configurados específicamente para manejar una parte determinada del tráfico de su sitio Web. Por ejemplo, si desea utilizar un conjunto de servidores para manejar todas las peticiones cgi-bin, otro conjunto para manejar todas las peticiones de sonido continuo y un tercer conjunto para manejar todas las demás peticiones, añadiría una norma con un patrón que coincidiese con la vía del directorio cgi-bin, otra que coincidiese con el tipo de archivo de los archivos de sonido continuo y una tercera norma siempre cierta para manejar el resto del tráfico. Después, añadiría los servidores adecuados para cada una de las normas.
Importante: Para conocer ejemplos y casos prácticos de cómo utilizar la norma de contenido y la sintaxis válida de la expresión regular para dicha norma, consulte Apéndice C, Sintaxis de la norma de contenido (patrón):.
Puede añadir normas utilizando el mandato ndcontrol rule add, editando el archivo de configuración de ejemplo o mediante la interfaz gráfica de usuario (GUI). Se pueden añadir una o varias normas a cada uno de los puertos definidos.
Se trata de un proceso en dos etapas: se añade la norma y posteriormente se define a qué servidores atender si la norma es verdadera. Por ejemplo, nuestro administrador del sistema desea efectuar un seguimiento de la utilización de los servidores proxy por parte de cada división del sitio Web. El administrador conoce las direcciones IP asignadas a cada una de las divisiones. Se podría crear el primer conjunto de normas basado en la dirección IP del cliente para separar el tráfico de cada división:
ndcontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 ndcontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 ndcontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
A continuación, se podría añadir un servidor diferente a cada norma y medir el tráfico en cada uno de los servidores para facturar a cada división por los servicios que utilizan. Por ejemplo:
ndcontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 ndcontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 ndcontrol rule use server 130.40.52.153:80:div3 207.72.33.47
La opción de evaluación de servidor sólo puede utilizarse en el componente Dispatcher.
El mandato ndcontrol rule tiene una opción de evaluación de servidor para normas. Utilice la opción evaluate para evaluar la condición de una norma en todos los servidores del puerto o para evaluar la condición sólo en los servidores comprendidos en la norma. (En versiones anteriores de Network Dispatcher, sólo se podía evaluar la condición de cada norma en todos los servidores del puerto).
Los ejemplos siguientes muestran cómo añadir o definir una opción de evaluación en una norma de ancho de banda reservado:
ndcontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate nivel ndcontrol rule set 9.22.21.3:80:rbweval evaluate nivel
El nivel de evaluación puede ser "port" (puerto) o "rule" (norma). El valor por omisión es "port".
La opción para evaluar la condición de una norma en los servidores comprendidos en la norma le permite configurar dos normas con estas características:
El resultado es que cuando el tráfico excede el valor umbral de los servidores comprendidos en la primera norma, el tráfico se envía al servidor de "sitio ocupado" comprendido en la segunda norma. Cuando el tráfico disminuye por debajo del valor umbral de los servidores comprendidos en la primera norma, el tráfico subsiguiente se envía de nuevo a los servidores de la primera norma.
Mediante las dos normas descritas en el ejemplo anterior, si establece la opción de evaluación en port para la primera norma (evaluar la condición de la norma en todos los servidores del puerto), cuando el tráfico excede el valor umbral de esa norma, el tráfico se envía al servidor de "sitio ocupado" comprendido en la segunda norma.
La primera norma mide el tráfico de todos los servidores del puerto (incluido el servidor de "sitio ocupado") para determinar si el tráfico excede el valor umbral. Cuando el tráfico disminuye para los servidores de la primera norma, se puede producir un resultado imprevisto cuando el tráfico sigue enviándose hacia el servidor de "sitio ocupado" debido a que el tráfico del puerto todavía excede el umbral de la primera norma.
En general, las funciones de reparto del tráfico del Dispatcher funcionan independientemente del contenido de los sitios Web en los que se utiliza el producto. Existe una cuestión, sin embargo, en la que el contenido de los sitios Web puede tener importancia y en la que, además, las decisiones tomadas con respecto a dicho contenido pueden afectar de forma significativa al grado de eficacia del Dispatcher. Se trata de la cuestión de las direcciones de los enlaces.
Si las páginas especifican enlaces que apuntan a servidores individuales del sitio Web, de hecho se obliga al cliente a ir a una máquina específica, con lo que se elude la función de reparto de tráfico que en otro caso podría estar en vigor. Por este motivo, se recomienda utilizar siempre la dirección de Dispatcher en los enlaces que las páginas contengan. Tenga presente que el tipo de direcciones utilizado no siempre resultará evidente si el sitio Web utiliza una programación automatizada que crea HTML dinámicamente. Con el fin de repartir al máximo el tráfico, debe tener en cuenta el encaminamiento explícito que pueda existir y evitarlo en la medida de lo posible.
Puede configurar Dispatcher y las máquinas servidor TCP con una red privada. Esta configuración puede reducir el grado de contención en la red pública o externa que puede afectar al rendimiento.
Para AIX, esta configuración también puede beneficiarse de la alta velocidad de SP High Performance Switch si está ejecutando las máquinas Dispatcher y servidor TCP en nodos de un bastidor SP.
Para crear una red privada, cada máquina debe tener al menos dos tarjetas de LAN y una de ellas debe estar conectada a la red privada. Además, la segunda tarjeta de LAN debe configurarse en una subred diferente. La máquina Dispatcher enviará entonces las peticiones de los clientes a las máquinas servidor TCP a través de la red privada.
Windows 2000: Ejecute el mandato siguiente:
ndconfig en1 10.0.0.x netmask 255.255.255.0
Donde en1 es el nombre de la segunda tarjeta de interfaz en la máquina Dispatcher, 10.0.0.x es la dirección de red de la segunda tarjeta de interfaz y 255.255.255.0 es la máscara de la red privada.
Los servidores que se añadan con el mandato ndcontrol server add deben añadirse con las direcciones de red privada; por ejemplo, siguiendo el ejemplo del servidor Apple de la Figura 27, el mandato sería:
ndcontrol server add dirección_cluster:80:10.0.0.1
y no
ndcontrol server add dirección_de_cluster :80:9.67.131.18
Si está utilizando Site Selector para proporcionar información sobre el tráfico al Dispatcher, debe configurar Site Selector para que notifique los tráficos de las direcciones privadas.
Figura 27. Ejemplo de una red privada mediante Dispatcher
La utilización de una configuración de red privada sólo se aplica al componente Dispatcher.
"Comodín" hace referencia a la capacidad del cluster de encontrar coincidencias con varias direcciones IP (es decir, actúa como comodín). La dirección de cluster 0.0.0.0 se utiliza para especificar un cluster comodín.
Si tiene numerosas direcciones de cluster para el reparto del tráfico y las configuraciones puerto/servidor son idénticas para todos los clusters, puede combinar todos los clusters en una configuración en estrella.
Debe seguir configurando explícitamente cada dirección de cluster en uno de los adaptadores de red de la estación de trabajo de Dispatcher. Sin embargo, no debe añadir ninguna de las direcciones de cluster a la configuración del Dispatcher mediante el mandato ndcontrol cluster add.
Añada solamente el cluster comodín (dirección 0.0.0.0) y configure los puertos y servidores según sea necesario para el reparto del tráfico. Se repartirá todo el tráfico dirigido a cualquiera de las direcciones configuradas en los adaptadores utilizando la configuración del cluster comodín.
Una ventaja de este método es que se tiene en cuenta el tráfico dirigido a todas las direcciones del cluster cuando se determina el mejor servidor al que se puede acudir. Si un cluster está recibiendo mucho tráfico y ha creado muchas conexiones activas en uno de los servidores, se repartirá el tráfico hacia otras direcciones del cluster utilizando esta información.
Puede combinar el cluster comodín con los clusters reales si tiene algunas direcciones de cluster con configuraciones puerto/servidor exclusivas, y algunas con configuraciones comunes. Se debe asignar a cada una de las configuraciones exclusivas una dirección de cluster real. Se puede asignar un cluster comodín a todas las configuraciones comunes.
La utilización de un cluster comodín para combinar configuraciones sólo se aplica al componente Dispatcher.
La utilización del cluster comodín para repartir el tráfico de los cortafuegos sólo es aplicable al componente Dispatcher. La dirección de cluster 0.0.0.0 se utiliza para especificar un cluster comodín.
El cluster comodín se puede utilizar para repartir el tráfico hacia direcciones que no están configuradas explícitamente en ningún adaptador de red de la estación de trabajo Dispatcher. Para que esto funcione, el Dispatcher debe, como mínimo, ser capaz de ver todo el tráfico que se va a repartir. La estación de trabajo Dispatcher no verá el tráfico hacia las direcciones que no se han configurado de forma explícita en uno de sus adaptadores de red, a menos que esté configurado como la ruta por omisión para parte del tráfico.
Una vez que se ha configurado Dispatcher como ruta por omisión, se repartirá todo el tráfico UDP o TCP a través de la máquina Dispatcher utilizando la configuración del cluster comodín.
Una aplicación de esto es repartir el tráfico de los cortafuegos. Puesto que los cortafuegos pueden procesar paquetes para cualquier dirección de destino y cualquier puerto de destino, es necesario poder repartir el tráfico, independientemente de la dirección y el puerto de destino.
Los cortafuegos se utilizan para gestionar el tráfico desde clientes no seguros a servidores seguros, y las respuestas de los servidores seguros, así como el tráfico de clientes del lado seguro a los servidores del lado no seguro, y las respuestas.
Debe configurar dos máquinas Dispatcher, una para repartir el tráfico no seguro hacia las direcciones de cortafuegos no seguras y otra para repartir el tráfico seguro hacia las direcciones de cortafuegos seguras. Puesto que ambas máquinas Dispatcher deben utilizar el cluster y puerto comodín con diferentes conjuntos de direcciones de servidores, los dos Dispatchers deben encontrarse en dos estaciones de trabajo distintas.
La utilización del cluster comodín con Caching Proxy para proxy transparente sólo es aplicable al componente Dispatcher. La dirección de cluster 0.0.0.0 se utiliza para especificar un cluster comodín.
La función del cluster comodín también permite utilizar Dispatcher para habilitar una función proxy transparente para un servidor Caching Proxy que reside en la misma máquina que Dispatcher. Esta es una característica de AIX únicamente, ya que debe haber comunicación entre el componente Dispatcher y el componente TCP del sistema operativo.
Para habilitar esta función, debe iniciar la recepción de peticiones de clientes por Caching Proxy en el puerto 80. A continuación debe configurar un cluster comodín. En el cluster comodín, debe configurar el puerto 80. En el puerto 80, debe configurar la dirección de no reenvío (NFA) de la máquina Dispatcher como el único servidor. Ahora todo el tráfico de cliente destinado a cualquier dirección del puerto 80 se entregará al servidor Caching Proxy que se ejecuta en la estación de trabajo de Dispatcher. La petición del cliente se encaminará de la forma habitual y la respuesta se devolverá desde Caching Proxy al cliente. En esta modalidad, el componente Dispatcher no realiza el reparto del tráfico.
El puerto comodín se puede utilizar para manejar el tráfico que no está destinado a ningún puerto configurado explícitamente. Se puede aplicar al reparto del tráfico del cortafuegos. También se puede utilizar para garantizar que el tráfico hacia un puerto no configurado se maneja correctamente. Al definir un puerto comodín sin servidores, garantizará que cualquier petición para un puerto que no se ha configurado se descarte en lugar de volver a entregarse al sistema operativo. Para especificar un puerto comodín, se utiliza el puerto número 0 (cero), por ejemplo:
ndcontrol port add cluster:0
La función de afinidad se habilita al configurar como persistente un puerto de un cluster. El configurar el puerto de un cluster como persistente permite que las peticiones subsiguientes del cliente se envíen al mismo servidor. Esto se realiza estableciendo el "tiempo de persistencia del puerto" en una cierta cantidad de segundos. Esta función se inhabilita estableciendo el tiempo de persistencia en cero.
Interacción con la afinidad entre puertos: Si habilita la afinidad entre puertos, los valores de tiempo de persistencia de los puertos compartidos deben tener el mismo valor (distinto de cero). Consulte Afinidad entre puertos para obtener más información.
Cuando la función de afinidad está inhabilitada, cada vez que se recibe una nueva conexión TCP procedente de un cliente, Dispatcher selecciona el servidor apropiado en ese momento y reenvía paquetes hacia él. Si llega una conexión posterior del mismo cliente, Dispatcher la trata como una conexión nueva independiente y selecciona de nuevo el servidor apropiado en ese momento.
Cuando la función de afinidad está habilitada, si se recibe una petición posterior del mismo cliente, la petición se envía al mismo servidor.
Con el paso del tiempo, el cliente dejará de enviar transacciones y el registro de afinidad desaparecerá. De aquí surge el concepto de "persistencia". Cada registro de afinidad tiene una duración que es igual al "tiempo de persistencia" expresado en segundos. Cuando se reciben varias conexiones posteriores dentro del tiempo de persistencia, el registro de afinidad continúa siendo válido y, por lo tanto, la petición se dirigirá al mismo servidor. Si no se recibe una conexión posterior dentro del intervalo de tiempo de persistencia, el registro se elimina y se seleccionará un nuevo servidor para las conexiones recibidas tras ese tiempo.
La API de afinidad dirigida por el servidor sólo se aplica al componente Dispatcher.
La función SDA proporciona una API que permite a un agente externo influir en el comportamiento de afinidad de Dispatcher.
Funciones de SDA
La aplicación puede haber indicado que sus sistemas servidor saben mejor que Dispatcher cómo dirigir las peticiones de clientes a determinados sistemas servidor. En lugar de "dirigir" un cliente al mismo servidor elegido por la selección de reparto del tráfico de Dispatcher, quizás desee "dirigir" el cliente al servidor de su elección. La función SDA proporciona esta API. Ahora puede escribir su propio software para implementar un agente SDA, que se comunica con un oyente en Dispatcher. A continuación, puede manipular las tablas de afinidad de Dispatcher para:
Los registros insertados en una tabla de afinidad por un agente SDA permanecen en la tabla indefinidamente. No tienen un tiempo de espera. Sólo se eliminan cuando el agente SDA los elimina o si un asesor Dispatcher detecta que el servidor no responde.
Componentes SDA de Dispatcher
Dispatcher implementa un nuevo oyente de socket para aceptar y manejar peticiones de un agente SDA. Cuando un agente SDA abre una conexión con Dispatcher, el oyente la aceptará y dejará la conexión abierta. Por esta conexión persistente pueden fluir varias peticiones y respuestas. El socket se cerrará cuando lo cierre el agente SDA o si Dispatcher detecta un error irrecuperable. En el interior de Dispatcher, el oyente toma cada petición del agente SDA, se comunica con la tabla de afinidad adecuada en el kernel ejecutor de Dispatcher y prepara una respuesta para dicho agente SDA.
Para obtener más información, consulte los archivos contenidos en el directorio de instalación de Network Dispatcher:
La afinidad entre puertos sólo es aplicable al componente Dispatcher.
La afinidad entre puertos es la función de persistencia que se ha ampliado para abarcar varios puertos. Por ejemplo, si primero se recibe una petición del cliente en un puerto y la petición siguiente se recibe en otro puerto, la afinidad entre puertos permite que la máquina de Dispatcher envíe la petición del cliente al mismo servidor. Para poder utilizar esta característica, los puertos deben:
Se puede asociar más de un puerto al mismo puerto (crossport). Cuando se reciban conexiones posteriores procedentes del mismo cliente en el mismo puerto o en un puerto compartido, se accederá al mismo servidor. El ejemplo siguiente muestra una configuración de varios puertos con afinidad entre puertos para el puerto 10:
ndcontrol port set cluster:20 crossport 10 ndcontrol port set cluster:30 crossport 10 ndcontrol port set cluster:40 crossport 10
Una vez establecida la afinidad entre puertos, podrá modificar el valor de tiempo de persistencia (stickytime) del puerto. Sin embargo, se le recomienda que modifique los valores de persistencia de todos los puertos compartidos con el mismo valor, de lo contrario pueden producirse resultados imprevisibles.
Para suprimir la afinidad entre puertos, vuelva a establecer el valor de crossport ensu propio número de puerto. Consulte el apartado ndcontrol port -- configurar puertos para obtener información detallada sobre la sintaxis del mandato para la opción crossport.
La máscara de dirección de afinidad sólo es aplicable al componente Dispatcher.
La máscara de dirección de afinidad es una mejora de la función de persistencia para agrupar clientes según la dirección de subred común. Si especifica stickymask en el mandato ndcontrol port puede enmascarar los bits comunes de orden superior de la dirección IP de 32 bits. Si está habilitada esta característica, la primera vez que una petición de cliente efectúa una conexión con el puerto, todas las peticiones siguientes procedentes de los clientes con la misma dirección de subred (que se representa mediante la parte de la dirección que se va a enmascarar) se dirigirán al mismo servidor.
Por ejemplo, si desea que todas las peticiones de cliente de entrada que tengan la misma dirección de red de clase A se dirijan al mismo servidor, deberá establecer el valor de stickymask en 8 (bits) para el puerto. Para agrupar las peticiones de cliente que tengan la misma dirección de red de clase B, establezca el valor de stickymask en 16 (bits). Para agrupar las peticiones de cliente que tengan la misma dirección de red de clase C, establezca el valor de stickymask en 24 (bits).
Para obtener los mejores resultados, establezca el valor de stickymask cuando inicie por primera vez Network Dispatcher. Si cambia el valor de stickymask de forma dinámica, los resultados pueden ser imprevisibles.
Interacción con la afinidad entre puertos: Si va a habilitar la afinidad entre puertos, los valores de stickymask de los puertos compartidos deben ser iguales. Consulte el apartado Afinidad entre puertos para obtener más información.
Para habilitar la máscara de dirección de afinidad, emita un mandato ndcontrol port similar al siguiente:
ndcontrol port set cluster:puerto stickymask 8
Los valores posibles de stickymask son 8, 16, 24 y 32. El valor 8 especifica que se enmascararán los primeros 8 bits de orden superior de la dirección IP (la dirección de red de clase A). El valor 16 especifica que se enmascararán los primeros 16 bits de orden superior de la dirección IP (la dirección de red de clase B). El valor 24 especifica que se enmascararán los primeros 24 bits de orden superior de la dirección IP (la dirección de red de clase C). Si especifica 32, se enmascarará toda la dirección IP, con lo cual inhabilitará la función que permite enmascarar la dirección de afinidad. El valor por omisión de stickymask es 32.
Consulte el apartado ndcontrol port -- configurar puertos para obtener información detallada sobre la sintaxis del mandato para stickymask (característica para enmascarar la dirección de afinidad).
Con esta alteración temporal de afinidad de norma, puede alterar temporalmente la persistencia de un puerto para un servidor específico. Por ejemplo, puede utilizar una norma para limitar el número de conexiones a cada servidor de aplicaciones y tener un servidor de desbordamiento con una norma siempre cierta que indica "vuélvalo a intentar más tarde" para dicha aplicación. El puerto tiene un valor de tiempo de persistencia de 25 minutos, por lo tanto no desea que el cliente utilice siempre este servidor. Con la alteración temporal de afinidad de norma, puede cambiar el servidor de desbordamiento de modo que se altere temporalmente la afinidad que normalmente está asociada a dicho puerto. La próxima vez que el cliente hace peticiones al cluster, el tráfico se dirige hacia el servidor de aplicaciones disponible más adecuado, no hacia el servidor de desbordamiento.
Consulte el apartado ndcontrol server -- configurar servidores para obtener información detallada sobre la sintaxis del mandato para la alteración temporal de afinidad de norma, utilizando la opción sticky del servidor.
La desactivación de conexiones persistentes es aplicable a los componentes Dispatcher y CBR.
Para eliminar un servidor en la configuración de Network Dispatcher por la razón que sea (actualizaciones, ampliaciones, tareas de mantenimiento, etc.), puede utilizar el mandato ndcontrol manager quiesce. El submandato quiesce permite que las conexiones existentes finalicen (sin ser interrumpidas) y sólo reenvía las nuevas conexiones subsiguientes desde el cliente al servidor desactivado si la conexión está definida como persistente y no ha transcurrido el tiempo de persistencia. El submandato quiesce rechaza cualquier otra nueva conexión con el servidor.
Utilice el mandato quiesce "now" (desactivar ahora) si tiene establecido un tiempo de persistencia y desea que las nuevas conexiones se envíen a otro servidor (en lugar del servidor desactivado) antes de que finalice el tiempo de persistencia. El ejemplo siguiente muestra cómo utilizar la opción "now" (ahora) para desactivar el servidor 9.40.25.67:
ndcontrol manager quiesce 9.40.25.67 now
La opción "now" determina la forma en que se manejan las conexiones persistentes, de esta manera:
Esta es la forma más ordenada, menos abrupta, para detener servidores. Por ejemplo, puede detener ordenadamente un servidor y luego esperar a que haya el menor volumen de tráfico en la red (probablemente a primera hora de la mañana) para eliminar completamente el servidor de la configuración.
Puede especificar los siguientes tipos de afinidad en el mandato ndcontrol rule:
El valor por omisión de la opción de afinidad es "none". La opción stickytime del mandato port debe ser cero (no habilitado) para poder definir para la opción affinity en el mandato rule el valor active cookie, passive cookie o URI. Cuando la afinidad está definida en la norma, no puede habilitar stickytime en el puerto.
La afinidad activa de cookie sólo se aplica al componente CBR. La afinidad pasiva de cookie y URI se aplican al componente CBR y al método de reenvío cbr del componente Dispatcher.
La función de afinidad activa de cookie sólo se aplica al componente CBR. Proporciona una forma de hacer que los clientes tengan "persistencia" en un servidor determinado. Esta función se habilita al establecer el tiempo de persistencia (stickytime) de una norma en un número positivo y al establecer la afinidad en "activecookie". Esto es posible cuando se añade la norma o mediante el mandato rule set. Consulte ndcontrol rule -- configurar normas para ver información detallada sobre la sintaxis del mandato.
Una vez habilitada una norma para la afinidad activa de cookie, se repartirá el tráfico de las peticiones nuevas de cliente utilizando los algoritmos estándares de CBR, mientras que las peticiones sucesivas del mismo cliente se enviarán al servidor elegido inicialmente. El servidor elegido se almacena como cookie en la respuesta al cliente. Mientras las futuras peticiones del cliente contengan el cookie y cada petición llegue dentro del intervalo de tiempo de persistencia, el cliente mantendrá la afinidad con el servidor inicial.
La afinidad activa de cookie sirve para asegurar que el tráfico de un cliente se continúa distribuyendo al mismo servidor durante un periodo de tiempo. Esto se efectúa enviando un cookie para que lo almacene el navegador del cliente. El cookie contiene el cluster:puerto que se utilizó para tomar la decisión, el servidor al que se distribuyó el tráfico y la indicación horaria de tiempo de espera en que la afinidad deja de ser válida. Siempre que una norma aplica la activación de la afinidad de cookie, se examina el cookie enviado por el cliente. Si se encuentra un cookie en que se incluye el identificador de cluster:puerto que se ha aplicado, se extraen del cookie el servidor del reparto del tráfico y la indicación de la hora de caducidad. Si el servidor todavía está en el conjunto utilizado por la norma y su peso es mayor que cero y la indicación de la hora de caducidad es mayor que ahora, se elige el servidor del cookie para realizar el reparto del tráfico. Si alguna de las tres condiciones anteriores no se cumple, se elige un servidor utilizando el algoritmo normal. Después de la elección de un servidor (mediante cualquiera de los dos métodos), se crea un nuevo cookie que contiene IBMCBR, información cluster:puerto:servidor_elegido y una indicación horaria. La indicación horaria será la hora en que caduca la afinidad. La información "cluster:puerto:servidor_elegido" está codificada para que no se revele información sobre la configuración de CBR. También está insertado en el cookie un parámetro de "caducidad". Este parámetro tiene un formato inteligible para el navegador y hace que el cookie se vuelva no válido dos horas después de la indicación de la hora de caducidad. Ésta es la razón de que no haya una acumulación excesiva en la base de datos de cookies del cliente.
Este nuevo cookie se inserta en las cabeceras que se devuelven al cliente y, si el navegador del cliente está configurado para aceptar cookies, volverá a enviar peticiones subsiguientes.
La opción de afinidad activa de cookie, para el mandato rule, sólo puede establecerse en activecookie si el tiempo de persistencia (stickytime) de puerto es cero (no habilitado). Cuando la afinidad activa de cookie está activa para una norma, no se puede habilitar el tiempo de persistencia en el puerto.
Para activar la afinidad activa de cookie para una determinada norma, utilice el siguiente mandato rule set:
rule set cluster:puerto:norma stickytime 60 rule set cluster:puerto:norma affinity activecookie
La creación de una norma con persistencia se suele utilizar para CGI o servlets que almacenan el estado del cliente en el servidor. El estado se identifica mediante un ID de cookie (éstos son los cookies de servidor). El estado del cliente sólo se encuentra en el servidor seleccionado, por lo cual el cliente necesita el cookie de ese servidor para mantener ese estado entre las peticiones.
La afinidad pasiva de cookie puede utilizarse con el encaminamiento basado en contenido (CBR) del componente Dispatcher y con el componente CBR. Consulte la sección Encaminamiento por contenido mediante Dispatcher (método de reenvío cbr), donde obtendrá información sobre cómo configurar el método de reenvío cbr de Dispatcher.
La afinidad pasiva de cookie proporciona una forma de hacer que los clientes tengan afinidad por un servidor determinado. La afinidad pasiva de cookie le permite repartir el tráfico Web con afinidad por un mismo servidor basándose en los cookies autodefinidos generados por los servidores. La afinidad pasiva de cookie se configura a nivel de norma. Cuando se aplica una norma, si la afinidad pasiva de cookie está habilitada, Network Dispatcher selecciona el servidor basándose en el nombre de cookie contenido en la cabecera HTTP de la petición del cliente. Network Dispatcher enviará las nuevas peticiones entrantes hacia los servidores basándose en los cookies generados por los servidores durante conexiones anteriores. Si el valor de cookie contenido en la petición del cliente no se encuentra o no coincide con ninguno de los valores de cookie de los servidores, el servidor se selecciona utilizando la técnica ponderada rotatoria.
Para configurar la afinidad pasiva de cookie:
La opción de afinidad pasiva de cookie, para el mandato rule, sólo puede establecerse en passivecookie si el tiempo de persistencia de puerto es cero (no habilitado). Cuando la afinidad pasiva de cookie está activa para una norma, no se puede habilitar el tiempo de persistencia en el puerto.
La afinidad de URI se puede utilizar con el método de reenvío CBR de Dispatcher y con el componente CBR. Consulte Encaminamiento por contenido mediante Dispatcher (método de reenvío cbr) para obtener información sobre cómo configurar el método de reenvío CBR.
La afinidad de URI le permite repartir el tráfico Web hacia servidores Caching Proxy, lo que permite poner en antememoria contenido exclusivo en cada servidor individual. Como consecuencia, aumenta de forma efectiva el tamaño de la antememoria del sitio Web al eliminar el almacenamiento redundante de contenido en varias máquinas. La afinidad de URI se configura a nivel de norma. Cuando se aplica una norma, si la afinidad de URI está habilitada y el mismo grupo de servidores está activo y respondiendo, Network Dispatcher reenvía hacia el mismo servidor las nuevas peticiones de los clientes que tengan el mismo URI.
Habitualmente, Network Dispatcher puede distribuir peticiones hacia varios servidores que abastecen el mismo contenido. Si utiliza Network Dispatcher con un grupo de servidores de antememoria, el contenido de acceso frecuente finalmente pasa a estar en la antememoria de todos los servidores. Esto permite un tráfico muy alto de peticiones de los clientes al duplicar un mismo contenido de antememoria en varias máquinas. Esto es especialmente útil para sitios Web de gran volumen.
Sin embargo, si el sitio Web tiene un tráfico moderado o alto de peticiones de clientes y prefiere tener una antememoria mayor repartida entre varios servidores, el rendimiento del sitio Web será mejor si el contenido de cada servidor es exclusivo y Network Dispatcher sólo distribuye la petición hacia el servidor con ese contenido.
Con la afinidad de URI, Network Dispatcher le permite distribuir el contenido de la antememoria hacia servidores individuales, eliminando el almacenamiento redundante de contenido en varias máquinas. Con esta mejora, los sitios Web con servidores de contenido diverso que utilicen servidores Caching Proxy tendrán un mayor rendimiento. Las peticiones iguales se enviarán hacia el mismo servidor, por lo que sólo se almacenará contenido en servidores individuales. Además, el tamaño efectivo de la antememoria será mayor con cada nueva máquina añadida a la agrupación.
Para configurar la afinidad de URI:
La opción de afinidad de URI, para el mandato rule, sólo puede establecerse en "URI" si el tiempo de persistencia de puerto es cero (no habilitado). Cuando la afinidad de URI está activa para una norma, no se puede habilitar el tiempo de persistencia en el puerto.
Esta característica sólo está disponible para el componente Dispatcher.
Dispatcher permite detectar posibles ataques de "denegación de servicio" y avisar al administrador mediante una alerta. Para ello, Dispatcher comprueba si las peticiones entrantes contienen un volumen importante de conexiones TCP semiabiertas en los servidores, lo cual es una característica habitual de los ataques simples de denegación de servicio. En un ataque de denegación de servicio, un sitio Web recibe una gran cantidad de paquetes SYN ficticios procedentes de numerosas direcciones IP y números de puerto, pero el sitio Web no recibe subsiguientes paquetes para esas conexiones TCP. Esto produce un gran número de conexiones TCP semiabiertas en los servidores, los cuales pueden llegar finalmente a ser muy lentos y no aceptar nuevas peticiones entrantes.
Network Dispatcher proporciona salidas de usuario que provocan la ejecución de scripts personalizables que avisan al administrador sobre un posible ataque de denegación de servicio. Dispatcher proporciona los siguientes archivos de script de ejemplo en el directorio ...nd/servers/samples:
Para poder ejecutar los archivos de script, debe trasladarlos al directorio ...nd/servers/bin y eliminar la extensión de archivo ".sample".
Para utilizar la detección de ataques de denegación de servicio, establezca el parámetro maxhalfopen del mandato ndcontrol port de esta manera:
ndcontrol port set 127.40.56.1:80 maxhalfopen 1000
En el ejemplo anterior, Dispatcher compara el número total actual de conexiones semiabiertas (para todos los servidores que residen en el cluster 127.40.56.1 del puerto 80) con el valor umbral 1000 (especificado por el parámetro maxhalfopen). Si el número actual de conexiones semiabiertas excede el valor umbral, se invoca un script de alerta (halfOpenAlert). Cuando el número de conexiones semiabiertas desciende por debajo del valor umbral, se invoca otro script de alerta (halfOpenAlertDone) para indicar que el ataque ha finalizado.
Para determinar cómo definir el valor maxhalfopen:Periódicamente (por ejemplo, cada 10 minutos) ejecute un mandato de informe de conexiones semiabiertas (ndcontrol port halfopenaddressreport cluster:puerto) cuando su sitio Web tenga un volumen de tráfico moderado o alto. El informe de conexiones semiabiertas mostrará el número total actual de conexiones semiabiertas recibidas. Debe establecer maxhalfopen en un valor que sea entre un 50% y un 200% mayor que el número más alto de conexiones semiabiertas que se producen en el sitio Web.
Además de los datos estadísticos presentados, halfopenaddressreport también crea entradas en el archivo de anotaciones (..nd/servers/logs/dispatcher/halfOpen.log) para todas las direcciones de clientes (hasta aproximadamente 8000 pares de direcciones) que han accedido a servidores y han originado conexiones semiabiertas.
Si desea proporcionar una protección adicional contra los ataques de denegación de servicio para los servidores de fondo, puede configurar clusters y puertos comodín. Específicamente, añada un puerto comodín sin servidores bajo cada cluster configurado. Añada, además, un cluster comodín con un puerto comodín y sin servidores. Esto tendrá el efecto de eliminar todos los paquetes que no vayan dirigidos a un cluster y unpuerto no comodín. Para obtener información sobre los clusters y puertos comodín, consulte la sección Utilizar el cluster comodín para combinar configuraciones de servidores y la sección Utilización del puerto comodín para dirigir el tráfico de puertos no configurados.
La función de anotaciones en binario permite que la información del servidor se almacene en archivos binarios. Estos archivos pueden procesarse para analizar la información del servidor recopilada a lo largo del tiempo.
Las anotaciones en binario de cada servidor definido en la configuración almacenan la información siguiente:
Parte de esta información se obtiene del ejecutor como parte del ciclo del gestor. Por lo tanto el gestor debe estar en ejecución para poder anotar información en las anotaciones en binario.
Utilice el conjunto de mandatos ndcontrol log para configurar las anotaciones en binario.
La opción start inicia el registro de información sobre servidores en archivos de anotaciones en binario, en el directorio logs. Cada hora se crea un archivo de anotaciones con la fecha y la hora como nombre del archivo.
La opción stop detiene la anotación de información del servidor en las anotaciones en binario. Por omisión, el servicio de anotaciones está detenido.
La opción set interval controla la frecuencia con la que la información se graba en las anotaciones. El gestor enviará información al servidor de anotaciones en cada intervalo de gestor. La información se grabará en las anotaciones solamente si han transcurrido los segundos especificados como intervalo de anotaciones desde que se grabó el último registro en las anotaciones. Por omisión, el intervalo de anotaciones está definido en 60 segundos. Existe una cierta interacción entre los valores del intervalo del gestor y el intervalo de anotaciones. Debido a que el servidor de anotaciones no recibirá la información en menos tiempo que los segundos del intervalo del gestor, al establecer un intervalo de anotaciones inferior al intervalo del gestor en realidad se establece en el mismo valor que el intervalo del gestor. Este método de anotaciones permite captar información del servidor con cualquier nivel de detalle (granularidad). Puede capturar todos los cambios realizados en la información del servidor detectados por el gestor para calcular los pesos de los servidores. Sin embargo, no es necesaria tanta cantidad de información para analizar la utilización del servidor y la tendencia. La anotación de información del servidor cada 60 segundos le proporciona vistas instantáneas de la información del servidor a lo largo del tiempo. Si se establece el intervalo de anotaciones en un valor demasiado bajo, se pueden generar grandes cantidades de datos.
La opción set retention controla durante cuánto tiempo se conservan los archivos. El servidor de archivos de anotaciones suprimirá los archivos de anotaciones que superen las horas de retención especificadas. Esto sólo se producirá si el gestor llama al servidor de anotaciones, de modo que detener el gestor hará que los archivos de anotaciones antiguos no se supriman.
La opción status devuelve los valores actuales del servicio de anotaciones. Estos valores son si el servicio se ha iniciado, cuál es el intervalo y cuáles son las horas de retención.
En el directorio ...nd/servers/samples/BinaryLog se proporcionan ejemplos de un programa Java y de un archivo de mandatos. Estos ejemplos muestran cómo recuperar toda la información de los archivos de anotaciones y visualizarla en la pantalla. Puede personalizar esos ejemplos para realizar cualquier tipo de análisis que desee con los datos. El siguiente es un ejemplo sobre cómo utilizar el programa y el script proporcionados para Dispatcher:
ndlogreport 2001/05/01 8:00 2001/05/01 17:00
a fin de obtener un informe sobre el servidor del componente Dispatcher de8:00 a 17:00 el 1 de mayo de 2001. (Para CBR, utilice cbrlogreport. Para Mailbox Locator, utilice mllogreport. Para Cisco Consultant, utilice lbclogreport.)
En Cisco Consultant, Cisco CSS Switch efectúa las tareas realizadas por el ejecutor en el componente Dispatcher. Además del valor actual de ponderación (peso) de cada servidor e información de otro tipo necesaria para realizar sus cálculos, el gestor obtiene el número de conexiones activas y de conexiones nuevas a partir del Cisco CSS Switch. Estos valores están basados en la información que se genera y almacena internamente en el Cisco CSS Switch.
Cisco Consultant consulta la MIB (base de información de gestión) de Cisco CSS Switch para obtener el número de conexiones activas y nuevas y recibe lo siguiente:
apSvcConnections OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Número total de conexiones TCP con este servicio" DEFVAL { 0 } --DEFAULT ap-display-name Service Connections ::= {apSvcEntry 20}
El identificador de objeto para apSvcConnections es:
1.3.6.1.4.1.2467.1.15.2.1.20
El número de conexiones activas depende del número de clientes y del período de tiempo necesario para utilizar los servicios proporcionados por los servidores sujetos a reparto del tráfico. Si las conexiones de los clientes son rápidas (por ejemplo, las realizadas para páginas Web pequeñas utilizando GET de HTTP), el número de conexiones activas será bastante bajo. Si las conexiones de los clientes son más lentas (por ejemplo, una consulta de base de datos), el número de conexiones activas será más alto.
El índice de esta variable es:
INDEX { apCntsvcOwnName, apCntsvcCntName, apCntsvcSvcName }Lo siguiente es la entrada correspondiente en la MIB:
apCntsvcHits OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Número total de peticiones del servicio para esta norma de contenido". DEFVAL { 0 } --DEFAULT ap-display-name Hits --DEFAULT apjam-popup-ref apCntSvcInst, Statistics --DEFAULT apjam-chart-def cntSvcHitsChart, pie, apCntInst, "Número de accesos a cada servicio: --DEFAULT apjam-chart-item cntSvcHitsChart, getnext, apCntsvcSvcName ::= {apSvcEntry 20}
El identificador de objeto para apCntsvcHits es:
1.3.6.1.4.1.2467.1.18.2.1.4
El Cisco CSS Switch se debe configurar para que utilice el método rotatorio ponderado de reparto del tráfico. Consulte "Configuring Weight" en el manual Content Services Switch Basic Configuration Guide para conocer cómo hacer esto.
Los pesos (valores de ponderación) son establecidos por el gestor de acuerdo con contadores internos de Cisco CSS Switch e información recibida de los asesores y Metric Server. Si desea definir los pesos manualmente mientras ejecuta el gestor, especifique la opción fixedweight en el mandato lbccontrol server.
Si todos los servidores están fuera de servicio, todos los pesos son igual a 0. En este caso, cuando no hay ningún servidor procesando peticiones debido a que todos los pesos son 0, los pesos se establecen en un valor igual a la mitad del valor "weightbound" para permitir la misma posibilidad de procesar una petición por parte de cualquier servidor apropiado. El programa monitor muestra el verdadero valor del peso (0), pero Cisco Consultant visualiza un peso igual a la mitad de "weightbound" en todos los demás lugares.
Los pesos se envían al Cisco CSS Switch utilizando SNMP. Cisco Consultant establece apSvcWeight en svcExt.mib. Lo siguiente es la entrada correspondiente a apSvcWeight.
apSvcWeight OBJECT-TYPE SYNTAX Integer 32(1..10) MAX-ACCESS read-create STATUS current DESCRIPTION "Peso del servicio que se utiliza junto con métricas del tráfico para tomar decisiones respecto a su reparto. El peso se puede utilizar para desviar el tráfico hacia el servicio especificado". DEFVAL { 1 } --DEFAULT ap-display-name Service Weight --DEFAULT apjam-popup-ref apServicesGroupInst, Properties, Advanced --DEFAULT apjam-wizard-field 2, normal ::= {apSvcEntry 16}
El identificador de objeto para apSvcWeight es:
1.3.6.1.4.1.2467.1.15.2.1.12
Los pesos se aplican a todos los servidores de un puerto. Para un puerto determinado cualquiera, las peticiones se reparten entre los servidores según el peso relativo de los servidores. Por ejemplo, si un servidor tiene establecido 10 como peso y otro tiene 5, el servidor con 10 debe obtener el doble de peticiones que el servidor con 5.
Para especificar el peso máximo que puede tener cualquier servidor, emita el mandato lbccontrol port set weightbound. Este mandato especifica las diferencias en el número de peticiones que recibe cada servidor. Si establece el peso máximo en 1, todos los servidores pueden tener 1 como peso, 0 si están desactivados o -1 si están marcados como inactivos. Cuanto más alto sea este número, mayor será la diferencia de pesos entre los servidores. Con un peso máximo de 2, un servidor puede recibir el doble de peticiones que otro.
Si un asesor detecta que un servidor está fuera de línea, informa al gestor y éste asigna el peso 0 al servidor. Cuando el peso de un servidor es mayor que 0, el peso se envía al Cisco CSS Switch, y el servidor pasa a estar activo; pero si el peso del servidor es menor o igual que 0, se detiene el servidor. Para activar o detener un servicio se define la variable apSvcEnable de la MIB, en svcExt.mib de Cisco CSS Switch. Lo siguiente es la entrada correspondiente a apSvcEnable en la MIB:
apSvcEnable OBJECT-TYPE SYNTAX Integer disable(0) enable(1) MAX-ACCESS read-create STATUS current DESCRIPTION "Estado del servicio: habilitado o inhabilitado." DEFVAL { disable } --DEFAULT ap-display-name Status --DEFAULT apjam-popup-ref apServicesGroupInst, Properties --DEFAULT apjam-wizard-field 2, normal ::= {apSvcEntry 12}
El identificador de objeto para apSvcEnable es:
1.3.6.1.4.1.2467.1.15.2.1.16
Este capítulo describe cómo utilizar y gestionar Network Dispatcher; incluye las secciones siguientes:
Network Dispatcher proporciona una opción para ejecutar sus programas de configuración en una máquina distinta de la que está ejecutando los servidores de Network Dispatcher.
La comunicación entre los programas de configuración (ndcontrol, cbrcontrol, mlcontrol, sscontrol, lbccontrol, ndwizard, cbrwizard, mlwizard, sswizard, ndadmin) se realiza mediante llamadas RMI (Java Remote Method Invocation) . El mandato para conectar a una máquina Network Dispatcher para la administración remota es ndcontrol host:sist_pral_remoto. Si la llamada RMI procede de una máquina distinta de la máquina local, debe producirse una secuencia de autenticación de clave pública/privada antes de que se acepte el mandato de configuración.
La comunicación entre los programas de control que se ejecutan en la misma máquina que los servidores de componentes no está autenticada.
Utilice el mandato siguiente para generar claves públicas y privadas a fin de utilizarlas en la autenticación remota:
Este mandato sólo se ejecuta en la misma máquina que Network Dispatcher.
Mediante la opción create se crea una clave pública en el directorio de claves de servidor (...nd/servers/key/) y se crean claves privadas en el directorio de claves de administración (...nd/admin/keys/) para cada componente de Network Dispatcher. El nombre de archivo para la clave privada es: componente-dirección_servidor-puerto_RMI. Luego, estas claves privadas se deben trasladar a los clientes remotos y situar en el directorio de claves de administración.
Para una máquina de Network Dispatcher cuya dirección de sistema principal es 10.0.0.25 y que utiliza el puerto RMI por omisión para cada componente, el mandato ndkeys create crea estos archivos:
El catálogo de archivos de administración se ha instalado en otra máquina. Los archivos de clave privada deben estar situados en el directorio .../nd/admin/keys de la máquina cliente remoto.
El cliente remoto ahora estará autorizado para configurar Network Dispatcher en 10.0.0.25.
Estas mismas claves se deben utilizar en todos los clientes remotos a los que desee dar autorización para configurar Network Dispatcher en 10.0.0.25.
Si ejecutase de nuevo el mandato ndkeys create, se generaría un nuevo conjunto de claves públicas/privadas. Esto significaría que todos los clientes remotos que han intentado conectarse utilizando las claves anteriores no estarían autorizados. La nueva clave debería colocarse en el directorio correcto en aquellos clientes que desea volver a autorizar.
El mandato ndkeys delete suprime las claves privadas y públicas de la máquina servidor. Si estas claves se suprimen, no se autorizará a ningún cliente remoto para conectarse a los servidores.
Tanto para ndkeys create como para ndkeys delete hay una opción force. La opción force suprime los indicadores de mandatos que le preguntan si desea sobrescribir o suprimir las claves existentes.
Network Dispatcher envía entradas a un archivo de anotaciones de servidor, un archivo de anotaciones de gestor, un archivo de anotaciones de supervisor de métrica (anotación de las comunicaciones con los agentes de Metric Server) y un archivo de anotaciones para cada asesor que se utilice.
Se puede establecer el nivel de registro para definir el volumen de los mensajes escritos en el archivo de anotaciones. Para el nivel 0, se anotan errores y Network Dispatcher también anota las cabeceras y los registros de eventos que se producen una sola vez (por ejemplo, un mensaje acerca del inicio de un asesor que se escribe en el archivo de anotaciones del gestor). El Nivel 1 incluye información de progreso y el Nivel 5 incluye todos los mensajes generados para ayudar en la depuración de un problema, si es necesario. El valor por omisión para el archivo de anotaciones del servidor es 0. El valor por omisión para los archivos de anotaciones del gestor, los asesores y del subagente es 1.
Se puede establecer también el tamaño máximo de un archivo de anotaciones. Si establece un tamaño máximo del archivo de anotaciones, éste se sobrescribirá; cuando el archivo alcance el tamaño especificado, las entradas siguientes se grabarán al principio del archivo encima de las ya existentes. No se puede establecer como tamaño de archivo de anotaciones un valor inferior al actual. En las entradas de anotaciones figura la indicación de la hora, de forma que puede establecerse el orden en que se han grabado.
Cuanto más alto sea el nivel de anotaciones, más cuidadosamente debe elegirse el tamaño del archivo de anotaciones. En el nivel 0, probablemente lo seguro sea dejar el tamaño del archivo de anotaciones en el valor por omisión de 1 MB; no obstante, si el nivel de anotaciones es 3 o superior, debe limitarse el tamaño sin hacerlo tan pequeño que resulte inútil.
Por omisión, los archivos de anotaciones creados por Network Dispatcher se guardan en el directorio de anotaciones de la instalación de Network Dispatcher. Para cambiar esta vía de acceso, defina la variable nd_logdir en el script ndserver.
AIX, Linux y Solaris: El script ndserver está situado en el directorio /usr/bin. En este script, la variable nd_logdir se establece en el directorio por omisión. Puede modificar esta variable de modo que especifique otro directorio para las anotaciones. Ejemplo:
ND_LOGDIR=/ruta/a/mis/archivos/
Windows 2000: El archivo ndserver está situado en el directorio del sistema Windows 2000, generalmente C:\WINNT\SYSTEM32. En el archivo ndserver, la variable nd_logdir tiene asignado el directorio por omisión. Puede modificar esta variable de modo que especifique otro directorio para las anotaciones. Ejemplo:
set ND_LOGDIR=c:\ruta\a\mis\archivos\
En todos los sistemas operativos, asegúrese de que no hay espacios en ninguno de los lados del signo igual y de que la vía finaliza con una barra inclinada ("/" o "\" según proceda).
La función de anotaciones en binario de Network Dispatcher utiliza el mismo directorio que los demás archivos de anotaciones. Consulte Utilizar las anotaciones en binario para analizar las estadísticas del servidor.
Esta sección describe cómo utilizar y gestionar el componente Dispatcher.
Para Network Dispatcher, se considera que una conexión está inactiva cuando no se ha producido actividad en ella durante el número de segundos especificado en el tiempo de espera de inactividad. Una vez transcurridos esos segundos sin que haya habido ninguna actividad, Network Dispatcher elimina el registro de esa conexión en sus tablas y se rechaza el tráfico subsiguiente dirigido a esa conexión.
A nivel de puerto, por ejemplo, puede especificar el valor de tiempo de espera de inactividad en el mandato ndcontrol port set staletimeout.
El tiempo de espera de inactividad se puede definir a nivel de ejecutor, cluster y puerto. A nivel de ejecutor y de cluster, el valor por omisión es 300 segundos y se propaga al puerto. A nivel de puerto, el valor por omisión depende del puerto. Algunos puertos bien definidos tienen valores diferentes para el tiempo de espera de inactividad. Por ejemplo, el puerto telnet 23 tiene un valor por omisión de 32.000.000 segundos.
Algunos servicios pueden también tener sus propios valores de tiempo de espera de inactividad. Por ejemplo, LDAP (Lightweight Directory Access Protocol) tiene un parámetro de configuración llamado idletimeout. Cuando transcurren los segundos especificados por idletimeout, se fuerza el cierre de una conexión de cliente inactiva. El parámetro idletimeout puede también tener el valor 0, lo que significa que nunca se hará un cierre forzado de la conexión.
Se pueden producir problemas de conectividad cuando el valor de tiempo de espera de inactividad de Network Dispatcher es menor que el tiempo de espera del servicio. En el caso de LDAP, el valor de tiempo de espera de inactividad de Network Dispatcher (staletimeout) se establece por omisión en 300 segundos. Si hay actividad en la conexión durante 300 segundos, Network Dispatcher eliminará el registro de la conexión en sus tablas. Si el valor idletimeout es mayor que 300 segundos (o se establece en 0), el cliente puede todavía creer que tiene una conexión con el servidor. Cuando el cliente envía paquetes, éstos son rechazados por Network Dispatcher. Esto hace que LDAP quede bloqueado cuando se efectúa una petición al servidor. Para evitar este problema, establezca el parámetro idletimeout de LDAP en un valor distinto de cero que sea igual o menor que el valor staletimeout de Network Dispatcher.
Un cliente envía un paquete FIN una vez que ha enviado todos los paquetes para que, así, el servidor sepa que la transacción ha finalizado. Cuando Dispatcher recibe el paquete FIN, quita a la transacción la marca de estado activo y le pone la marca de estado de finalización. Cuando se ha marcado una transacción con el estado de finalización, el recogedor de basura incluido en el ejecutor puede borrar la memoria reservada para la conexión.
Se puede utilizar el tiempo de espera para estado de finalización y el número de conexiones finalizadas para establecer la frecuencia con la que el ejecutor realizará la recogida de basura y hasta qué punto. El ejecutor comprueba periódicamente la lista de las conexiones que ha asignado. Si el número de conexiones en estado de finalización es mayor o igual que el número de conexiones finalizadas, el ejecutor intentará liberar la memoria utilizada para contener la información sobre las conexiones. Se puede cambiar el número de conexiones finalizadas con el mandato ndcontrol executor set fincount.
El recogedor de basura libera la memoria de aquellas conexiones que se encuentren en estado de finalización y superen el número de segundos especificado en el tiempo de espera para estado de finalización. Se puede cambiar el tiempo de espera para estado de finalización entrando el mandato ndcontrol executor set fintimeout.
El valor de tiempo de espera de inactividad (staletimeout) es el número de segundos durante los cuales puede haber ausencia de actividad en una conexión antes de que dicha conexión se elimine. Consulte Utilización del valor de tiempo de espera de inactividad para obtener más información. El número de conexiones finalizadas también afecta a la frecuencia con que se eliminan las conexiones "sin actividad". Si tiene poca memoria en la máquina Dispatcher, debe establecer un número de conexiones finalizadas bajo. Si tiene un sitio Web muy ocupado, debe establecer un número de conexiones finalizadas alto.
Se pueden mostrar diversos diagramas basándose en la información procedente del ejecutor y transmitida al gestor. La opción de menú Supervisor de GUI necesita que la función del gestor se esté ejecutando):
Un sistema de gestión de red es un programa que se ejecuta continuamente y que se utiliza para supervisar, controlar y reflejar el estado de una red. El estándar actual para la gestión de red es el Protocolo simple de gestión de red (SNMP), un popular protocolo para la comunicación con dispositivos en una red. Los dispositivos de red disponen generalmente de un agente SNMP y de uno o más subagentes. El agente SNMP se comunica con la estación de gestión de red o responde a peticiones SNMP efectuadas desde la línea de mandatos. El subagente SNMP recupera y actualiza la información y la entrega al agente SNMP para que la devuelva al peticionario.
Dispatcher proporciona una Base de información de gestión (ibmNetDispatcherMIB) SNMP y un subagente SNMP, de manera que para supervisar la salud, la actividad y el rendimiento de Dispatcher, se puede utilizar cualquier sistema de gestión de redes como, por ejemplo, Tivoli NetView, Tivoli Distributed Monitoring o HP OpenView. Los datos MIB describen el Dispatcher que se está gestionando y reflejan al estado actual de Dispatcher. La MIB se instala en el subdirectorio ..nd/admin/MIB.
El sistema de gestión de red utiliza los mandatos GET de SNMP para averiguar los valores MIB de otras máquinas. A continuación le notifica si se han excedido los valores umbral especificados. Posteriormente se puede retocar el rendimiento de Dispatcher modificando los datos de configuración de Dispatcher, para ajustar o solucionar problemas de Dispatcher antes de que se conviertan en cortes de Dispatcher o del servidor Web.
El sistema proporciona generalmente un agente SNMP para cada una de las estaciones de gestión de red. El usuario envía un mandato GET al agente SNMP. En respuesta, el agente SNMP envía un mandato GET para recuperar los valores MIB especificados de un subagente responsable de dichas variables MIB.
Dispatcher proporciona un subagente que actualiza y recupera los datos MIB. Cuando el agente SNMP envía un mandato GET, el subagente responde con los datos MIB apropiados. El agente SNMP comunica los datos a la estación de gestión de red. La estación de gestión de red le notificará a usted si se superan los valores umbral especificados.
El soporte para SNMP de Dispatcher incluye un subagente SNMP que utiliza las capacidades de la Interfaz de protocolo distribuido (DPI). DPI es una interfaz entre un agente SNMP y sus subagentes.
Figura 28. Mandatos SNMP para AIX y Solaris
AIX proporciona un agente SNMP que hace uso del protocolo SMUX (SNMP Multiplexer) y proporciona DPID2, que es un ejecutable adicional que actúa como conversor entre DPI y SMUX.
Para Solaris, debe obtener un agente SNMP que esté habilitado para SMUX, pues Solaris no proporciona uno. Network Dispatcher proporciona DPID2 para Solaris en el directorio /opt/nd/servers/samples/SNMP.
El agente DPI debe ejecutarse como usuario root. Antes de ejecutar el daemon DPID2, actualice los archivos /etc/snmpd.peers y /etc/snmpd.conf de la siguiente manera:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "contraseña_dpid"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 contraseña_dpid #dpid
Renueve snmpd para que vuelva a leer el archivo /etc/snmpd.conf:
refresh -s snmpd
Inicie el igual DPID SMUX:
dpid2
Los daemons deben arrancarse en el siguiente orden:
Figura 29. Mandatos de SNMP para Windows 2000
Para obtener un agente de SNMP habilitado para DPI en Windows 2000, instale la versión para Windows NT del kit de utilidades IBM SystemView Agent, contenido en http://www.tivoli.com/support/sva.
Antes de iniciar el proceso SNMPD de SystemView, debe inhabilitar el soporte SNMP de Microsoft Windows. El snmpd SystemView da soporte a subagentes DPI y agentes conformes a Microsoft.
Para inhabilitar el soporte de SNMP para Windows:
Para configurar el agente SystemView de SNMP, siga las instrucciones que aparecen en Provisión de un nombre de comunidad para SNMP.
Debe configurar el nombre de comunidad de SNMP. El nombre de comunidad SNMP por omisión es public. En los sistemas UNIX, el nombre de comunidad se define en un archivo llamado /etc/snmpd.conf.
En todos los sistemas, el nombre de comunidad se debe configurar y utilizar de forma coherente. Es decir, si el nombre de comunidad para Network Dispatcher se define como "NuestraComunidad" en la configuración del agente de SNMP, este nombre también debe ser "NuestraComunidad" en la congiguración del subagente.
Para Windows 2000, antes de crear un nombre de comunidad, configure el agente IBM SystemView de SNMP.
Este paso permite que cualquier sistema principal de cualquier red acceda a las variables SNMP de la MIB. Una vez que haya verificado que estos valores funcionan, puede modificarlos de acuerdo a sus necesidades.
Con el ejecutor en funcionamiento, utilice el mandato ndcontrol subagent start [nombrecomunidad] para definir el nombre de comunidad utilizado entre el subagente DPI y el agente SNMP de Dispatcher. El valor por omisión que corresponde al nombre de comunidad es public. Si cambia este valor, debe también añadir el nuevo nombre de comunidad al agente SystemView utilizando snmpcfg, como se describió anteriormente.
SNMP se comunica por medio del envío y recepción de detecciones, mensajes enviados por los dispositivos gestionados para informar de condiciones excepcionales o de la aparición de sucesos significativos, como que se alcance un umbral.
El subagente utiliza las detecciones siguientes:
La detección indHighAvailStatus anuncia que ha cambiado el valor de la variable de estado de alta disponibilidad (hasState). Los posibles valores de hasState son:
La detección indSrvrGoneDown anuncia que el peso del servidor especificado por la parte csAddr, psNum, ssAddr del Identificador de objeto ha pasado a cero. Se envía a la detección el último número conocido de conexiones activas. Esta detección indica que, por lo que puede determinar Dispatcher, el servidor especificado está desactivado.
La detección indDOSAttack indica que numhalfopen, el número de conexiones semiabiertas que sólo constan de paquetes SYN, ha sobrepasado el umbral de maxhhalfopen para el puerto especificado por la parte csAddr, psNum del Identificador de objeto. En la detección se envía el número de servidores configurados en el puerto. Esta detección indica que Network Dispatcher puede estar experimentando un ataque de denegación de servicio.
La detección indDOSAttackDone indica que numhalfopen, el número de conexiones semiabiertas que sólo constan de paquetes SYN, está por debajo del umbral de maxhalfopen para el puerto especificado por la parte csAddr, psNum del Identificador de objeto. En la detección se envía el número de servidores configurados en el puerto. Cuando Network Dispatcher determine que ha terminado el posible ataque de denegación de servicio, enviará esta detección después de enviar la detección indDOSAttack.
Debido a una limitación de la API SMUX, el identificador de empresa informado en las detecciones del subagente ibmNetDispatcher puede 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, las utilidades de gestión SNMP podrán determinar el origen de la detección, ya que los datos contendrán un identificador de objeto de la MIB de ibmNetDispatcher.
El mandato ndcontrol subagent start activa el soporte SNMP. El mandato ndcontrol subagent stop desactiva el soporte SNMP.
Para más información acerca del mandato ndcontrol, consulte ndcontrol subagent -- configurar subagente SNMP.
Integrado en el kernel de Linux hay un recurso de cortafuegos denominado ipchains. Cuando se ejecutan simultáneamente Network Dispatcher e ipchains, Network Dispatcher ve primero paquetes, seguido de ipchains. Esto permite utilizar ipchains para reforzar un recuadro de Network Dispatcher de Linux, que puede ser, por ejemplo, un recuadro de Network Dispatcher que se utiliza para repartir el tráfico de los cortafuegos.
Cuando ipchains o iptables se configuran como completamente restringidos (no se permite tráfico de entrada ni de salida), la parte de envío de paquetes de Network Dispatcher continúa funcionando con normalidad.
Tenga en cuenta que ipchains e iptables no se pueden utilizar para filtrar el tráfico de entrada antes de que se reparta el tráfico.
Se debe permitir cierto tráfico adicional para que todo Network Dispatcher funcione correctamente. Algunos ejemplos de esta comunicación son:
En general, una estrategia de ipchains adecuada para recuadros Network Dispatcher es no permitir ningún tráfico, excepto el que procede o el que va destinado a los servidores de fondo, Network Dispatcher de alta disponibilidad de asociados, destinos a alcanzar o sistemas principales de configuración.
Esta sección describe cómo utilizar y gestionar el componente CBR de Network Dispatcher.
CBR y Caching Proxy trabajan conjuntamente mediante la API de Caching Proxy para gestionar las peticiones HTTP y HTTPS (SSL). Caching Proxy debe estar ejecutándose en la misma máquina para que CBR comience a repartir el tráfico entre servidores. Configure CBR y Caching Proxy tal como se describe en Ejemplo de configuración de CBR.
Después de iniciar CBR, puede controlarlo utilizando cualquiera de estos dos métodos:
Los archivos de anotaciones utilizados por CBR son similares a los utilizados en Dispatcher. Para obtener más información, consulte Utilización de los archivos de anotaciones de Network Dispatcher.
Después de iniciar Mailbox Locator, puede controlarlo utilizando cualquiera de estos dos métodos:
Los archivos de anotaciones utilizados por Mailbox Locator son similares a los utilizados en Dispatcher. Para obtener una descripción más detallada, consulte Utilización de los archivos de anotaciones de Network Dispatcher.
Después de iniciar Site Selector, puede controlarlo utilizando cualquiera de estos dos métodos:
Los archivos de anotaciones utilizados por Site Selector son similares a los utilizados en Dispatcher. Para obtener una descripción más detallada, consulte Utilización de los archivos de anotaciones de Network Dispatcher.
Después de iniciar Cisco Consultant, puede controlarlo utilizando cualquiera de estos dos métodos:
Los archivos de anotaciones utilizados por Cisco Consultant son similares a los utilizados en Dispatcher.Para obtener una descripción más detallada, consulte Utilización de los archivos de anotaciones de Network Dispatcher.
Metric Server proporciona a Network Dispatcher información sobre el tráfico de los servidores. Metric Server reside en cada uno de los servidores para los que se reparte el tráfico.
Cambie el nivel de anotaciones en el script de arranque de Metric Server. Puede especificar un rango de nivel de anotaciones de 0 a 5, similar al rango de nivel de anotaciones de los archivos de anotaciones de Network Dispatcher. Esto generará un archivo de anotaciones de agente en el directorio ...ms/logs.
Este capítulo le ayuda a detectar y a resolver problemas asociados con Network Dispatcher. Busque el síntoma que está experimentando en Tablas de resolución de problemas.
A continuación se proporcionan tablas de resolución de problemas
para Dispatcher, CBR, Mailbox Locator, Site Selector y Consultant para Cisco
CSS Switches.
Tabla 14. Tabla de resolución de problemas de Dispatcher
Síntoma | Causa posible | Diríjase a... |
---|---|---|
Dispatcher no se ejecuta correctamente | Números de puerto en conflicto | Comprobar los números de puerto de Dispatcher |
Se ha configurado un servidor con ubicación compartida y no responderá a las peticiones de reparto del tráfico | Dirección errónea o en conflicto | Problema: Dispatcher y el servidor no responderán |
Conexiones de las máquinas cliente no atendidas o se ha agotado el tiempo de espera de las mismas |
| Problema: no se realiza el reparto del tráfico para las peticiones de Dispatcher |
Las máquinas cliente no se están atendiendo o están agotando el tiempo de espera | La alta disponibilidad no funciona | Problema: la modalidad de alta disponibilidad de Dispatcher no funciona |
No se puede añadir pulso (Windows 2000) | La dirección origen no está configurada en un adaptador | Problema: no se puede añadir pulso (Windows 2000) |
El servidor no atiende a las peticiones (Windows) | Se ha creado una ruta adicional en la tabla de encaminamiento | Problema: rutas sobrantes (sólo Windows 2000) |
Los asesores no están funcionando correctamente con el área amplia | Los asesores no se están ejecutando en las máquinas remotas | Problema: los asesores no funcionan correctamente |
SNMPD no arranca o no seguirá ejecutándose (Windows 2000) | El nombre de comunidad que se ha pasado en los mandatos SNMP no se corresponde con el nombre de comunidad con el que se ha iniciado el subagente | Problema: SNMPD no se ejecuta correctamente (Windows 2000) |
Dispatcher, Microsoft IIS y SSL no están funcionando o no van a seguir haciéndolo | No se pueden enviar datos cifrados a través de los protocolos | Problema: Dispatcher, Microsoft IIS y SSL no funcionan (Windows 2000) |
Conexión a máquina remota rechazada | Se sigue utilizando una versión más antigua de las claves | Problema: conexión de Dispatcher a una máquina remota |
Un mandato ndcontrol o ndadmin da error con en mensaje 'El servidor no responde' o 'No se puede acceder al servidor RMI' |
| Problema: el mandato ndcontrol o ndadmin da error |
Mensaje de error del tipo "No se puede encontrar el archivo..." cuando se ejecuta Netscape como navegador por omisión para ver la ayuda en línea (Windows 2000) | Valor incorrecto para la asociación de archivo HTML | Problema: se visualiza el mensaje de error del tipo "No se puede encontrar el archivo... al intentar visualizar la ayuda en línea (Windows 2000) |
Al iniciar ndserver en Solaris 2.7, aparece el mensaje de error: "stty: No existe tal dispositivo ni dirección". | Puede pasar por alto este mensaje de error. No es indicativo de un problema. Ndserver se ejecutará correctamente | Problema: mensaje falso de error al iniciar ndserver en Solaris 2.7 |
La interfaz gráfica de usuario no se inicia correctamente | Espacio de paginación insuficiente | Problem: la interfaz gráfica de usuario (GUI) no arranca correctamente |
Error al ejecutar Dispatcher cuando Caching Proxy está instalado | Dependencia de Caching Proxy respecto a un archivo | Problema: error al ejecutar Dispatcher cuando Caching Proxy está instalado |
La interfaz gráfica de usuario no se visualiza correctamente. | El valor de resolución de pantalla no es correcto. | Problema: la interfaz gráfica de usuario (GUI) no se visualiza correctamente |
Algunas veces los paneles de ayuda quedan ocultos detrás de otras ventanas | Limitación de Java | Problema: en Windows 2000, las ventanas de ayuda algunas veces quedan ocultas detrás de otras ventanas abiertas |
Network Dispatcher no puede procesar y reenviar una trama | Es necesaria una dirección MAC exclusiva para cada adaptador de red | Problema: Network Dispatcher no puede procesar y reenviar una trama |
Aparece una pantalla azul | No hay una tarjeta de red instalada y configurada | Problema: aparece una pantalla azul al iniciar el ejecutor de Network Dispatcher |
La vía de acceso de descubrimiento impide la devolución de tráfico | El cluster tiene un alias en el bucle de retorno | Problema: la vía de acceso de descubrimiento impide la devolución de tráfico con Network Dispatcher |
Los asesores muestran que todos los servidores están inactivos | La suma de comprobación de TCP no se ha calculado correctamente | Problema: los asesores muestran que todos los servidores están inactivos |
La alta disponibilidad en la modalidad de área amplia de Network Dispatcher no funciona. | Debe definirse un Dispatcher remoto como servidor de un cluster en el Dispatcher local | Problema: la alta disponibilidad en la modalidad de área amplia de Network Dispatcher no funciona |
La GUI se cuelga (o se comporta de forma inesperada) cuando se intenta cargar un archivo de configuración grande. | Java no tiene acceso a la suficiente memoria como para manejar un cambio tan grande en la GUI. | Problema: la GUI se cuelga (o se comporta de forma inesperada) cuando se intenta cargar un archivo de configuración grande |
Tabla 15. Tabla de resolución de problemas de CBR
Síntoma | Causa posible | Ir a... |
CBR no se ejecuta correctamente | Números de puerto en conflicto | Comprobación de los números de puerto de CBR |
El mandato cbrcontrol o ndadmin falla y devuelve el mensaje 'El servidor no responde' o 'No se puede acceder al servidor RMI' | Los mandatos fallan debido a una pila con socks. O los mandatos fallan debido a que cbrserver no se ha iniciado | Problema: el mandato cbrcontrol o ndadmin falla |
No se realiza el reparto del tráfico para las peticiones | Se ha iniciado Caching Proxy antes de iniciar el ejecutor | Problema: no se realiza el reparto del tráfico para las peticiones |
En Solaris, el mandato cbrcontrol executor start falla con el mensaje 'Error: No se ha iniciado el ejecutor.' | El mandato falla porque puede que tengan que modificarse los valores por omisión de IPC del sistema | Problema: en Solaris, el mandato cbrcontrol executor start falla |
La norma de URL no funciona | Error sintáctico o de configuración | Problema: error sintáctico o de configuración |
Tabla 16. Tabla de resolución de problemas de Mailbox Locator
Síntoma | Causa posible | Ir a... |
Mailbox Locator no se ejecuta correctamente | Números de puerto en conflicto | Comprobación de los números de puerto de Mailbox Locator |
El mandato mlserver devuelve la excepción "java.rmi.RMI Security Exception: security.fd.read" | El límite de descriptores de archivo del sistema es demasiado pequeño para el número de peticiones a las que intenta atender mlserver | Problema: el mandato mlserver está detenido |
El mandato mlcontrol o ndadmin falla y devuelve el mensaje 'El servidor no responde' o 'No se puede acceder al servidor RMI' | Los mandatos fallan debido a una pila con socks. O bien los mandatos fallan debido a que mlserver no está iniciado. | Problema: el mandato mlcontrol o ndadmin falla |
No se puede añadir un puerto | Otra aplicación ya está a la escucha en ese puerto | Problema: no se puede añadir un puerto |
Se recibe un error de proxy al intentar añadir un puerto | No se ha configurado la dirección de cluster en un adaptador de red antes de iniciar el proxy, O bien otra aplicación está en ejecución en ese puerto. | Problema: se recibe un error de proxy al intentar añadir un puerto |
Tabla 17. Tabla de resolución de problemas de Site Selector
Síntoma | Causa posible | Diríjase a... |
---|---|---|
Site Selector no se ejecuta correctamente | Número de puerto en conflicto | Comprobación de los números de puerto de Site Selector |
Site Selector no efectúa el reparto rotatorio del tráfico para las peticiones entrantes procedentes de clientes Solaris | Los sistemas Solaris ejecutan una daemon de servicio de nombres en antememoria. | Problema: Site Selector no efectúa un reparto rotatorio para el tráfico procedente de clientes Solaris |
El mandato sscontrol o ndadmin falla y devuelve el mensaje 'El servidor no responde' o 'No se puede acceder al servidor RMI' | Los mandatos fallan debido a una pila con socks. O bien los mandatos fallan debido a que ssserver no está iniciado. | Problema: el mandato sscontrol o ndadmin falla |
ssserver no se inicia en Windows 2000 | Windows no necesita que el nombre del sistema principal esté en el DNS. | Problema: ssserver no se inicia en Windows 2000 |
La máquina con rutas duplicadas no reparte el tráfico correctamente -- la resolución de nombres parece ser anómala | La máquina de Site Selector tiene varios adaptadores de red que están conectados a la misma subred | Problema: Site Selector no reparte el tráfico correctamente si hay rutas duplicadas |
Tabla 18. Tabla de resolución de problemas de Consultant para Cisco CSS Switches
Síntoma | Causa posible | Diríjase a... |
---|---|---|
lbcserver no arranca | Números de puerto en conflicto | Comprobación de los números de puerto de Cisco Consultant |
El mandato lbccontrol o ndadmin falla y devuelve el mensaje 'El servidor no responde' o 'No se puede acceder al servidor RMI' | Los mandatos fallan debido a una pila con socks. O bien los mandatos fallan debido a que lbcserver no está iniciado. | Problema: el mandato lbccontrol o ndadmin falla |
Error de recepción: No se puede crear registro para el puerto 14099 | Licencia de producto caducada | Problema: No se puede crear el registro para el puerto 14099 |
Tabla 19. Tabla de resolución de problemas de Metric Server
Síntoma | Causa posible | Diríjase a... |
---|---|---|
Excepción de E/S de Metric Server en Windows 2000 al ejecutar los archivos de métrica del usuario .bat o .cmd | Es necesario el nombre de métrica completo | Problema: excepción de E/S de Metric Server en Windows 2000 al ejecutar los archivos de métrica del usuario .bat o .cmd |
Metric Server no notifica a la máquina Network Dispatcher información sobre carga | Las posibles causas son:
| Problema: Metric Server no notifica cargas a la máquina Network Dispatcher |
Las anotaciones de Metric Server indican que "se necesita una firma para acceder al agente" cuando se transfieren archivos de claves al servidor | El archivo de claves no ofrece autorización porque está dañado. | Problema: las anotaciones de Metric Server indican que se necesita una firma para poder acceder al agente |
Si tiene problemas al ejecutar Dispatcher, es posible que una de las aplicaciones utilice un número de puerto que utiliza normalmente Dispatcher. Tenga presente que el servidor Dispatcher utiliza los números de puerto siguientes:
Si otra aplicación utiliza uno de los números de puerto de Dispatcher, puede cambiar dicho número para Dispatcher haciendo lo siguiente:
Si tiene problemas al ejecutar CBR, puede que una de las aplicaciones esté utilizando un número de puerto utilizado habitualmente por CBR. Tenga presente que CBR utiliza los siguientes números de puerto:
Si otra aplicación utiliza uno de los números de puerto de CBR, puede cambiar el número de puerto de CBR haciendo lo siguiente:
Si tiene problemas al ejecutar Mailbox Locator, puede que una de las aplicaciones esté utilizando un número de puerto utilizado normalmente por Mailbox Locator. Tenga presente que Mailbox Locator utiliza los siguientes números de puerto:
Si otra aplicación utiliza uno de los números de puerto de Mailbox Locator, puede cambiar el número de puerto de Mailbox Locator haciendo lo siguiente:
Si tiene problemas al ejecutar el componente Site Selector, puede que una de las aplicaciones esté utilizando un número de puerto utilizado normalmente por Site Selector. Tenga presente que Site Selector utiliza los siguientes números de puerto:
Si otra aplicación utiliza uno de los números de puerto de Site Selector, puede cambiar el número de puerto de Site Selector haciendo lo siguiente:
Si tiene problemas al ejecutar el componente Cisco Consultant, puede que una de las aplicaciones esté utilizando un número de puerto utilizado normalmente por el archivo lbcserver de Cisco Consultant. Tenga presente que Cisco Consultant utiliza los siguientes números de puerto:
14099 para recibir mandatos de lbccontrol
10004 para enviar consultas métricas a Metric Server
Si otra aplicación utiliza uno de los números de puerto de Consultant, puede cambiar los números de puerto de Consultant haciendo lo siguiente:
Este problema puede suceder cuando otra aplicación utiliza uno de los puertos utilizado por Dispatcher. Para obtener más información, vaya al apartado Comprobar los números de puerto de Dispatcher.
Este problema se produce cuando se está utilizando una dirección diferente a la especificada. Cuando establezca la ubicación compartida del servidor y Dispatcher, asegúrese de que la dirección de servidor utilizada en la configuración es la dirección NFA o que está configurada como ubicación compartida.
Los síntomas de este problema son, entre otros, que las conexiones de las máquinas cliente no sean atendidas o que se agote el tiempo de espera de las mismas. Para efectuar un diagnóstico del problema, compruebe lo siguiente:
Este problema se presenta cuando se configura el entorno de alta disponibilidad de Dispatcher y las conexiones de las máquinas cliente no son atendidas o agotan el tiempo de espera. Para corregir o diagnosticar el problema, compruebe lo siguiente:
Este error de Windows 2000 se produce cuando la dirección de origen no está configurada en un adaptador. Para corregir o diagnosticar el problema, compruebe lo siguiente.
ndconfig tr0 <dirección_IP> netmask <máscara_red> o bien ndcontrol cluster configure
Después de configurar las máquinas servidor, puede detectar que ha creado accidentalmente una o más rutas sobrantes. Si no se eliminan, estas rutas sobrantes impedirán que Dispatcher funcione. Para comprobar si existen estas rutas y suprimirlas, consulte Configuración de las máquinas servidor para el reparto del tráfico.
Si está utilizando el soporte de área amplia y los asesores no parecen funcionar correctamente, asegúrese de que se han arrancado tanto en el Dispatcher local como en el remoto. Consulte Utilización de asesores remotos con soporte de área amplia.
Cuando se utilizan subagentes SNMP, si el daemon SNMP SystemViewAgent no se arranca y se mantiene en marcha, asegúrese de que ha configurado la comunidad SNMP por medio del programa snmpcfg. Para acceder a los datos SNMP desde el subagente de Dispatcher, el nombre de comunidad que se pase en los mandatos SNMP debe corresponder con el nombre de comunidad con el que se arrancó el subagente.
Al utilizar Dispatcher, Microsoft IIS y SSL, si éstos no funcionan conjuntamente, puede existir un problema para habilitar la seguridad de 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 que necesite SSL, consulte la publicación Microsoft Information and Peer Web Services Information and Planning Guide, que se suministra con Windows 2000. El URL local del documento, que se visualiza mediante un navegador Web, es archivo:///C|/WINNT/system32/inetsrv/iisadmin/htmldocs/inetdocs.htm.
Dispatcher utiliza claves para permitirle conectarse a una máquina remota y configurarla. Las claves especifican un puerto RMI para la conexión. Es posible modificar el puerto RMI debido a conflictos o razones de seguridad. Al modificar los puertos RMI, el nombre de archivo de la clave es diferente. Si tiene más de una clave en su directorio de claves para la misma máquina remota, y éstas especifican diferentes puertos RMI, la línea de mandatos sólo probará el primero que encuentre. Si es el incorrecto, la conexión se rechazará. La conexión no se producirá a menos que suprima la clave incorrecta.
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
El puerto aleatorio puede ocasionar problemas cuando 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 Network Dispatcher se ejecuta en la misma máquina que un cortafuegos y emite mandatos ndcontrol, puede encontrarse con errores del tipo Error: El servidor no responde.
Para evitar este problema, edite el archivo de script ndserver (situado en PATH) para definir el puerto aleatorio que utiliza RMI. Incluya -DND_RMI_SERVER_PORT=suPuerto en la serie de caracteres END_ACCESS, donde suPuerto es el puerto que especifique.
Por ejemplo:
END_ACCESS='-DND_CLIENT_KEYS_DIRECTORY=/usr/lpp/nd/admin/keys/dispatcher -DND_SERVER_KEYS_DIRECTORY=/usr/lpp/nd/dispatcher/key -DND_RMI_SERVER_PORT=10100' ND_RMIPORT=10099
Una vez completado, vuelva a iniciar ndserver y abra el tráfico para los puertos 10099 y 10100 o para el puerto elegido para la dirección del sistema principal desde el que se ejecutará la consola de administración.
En Windows 2000, cuando se utiliza Netscape como navegador por omisión, el mensaje de error que se visualiza con este problema es " No se puede encontrar el archivo '<nombre_archivo>.html' (o uno de sus componentes). Asegure de que la vía de acceso y el nombre de archivo son correctos y que están disponibles todas las bibliotecas necesarias".
El problema se debe a un valor incorrecto para la asociación de archivo HTML. Para corregir el problema:
Al iniciar ndserver en las plataformas Solaris 2.7, aparece el siguiente mensaje falso de error: "stty: : No existe tal dispositivo ni dirección". Puede pasar por alto este mensaje de error. Ndserver se ejecutará correctamente.
La interfaz gráfica de usuario (GUI), que es ndadmin, necesita una cantidad suficiente de espacio de paginación para funcionar correctamente. Si la GUI no dispone de espacio de paginación suficiente, puede que no arranque completamente. Si ocurre esto, compruebe el espacio de paginación y auméntelo si es necesario.
Si desinstala Network Dispatcher para reinstalar otra versión y obtiene un error al intentar iniciar el componente Dispatcher, compruebe si Caching Proxy está instalado. Caching Proxy depende de uno de los archivos de Dispatcher; este archivo se desinstala sólo al desinstalar Caching Proxy.
Para evitar este problema:
Si la GUI de Network Dispatcher tiene un aspecto anómalo, compruebe el valor del sistema operativo correspondiente a la resolución del escritorio. La mejor visualización de la GUI se consigue para una resolución de 1024x768 pixels.
Cuando abre por primera vez ventanas de ayuda en Windows 2000, algunas veces quedan ocultas detrás de ventanas existentes. Si ocurre esto, pulse sobre la ventana para devolverla al primer plano.
En Solaris, cada adaptador de red tiene la misma dirección MAC por omisión. Esto es apropiado cuando cada adaptador está en una subred IP diferente; sin embargo, en un entorno conmutado, cuando varios adaptadores de red con la misma dirección MAC y la misma dirección de subred IP se comunican con el mismo conmutador, éste envía todo el tráfico destinado a la dirección MAC (y ambos IP) a través del mismo canal. Sólo el adaptador que envío por última vez una trama por la red detecta los paquetes IP destinados a ambos adaptadores. Solaris puede descartar los paquetes destinados a una dirección IP válida que hayan llegado en la interfaz "equivocada".
Si todas las interfaces de red no están diseñadas para Network Dispatcher tal como está configurado en ibmnd.conf, y si el adaptador de red que no está definido en ibmnd.conf recibe una trama, Network Dispatcher no puede procesar y reeenviar la trama.
Para evitar este problema, debe anular el valor por omisión y establecer una dirección MAC exclusiva para cada interfaz. Utilice este mandato:
ifconfig interfaz ether macAddr
Por ejemplo:
ifconfig hme0 ether 01:02:03:04:05:06
En Windows 2000, antes de iniciar el ejecutor debe instalar y configurar una tarjeta de red.
El sistema operativo AIX contiene un parámetro de red denominado "path MTU discovery". 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 parámetro "path MTU discovery" hace que AIX cree una ruta para recordar esos datos. La nueva ruta es para ese cliente IP específico y registra la MTU necesaria para su acceso.
Mientras se crea la ruta, puede producirse un problema relacionado con los servidores como consecuencia de que el cluster tenga un alias en el bucle de retorno. Si la dirección de pasarela de la ruta es la subred del cluster/máscara de red, AIX crea la ruta en el bucle de retorno. Sucede así porque era la última interfaz unida a esa subred por medio de un alias.
Por ejemplo, si el cluster es 9.37.54.69 y se utiliza la máscara de red 255.255.255.0 y la pasarela que se pretende es 9.37.54.1, AIX utiliza el bucle de retorno para la ruta. Esto provoca que las respuestas del servidor nunca salgan del sistema y se sobrepase el tiempo de espera del cliente. Normalmente, el cliente obtiene una respuesta del cluster, entonces se crea la ruta y el cliente ya no recibe más información.
Existen dos soluciones para este problema.
Notas:
Windows 2000 tiene una nueva función denominada Descarga de tareas, que permite calcular la suma de comprobación de TCP mediante la tarjeta adaptadora en lugar del sistema operativo. Esto mejora el rendimiento del sistema. Si se habilita la Descarga de tareas, los asesores de Network Dispatcher informan de que los servidores están inactivos cuando no lo están.
El problema es que la suma de comprobación de TCP no se calcula correctamente para los paquetes que proceden de la dirección de cluster, que es lo que sucede con el tráfico de los asesores.
Para evitar este problema, vaya a los valores de tarjeta adaptadora e inhabilite la Descarga de tareas.
Este problema se observó por primera vez con el adaptador de Adaptec ANA62044 QuadPort. Esta tarjeta adaptadora reconoce la función con el nombre de Descarga de la suma de comprobación de transmisiones. Inhabilite la Descarga de la suma de comprobación de transmisiones para evitar el problema.
Cuando configure un Network Dispatcher de área amplia, debe definir el Dispatcher remoto como servidor de un cluster en el Dispatcher local. Normalmente, se utiliza la dirección de no reenvío (NFA) del Dispatcher remoto como dirección de destino del servidor remoto. Si hace esto y luego configura la modalidad de alta disponibilidad en el Dispatcher remoto, el resultado no será satisfactorio. Sucede así porque el Dispatcher local siempre apunta al principal de la parte remota cuando se utiliza su NFA para el acceso.
Para solucionar este problema:
Cuando el Dispatcher principal remoto se active, creará un alias para esta dirección en su adaptador, lo que le permitirá aceptar el tráfico. Si se produce una anomalía, la dirección pasa a la máquina de reserva y ésta continúa aceptando el tráfico para esa dirección.
Cuando se intenta cargar un archivo de configuración grande (con unos 200 o más mandatos add), puede que la GUI se cuelgue o muestre un comportamiento inesperado, como por ejemplo que responda a cambios en la pantalla a una velocidad extremadamente baja.
Esto se debe a que Java no tiene acceso a suficiente memoria como para manejar un cambio tan grande en la GUI.
Se puede especificar una opción en el entorno de ejecución para aumentar la agrupación de asignación de memoria disponible para Java.
Esta opción es -Xmxn, donde n es el tamaño máximo, en bytes, para la agrupación de asignación de memoria. n debe ser múltiplo de 1024 y debe ser mayor que 2 MB. El valor n puede ir seguido de k o K para indicar kilobytes, o de m o M para indicar megabytes. Por ejemplo, -Xmx128M y -Xmx81920k son valores válidos. El valor por omisión es 64MB. Las plataformas SPARC de Solaris 7 y Solaris 8 tienen un valor máximo de 4000m; las plataformas Solaris 2.6 y x86 tienen un valor máximo de 2000m.
Para añadir esta opción, modifique el script ndadmin del siguiente modo:
START jrew -mx64m %END_ACCESS% %CONFIG_DIR% -DEND_INSTALL_PATH=%IBMNDPATH% -cp %NDCLASSPATH% com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode1
$JREDIR/$JRE -mx64m $END_ACCESS $CONFIG_DIR -DEND_INSTALL_PATH=/opt/&BASEDIR -cp $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode &1
re -mx64m $END_ACCESS $CONFIG_DIR $NDLOCALE -DEND_INSTALL_PATH=/opt/nd -classpath $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode 1>/dev/null 2>&1 &1
ava -mx64m $END_ACCESS $CONFIG_DIR $NDLOCALE -DEND_INSTALL_PATH=/usr/lpp/&BASEDIR -classpath $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode 1>/dev/null 2>&1 &
No hay ningún valor recomendado para n, pero debe ser mayor que la opción por omisión. Un buen punto de partido es el doble que el valor por omisión.
Este problema puede suceder cuando otra aplicación utiliza uno de los puertos utilizados por CBR. Para obtener más información, vaya al apartado Comprobación de los números de puerto de CBR.
El mandato cbrcontrol devuelve: "Error: El servidor no responde". O bien el mandato ndadmin devuelve: "Error: no se puede acceder al servidor RMI". Estos errores se pueden producir cuando la máquina tiene una pila con socks. Para corregir el problema, edite el archivo socks.cnf e incluya las líneas siguientes:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Estos errores también se pueden producir si todavía no ha iniciado cbrserver.
Caching Proxy y CBR se han iniciado, pero no se realiza el reparto del tráfico para las peticiones. Puede producirse este error si se inicia Caching Proxy antes de iniciar el ejecutor. Si es así, el archivo de anotaciones stderr de Caching Proxy contendrá el siguiente mensaje de error: "ndServerInit: No se ha podido conectar con el ejecutor". Para evitar este problema, inicie el ejecutor antes de iniciar Caching Proxy.
En Solaris, el mandato cbrcontrol executor start devuelve: "Error: No se ha iniciado el ejecutor". Este error se produce si no configura IPC (Inter-process Communication) para el sistema de manera que el tamaño máximo de un segmento de memoria compartida y los ID de semáforo superen el valor por omisión del sistema operativo. Para aumentar el tamaño del segmento de memoria compartida y los ID de semáforo, debe editar el archivo /etc/system. Para obtener más información sobre cómo configurar este archivo, consulte ***.
Si la norma de URL no funciona, puede deberse a un error sintáctico o de configuración. Para corregir este problema, compruebe lo siguiente:
Este problema puede suceder cuando otra aplicación utiliza uno de los puertos utilizados por Mailbox Locator. Para obtener más información, consulte Comprobación de los números de puerto de Mailbox Locator.
En una plataforma UNIX, este problema se produce cuando se utiliza mlserver para repartir un gran número de peticiones de clientes IMAP/POP3 y el límite del sistema para los descriptores de archivo es demasiado pequeño para el número de peticiones que mlserver intenta atender. Mlserver produce la excepción siguiente y luego se detiene:
java.rmi.RMISecurityException: security.fd.read
El archivo de anotaciones de proxy específico del protocolo informa:
SocketException=java.net.SocketException: Socket closed
La solución consiste en modificar el límite nofiles (AIX, Linux) o modificar el límite open files (Solaris) en el shell donde se ha iniciado mlserver. Aumente el valor de nofiles a un valor razonable mayor. Utilice ulimit -a para visualizar el valor de nofiles actual y utilice ulimit -n valor para aumentar el valor.
El mandato mlcontrol devuelve: "Error: El servidor no responde". O bien el mandato ndadmin devuelve: "Error: no se puede acceder al servidor RMI". Estos errores se pueden producir cuando la máquina tiene una pila con socks. Para corregir el problema, edite el archivo socks.cnf e incluya las líneas siguientes:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Estos errores también se pueden producir si todavía no ha iniciado mlserver.
Cuando intente añadir un puerto a una configuración, puede recibir este mensaje de error: Error: No se puede añadir el puerto. Es posible que otra aplicación ya esté a la escucha en ese puerto. Mailbox Locator intenta iniciar un proxy que se vincula con el cluster IP en el puerto especificado en el mandato. Si otra aplicación se está vinculando con ese IP o está escuchando a todos los IP en ese puerto, el arranque del proxy falla. Para utilizar Mailbox Locator en ese puerto, deberá detener la aplicación que provoca el conflicto.
Tenga en cuenta que, en la plataforma Linux, el daemon xinetd puede iniciar un oyente sin que se ejecute, como, por ejemplo, un programa POP3. Por lo tanto, es importante comprobar netstat -a para determinar si alguna aplicación está a la escucha en el puerto deseado.
Para Mailbox Locator, el mandato mlcontrol port add produce el mensaje de error siguiente: "El proxy del cluster <cluster> , puerto <puerto> no se inició." La solución consiste en configurar la dirección del cluster en una NIC antes de iniciar el proxy. Compruebe también que no haya ninguna otra aplicación activa en ese puerto que esté a la escucha de la dirección del cluster (incluidas las aplicaciones de escucha genérica).
Este problema puede suceder cuando otra aplicación utiliza uno de los puertos utilizados por Site Selector. Para obtener más información, consulte Comprobación de los números de puerto de Site Selector.
Síntoma: el componente Site Selector no efectúa el reparto rotatorio del tráfico para las peticiones entrantes procedentes de los clientes Solaris.
Causa posible: los sistemas Solaris ejecutan una daemon de servicio de nombres en antememoria. Si este daemon está en ejecución, la petición subsiguiente de resolución de direcciones se responderá desde esta antememoria, en lugar de consultar a Site Selector.
Solución: Desactive el daemon del servicio de nombres en antememoria para la máquina Solaris.
El mandato sscontrol devuelve: "Error: El servidor no responde". O bien el mandato ndadmin devuelve: "Error: no se puede acceder al servidor RMI". Estos errores se pueden producir cuando la máquina tiene una pila con socks. Para corregir el problema, edite el archivo socks.cnf e incluya las líneas siguientes:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Estos errores también se pueden producir si todavía no ha iniciado ssserver.
Site Selector debe poder participar en un DNS. Todas las máquinas que intervienen en la configuración deben participar también en este sistema. Windows no siempre necesita que el nombre del sistema principal configurado esté en el DNS. Site Selector necesita que su nombre de sistema principal esté definido en el DNS para que se inicie correctamente.
Compruebe que este sistema principal esté definido en el DNS. Edite el archivo ssserver.cmd y elimine la "w" de "javaw". Esto debería ocasionar más errores.
El servidor de nombres de Site Selector no establece ninguna asociación con ninguna dirección de la máquina. El servidor responderá a las peticiones destinadas a cualquier IP válido de la máquina. Site Selector depende del sistema operativo para encaminar la respuesta hacia el cliente. Si la máquina de Site Selector tiene varios adaptadores de red y varios de ellos están conectados a la misma subred, puede que el sistema operativo envíe la respuesta a un cliente que tiene una dirección diferente a la dirección desde donde se recibió la petición. Algunas aplicaciones de cliente no aceptan una respuesta recibida desde una dirección diferente a aquélla desde donde se envió. Como consecuencia, la resolución de nombres fallará.
Este problema puede suceder cuando otra aplicación utiliza uno de los puertos utilizado por el archivo lbcserver de Consultant. Para obtener más información, consulte Comprobación de los números de puerto de Cisco Consultant.
El mandato lbccontrol devuelve: "Error: El servidor no responde". O bien el mandato ndadmin devuelve: "Error: no se puede acceder al servidor RMI". Estos errores se pueden producir cuando la máquina tiene una pila con socks. Para corregir el problema, edite el archivo socks.cnf e incluya las líneas siguientes:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Estos errores también se pueden producir si todavía no ha iniciado lbcserver.
Este problema se puede producir si falta una licencia válida de producto. Cuando intenta iniciar lbcserver, recibe este mensaje:
Su licencia ha caducado. Consulte al representante local de IBM o al distribuidor autorizado de IBM.
Para corregir este problema:
Debe utilizar el nombre de métrica completo para la métrica escrita por el usuario en los Metric Servers de Windows 2000. Por ejemplo, debe especificar usermetric.bat en lugar de usermetric. El nombre usermetric es válido en la línea de mandatos, pero no funciona cuando se ejecuta desde el entorno de unidad ejecutable. Si no utiliza el nombre de métrica completo, recibirá una excepción de E/S (IOException) de Metric Server. Establezca la variable LOG_LEVEL en el valor 3 en el archivo de mandatos metricserver y luego compruebe la salida del archivo de anotaciones. En este ejemplo, la excepción aparece así:
... java.io.IOException: CreateProcess: usermetric error=2
Puede haber varias razones por las que Metric Server no notifique información sobre cargas a Network Dispatcher. Para determinar la causa, realice las siguientes comprobaciones:
Las anotaciones de Metric Server notifican este mensaje de error después de que los archivos de claves se hayan transferido al servidor.
Este error queda anotado cuando el archivo de claves no consigue autorización con la clave emparejada debido a que el par está dañado. Para corregir este problema intente lo siguiente:
El diagrama de sintaxis muestra cómo especificar un mandato de forma que el sistema operativo pueda interpretar correctamente lo que se teclea. El diagrama de sintaxis se lee de izquierda a derecha y de arriba a abajo, siguiendo la línea horizontal (línea principal).
En los diagramas de sintaxis se utilizan los símbolos siguientes:
Deben incluirse todos los signos de puntuación, como por ejemplo dos puntos, comillas y signos menos que aparecen en el diagrama de sintaxis.
En los diagramas de sintaxis se utilizan los siguientes tipos de parámetros.
Los parámetros se clasifican como palabras clave o variables. Las palabras clave se visualizan en letras minúsculas y pueden especificarse en letras minúsculas. Por ejemplo, un nombre de mandato es una palabra clave. Las variables aparecen en cursiva y representan nombres o valores suministrados por el usuario.
En el ejemplo siguiente, el mandato user es una palabra clave. La variable obligatoria es ID_usuario y la variable opcional es contraseña. Sustituya las variables por los valores que desee.
>>-user--ID_usuario--+------------+---------------------------->< '-contraseña-'
Palabras clave obligatorias: Las palabras clave y las variables obligatorias aparecen en la línea principal.
>>-palabra_clave_obligatoria-----------------------------------><
Debe codificar las palabras clave y los valores obligatorios.
Elija un elemento obligatorio de una lista: Si puede elegirse más de una palabra clave o variable obligatoria mutuamente excluyente, se clasifican verticalmente en orden alfanumérico.
>>-+-parámetro_obligatorio_1-+--------------------------------->< '-parámetro_obligatorio_2-'
Valores opcionales: Las palabras clave y variables opcionales aparecen debajo de la línea principal.
>>-+---------------+------------------------------------------->< '-palabra_clave-'
Puede elegir no codificar las palabras clave y variables opcionales.
Elija una palabra clave opcional de una lista: Si puede elegirse más de una palabra clave o variable opcional mutuamente excluyente, se clasifican verticalmente en orden alfanumérico debajo de la línea principal.
>>-+-------------+--------------------------------------------->< +-parámetro_1-+ '-parámetro_2-'
Variables: Una palabra en cursiva es una variable. Cuando vea una variable en la sintaxis, debe sustituirla por uno de los nombres o valores permitidos, tal como se define en el texto.
>>-variable----------------------------------------------------><
Caracteres no alfanuméricos: Si un diagrama muestra un carácter que no es alfanumérico (como por ejemplo dos puntos, comillas o signos menos), debe codificar el carácter como parte de la sintaxis. En este ejemplo, debe codificar cluster:puerto.
>>-cluster:puerto----------------------------------------------><
Este apéndice describe cómo utilizar los mandatos ndcontrol de Dispatcher. También es una guía de consulta para los mandatos de CBR y Mailbox Locator. CBR y Mailbox Locator utilizan un subconjunto de los mandatos de Dispatcher. En Diferencias de configuración entre CBR, Mailbox Locator y Dispatcher hallará más información.
A continuación sigue una lista de los mandatos descritos en este apéndice:
Puede especificar una versión abreviada de los parámetros de los mandatos ndcontrol. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede entrar ndcontrol he f en lugar de ndcontrol help file.
Para iniciar la interfaz de línea de mandatos, emita ndcontrol para visualizar un indicador de mandatos de ndcontrol.
Para cerrar la interfaz de línea de mandatos, emita exit o quit.
La interfaz de línea de mandatos de CBR y Mailbox Locator es en su mayor parte un subconjunto de la interfaz de línea de mandatos de Dispatcher. Para configurar el componente, utilice el mandato cbrcontrol (para el componente CBR) o utilice el mandato mlcontrol (para el componente Mailbox Locator) en lugar de ndcontrol.
Estos son algunos de los mandatos que están omitidos en CBR:
Estos son algunos de los mandatos que están omitidos en Mailbox Locator:
>>-ndcontrol--advisor--+-connecttimeout--nombre--+-puerto---------+--segundos_inactividad-+->< | '-cluster:puerto-' | +-interval--nombre--+-puerto---------+--segundos-------------------+ | '-cluster:puerto-' | +-list-------------------------------------------------------------+ +-loglevel--nombre--+-puerto---------+--nivel----------------------+ | '-cluster:puerto-' | +-logsize--nombre--+-puerto---------+--+-unlimited-----------+-----+ | '-cluster:puerto-' '-número de registros-' | +-receivetimeout--nombre--+-puerto---------+--segundos_inactividad-+ | '-cluster:puerto-' | +-report--nombre--+-puerto---------+-------------------------------+ | '-cluster:puerto-' | +-start--nombre--+-puerto---------+--+------------------------+----+ | '-cluster:puerto-' '-archivo de anotaciones-' | +-status--nombre--+-puerto---------+-------------------------------+ | '-cluster:puerto-' | +-stop--nombre--+-puerto---------+---------------------------------+ | '-cluster:puerto-' | +-timeout--nombre--+-puerto---------+--+-unlimited-+---------------+ | '-cluster:puerto-' '-segundos--' | '-version--nombre--+-puerto---------+------------------------------' '-cluster:puerto-'
Los nombres de los asesores personalizados se encuentran en el formato xxxx, donde ADV_xxxx es el nombre de la clase que implementa el asesor personalizado. En Creación de asesores personalizados (personalizables) hallará más información.
El cluster es la dirección en formato decimal con puntos o un nombre simbólico. El puerto es el número del puerto que el asesor está supervisando.
Nombre de asesor | Protocolo | Puerto |
---|---|---|
connect | ICMP | 12345 |
db2 | privado | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
ibmproxy | HTTP (a través de Caching Proxy) | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | privado | 12345 |
smtp | SMTP | 25 |
ssl | HTTP | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | privado | 10.007 |
El archivo por omisión es nombreasesor_puerto .log, por ejemplo, http_80.log. Para cambiar el directorio en el que se conservarán los archivos de anotaciones, consulte la sección Cambio de la vía de acceso de los archivos de anotaciones. Los archivos de anotaciones por omisión para asesores específicos del cluster (o sitio Web) se crean con la dirección de cluster, por ejemplo, http_127.40.50.1_80.log.
Ejemplos
ndcontrol advisor start http 127.40.50.1:80
ndcontrol advisor start http 88
ndcontrol advisor stop http 127.40.50.1:80
ndcontrol advisor connecttimeout http 80 30
ndcontrol advisor connecttimeout http 127.40.50.1:80 20
ndcontrol advisor interval ftp 21 6
ndcontrol advisor listEste mandato produce una salida similar a la siguiente:
--------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
ndcontrol advisor loglevel http 80 0
ndcontrol advisor logsize ftp 21 5000
ndcontrol advisor receivetimeout http 80 60
ndcontrol advisor report ftp 21Este mandato produce una salida similar a la siguiente:
Advisor Report: --------------- Advisor name ............. Ftp Port number .............. 21 Cluster address .......... 9.67.131.18 Server address ........... 9.67.129.230 Load ..................... 8 Cluster address .......... 9.67.131.18 Server address ........... 9.67.131.215 Load ..................... -1
ndcontrol advisor status http 80Este mandato produce una salida similar a la siguiente:
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited
ndcontrol advisor timeout ftp 21 5
ndcontrol advisor version ssl 443Este mandato produce una salida similar a la siguiente:
Version: 04.00.00.00 - 07/12/2001-10:09:56-EDT
>>-ndcontrol--cluster--+-add--cluster+c2+...--+-----------------------------------------------+-+->< | +-proportions--activas--nuevas--puerto--sistema-+ | | +-maxports--tamaño------------------------------+ | | +-maxservers--tamaño----------------------------+ | | +-stickytime--tiempo----------------------------+ | | +-weightbound--peso-----------------------------+ | | +-porttype--tipo--------------------------------+ | | +-primaryhost--dirección------------------------+ | | +-staletimeout--tiempo_espera_inactividad-------+ | | '-sharedbandwidth--tamaño-----------------------' | +-set--cluster+c2+...--+-maxports--tamaño------------------------+-------+ | +-maxservers--tamaño----------------------+ | | +-stickytime--tiempo----------------------+ | | +-weightbound--peso-----------------------+ | | +-porttype--tipo--------------------------+ | | +-primaryhost--dirección------------------+ | | +-staletimeout--tiempo_espera_inactividad-+ | | '-sharedbandwidth--tamaño-----------------' | +-remove--cluster--------------------------------------------------------+ +-report--cluster--------------------------------------------------------+ +-status--cluster--------------------------------------------------------+ +-configure--cluster--+-------------------------------+------------------+ | '-nombre_interfaz - máscara_red-' | '-unconfigure--cluster---------------------------------------------------'
Puede utilizar un signo de dos puntos (:) como comodín, con excepción del mandato ndcontrol cluster add. Por ejemplo, el mandato ndcontrol cluster set : weightbound 80 definirá un peso máximo de 80 para todos los clusters.
Si se modifica el sistema principal primario de un cluster cuando las máquinas principal y de reserva ya se han iniciado y están ejecutándose con alta disponibilidad mutua, deberá forzar también el nuevo sistema principal primario para que asuma el control. También deberá actualizar los scripts, así como anular la configuración y volver a configurar manualmente el cluster de forma correcta. En Alta disponibilidad mutua hallará más información.
Ejemplos
ndcontrol cluster add 130.40.52.153
ndcontrol cluster remove 130.40.52.153
ndcontrol cluster set 9.6.54.12 proportions 60 35 5 0
ndcontrol cluster add 0.0.0.0
ndcontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
ndcontrol cluster status 9.67.131.167Este mandato produce una salida similar a la siguiente:
Cluster Status: --------------- Address ................................. 9.67.131.167 Number of target ports .................. 3 Default sticky time ..................... 0 Default stale timeout ................... 30 Default port weight bound ............... 20 Maximum number of ports ................. 8 Default port protocol ................... tcp/udp Default maximum number of servers ....... 32 Proportion given to active connections... 0.5 Proportion given to new connections...... 0.5 Proportion given specific to the port.... 0 Proportion given to system metrics....... 0 Shared bandwidth (KBytes) ............... 0 Primary Host Address .................... 9.67.131.167
>>-ndcontrol--executor--+-report-------------------------------------------+->< +-set--+-nfa--dirección IP-----------------------+-+ | +-maxclusters--tamaño---------------------+ | | +-maxports--tamaño------------------------+ | | +-fincount--número_conexiones_finalizadas-+ | | +-fintimeout--tiempo_espera_finalización--+ | | +-maxservers--tamaño----------------------+ | | +-staletimeout--tiempo_espera_inactividad-+ | | +-stickytime--tiempo----------------------+ | | +-clientgateway--dirección----------------+ | | +-weightbound--peso-----------------------+ | | +-porttype--tipo--------------------------+ | | +-wideportnumber--puerto------------------+ | | '-sharedbandwidth--tamaño-----------------' | +-start--------------------------------------------+ +-status-------------------------------------------+ '-stop---------------------------------------------'
Ejemplos
ndcontrol executor status Executor Status: ---------------- Nonforwarding address ............... 9.67.131.151 Client gateway address .............. 0.0.0.0 Fin count ........................... 4,000 Fin timeout ......................... 60 Wide area network port number ....... 2,001 Shared bandwidth (Kbytes) ........... 0 Default maximum ports per cluster ... 8 Maximum number of clusters .......... 100 Default maximum servers per port .... 32 Port stale timeout .................. 300 Port sticky time .................... 0 Port weight bound ................... 20 Maximum number of clusters .......... 100
ndcontrol executor set nfa 130.40.52.167
ndcontrol executor set maxclusters 4096
ndcontrol executor start
ndcontrol executor stop
>>-ndcontrol--file--+-delete--archivo[.ext]----------+--------->< +-appendload--archivo[.ext]------+ +-report-------------------------+ +-save--archivo[.ext]--+-------+-+ | '-force-' | '-newload--archivo[.ext]---------'
La extensión del archivo (.ext) puede ser cualquiera que elija el usuario y se puede omitir.
Vía de acceso común de directorio de instalación -- c:\Archivos de programa\ibm\edge\nd\servers\configurations\componente
Vía de acceso nativa de directorio de instalación -- c:\Archivos de programa\ibm\nd\servers\configurations\componente
Ejemplos
ndcontrol file delete archivo3 Se ha suprimido el archivo (archivo3).
ndcontrol archivo newload archivo1.sv Se ha cargado el archivo (archivo1.sv) en Dispatcher.
ndcontrol archivo appendload archivo2.sv Se ha añadido el archivo (archivo2.sv) a la configuración actual y se ha cargado.
ndcontrol file report INFORME DE ARCHIVOS: archivo1.guardar archivo2.sv archivo3
ndcontrol file save archivo3 La configuración se ha guardado en el archivo (archivo3).
>>-ndcontrol--help--+-help--------------+---------------------->< +-sistema principal-+ +-executor----------+ +-manager-----------+ +-advisor-----------+ +-cluster-----------+ +-puerto------------+ +-rule--------------+ +-server------------+ +-subagent----------+ +-highavailability--+ +-file--------------+ +-set---------------+ +-status------------+ '-log---------------'
Ejemplos
ndcontrol helpEste mandato produce una salida similar a la siguiente:
ARGUMENTOS DEL MANDATO HELP: --------------------------------- Uso: help <opción de ayuda> Ejemplo: help cluster help - imprimir texto completo de la ayuda advisor - ayuda para el mandato advisor cluster - ayuda para el mandato cluster executor - ayuda para el mandato executor file - ayuda para el mandato file host - ayuda para el mandato host log - ayuda para el mandato log manager - ayuda para el mandato manager metric - ayuda para el mandato metric port - ayuda para el mandato port rule - ayuda para el mandato rule server - ayuda para el mandato server set - ayuda para el mandato set status - ayuda para el mandato status subagent - ayuda para el mandato subagent highavailability - ayuda para el mandato high availabilityTenga en cuenta que los parámetros especificados entre <> son variables.
fintimeout <dirección cluster>|all <tiempo> -Cambiar tiempo de espera de finalización (Utilice 'all' para cambiar todos los clusters)
>>-ndcontrol--highavailability--+-status--------------------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--p-+-------------+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--dirección--máscara-------------------+ | '-delete-' | +-heartbeat--+-add--dirección_origen--dirección_destino-+-+ | '-delete--dirección------------------------' | '-takeover--+-----------+---------------------------------' '-dirección-'
Además, la palabra clave status devuelve información acerca de diversos subestados:
Configuración de alta disponibilidad mutua (la función de las máquinas Dispatcher es la de ambas máquinas).
Notas:
Ejemplos
ndcontrol highavailability status
Salida:
Estado de alta disponibilidad: ------------------------- Función ..................... primario Estrategia de recuperación .. manual Estado ...................... Activo Subestado ............. Sincronizado Sis. principal primario 9.67.131.151 Puerto .......................12,345 Destino preferente .... 9.67.134.223 Estado de pulso: ----------------- Número ............... 1 Estado de accesibilidad: -------------------- Número ............... 1
ndcontrol highavailability backup add primary auto 80
ndcontrol highavailability reach add 9.67.125.18
Principal - highavailability heartbeat add 9.67.111.3 9.67.186.8 Reserva - highavailability heartbeat add 9.67.186.8 9.67.111.3
ndcontrol highavailability takeover
>>-ndcontrol--host:--sispral_remoto----------------------------><
ndcontrol host: sistema_principal_remoto
Una vez emitido este mandato en el indicador de mandatos, escriba cualquier mandato ndcontrol válido que desee emitir en la máquina Network Dispatcher remoto.
>>-ndcontrol--log--+-start--------------------------+---------->< +-stop---------------------------+ +-set--+-retention-horas-------+-+ | '---interval-segundos---' | '-status-------------------------'
>>-ndcontrol--manager--+-interval--segundos--------------------------------+->< +-loglevel--nivel-----------------------------------+ +-logsize--+-unlimited-+----------------------------+ | '-bytes-----' | +-quiesce--servidor--+-----+------------------------+ | '-now-' | +-reach set--+-interval-segundos------+-------------+ | '-+-loglevel-nivel-----+-' | | '---logsize-tamaño---' | +-refresh--ciclo renovación-------------------------+ +-report--+----------------+------------------------+ | '-cluster+c2+...-' | +-restart--mensaje----------------------------------+ +-sensitivity--peso---------------------------------+ +-smoothing--índice de corrección-------------------+ +-start--+----------------------------------------+-+ | '-archivo de anotaciones--puerto_métrica-' | +-status--------------------------------------------+ +-stop----------------------------------------------+ +-unquiesce--servidor-------------------------------+ '-version-------------------------------------------'
O bien, si ha utilizado el particionamiento de servidores, utilice el nombre exclusivo del servidor lógico. En Particionamiento del servidor: servidores lógicos configurados para un solo servidor físico (dirección IP) hallará más información.
El archivo por omisión se instalará en el directorio logs. Consulte Apéndice F, Ejemplos de archivos de configuración. Para cambiar el directorio en el que se conservarán los archivos de anotaciones, consulte la sección Cambio de la vía de acceso de los archivos de anotaciones.
Ejemplos
ndcontrol manager interval 5
ndcontrol manager loglevel 0
ndcontrol manager logsize 1000000
ndcontrol manager quiesce 130.40.52.153
ndcontrol manager refresh 3
ndcontrol manager reportEste mandato produce una salida similar a la siguiente:
---------------------------------- | HOST TABLE LIST | STATUS | ---------------------------------- | 9.67.129.221| ACTIVE| | 9.67.129.213| ACTIVE| | 9.67.134.223| ACTIVE| ---------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| WEIGHT | ACTIVE % 48| NEW % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 80 |NOW | NEW |WT | CONN |WT | CONN | WT | LOAD | WT | LOAD | ----------------------------------------------------------------------------------- | 9.67.129.221| 8 | 8 | 10 | 0| 10 | 0 | 7 | 29 | 0 | 0| | 9.67.134.223| 11 | 11 | 10 | 0| 10 | 0 | 12 | 17 | 0 | 0| ----------------------------------------------------------------------------------- | PORT TOTALS:| 19 | 19 | | 0| | 0 | | 46 | | 0| ----------------------------------------------------------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| WEIGHT | ACTIVE % 48| NEW % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 23 |NOW | NEW |WT | CONN |WT | CONN | WT | LOAD | WT | LOAD | ----------------------------------------------------------------------------------- | 9.67.129.213| 10 | 10 | 10 | 0| 10 | 0 | 10 | 71 | 0 | 0| | 9.67.134.223| 0 | 0 | 10 | 0| 10 | 0 |-9999 | -1 | 0 | 0| ----------------------------------------------------------------------------------- | PORT TOTALS:| 10 | 10 | | 0| | 0 | | 70 | | 0| ----------------------------------------------------------------------------------- -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
ndcontrol manager restart Reiniciando el gestor para actualizar códigoEste mandato produce una salida similar a la siguiente:
320-14:04:54 Reiniciando el gestor para actualizar código
ndcontrol manager sensitivity 10
ndcontrol manager smoothing 2.0
ndcontrol manager start ndmgr.log
ndcontrol manager statusEste mandato produce una salida similar al ejemplo siguiente:
Manager status: ============= Metric port................................... 10,004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 0.05 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7
ndcontrol manager stop
ndcontrol manager quiesce 130.40.52.153 now
ndcontrol manager quiesce 130.40.52.153
ndcontrol manager unquiesce 130.40.52.153
ndcontrol manager version
>>-ndcontrol--metric--+-add--cluster+c2+...+cN:métrica+métrica1+...+métricaN-----+->< +-remove--cluster+c2+...+cN:métrica+métrica1+...+métricaN--+ +-proportions--cluster+c2+...+cN prop1 prop2 prop3...propN-+ '-status--cluster+c2+...+cN:métrica+métrica1+...+métricaN--'
Nota: para Cisco Consultant, la dirección de cluster corresponde la dirección IP virtual (dirección VIP) de la norma de contenido del propietario en la configuración de Cisco CSS Switch.
Ejemplos
sscontrol metric add site1:metric1
sscontrol metric proportions site1 0 100
sscontrol metric status sitio1:métrica1Este mandato produce una salida similar a la siguiente:
Metric Status: ------------ Cluster ....................... 10.10.10.20 Metric name ................... metric1 Metric proportion ............. 50 Server .................... plm3 Metric data ............... -1
>>-ndcontrol--puerto--+-add--cluster:puerto--+-----------------------+-+->< | +-crossport--otropuerto-+ | | +-maxservers--tamaño----+ | | +-stickymask--valor-----+ | | +-stickytime--tiempo----+ | | +-method--tipo----------+ | | +-staletimeout--valor---+ | | +-weightbound--peso-----+ | | +-porttype--tipo--------+ | | '-protocol--tipo--------' | +-set--cluster:puerto--+-crossport--otropuerto-+-+ | +-maxservers--tamaño----+ | | +-stickymask--valor-----+ | | +-stickytime--tiempo----+ | | +-staletimeout--valor---+ | | +-weightbound--peso-----+ | | +-porttype--tipo--------+ | | '-maxhalfopen--valor----' | +-remove--cluster:puerto-------------------------+ +-report--cluster:puerto-------------------------+ +-status--cluster:puerto-------------------------+ '-halfopenaddressreport--cluster:puerto----------'
En Windows, esto significa que debe estar en la configuración de red de Windows. No basta con el mandato cluster configure porque sólo simula el alias de IP y el proxy no puede vincularse con este IP falso. Para los otros sistemas operativos, el mandato cluster configure es adecuado porque utiliza ifconfig para crear el alias del IP.
Para suprimir la afinidad entre puertos, vuelva a establecer el valor crossport a su propio número de puerto. Para obtener más información sobre la afinidad entre puertos, consulte Afinidad entre puertos.
Para el componente Dispatcher:
Para el componente CBR: Si establece para stickytime del puerto un valor distinto de cero, el tipo de afinidad de la norma debe ser ninguno (valor por omisión). La afinidad basada en normas (cookie pasiva, URI, cookie activa) no puede coexistir cuando stickytime está establecido en el puerto.
Un valor positivo indica que se comprobará si el número actual de conexiones semiabiertas excede el valor umbral. Si el valor actual es mayor que el umbral, se invoca un script de alerta. En Detección de ataques de denegación de servicio hallará más información.
Ejemplos
ndcontrol port add 130.40.52.153:80+23
ndcontrol port set 130.40.52.153:0
mlcontrol port add 9.37.60.91:20 protocol pop3
ndcontrol port set 130.40.52.153:80 weightbound 10
ndcontrol port set 130.40.52.153:80+23 stickytime 60
ndcontrol port set 130.40.52.153:80 crossport 23
ndcontrol port remove 130.40.52.153:23
ndcontrol port status 9.67.131.153:80Este mandato produce una salida similar a la siguiente:
Port Status: ------------ Port number .................... 80 Cluster address ................ 9.67.131.153 Number of servers .............. 2 Stale timeout .................. 30 Weight bound ................... 20 Maximum number of servers ...... 32 Sticky time .................... 0 Port type ...................... tcp/udp Forwarding method .............. MAC Based Forwarding Sticky mask bits ............... 32 Cross Port Affinity ............ 80 Max Half Open Connections ...... 0
ndcontrol port halfopenaddressreport 9.67.127.121:80Este mandato produce una salida similar a la siguiente:
Half open connection report successfully created: ------------ Half Open Address Report for cluster:port = 9.67.127.121:80 Total addresses with half open connections reported ... 0 Total number of half open connections reported ........ 0 Largest number of half open connections reported ...... 0 Average number of half open connections reported ...... 0 Average half open connection time (seconds) reported .. 0 Total half open connections received .................. 0
>>-ndcontrol--rule--+-add--cluster:puerto:norma--type--tipo--| opciones |-+->< +-dropserver--cluster:puerto:norma--servidor----------+ +-remove--cluster:puerto:norma------------------------+ +-report--cluster:puerto:norma------------------------+ +-set--cluster:puerto:norma--| opciones |-------------+ +-status--cluster:puerto:norma------------------------+ '-useserver--cluster:puerto:norma--servidor+s2+...----' opciones |--+----------------------------------+-------------------------| +-beginrange--bajo--endrange--alto-+ +-priority--nivel------------------+ +-pattern=--patrón-----------------+ +-tos--valor-----------------------+ +-stickytime--tiempo---------------+ +-affinity--tipo_afinidad----------+ +-cookiename--valor----------------+ +-evaluate--nivel------------------+ '-sharelevel--nivel----------------'
En Afinidad activa de cookie hallará más información.
El tipo de afinidad "activecookie" permite repartir el tráfico Web con afinidad por el mismo servidor basándose en los cookies generados por Network Dispatcher.
El tipo de afinidad "passivecookie" permite repartir el tráfico Web con afinidad por el mismo servidor basándose en los cookies autodefinidos generados por los servidores. Debe utilizarse el parámetro cookiename junto con la afinidad pasiva de cookie.
La afinidad de tipo URI le permite repartir el tráfico Web hacia servidores caching-proxy y aumentar de forma efectiva el tamaño de la antememoria.
Consulte la sección Afinidad activa de cookie, la sección Afinidad pasiva de cookie y la sección Afinidad de URI para obtener más información.
En Afinidad pasiva de cookie hallará más información.
O bien, si ha utilizado el particionamiento de servidores, utilice el nombre exclusivo del servidor lógico. En Particionamiento del servidor: servidores lógicos configurados para un solo servidor físico (dirección IP) hallará más información.
Ejemplos
ndcontrol rule add 9.37.67.100:80:trule type true priority 100
ndcontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
ndcontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 ndcontrol rule useserver cluster1:80:timerule server05
ndcontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
ndcontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
ndcontrol cluster set 9.67.131.153 sharedbandwidth 200 ndcontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-ndcontrol--server--+-add--cluster:puerto:servidor--+------------------------------------+-+->< | +-address--dirección-----------------+ | | +-collocated--valor------------------+ | | +-sticky--valor----------------------+ | | +-weight--valor----------------------+ | | +-fixedweight--valor-----------------+ | | +-mapport--valor_puerto--------------+ | | +-router--dirección------------------+ | | +-cookievalue--valor-----------------+ | | +-returnaddress--dirección-----------+ | | +-advisorrequest--cadena_caracteres--+ | | '-advisorresponse--cadena_caracteres-' | +-set--cluster:puerto:servidor--+-collocated--valor------------------+-+ | +-sticky--valor----------------------+ | | +-weight--valor----------------------+ | | +-fixedweight--valor-----------------+ | | +-router--dirección------------------+ | | +-cookievalue--valor-----------------+ | | +-advisorrequest--cadena_caracteres--+ | | '-advisorresponse--cadena_caracteres-' | +-down--cluster:puerto:servidor----------------------------------------+ +-remove--cluster:puerto:servidor--------------------------------------+ +-report--cluster:puerto:servidor--------------------------------------+ +-up--cluster:puerto:servidor------------------------------------------+ '-status--cluster:puerto:servidor--------------------------------------'
O bien, si utiliza un nombre exclusivo que no da lugar a una dirección IP, debe proporcionar el parámetro address en el mandato ndcontrol server add. En Particionamiento del servidor: servidores lógicos configurados para un solo servidor físico (dirección IP) hallará más información.
Ejemplos
ndcontrol server add 130.40.52.153:80:27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 sticky no
ndcontrol server down 130.40.52.153:80:27.65.89.42
ndcontrol server remove ::27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
ndcontrol server set 130.40.52.153:80:27.65.89.42 weight 10
ndcontrol server up 130.40.52.153:80:27.65.89.42
ndcontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
ndcontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/2.0\""
>>-ndcontrol--set--+-loglevel--nivel--------+------------------>< +-logsize--+-unlimited-+-+ | '-tamaño----' | '-logstatus--------------'
>>-ndcontrol--status-------------------------------------------><
Ejemplos
ndcontrol statusEste mandato produce una salida similar a la siguiente:
Executor has been started. Manager has been started. -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
>>-ndcontrol--subagent--+-loglevel--nivel-------------------------------------+->< +-logsize--+-bytes-----+------------------------------+ | '-unlimited-' | +-report----------------------------------------------+ +-start--+------------------------------------------+-+ | '-nombre_comunidad--archivo de anotaciones-' | +-status----------------------------------------------+ +-stop------------------------------------------------+ '-version---------------------------------------------'
Ejemplos
ndcontrol subagent start bigguy bigguy.log
Este apéndice describe cómo utilizar la sintaxis de norma de contenido (patrón) para el componente CBR y el método de envío cbr del componente Dispatcher, junto con escenarios y ejemplos de su uso.
Sólo es aplicable si ha seleccionado "content" para el tipo de norma.
Entre la sintaxis del patrón que desea utilizar, siguiendo las siguientes restricciones
Las palabras clave reservadas van siempre seguidas por un signo igual ("=").
Un navegador que apunte a http://www.company.com/path/webpage.htm puede producir valores tales como:
Method=GET URI=/path/webpage.htm Version=/HTTP/1.1 Host=www.company.com Connection=Keep-Alive Referer=http://www.company.com/path/parentwebpage.htm
Por ejemplo, el siguiente mandato sólo es válido cuando se utiliza el indicador cbrcontrol>>.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern client=181.0.153.222&uri=http://10.1.203.4/nipoek/*
Cuando se utilizan caracteres especiales, para que este mismo mandato funcione en el indicador del sistema operativo se debe encerrar el patrón entre dobles comillas (" ") del siguiente modo:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "client=181.0.153.222&uri=http://10.1.203.4/nipoek/*"
Si no se utilizan las comillas, puede truncarse parte del patrón cuando se guarde la norma en CBR. Tenga en cuenta que las comillas no están soportadas cuando se utiliza el indicador de mandatos cbrcontrol>>.
A continuación siguen varios casos prácticos y ejemplos sobre la utilización de sintaxis de patrones
Caso 1:
La instalación para un solo nombre de cluster comprende un grupo de servidores Web para contenido HTML estándar, otro grupo de servidores Web con WebSphere Application Server para peticiones de servlet, otro grupo de servidores Lotus Notes para archivos NSF, etc. Es necesario el acceso a los datos del cliente para diferenciar entre esas páginas solicitadas. También es necesario enviarlas a los servidores apropiados. Las normas para la comparación de patrones de contenido proporcionan la separación necesaria para realizar esas tareas. Se configuran una serie de normas para que se produzca automáticamente la separación necesaria de las peticiones. Por ejemplo, los mandatos siguientes llevan a cabo las tres separaciones mencionadas:
>>rule add cluster1:80:servlets type content pattern uri=*/servlet/*priority 1 >>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern uri=*.nsf* priority 2 >>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3 >>rule uses cluster1:80:regular server5+server6
Si Network Dispatcher recibe una petición para un archivo NSF, se prueba primero la norma para servlets, pero no se produce coincidencia. Luego la petición se prueba con la norma de notes y se obtiene una coincidencia. El tráfico del cliente se reparte entre server3 y server4.
Caso 2
Otro caso habitual es aquél en el que el sitio Web principal controla varios grupos internos diferenciados. Por ejemplo, www.company.com/software comprende un grupo de servidores y contenido que son diferentes de la división www.company.com/hardware. Debido a que las peticiones están todas basadas en el cluster raíz www.company.com, son necesarias normas de contenido para encontrar las diferencias de URI y efectuar el reparto del tráfico. La norma de este caso práctico tiene este aspecto:
>>rule add cluster1:80:div1 type content pattern uri=/software/* priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern uri=/hardware/* priority 2 >>rule uses cluster1:80:div2 server3+server4
Caso 3
Determinadas combinaciones son sensibles al orden en el que se buscan las normas. Por ejemplo, en el Caso 2, los clientes se repartieron de acuerdo con un directorio existente en la ruta de la petición; pero el directorio de destino puede aparecer en varios niveles de la ruta y tener significados diferentes según la ubicación. Por ejemplo, www.company.com/pcs/fixes/software representa un destino diferente que www.company.com/mainframe/fixes/software. Las normas se deben definir teniendo en cuenta esta posibilidad y no pretender abarcar demasiados casos al mismo tiempo. Por ejemplo, la especificación "uri=*/software/*" es una búsqueda general demasiado amplia en este caso. Se podrían estructurar normas alternativas de la manera indicada a continuación:
La siguiente búsqueda de combinación puede limitar el ámbito de la búsqueda:
>>rule add cluster1:80:pcs type content pattern (uri=/pcs/*)&(uri=*/software/*) >>rule uses cluster 1:80:pcs server1
Cuando no hay combinaciones para utilizar, el orden se convierte en una cuestión importante:
>>rule add cluster1:80:pc1 type content pattern uri=/pcs/* >>rule uses cluster1:80:pc1 server2
La segunda norma se aplica cuando "pcs" aparece en lugares posteriores de la ruta de directorios en lugar de aparecer en primer lugar.
>>rule add cluster1:80:pc2 type content pattern uri=/*/pcs/* >>rule uses cluster1:80:pc2 server3
En la mayoría de los casos, es conveniente finalizar las normas con una norma siempre cierto para abarcar las situaciones no cubiertas por las demás normas. Esto también puede adoptar la forma de una respuesta del tipo "El sitio Web está actualmente fuera de servicio; pruebe más tarde", cuando todos los demás servidores no atienden la petición del cliente.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5
Este apéndice describe cómo utilizar los siguientes mandatos sscontrol de Site Selector:
Puede especificar una versión abreviada de los parámetros de los mandatos sscontrol. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede entrar sscontrol he f en lugar de sscontrol help file.
>>-sscontrol--advisor--+-connecttimeout--nombre--+-puerto-------------+--segundos----------+->< | '-nombresitio:puerto-' | +-interval--nombre--+-puerto-------------+--segundos----------------+ | '-nombresitio:puerto-' | +-list--------------------------------------------------------------+ +-loglevel--nombre--+-puerto-------------+--nivel-------------------+ | '-nombresitio:puerto-' | +-logsize--nombre--+-puerto-------------+--+-size | unlimited-+-----+ | '-nombresitio:puerto-' '-bytes------------' | +-receivetimeout--nombre--+-puerto-------------+--segundos----------+ | '-nombresitio:puerto-' | +-report--nombre--+-puerto-------------+----------------------------+ | '-nombresitio:puerto-' | +-start--nombre--+-puerto-------------+--+------------------------+-+ | '-nombresitio:puerto-' '-archivo de anotaciones-' | +-status--nombre--+-puerto-------------+----------------------------+ | '-nombresitio:puerto-' | +-stop--nombre--+-puerto-------------+------------------------------+ | '-nombresitio:puerto-' | +-timeout--nombre--+-puerto-------------+---------------------------+ | '-nombresitio:puerto-' | '-version--nombre--+-puerto-------------+--segundos-----------------' '-nombresitio:puerto-'
.
Nombre de asesor | Protocolo | Puerto |
---|---|---|
Connect | n/d | definido por el usuario |
db2 | privado | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
PING | PING | 0 |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
El archivo por omisión es nombreasesor_puerto .log, por ejemplo, http_80.log. Para cambiar el directorio donde se guardan los archivos de anotaciones, consulte Cambio de la vía de acceso de los archivos de anotaciones.
Puede iniciar un solo asesor para cada nombresitio.
Ejemplos
sscontrol advisor connecttimeout http 80 30
sscontrol advisor interval ftp 21 6
sscontrol advisor listEste mandato produce una salida similar a la siguiente:
--------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | --------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
sscontrol advisor loglevel http mysite:80 0
sscontrol advisor logsize ftp mysite:21 5000
sscontrol advisor receivetimeout http 80 60
sscontrol advisor report ftp 21Este mandato produce una salida similar a la siguiente:
Advisor Report: --------------- Advisor name ............. http Port number .............. 80 sitename ................. mySite Server address ........... 9.67.129.230 Load ..................... 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80Este mandato produce una salida similar a la siguiente:
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited
sscontrol advisor stop http 80
sscontrol advisor timeout ftp 21 5
sscontrol advisor version ssl 443
>>-sscontrol--file--+-delete--nombre_archivo.ext----------+---->< +-appendload--nombre_archivo.ext------+ +-report------------------------------+ +-save--nombre_archivo.ext--+-------+-+ | '-force-' | '-newload--nombre_archivo.ext---------'
La extensión del archivo (.ext) puede ser cualquiera que elija el usuario y es opcional.
Vía de acceso común de directorio de instalación -- c:\Archivos de programa\ibm\edge\nd\servers\configurations\componente
Vía de acceso nativa de directorio de instalación -- c:\Archivos de programa\ibm\nd\servers\configurations\componente
Ejemplos
sscontrol file delete file3 Se ha suprimido el archivo (file3).
sscontrol file newload file1.sv Se ha cargado el archivo (file1.sv) en Dispatcher.
sscontrol file appendload file2.sv Se ha añadido el archivo (file2.sv) a la configuración actual y se ha cargado.
sscontrol file report FILE REPORT: file1.save file2.sv file3
sscontrol file save file3 La configuración se ha guardado en el archivo (file3).
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-manager----+ +-metric-----+ +-nameserver-+ +-rule-------+ +-server-----+ +-set--------+ +-sitename---+ '-status-----'
Ejemplos
sscontrol helpEste mandato produce una salida similar a la siguiente:
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help name help - print complete help text advisor - help on advisor command file - help on file command host - help on host command manager - help on manager command metric - help on metric command sitename - help on sitename command nameserver - help on nameserver command rule - help on rule command server - help on server command set - help on set command status - help on status commandLos parámetros especificados dentro de < > son variables.
logsize <número de bytes | unlimited> -Establece el número máximo de bytes que se registrarán en el archivo de anotaciones.
>>-sscontrol--manager--+-interval--segundos--------------------------------+->< +-loglevel--nivel-----------------------------------+ +-logsize--+-size | unlimited-+---------------------+ | '-bytes------------' | +-reach set--+-interval-segundos----------+---------+ | '-+-loglevel-nivel---------+-' | | '---tamaño | unlimited---' | +-report--nombresitio+ns2+...+nsN-------------------+ +-restart--mensaje----------------------------------+ +-sensitivity--peso---------------------------------+ +-smoothing--índice de suavizado--------------------+ +-start--+----------------------------------------+-+ | '-archivo de anotaciones--puerto_métrica-' | +-status--------------------------------------------+ +-stop----------------------------------------------+ '-version-------------------------------------------'
El archivo por omisión se instala en el directorio logs. Consulte Apéndice F, Ejemplos de archivos de configuración. Para cambiar el directorio donde se guardarán los archivos de anotaciones, consulte Cambio de la vía de acceso de los archivos de anotaciones.
Ejemplos
sscontrol manager interval 5
sscontrol manager loglevel 0
sscontrol manager logsize 1000000
sscontrol manager reportEste mandato produce una salida similar a la siguiente:
---------------------------------- | SERVER | STATUS | ---------------------------------- | 9.67.129.221| ACTIVE| | 9.67.129.213| ACTIVE| | 9.67.134.223| ACTIVE| ---------------------------------- -------------------------- | MANAGER REPORT LEGEND | -------------------------- | CPU | CPU Load | | MEM | Memory Load | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | -------------------------- ------------------------------------------------------------------------ | mySite | WEIGHT | CPU 49% | MEM 50% | PORT 1% | SYS 0% | ------------------------------------------------------------------------ | |NOW NEW | WT LOAD | WT LOAD | WT LOAD | WT LOAD | ------------------------------------------------------------------------ | 9.37.56.180 | 10 10 |-99 -1|-99 -1|-99 -1| 0 0| ------------------------------------------------------------------------ | TOTALS:| 10 10 | -1| -1| -1| 0| ------------------------------------------------------------------------ ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ----------------------------------------- | http | 80 | unlimited | -----------------------------------------
sscontrol manager restart Restarting the manager to update codeEste mandato produce una salida similar a la siguiente:
320-14:04:54 Reiniciando el gestor para actualizar código
sscontrol manager sensitivity 10
sscontrol manager smoothing 2.0
sscontrol manager start ndmgr.log
sscontrol manager statusEste mandato produce una salida similar al ejemplo siguiente:
Manager status: ============= Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 5 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--nombresitio+ns2+...+nsN:métrica+métrica1+...+métricaN-----+->< +-remove--nombresitio+ns2+...+nsN:métrica+métrica1+...+métricaN--+ +-proportions--nombresitio+ns2+...+nsN:prop1 prop2 prop3...propN-+ '-status--nombresitio+ns2+...+nsN métrica+métrica1+...+métricaN--'
Ejemplos
sscontrol metric add site1:metric1
sscontrol metric proportions site1 0 100
sscontrol metric status site1:metric1Este mandato produce una salida similar a la siguiente:
Metric Status: ------------ sitename ..................... site1 Metric name ................... metric1 Metric proportion ............. 50 Server ......... 9.37.56.100 Metric data .... -1
>>-sscontrol--nameserver--+-start--+------------------------+-+->< | '-bindaddress--dirección-' | +-stop------------------------------+ '-status----------------------------'
>>-sscontrol--rule--+-add--nombresitio+ns2+...+nsN:norma+n2+...+nN--type--valor--| valor |--| opciones |-+->< +-dropserver--nombresitio+ns2+...+nsN:norma+n2+...+nN--servidor+s2+...+nsN-----------+ +-remove--nombresitio+ns2+...+nsN:norma+n2+...+nN------------------------------------+ +-set--nombresitio+ns2+...+nsN:norma+n2+...+nN--| valor |--| opciones |--------------+ +-status--nombresitio+ns2+...+nsN:norma+n2+...+nN------------------------------------+ '-useserver--nombresitio+ns2+...+nsN:norma+n2+...+nN--servidor+s2+...+nsN------------' opciones |--+----------------------------------+-------------------------| +-beginrange--bajo--endrange--alto-+ +-priority--valor------------------+ '-metricname--valor----------------'
Ejemplos
sscontrol rule add nombresitio:nombrenorma type true priority 100
sscontrol rule add nombresitio:nombrenorma type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add nombresitio:nombrenorma type time beginrange 11 endrange 14 sscontrol rule useserver nombresitio:nombrenorma server05
>>-sscontrol--server--+-add--nombresitio+ns2+...+nsN:servidor+s2+...+sN--+--------------------------+-+->< | +-metricaddress--dirección-+ | | '-weight--valor------------' | +-down--nombresitio+ns2+...+nsN:servidor+s2+...+sN------------------------------+ +-remove--nombresitio+ns2+...+nsN:servidor+s2+...+sN----------------------------+ +-set--nombresitio+ns2+...+nsN:servidor+s2+...+sN--+--------------------------+-+ | +-metricaddress--dirección-+ | | '-weight--valor------------' | +-status--nombresitio+ns2+...+nsN:servidor+s2+...+sN----------------------------+ '-up--nombresitio+ns2+...+nsN:servidor+s2+...+sN--------------------------------'
Ejemplos
sscontrol server add site1:27.65.89.42
sscontrol server down site1:27.65.89.42
sscontrol server remove :27.65.89.42
sscontrol server up site1:27.65.89.42
>>-sscontrol--set--+-loglevel--nivel--------+------------------>< +-logsize--+-unlimited-+-+ | '-tamaño----' | '-logstatus--------------'
>>-sscontrol--sitename--+-add--nombresitio+ns2+...+nsN--+--------------------------------------------+-+->< | +-cachelife--valor---------------------------+ | | +-networkproximity--sí | no------------------+ | | +-proportions--cpu--memoria--puerto--métrica-+ | | +-proximitypercentage--valor-----------------+ | | +-stickytime--tiempo-------------------------+ | | +-ttl--tiempo--------------------------------+ | | +-waitforallresponses--sí | no---------------+ | | '-weightbound--peso--------------------------' | +-remove--nombresitio+ns2+...+nsN----------------------------------------------+ +-set--nombresitio+ns2+...+nsN--+--------------------------------------------+-+ | +-cachelife--valor---------------------------+ | | +-networkproximity--sí | no------------------+ | | +-proportions--cpu--memoria--puerto--métrica-+ | | +-proximitypercentage--valor-----------------+ | | +-stickytime--tiempo-------------------------+ | | +-ttl--tiempo--------------------------------+ | | +-waitforallresponses--sí | no---------------+ | | '-weightbound--peso--------------------------' | '-status--nombresitio+ns2+...+nsN----------------------------------------------'
Ejemplos
sscontrol sitename add 130.40.52.153
sscontrol sitename set mySite networkproximity yes
sscontrol sitename set mySite cachelife 1900000
sscontrol sitename set mySite proximitypercentage 45
sscontrol sitename set mySite waitforallresponses no
sscontrol sitename set mySite ttl 7
sscontrol sitename set mySite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status mySiteEste mandato produce una salida similar a la siguiente:
SiteName Status: --------------- SiteName ........................... mySite WeightBound ........................ 20 TTL ................................ 5 StickyTime ......................... 0 Number of Servers .................. 1 Proportion given to CpuLoad ........ 49 Proportion given to MemLoad ........ 50 Proportion given to Port ........... 1 Proportion given to System metric .. 0 Advisor running on port ............ 80 Using Proximity .................... N
>>-sscontrol--status-------------------------------------------><
Ejemplos
sscontrol statusEste mandato produce una salida similar a la siguiente:
NameServer has been started. Manager has been started. ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
Este apéndice describe cómo utilizar los siguientes mandatos lbccontrol para Consultant para Cisco CSS Switches:
Puede especificar una versión abreviada de los parámetros de los mandatos ndcontrol. Sólo necesita especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato "file save", puede entrar lbccontrol he f en lugar de lbccontrol help file.
El prefijo "lbc" significa "load-balancing consultant" (asesor de reparto del tráfico).
>>-lbccontrol--asesor--+-connecttimeout--nombre--+-puerto---------+--segundos_inactividad-+->< | '-cluster:puerto-' | +-interval--nombre--+-puerto---------+--segundos-------------------+ | '-cluster:puerto-' | +-list-------------------------------------------------------------+ +-loglevel--nombre--+-puerto---------+--nivel----------------------+ | '-cluster:puerto-' | +-logsize--+-puerto---------+--puerto--+-size | unlimited-+--------+ | '-cluster:puerto-' '-bytes------------' | +-receivetimeout--nombre--+-puerto---------+--segundos_inactividad-+ | '-cluster:puerto-' | +-report--nombre--+-puerto---------+-------------------------------+ | '-cluster:puerto-' | +-start--nombre--+-puerto---------+--+------------------------+----+ | '-cluster:puerto-' '-archivo de anotaciones-' | +-status--nombre--+-puerto---------+-------------------------------+ | '-cluster:puerto-' | +-stop--nombre--+-puerto---------+---------------------------------+ | '-cluster:puerto-' | +-timeout--nombre--+-puerto---------+--+-seconds | unlimited-+-----+ | '-cluster:puerto-' '-segundos------------' | '-version--nombre--+-puerto---------+------------------------------' '-cluster:puerto-'
Nombre de asesor | Protocolo | Puerto |
---|---|---|
connect | ICMP | 12345 |
db2 | privado | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
ibmproxy | HTTP (a través de Caching Proxy) | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | privado | 10007 |
El archivo por omisión es nombreasesor_puerto .log, por ejemplo, http_80.log. Para cambiar el directorio en el que se conservarán los archivos de anotaciones, consulte Cambio de la vía de acceso de los archivos de anotaciones.
Establezca las proporciones del gestor de modo que se utilice la información del asesor.
Ejemplos
lbccontrol advisor connecttimeout http 80 30
lbccontrol advisor interval ftp 21 6
lbccontrol advisor listEste mandato produce una salida similar a la siguiente:
------------------------------ | ADVISOR | PORT | TIMEOUT | ------------------------------ | http | 80 | unlimited | | ftp | 21 | unlimited | ------------------------------
lbccontrol advisor loglevel http 80 0
lbccontrol advisor logsize ftp 21 5000
lbccontrol advisor receivetimeout http 80 60
lbccontrol advisor report ftp 21Este mandato produce una salida similar a la siguiente:
Advisor Report: --------------- Advisor name ............. Ftp Port number .............. 21 Cluster address .......... 9.67.131.18 Server address ........... 9.67.129.230 Load ..................... 8 Cluster address .......... 9.67.131.18 Server address ........... 9.67.131.215 Load ..................... -1
lbccontrol advisor start ftp 21 ftpadv.log
lbccontrol advisor status http 80Este mandato produce una salida similar a la siguiente:
Advisor Status: --------------- Interval (seconds) ............ 15 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited
lbccontrol advisor stop http 80
lbccontrol advisor timeout ftp 21 5
lbccontrol advisor version ssl 443
>>-lbccontrol--cluster--+-add--cluster+c2+...--+-proportions--activas--nuevas--puerto--sistema-+-+->< | '-weightbound--peso-----------------------------' | +-set--cluster+c2+...--+-proportions--activas--nuevas--puerto--sistema-+-+ | '-weightbound--peso-----------------------------' | +-remove--cluster--------------------------------------------------------+ '-status--cluster--------------------------------------------------------'
Ejemplos
lbccontrol cluster add 130.40.52.153
lbccontrol cluster remove 130.40.52.153
lbccontrol cluster proportions 60 35 5 0
lbccontrol cluster status 9.67.131.167Este mandato produce una salida similar a la siguiente:
Cluster Status: --------------- Address ................................. 9.67.131.167 Number of target ports .................. 3 Default port weight bound ............... 10 Proportion given to active connections .. 49 Proportion given to new connections ..... 49 Proportion given specific to the port ... 2 Proportion given to system metrics ...... 0
>>-lbccontrol--executor--+-set--+-address--valor-------+-+----->< | +-communityname--valor-+ | | +-timeout--valor-------+ | | '-retries--valor-------' | '-status------------------------'
Ejemplos
lbccontrol executor status Executor Status: ---------------- address ............................. 9.67.131.151 community name ...................... public timeout value ....................... 3 retires value ....................... 2
lbccontrol executor set address 130.40.52.167
>>-lbccontrol--file--+-delete--nombre_archivo.ext-------------+->< +-appendload--nombre_archivo.ext---------+ +-report---------------------------------+ +-save--nombre_archivo.ext--force--------+ '-newload--nombre_archivo.ext--+-------+-' '-force-'
La extensión del archivo (.ext) puede ser cualquiera que elija el usuario y es opcional.
Vía de acceso común de directorio de instalación -- c:\Archivos de programa\ibm\edge\nd\servers\configurations\componente
Vía de acceso nativa de directorio de instalación -- c:\Archivos de programa\ibm\nd\servers\configurations\componente
Ejemplos
lbccontrol file delete file3 Se ha suprimido el archivo (file3).
lbccontrol file newload file1.sv Se ha cargado el archivo (archivo1.sv) en Dispatcher.
lbccontrol file appendload file2.sv Se ha añadido el archivo (file2.sv) a la configuración actual y se ha cargado.
lbccontrol file report FILE REPORT: file1.save file2.sv file3
lbccontrol file save file3 La configuración se ha guardado en el archivo (file3).
>>-lbccontrol--help--+-advisor--+------------------------------>< +-cluster--+ +-executor-+ +-file-----+ +-help-----+ +-host-----+ +-log------+ +-manager--+ +-metric---+ +-puerto---+ +-server---+ +-set------+ '-status---'
Ejemplos
lbccontrol helpEste mandato produce una salida similar a la siguiente:
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help cluster executor - help on executor command cluster - help on cluster command port - help on port command server - help on server command manager - help on manager command metric - help on metric command advisor - help on advisor command file - help on file command host - help on host command log - help on log command set - help on set command status - help on status command help - print complete help textLos parámetros especificados dentro de < > son variables.
>>-lbccontrol--host:--sispral_remoto---------------------------><
lbccontrol host:sispral_remoto
Emita este mandato desde un indicador de mandatos, y luego escriba cualquier mandato lbccontrol válido que desee emitir para la máquina Cisco Consultant remota.
>>-lbccontrol--log--+-start-----------------------+------------>< +-stop------------------------+ +-set--+-retention--horas---+-+ | '-interval--segundos-' | '-status----------------------'
>>-lbccontrol--manager--+-interval--segundos------------------------------------+->< +-loglevel--nivel---------------------------------------+ +-logsize--+-size | unlimited-+-------------------------+ | '-bytes------------' | +-quiesce--servidor--+-----+----------------------------+ | '-now-' | +-reach set--+-interval--segundos----------+------------+ | +-loglevel--nivel-------------+ | | '-logsize--tamaño | unlimited-' | +-refresh--ciclo renovación-----------------------------+ +-report--+----------------+----------------------------+ | '-cluster+c2+...-' | +-restart--mensaje--------------------------------------+ +-sensitivity--peso-------------------------------------+ +-smoothing--valor--------------------------------------+ +-start--+--------------------------------------------+-+ | '-nombre_archivo_anotaciones--puerto_métrica-' | +-status------------------------------------------------+ +-stop--------------------------------------------------+ +-unquiesce--servidor-----------------------------------+ '-version-----------------------------------------------'
El archivo por omisión se instala en el directorio logs. Consulte Apéndice F, Ejemplos de archivos de configuración. Consulte Cambio de la vía de acceso de los archivos de anotaciones para conocer cómo cambiar el directorio donde se guardan los archivos de anotaciones.
Ejemplos
lbccontrol manager interval 5
lbccontrol manager loglevel 0
lbccontrol manager logsize 1000000
lbccontrol manager quiesce 130.40.52.153
lbccontrol manager refresh 3
lbccontrol manager reportEste mandato produce una salida similar a la siguiente:
lbccontrol>>manager report ---------------------------------------- | HOST TABLE LIST | STATUS | ---------------------------------------- | server6| ACTIVE| | server5| ACTIVE| | server4| ACTIVE| | server3| ACTIVE| | server2| ACTIVE| | server1| ACTIVE| ---------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.35 | WEIGHT | ACTIVE % 49 | NEW % 50 | PORT % 1 | SYSTEM % 0 | ------------------------------------------------------------------------------------------------- | PORT: 80 | NOW | NEW | WT | CONNECT | WT | CONNECT | WT | LOAD | WT | LOAD | ------------------------------------------------------------------------------------------------- | server1 | 4 | 4 | 5 | 0 | 5 | 0 | 3| 301| -9999| -1| | server2 | 5 | 5 | 5 | 0 | 5 | 0 | 6| 160| -9999| -1| ------------------------------------------------------------------------------------------------- | PORT TOTALS:| 9 | 9 | | 0 | | 0 | | 461 | | -2 | ------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.35 | WEIGHT | ACTIVE % 49 | NEW % 50 | PORT % 1 | SYSTEM % 0 | ------------------------------------------------------------------------------------------------- | PORT: 443 | NOW | NEW | WT | CONNECT | WT | CONNECT | WT | LOAD | WT | LOAD | ------------------------------------------------------------------------------------------------- | server3 | 4 | 4 | 5 | 0 | 5 | 0 | | 0| -9999| -1| | server4 | 5 | 5 | 5 | 0 | 5 | 0 | 0| 0| -9999| -1| ------------------------------------------------------------------------------------------------- | PORT TOTALS:| 9 | 9 | | 0 | | 0 | | 0 | | -2 | ------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.34 | WEIGHT | ACTIVE % 49 | NEW % 50 | PORT % 1 | SYSTEM % 0 | ------------------------------------------------------------------------------------------------- | PORT: 80 | NOW | NEW | WT | CONNECT | WT | CONNECT | WT | LOAD | WT | LOAD | ------------------------------------------------------------------------------------------------- | server5 | 5 | 5 | 5 | 0 | 5 | 0 | 5| 160| -9999| -1| | server6 | 0 | 0 | 5 | 0 | 5 | 0 | -9999| -1| -9999| -1| ------------------------------------------------------------------------------------------------- | PORT TOTALS:| 5 | 5 | | 0 | | 0 | | 159 | | -2 | ------------------------------------------------------------------------------------------------- -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | http | 80 | unlimited | --------------------------------
lbccontrol manager restart Restarting the manager to update codeEste mandato produce una salida similar a la siguiente:
320-14:04:54 Restarting the manager to update code
lbccontrol manager sensitivity 10
lbccontrol manager smoothing 2.0
lbccontrol manager start ndmgr.log
lbccontrol manager statusEste mandato produce una salida similar al ejemplo siguiente:
Manager status: ============= Metric port .................................. 10004 Manager log filename ......................... manager.log Manager log level ............................ 1 Maximum manager log size (bytes) ............. unlimited Sensitivity level ............................ 0.05 Smoothing index .............................. 1.5 Update interval (seconds) .................... 2 Weights refresh cycle ........................ 1 Reach log level .............................. 1 Maximum reach log size (bytes) ............... unlimited Reach update interval (seconds) .............. 7
lbccontrol manager stop
lbccontrol manager version
>>-lbccontrol--metric--+-add--cluster+c2+...+cN:métrica+métrica1+...+métricaN-----+->< +-remove--cluster+c2+...+cN:métrica+métrica1+...+métricaN--+ +-proportions--cluster+c2+...+cN:prop1 prop2 prop3...propN-+ '-status--cluster+c2+...+cN:métrica+métrica1+...+métricaN--'
Nota: para Cisco Consultant, la dirección de cluster corresponde la dirección IP virtual (dirección VIP) de la norma de contenido del propietario en la configuración de Cisco CSS Switch.
Ejemplos
lbccontrol metric add 10.10.10.20:metric1
lbccontrol metric proportions 10.10.10.20 48 52
lbccontrol metric status 10.10.10.20:metric1Este mandato produce una salida similar a la siguiente:
Metric Status: ------------ Cluster ....................... 10.10.10.20 Metric name ................... metric1 Metric proportion ............. 52 Server ......... 9.37.56.100 Metric data .... -1
>>-lbccontrol--puerto--+-add--cluster:puerto--+-------------------+-+->< | '-weightbound--peso-' | +-set--cluster:puerto--+-------------------+-+ | '-weightbound--peso-' | +-remove--cluster:puerto---------------------+ '-status--cluster:puerto---------------------'
Ejemplos
lbccontrol port add 130.40.52.153:80+23
lbccontrol port set 130.40.52.153:80 weightbound 10
lbccontrol port remove 130.40.52.153:23
lbccontrol port status 9.67.131.153:80Este mandato produce una salida similar a la siguiente:
Port Status: ------------ Port number .................... 80 Cluster address ................ 9.67.131.153 Number of servers .............. 2 Weight bound ................... 10
>>-lbccontrol--server--+-add--cluster:puerto:servidor--+--------------------+-+->< | +-weight--valor------+ | | +-fixedweight--valor-+ | | '-address--dirección-' | +-set--cluster:puerto:servidor--+-weight--valor------+-+ | '-fixedweight--valor-' | +-down--cluster:puerto:servidor------------------------+ +-remove--cluster:puerto:servidor----------------------+ +-report--cluster:puerto:servidor----------------------+ +-up--cluster:puerto:servidor--------------------------+ '-status--cluster:puerto:servidor----------------------'
Ejemplos
lbccontrol server add 130.40.52.153:80:27.65.89.42
lbccontrol server remove ::27.65.89.42
lbccontrol server set 130.40.52.153:80:27.65.89.42 weight 10
>>-lbccontrol--set--+-loglevel--nivel-----+-------------------->< +-logsize--+-size---+-+ | '-tamaño-' | '-logstatus-----------'
>>-lbccontrol--status------------------------------------------><
Ejemplos
lbccontrol statusEste mandato produce una salida similar a la siguiente:
Manager has been started. -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
Este apéndice contiene archivos de configuración de ejemplo para el componente Dispatcher de Network Dispatcher.
Los archivos de ejemplo están situados en el directorio .../nd/servers/samples/.
#!/bin/ksh
#
# configuration.sample - Archivo de configuración de ejemplo para el componente
# Dispatcher
#
#
# Comprobar que es el usuario root quien ejecuta este script.
#
# iam=`whoami`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "Debe iniciar la sesión como usuario root para ejecutar este script"
# exit 2
# fi
#
# Primero se arranca el servidor
#
# ndserver start
# sleep 5
#
# Seguidamente arrancar el ejecutor
#
# ndcontrol executor start
#
# El Dispatcher puede eliminarse en cualquier momento con los mandatos
# "ndcontrol executor stop" y "ndserver stop" para detener el
# ejecutor y el servidor respectivamente antes de eliminar el
# software de Dispatcher.
#
# El siguiente paso de configuración de Dispatcher es definir la
# NFA (dirección de no reenvío) y la dirección o direcciones de cluster.
#
# La dirección de no reenvío se utiliza para acceder de forma remota a la
# máquina Dispatcher con fines de administración o configuración. Dicha
# dirección es necesaria, puesto que Dispatcher reenviará los paquetes
# a la dirección o direcciones de cluster.
#
# La dirección de cluster (CLUSTER) es el nombre del sistema principal
# (o dirección IP) al que se conectarán los clientes remotos.
#
# En cualquier parte de este archivo, puede utilizar nombres de
# sistema principal y direcciones IP indistintamente.
#
# NFA=nombsistprinc.dominio.nombre
# CLUSTER=www.sucompañía.com
# echo "Cargando la dirección de no reenvío"
# ndcontrol executor set nfa $NFA
#
# El siguiente paso en la configuración de Dispatcher es crear
# un cluster. Dispatcher encaminará las peticiones enviadas a la
# dirección de cluster a las máquinas servidor correspondientes
# definidas para ese cluster. Puede configurar y dar servicio a
# varias direcciones de cluster mediante la utilización de Dispatcher.
# Se debe utilizar una configuración similar para CLUSTER2, CLUSTER3, etc.
#
# echo "Cargando la primera dirección de CLUSTER "
# ndcontrol cluster add $CLUSTER
#
# Ahora se deben definir los puertos que utilizará este cluster.
# Las peticiones recibidas por Dispatcher en un puerto definido se
# reenviarán al puerto correspondiente de una de las máquinas
# servidor.
#
# echo "Creando puertos para CLUSTER: $CLUSTER"
# ndcontrol port add $CLUSTER:20+21+80
#
# El último paso consiste en añadir cada máquina servidor a los
# puertos de este cluster.
# De nuevo, puede utilizar el nombre de sistema principal o la dirección IP
# de las máquinas servidor.
#
# SERVER1=nombreserv1.dominio.nombre
# SERVER2=nombreserv2.dominio.nombre
# SERVER3=nombreserv3.dominio.nombre
# echo "Añadiendo máquinas servidor"
# ndcontrol server add $CLUSTER:20+21+80:
# $SERVER1+$SERVER2+$SERVER3
#
# Ahora iniciaremos los componentes de reparto del tráfico de
# Dispatcher. El componente principal de reparto del tráfico se conoce
# como el gestor y los componentes secundarios de reparto del tráfico
# se conocen como asesores.
# Si el gestor y los asesores no se están ejecutando,
# Dispatcher envía peticiones en un formato rotatorio
# ("round-robin"). Una vez que se arranca
# el gestor, se emplean las decisiones sobre el peso según el número de
# conexiones nuevas y activas, y las peticiones entrantes
# se envían al mejor servidor. Los asesores proporcionan al
# gestor más información sobre la capacidad de los servidores de dar servicio a
# peticiones, y detectan si un servidor está activado. Si
# un asesor detecta que un servidor está desactivado, estará marcado
# como inactivo (siempre y cuando las proporciones del gestor se hayan
# establecido para incluir la información del asesor) y no se encaminarán
# más peticiones hacia el servidor.
# El último paso en la configuración de los componentes del reparto
# del tráfico es establecer las proporciones del gestor. Éste actualiza
# el peso de los servidores basándose en cuatro políticas:
# 1. El número de conexiones activas de cada servidor.
# 2. El número de conexiones nuevas a cada servidor.
# 3. La información de entrada procedente de los asesores.
# 4. La información de entrada procedente del asesor a nivel de sistema.
# Estas proporciones deben sumar 100. Por ejemplo,
# si establece las proporciones del gestor mediante
# ndcontrol manager proportions 48 48 4 0
# las conexiones nuevas y activas contribuirán en un 48%
# en la asignación de pesos, los asesores contribuirán en
# en un 4% y la información del sistema no se tendrá en cuenta.
#
# NOTA: Las proporciones por omisión del gestor están
# establecidas en 50 50 0 0
#
# echo "Iniciando el gestor..."
# ndcontrol manager start
# echo "Iniciando el asesor FTP en el puerto 21 ..."
# ndcontrol advisor start ftp 21
# echo "Iniciando el asesor HTTP en el puerto 80 ..."
# ndcontrol advisor start http 80
# echo "Iniciando el asesor Telnet en el puerto 23 ..."
#ndcontrol advisor start telnet 23
# echo "Iniciando el asesor SMTP en el puerto 25 ..."
# ndcontrol advisor start smtp 25
# echo "Iniciando el asesor POP3 en el puerto 110 ..."
# ndcontrol advisor start pop3 110
# echo "Iniciando el asesor NNTP en el puerto 119 ..."
# ndcontrol advisor start nntp 119
# echo "Iniciando el asesor SSL en el puerto 443 ..."
# ndcontrol advisor start ssl 443
#
# echo "Estableciendo las proporciones del gestor..."
# ndcontrol manager proportions 58 40 2 0
#
# El último paso en la configuración de la máquina Dispatcher es asignar
# un alias a la tarjeta de interfaz de red (NIC).
#
# NOTA: NO utilice este mandato en un entorno de alta
# disponibilidad. Los scripts go* configurarán la NIC y el
# bucle de retorno tal como sea necesario.
# ndcontrol cluster configure $CLUSTER
# Si la dirección de cluster está en una subred o NIC diferente de la
# dirección de no reenvío, utilice el siguiente formato para el
# mandato de configuración de cluster.
# ndcontrol cluster configure $CLUSTER tr0 0xfffff800
# donde tr0 es la NIC (tr1 para la segunda tarjeta de Red en Anillo, en0
# para la primera tarjeta Ethernet) y 0xfffff800 es una máscara de
# subred válida para su sitio Web.
#
#
# Los mandatos siguientes están establecidos en sus valores por omisión.
# Utilice estos mandatos como guía para cambiar los valores por omisión.
# ndcontrol manager loglevel 1
# ndcontrol manager logsize 1048576
# ndcontrol manager sensitivity 5,000000
# ndcontrol manager interval 2
# ndcontrol manager refresh 2
#
# ndcontrol advisor interval ftp 21 5
# ndcontrol advisor loglevel ftp 21 1
# ndcontrol advisor logsize ftp 21 1048576
# ndcontrol advisor timeout ftp 21 unlimited
# ndcontrol advisor interval telnet 23 5
# ndcontrol advisor loglevel telnet 23 1
# ndcontrol advisor logsize telnet 23 1048576
# ndcontrol advisor timeout telnet 23 unlimited
# ndcontrol advisor interval smtp 25 5
# ndcontrol advisor loglevel smtp 25 1
# ndcontrol advisor logsize smtp 25 1048576
# ndcontrol advisor timeout smtp 25 unlimited
# ndcontrol advisor interval http 80 5
# ndcontrol advisor loglevel http 80 1
# ndcontrol advisor logsize http 80 1048576
# ndcontrol advisor timeout http 80 unlimited
# ndcontrol advisor interval pop3 110 5
# ndcontrol advisor loglevel pop3 110 1
# ndcontrol advisor logsize pop3 110 1048576
# ndcontrol advisor timeout pop3 110 unlimited
# ndcontrol advisor interval nntp 119 5
# ndcontrol advisor loglevel nntp 119 1
# ndcontrol advisor logsize nntp 119 1048576
# ndcontrol advisor timeout nntp 119 unlimited
# ndcontrol advisor interval ssl 443 5
# ndcontrol advisor loglevel ssl 443 1
# ndcontrol advisor logsize ssl 443 1048576
# ndcontrol advisor timeout ssl 443 unlimited
#
El siguiente es un archivo de configuración de ejemplo de Network Dispatcher denominado configuration.cmd.sample que se puede utilizar con Windows.
@echo off rem configuration.cmd.sample - Archivo de configuración de ejemplo para rem el componente Dispatcher. rem rem ndserver ha de iniciarse a través de Servicios rem rem rem Seguidamente arrancar el ejecutor rem rem call ndcontrol executor start rem rem El siguiente paso de configuración del Dispatcher es definir la rem dirección de no reenvío (NFA) y la dirección o direcciones rem de cluster. rem rem La dirección de no reenvío se utiliza para acceder de forma rem remota a la máquina Dispatcher para la configuración de la rem administración. Esta dirección es necesaria, puesto que Dispatcher rem reenviará los paquetes a la dirección o direcciones de cluster. rem rem La dirección del cluster (CLUSTER) es el nombre de sistema principal rem (o dirección IP) a la que se conectarán los clientes remotos. rem rem Puede utilizar nombres de sistema principal y direcciones IP rem indistintamente en cualquier parte del archivo. rem NFA=[dirección de no reenvío] rem CLUSTER=[nombre del cluster] rem rem set NFA=nombresistpral.dominio.nombre rem set CLUSTER=www.suempresa.com rem echo "Cargando la dirección de no reenvío" rem call ndcontrol executor set nfa %NFA% rem rem Los mandatos siguientes están establecidos en los valores por omisión. rem Utilícelos para cambiar los valores por omisión rem call ndcontrol executor set fintimeout 30 rem call ndcontrol executor set fincount 4000 rem rem El siguiente paso de configuración del Dispatcher es crear rem un cluster. El Dispatcher encaminará las peticiones enviadas a la rem dirección de cluster a las máquinas servidor correspondientes rem definidas para dicho cluster. Puede configurar y dar servicio a rem varias direcciones de cluster utilizando el Dispatcher. rem Utilice una configuración parecida para un CLUSTER2, CLUSTER3, etc. rem rem echo "Cargando la primera dirección de CLUSTER " rem call ndcontrol cluster add %CLUSTER% rem rem Ahora se deben definir los puertos que utilizará este cluster. Todas rem las peticiones recibidas por Dispatcher en un puerto definido se rem reenviarán al puerto correspondiente rem de una de las máquinas servidor. rem rem echo "Creando puertos para CLUSTER: %CLUSTER%" rem call ndcontrol port add %CLUSTER%:20+21+80 rem rem El último paso consiste en añadir cada máquina servidor a rem los puertos de este cluster. De nuevo, se puede utilizar el nombre rem de sistema principal o la dirección IP de las máquinas servidor. rem rem set SERVER1=nombreservidor1.dominio.nombre rem set SERVER2=nombreservidor2.dominio.nombre rem set SERVER3=nombreservidor3.dominio.nombre rem echo "Añadiendo máquinas servidor" rem call ndcontrol server add %CLUSTER%:20+21+80: rem %SERVER1%+%SERVER2%+%SERVER3% rem rem Ahora, iniciaremos los componentes de reparto del tráfico del rem Dispatcher. El componente principal de reparto del tráfico se llama rem gestor y los componentes secundarios de reparto del tráfico son los rem asesores. Si el gestor y los asesores no se están ejecutando, rem el Dispatcher envía peticiones en un formato rotatorio. rem Una vez iniciado el gestor, se emplean decisiones de peso rem según el número de conexiones nuevas y activas, rem y las peticiones entrantes se envían al mejor rem servidor. Los asesores facilitan al gestor más información rem sobre la capacidad de los servidores para dar servicio a las peticiones rem y detectan si un servidor está activo. Si un asesor detecta rem que un servidor está desactivado, se marcará como desactivado (siempre rem que las proporciones del gestor se hayan definido para incluir rem la entrada del asesor) y no se encaminarán más peticiones al servidor. rem El último paso para configurar los componentes del reparto del rem tráfico es establecer las proporciones del gestor. Éste actualiza rem el peso de cada servidor basándose en cuatro rem políticas: rem 1. El número de conexiones activas de cada servidor rem 2. El número de conexiones nuevas de cada servidor rem 3. La información de entrada procedente de los asesores. rem 4. La información de entrada procedente del asesor a nivel de sistema. rem rem Estas proporciones deben sumar 100. Por ejemplo, rem si establece las proporciones del cluster mediante rem ndcontrol cluster set <cluster> proportions 48 48 4 0 rem las conexiones nuevas y activas contribuirán en un 48% rem en la asignación de pesos, el asesor contribuirá en un 4% rem y la información del sistema no se tendrá en cuenta. rem rem NOTA: Las proporciones por omisión del gestor están rem establecidas en 50 50 0 0 rem echo "Iniciando el gestor..." rem call ndcontrol manager start rem echo "Iniciando el asesor FTP en el puerto 21 ..." rem call ndcontrol advisor start ftp 21 rem echo "Iniciando el asesor HTTP en el puerto 80 ..." rem call ndcontrol advisor start http 80 rem echo "Iniciando el asesor Telnet en el puerto 23..." rem call ndcontrol advisor start telnet 23 rem echo "Iniciando el asesor SMTP en el puerto 25..." rem call ndcontrol advisor start smtp 25 rem echo "Iniciando el asesor POP3 en el puerto 110..." rem call ndcontrol advisor start pop3 110 rem echo "Iniciando el asesor NNTP en el puerto 119..." rem call ndcontrol advisor start nntp 119 rem echo "Iniciando el asesor SSL en el puerto 443..." rem call ndcontrol advisor start ssl 443 rem rem echo "Estableciendo las proporciones del cluster..." rem call ndcontrol cluster set %CLUSTER% proportions 58 40 2 0 rem rem El paso final para configurar la máquina del Dispatcher rem es asignar un alias a la NIC (tarjeta de interfaz de red). rem rem NOTA: NO utilice este mandato en un entorno de alta disponibilidad. rem Los scripts go* configurarán la NIC y el rem bucle de retorno según sea necesario. rem rem ndcontrol cluster configure %CLUSTER% rem Si la dirección de cluster se encuentra en una NIC o subred rem diferentes de la dirección de no reenvío (NFA), utilice el formato rem siguiente para el mandato de configuración del cluster: rem ndcontrol cluster configure %CLUSTER% tr0 0xfffff800 rem donde tr0 es su NIC (tr1 para la segunda tarjeta de Red en Anillo, rem en0 para la primera tarjeta Ethernet) y 0xfffff800 es una rem máscara de subred válida para su sitio Web. rem rem rem Los mandatos siguientes están establecidos en los valores por omisión. rem Utilice estos mandatos como guía para cambiar los valores por omisión. rem call ndcontrol manager loglevel 1 rem call ndcontrol manager logsize 1048576 rem call ndcontrol manager sensitivity 5,000000 rem call ndcontrol manager interval 2 rem call ndcontrol manager refresh 2 rem rem call ndcontrol advisor interval ftp 21 5 rem call ndcontrol advisor loglevel ftp 21 1 rem call ndcontrol advisor logsize ftp 21 1048576 rem call ndcontrol advisor timeout ftp 21 unlimited rem call ndcontrol advisor interval telnet 23 5 rem call ndcontrol advisor loglevel telnet 23 1 rem call ndcontrol advisor logsize telnet 23 1048576 rem call ndcontrol advisor timeout telnet 23 unlimited rem call ndcontrol advisor interval smtp 25 5 rem call ndcontrol advisor loglevel smtp 25 1 rem call ndcontrol advisor logsize smtp 25 1048576 rem call ndcontrol advisor timeout smtp 25 unlimited rem call ndcontrol advisor interval http 80 5 rem call ndcontrol advisor loglevel http 80 1 rem call ndcontrol advisor logsize http 80 1048576 rem call ndcontrol advisor timeout http 80 unlimited rem call ndcontrol advisor interval pop3 110 5 rem call ndcontrol advisor loglevel pop3 110 1 rem call ndcontrol advisor logsize pop3 110 1048576 rem call ndcontrol advisor timeout pop3 110 unlimited rem call ndcontrol advisor interval nntp 119 5 rem call ndcontrol advisor loglevel nntp 119 1 rem call ndcontrol advisor logsize nntp 119 1048576 rem call ndcontrol advisor timeout nntp 119 unlimited rem call ndcontrol advisor interval ssl 443 5 rem call ndcontrol advisor loglevel ssl 443 1 rem call ndcontrol advisor logsize ssl 443 1048576 rem call ndcontrol advisor timeout ssl 443 unlimited rem
A continuación se muestra un archivo de asesor de ejemplo llamado ADV_sample.
/**
* ADV_sample: El asesor HTTP de Network Dispatcher
*
*
* Esta clase define un asesor de ejemplo personalizado para Network
* Dispatcher.
* Al igual que todos los asesores, este asesor personalizado amplía la función
* del asesor base, denominado ADV_Base. Es el asesor base el que realmente
* efectúa la mayoría de las funciones del asesor, como informar del tráfico
* a Network Dispatcher para que se utilicen estos datos en el algoritmo
* de peso de Network Dispatcher.
* El asesor base también realiza las operaciones de conexión
* y cierre de socket, además de proporcionar los métodos de envío y recepción
* para que el asesor los utilice.
* El asesor en sí solamente se utiliza para enviar y recibir
* datos hacia y desde el puerto del servidor que se asesora.
* Los métodos TCP incluidos en el asesor base están temporizados para calcular el
* tráfico. Si se desea, un indicador dentro del constructor en el ADV_base
* sobregraba el tráfico existente con el nuevo tráfico devuelto por
* el asesor.
*
* Nota: De acuerdo con un valor establecido en el constructor, la base
* del asesor notifica periódicamente el tráfico al algoritmo de
* ponderación. Si el asesor real no ha finalizado y no puede devolver
* un valor válido de tráfico, la base del asesor utiliza el valor de
* tráfico anterior.
*
* NOMENCLATURA
*
* El convenio de nomenclatura es el siguiente:
*
* - El archivo debe estar situado en los directorios siguientes
* de Network Dispatcher:
*
* nd/servers/lib/CustomAdvisors/
* (nd\servers\lib\CustomAdvisors en Windows 2000)
*
* - El nombre del asesor debe ir precedido de "ADV_". Sin embargo, el
* asesor puede arrancarse simplemente con el nombre; por ejemplo,
* el asesor "ADV_sample" puede arrancarse con "sample".
*
* - El nombre del asesor debe estar en minúsculas.
*
* Por lo tanto, teniendo en cuenta estas normas, este ejemplo
* se identifica de la siguiente manera:
*
* <directorio base>/lib/CustomAdvisors/ADV_sample.class
*
*
* Los asesores, al que el resto de Network Dispatcher, se deben compilar
* con la versión necesaria de Java.
*
* Para asegurar el acceso a las clases de Network Dispatcher,
* la variable CLASSPATH del sistema debe incluir el archivo
* ibmnd.jar (situado en el subdirectorio lib del directorio base)
*
*
* Métodos proporcionados por ADV_Base:
*
* - ADV_Base (Constructor):
*
* - Parámetros
* - String sName = Nombre del asesor
* - String sVersion = Versión del asesor
* - int iDefaultPort = Número de puerto por omisión a asesorar
* - int iInterval = Intervalo durante el cual se asesora a los servidores
* - String sDefaultLogFileName = No utilizado. Debe pasarse como "".
* - boolean replace = True - sustituir el valor de tráfico calculado
* por la base del asesor
* False - añadir al valor de tráfico calculado
* por la base del asesor
* - Retorno
* - Los constructores no tienen valores de retorno.
*
* Debido a que la base del asesor utiliza subprocesos, dispone
* de otros varios métodos que pueden ser utilizados por un asesor. Estos
* métodos se pueden invocar utilizando el parámetro CALLER pasado con
* getLoad().
*
* Estos métodos son los siguientes:
*
* - send - Enviar un paquete de información en la conexión de socket
establecida con el servidor del puerto especificado
* - Parámetros
* - String sDataString - Los datos a enviar se envían en forma
de serie de caracteres
* - Retorno
* - int RC - Indicación de si los datos se enviaron correctamente:
un 0 indica que los datos se enviaron; un entero negativo
* denota un error.
*
* - receive - Recibir información desde la conexión de socket.
* - Parámetros
* - StringBuffer sbDataBuffer - Los datos recibidos durante la
llamada de recepción
* - Retorno
* - int RC - Indicación de si los datos se enviaron correctamente:
un 0 indica que los datos se enviaron; un entero negativo
* denota un error.
*
* Si la función proporcionada por la base del asesor no es
* suficiente, puede crear la función apropiada dentro del asesor y
* no se tendrán en cuenta los métodos proporcionados por la base
* del asesor.
*
* Una cuestión importante relativa al valor de tráfico devuelto
* es si debe aplicarse al valor de tráfico que se está generando en
* la base del asesor o si debe sustituirlo; existen casos válidos de ambas
* situaciones.
*
* Este ejemplo es en esencia el asesor HTTP de Network Dispatcher.
* Funciona de una manera muy simple:
* Se emite una petición de transmisión (una petición de cabecera
* http). Una vez recibida la respuesta, el método getLoad termina y
* marca la base del asesor para detener la temporización de la petición.
* El método entonces se completa. La información devuelta no se analiza;
* el valor de tráfico está basado en el tiempo necesario
* para realizar las operaciones de transmisión y recepción.
*/
package CustomAdvisors;
import com.ibm.internet.nd.advisors.*;
public class ADV_sample extends ADV_Base implements ADV_MethodInterface
{
String COPYRIGHT = "(C) Copyright IBM Corporation 1997,
All Rights Reserved.\n";
static final String ADV_NAME = "Sample";
static final int ADV_DEF_ADV_ON_PORT = 80;
static final int ADV_DEF_INTERVAL = 7;
// Nota: La mayoría de los protocolos de servidor precisan un retorno
// de carro ("\r") y un salto de página ("\n") al final de los mensajes.
// Si es así, inclúyalos aquí.
static final String ADV_SEND_REQUEST =
"HEAD / HTTP/1.0\r\nAccept: */*\r\nUser-Agent: " +
"IBM_Network_Dispatcher_HTTP_Advisor\r\n\r\n";
/**
* Constructor.
*
* Parámetros: ninguno, pero el constructor de ADV_Base tiene varios
* parámetros que se le deben pasar.
*
*/
public ADV_sample()
{
super( ADV_NAME,
"2.0.0.0-03.27.98",
ADV_DEF_ADV_ON_PORT,
ADV_DEF_INTERVAL,
"", // no se utiliza
false);
super.setAdvisor( this );
}
/**
* ADV_AdvisorInitialize
*
* Cualquier inicialización específica del asesor que deba
* efectuarse una vez iniciada la base del asesor.
* Este método se invoca una sola vez y generalmente no se utiliza.
*/
public void ADV_AdvisorInitialize()
{
return;
}
/**
* getLoad()
*
* Este método es invocado por la base del asesor para completar la
* operación del asesor, de acuerdo con datos específicos del protocolo.
* En este asesor de ejemplo, sólo son necesarias una única transmisión
* y recepción; para códigos más complejos, se pueden emitir varias
* operaciones de transmisión y recepción.
*
* Parámetros:
*
* - iConnectTime - El tráfico actual de acuerdo con el período de
* tiempo que fue necesario para establecer la conexión
* con el servidor a través del puerto especificado.
*
* - caller - Una referencia a la clase de la base del asesor en la que
* los métodos proporcionados por Network Dispatcher deben realizar
* peticiones TCP simples, principalmente de transmisión y recepción.
*
* Resultados:
*
* - El tráfico - Un valor, expresado en milisegundos, que se puede
* sumar al valor de tráfico existente o sustituirlo, según determine el
* indicador "replace" del constructor.
*
* Cuanto mayor sea el tráfico, más tiempo necesitará el servidor
* para responder; por lo tanto, mayor será el peso utilizado por
* Network Dispatcher para el reparto del tráfico.
*
* Si el valor es negativo, se supone que se ha producido un error.
* Un error procedente de un asesor indica que el asesor no puede
* acceder al servidor y éste se ha marcado como inactivo.
* Network Dispatcher no intentará repartir el tráfico hacia un
* servidor que esté inactivo.
* Network Dispatcher reanudará el reparto de tráfico hacia el
* servidor cuando se reciba un valor positivo.
*
* Raramente se devuelve un valor 0 de tráfico; Network Dispatcher
* trata esta situación de una forma especial.
* Se considera que el valor 0 indica un estado desconocido y, como
* respuesta, Network Dispatcher otorga al servidor un peso alto.
*/
public int getLoad(int iConnectTime, ADV_Thread caller)
{
int iRc;
int iLoad = ADV_HOST_INACCESSIBLE; // -1
// Enviar petición tcp
iRc = caller.send(ADV_SEND_REQUEST);
if (iRc >= 0)
{
// Realizar una recepción
StringBuffer sbReceiveData = new StringBuffer("");
iRc = caller.receive(sbReceiveData);
// Si la operación de recepción es satisfactoria, se devuelve un valor 0
// de tráfico.
// Esto es debido al valor "false" del indicador "replace",
// que denota que debe utilizarse el valor de tráfico creado dentro de la
// base del asesor.
// Debido a que no se han utilizado los datos devueltos, no es necesario
// un tráfico adicional.
// Nota: Se sabe que el valor de tráfico devuelto por la base del asesor
// no será 0, por lo tanto no se devolverá un tráfico 0
// para calcular el peso.
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // End - ADV_sample
Este apéndice describe cómo realizar una configuración de alta disponibilidad de 2 niveles combinando las funciones de los dos componentes de Network Dispatcher (el componente Dispatcher y el componente CBR) junto con Caching Proxy.
La configuración de la máquina servidor correspondiente a Figura 30 es la siguiente:
La Figura 30 muestra una representación básica de varios servidores (EdgeServer1, EdgeServer2, EdgeServer3) distribuyendo el tráfico entre varios servidores Web de fondo. El componente CBR utiliza Caching Proxy para reenviar peticiones basándose en el contenido del URL a los servidores Web de fondo. El componente Dispatcher se utiliza para repartir el tráfico a los componentes CBR a través de Edge Servers. La función de alta disponibilidad del componente Dispatcher se utiliza para asegurar que las peticiones a los servidores de fondo continúan aunque la máquina principal de alta disponibilidad (EdgeServer1) falle en algún momento.
Líneas generales de la configuración básica:
Líneas de ejemplo a las que se hace referencia en las notas 1-4 (anteriores):
Hostname www.company.com SendRevProxyName yes Caching ON CacheMemory 128000 K Proxy /* http://www.company.com/* www.company.com
Archivos de configuración de ejemplo:
Los siguientes archivos de configuración de ejemplo son parecidos a los archivos que se crean cuando se prepara una configuración de Edge Server tal como se muestra en la Figura 30. Los archivos de configuración de ejemplo muestran los archivos correspondientes a los componentes Dispatcher y CBR de Network Dispatcher. En la configuración de ejemplo, se utiliza un solo adaptador Ethernet para cada una de las máquinas Edge Server y todas las direcciones están representadas dentro de una subred privada. Los archivos de configuración de ejemplo utilizan las siguientes direcciones IP para las máquinas especificadas:
Archivo de configuración de ejemplo correspondiente al componente Dispatcher en el Edge Server principal de alta disponibilidad:
ndcontrol executor start ndcontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 ndcontrol port add 192.168.1.11:80 ndcontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 ndcontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 ndcontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 ndcontrol manager start manager.log 10004 ndcontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 ndcontrol highavailability backup add primary auto 4567
Archivo de configuración de ejemplo correspondiente al componente CBR en los Edge Servers:
cbrcontrol set loglevel 1 cbrcontrol executor start cbrcontrol cluster add 192.168.1.11 cbrcontrol port add 192.168.1.11:80 cbrcontrol server add 192.168.1.11:80:webserverA address 192.168.1.71 cbrcontrol server add 192.168.1.11:80:webserverB address 192.168.1.72 cbrcontrol server add 192.168.1.11:80:webserverC address 192.168.1.73 cbrcontrol rule add 192.168.1.11:80:webA_rule type content pattern (URI=*WSA*)|(URI=*wsA*) priority 21 cbrcontrol rule useserver 192.168.1.11:80:webA_rule webserverA cbrcontrol rule add 192.168.1.11:80:webB_rule type content pattern (URI=/WS_B*) priority 22 cbrcontrol rule useserver 192.168.1.11:80:webB_rule webserverB cbrcontrol rule add 192.168.1.11:80:webC_rule type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_rule webserverC
En muchos casos, puede utilizar teclas o combinaciones de teclas para realizar operaciones que también se pueden efectuar mediante acciones del ratón. Muchas acciones de menú se pueden iniciar desde el teclado.
Consulte la documentación de su sistema operativo para obtener instrucciones sobre el uso del teclado.
Network Dispatcher incluye un recurso de ayuda en línea, que describe las tareas que el usuario realiza al instalar, planificar, configurar y utilizar el producto.
Para obtener ayuda para la ventana actual, pulse el signo de interrogación (?) de la esquina superior derecha. Puede elegir entre estas opciones:
Para obtener más información sobre la utilización de Network Dispatcher, consulte:
http://www.ibm.com/software/webservers/edgeserver
http://www.ibm.com/software/webservers/edgeserver/support.html
Pulse en Search for Network Dispatcher hints and tips.
Las referencias hechas en esta publicación a productos, programas o servicios IBM no implican que IBM tenga previsto comercializarlos en todos los países en los que IBM realiza operaciones comerciales. Las referencias a productos, programas o servicios IBM no pretenden afirmar ni implican que únicamente puedan utilizarse dichos productos, programas o servicios IBM. En su lugar puede utilizarse cualquier otro producto, programa o servicio funcionalmente equivalente que no infrinja ninguno de los derechos de propiedad intelectual de IBM ni ningún otro tipo de derecho protegido legalmente. La evaluación y verificación del funcionamiento conjunto con otros productos, excepto los que IBM indica expresamente, son responsabilidad del usuario.
IBM puede tener patentes o solicitudes de patentes en tramitación que afecten al tema tratado en este documento. La entrega de este documento no otorga ninguna licencia sobre dichas patentes. Puede enviar consultas sobre licencias, por escrito, a: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785, Estados Unidos.
Los licenciatarios de este programa que deseen información sobre el mismo
con el fin de posibilitar: (i) el intercambio de información entre
programas creados de forma independiente y otros programas (incluido éste) y
(ii) la utilización mutua de la información intercambiada, deben dirigirse
a:
Site Counsel
IBM Corporation
P.O. Box 12195
3039 Cornwallis Avenue
Research Triangle Park, NC 27709-2195
Estados Unidos
IBM facilita el programa bajo licencia descrito en este documento, así como todo el material bajo licencia disponible para él, sujeto a las condiciones generales para la contratación de programas IBM bajo licencia.
Este documento no está pensado para su uso en un entorno de trabajo real y se entrega tal cual sin garantías de ninguna clase; por el presente documento se deniega cualquier garantía, incluidas las de comercialización y las de adecuación a un propósito determinado.
Este producto incluye software informático creado y disponible por medio de CERN. Esta notificación debe mencionarse en su totalidad en cualquier producto que incluya, en parte o en su totalidad, el software informático CERN.
Los términos siguientes son marcas registradas o marcas comerciales de IBM Corporation en los Estados Unidos o en otros países.
AIX
IBM
IBMLink
LoadLeveler
OS/2
NetView
WebSphere
Lotus es una marca registrada de Lotus Development Corporation en los Estados Unidos o en otros países.
Domino es una marca registrada de Lotus Development Corporation en los Estados Unidos o en otros países.
Tivoli es una marca registrada de Tivoli Systems, Inc. en los Estados Unidos o en otros países.
Java y todas las marcas registradas y logotipos basados en Java son marcas registradas o marcas comerciales de Sun Microsystems, Inc. en los Estados Unidos o en otros países.
Solaris es una marca registrada de Sun Microsystems, Inc. en los Estados Unidos o en otros países.
Microsoft y Windows 2000 son marcas registradas o marcas comerciales de Microsoft Corporation en los Estados Unidos o en otros países.
Cisco es una marca registrada de Cisco Systems, Inc. en los Estados Unidos o en otros países.
HP es una marca registrada de Hewlett-Packard Company en los Estados Unidos o en otros países.
Linux es una marca registrada de Linus Torvalds.
Red Hat es una marca registrada de Red Hat, Inc.
UNIX es una marca registrada de The Open Group en los Estados Unidos o en otros países.
Otros nombres de empresas, productos y servicios, que pueden estar señalados con dos asteriscos (**), pueden ser marcas registradas o marcas de servicio de terceros.