Esta edición se aplica a:
y a todos los releases y modificaciones posteriores hasta que se indique lo contrario en nuevas ediciones.
Realice el pedido de las publicaciones a través del representante de IBM o de la sucursal de IBM que presta servicio en su localidad.
Este manual, WebSphere Application Server Conceptos, planificación e instalación de Edge Components, sirve de introducción al producto Edge Components de WebSphere Application Server. Proporciona visiones generales del producto de alto nivel, explicaciones detalladas de su funcionalidad relativas a los componentes clave, escenarios en el extremo de la red, información sobre la instalación y configuración inicial y redes de demostración.
El manual WebSphere Application Server Conceptos, planificación e instalación de Edge Components se ha escrito para aquellos administradores de red y de sistemas expertos que estén familiarizados con sus sistemas operativos y con el suministro de servicios de Internet. No es necesario tener conocimientos previos de WebSphere Application Server o Edge Components de WebSphere Application Server.
Las características de accesibilidad ayudan al usuario que tiene discapacidades físicas, como por ejemplo una movilidad restringida o una visión limitada, a utilizar satisfactoriamente los productos de software. Éstas son las principales características de accesibilidad en WebSphere Application Server, Versión 6.1:
Esta documentación utiliza los siguientes convenios tipográficos y de teclas.
Convenio | Significado |
---|---|
Negrita | Cuando se hace referencia a interfaces gráficas de usuario (las GUI), se indican en negrita menús, elementos de los menús, etiquetas, botones, iconos y carpetas. También puede utilizarse para enfatizar nombres de mandatos que, de lo contrario, podrían confundirse con el texto de alrededor. |
Monoespaciado | Indica texto que es necesario entrar en un indicador de mandatos. Además, el monoespaciado indica texto que aparece en la pantalla, ejemplos de código y extractos de archivos. |
Cursiva | Indica valores de variable que debe proporcionar el usuario (por ejemplo, el usuario facilitará el nombre de un archivo para NombreArchivo). La cursiva también indica énfasis y los títulos de manuales. |
Control-x | Donde x es el nombre de una tecla, indica una secuencia de Control-carácter. Por ejemplo, Control-c significa pulsar y mantener pulsada la tecla Control mientras se pulsa la tecla c. |
Intro | Se refiere a la tecla etiquetada con la palabra Intro o con la flecha hacia la izquierda. |
% | Representa el indicador de shell de mandatos de Linux y UNIX para un mandato que no requiere privilegios root. |
# | Representa el indicador de shell de mandatos de Linux y UNIX de un mandato que requiere privilegios root. |
C:\ | Representa el indicador de mandatos de Windows. |
Entrada de mandatos | Cuando se le indique que "entre" o "emita" un mandato, escriba el mandato y luego pulse Intro. Por ejemplo, la instrucción "Entre el mandato ls" significa que debe escribir ls en un indicador de mandatos y, después, pulsar Intro. |
[ ] | Encierran elementos opcionales en las descripciones de sintaxis. |
{ } | Encierran listas de las que debe elegirse un elemento en las descripciones de sintaxis. |
| | Separa elementos en una lista de opciones encerradas entre los signos { } (llaves) en las descripciones de sintaxis. |
... | Los puntos suspensivos que aparecen en las descripciones de sintaxis indican que es posible repetir el elemento anterior una o más veces. Los puntos suspensivos que aparecen en los ejemplos indican que se ha omitido información en el ejemplo para una mayor brevedad. |
Esta parte es una introducción a Edge Components de WebSphere Application Server, el Proxy de antememoria y Load Balancer, en la que se describe su integración con Application Server. Además, se definen los componentes del Proxy de antememoria y de Load Balancer. Asimismo, este apartado presenta otros productos de la familia WebSphere relacionados.
Esta parte contiene los capítulos siguientes:
WebSphere es un tipo de software de infraestructura de Internet que permite a las compañías desarrollar, desplegar e integrar aplicaciones de e-business de la próxima generación, tales como las de e-commerce de empresa a empresa. El middleware de WebSphere da soporte a aplicaciones comerciales que van desde la simple publicación en la Web hasta el proceso de transacciones a escala de empresa.
Como fundamento de la plataforma WebSphere, el producto WebSphere Application Server ofrece un juego completo de middleware que permite a los usuarios diseñar, implementar, desplegar y gestionar aplicaciones comerciales. Estas aplicaciones pueden incluir desde un simple escaparate de sitio Web hasta una revisión total de la infraestructura de sistemas de una organización.
Las características intensivas de procesador, como, por ejemplo, la personalización, brindan una ventaja competitiva para cada e-business. No obstante, si habitualmente se relegan estas características a servidores centrales, puede impedirse la escala de funciones valiosas a las proporciones de Internet. En consecuencia, con la adición constante de nuevas aplicaciones Web, la infraestructura de Internet de una empresa ha de crecer en cuanto al ámbito y al impacto. Además, la fiabilidad y la seguridad resultan extraordinariamente importantes para e-business. Incluso una mínima interrupción del servicio puede suponer pérdidas en la empresa.
El producto Edge Components (anteriormente Edge Server) forma parte ahora de la oferta de WebSphere Application Server. Es posible utilizar Edge Components junto con WebSphere Application Server a fin de controlar el acceso de los clientes a los servidores Web y de permitir que las empresas comerciales proporcionen un mejor servicio a los usuarios que acceden al contenido basado en la Web en Internet o en una intranet corporativa. Utilizando Edge Components, podrá reducir la congestión en los servidores Web, aumentar la disponibilidad de los contenidos y mejorar el rendimiento de dichos servidores. Como su nombre (Edge) indica, normalmente el producto Edge Components se ejecuta en máquinas que se encuentran cercanas (en el sentido de la configuración de la red) al límite entre la intranet de una empresa e Internet.
WebSphere Application Server incluye el Proxy de antememoria y Load Balancer como Edge Components.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
El Proxy de antememoria reduce el uso del ancho de banda y mejora la velocidad y fiabilidad de un sitio Web al proporcionar un nodo de punto de presencia para uno o más servidores de contenido finales. El Proxy de antememoria puede colocar en antememoria y servir contenido estático y contenido generado dinámicamente por WebSphere Application Server.
Se puede configurar el Proxy de antememoria con el rol de un servidor proxy inverso (configuración por omisión) o un servidor proxy de envío, lo que proporciona un punto de presencia para una red o para un servidor de red interno con mejores tiempos de respuesta y petición. Para obtener más información sobre las configuraciones de proxy de envío e inverso, consulte Configuraciones de proxy de antememoria básico.
El servidor proxy intercepta las peticiones de datos de un cliente, recupera la información solicitada de las máquinas que alojan contenidos y devuelve esos contenidos al cliente. Habitualmente, las peticiones se refieren a documentos que se almacenan en máquinas de servidor Web (también llamadas servidores de origen o sistemas principales que alojan contenidos) y se entregan mediante el HTTP (Protocolo de transferencia de hipertexto). No obstante, es posible configurar el servidor proxy de forma que maneje otros protocolos, tales como el Protocolo de transferencia de archivos (FTP) y el Gopher.
Antes de entregarlos al peticionario, el servidor proxy almacena en una antememoria local los contenidos que pueden colocarse en antememoria. Entre los ejemplos de contenidos que pueden colocarse en antememoria se incluyen las páginas Web estáticas y los archivos de JavaServer Pages con información que se genera dinámicamente, pero que cambia con poca frecuencia. La antememoria permite al servidor proxy satisfacer las peticiones subsiguientes que se refieren a los mismos contenidos entregándolos directamente desde la antememoria local, lo cual es mucho más rápido que recuperarlos otra vez del sistema principal que aloja contenidos.
Los conectores de Proxy de antememoria añaden funcionalidad al servidor proxy.
Puede ampliar todavía más las funciones del Proxy de antememoria escribiendo módulos de conector personalizados con una interfaz de programas de aplicación (API). La API es flexible, fácil de utilizar e independiente de la plataforma. El proxy realiza una secuencia de pasos para cada petición de cliente que procesa. Una aplicación de conector modifica o sustituye un paso dentro del flujo de trabajo de proceso de peticiones, como la autenticación de un cliente o la filtración de peticiones. La potente interfaz Transmogrify, por ejemplo, proporciona acceso a los datos HTTP y permite la sustitución o transformación de URL y contenidos Web. Los conectores pueden modificar o sustituir los pasos de proceso designados, y puede invocarse más de un conector para un paso determinado.
Load Balancer crea sistemas al extremo de la red que dirigen el flujo de tráfico de la red, lo que reduce la congestión y equilibra la carga en otros servicios y sistemas distintos. Load Balancer proporciona selección de sitio, gestión de carga de trabajo, afinidad de las sesiones y una sustitución por anomalía transparente.
Load Balancer se instala entre Internet y los servidores finales de la empresa, que pueden ser sistemas principales que alojan contenidos o máquinas de Proxy de antememoria. Load Balancer actúa como el único nodo de punto de presencia de la empresa en Internet aunque la empresa utilice varios servidores finales a causa de la alta demanda o de grandes volúmenes de contenido. También puede garantizarse una alta disponibilidad mediante la instalación de un Load Balancer de reserva que asuma la carga del primario si éste falla temporalmente.
Load Balancer intercepta peticiones de datos de los clientes y reenvía cada petición al servidor que actualmente tiene más posibilidades de cumplir la petición. Es decir, equilibra la carga de peticiones entrantes entre un conjunto definido de máquinas que atienden al mismo tipo de peticiones. Load Balancer puede distribuir peticiones a muchos tipos de servidores, incluidas máquinas de WebSphere Application Server y máquinas de Proxy de antememoria. El equilibrio de carga podrá personalizarse para una aplicación o plataforma en particular utilizando consejeros personalizados. Se encuentran disponibles consejeros de fines especiales para obtener información para los WebSphere Application Server de equilibrio de carga.
Si se instala el componente Direccionamiento basado en el contenido junto con el Proxy de antememoria, incluso pueden distribuirse las peticiones HTTP y HTTPS basándose en los URL o en otras características determinadas por el administrador, lo que eliminará la necesidad de almacenar contenidos idénticos en todos los servidores finales. Asimismo, el componente Dispatcher puede proporcionar la misma función para las peticiones HTTP.
El equilibrio de carga mejora la disponibilidad y escalabilidad del sitio Web al agrupar en clúster y de forma transparente los servidores de contenido, incluidos servidores HTTP, servidores de aplicaciones y servidores proxy, que son servidores de contenido sustitutos. La disponibilidad se consigue a través del paralelismo, equilibrio de carga y soporte de sustitución por anomalía. Cuando un servidor está inactivo, no se interrumpe la actividad empresarial. La escalabilidad de una infraestructura mejorará en gran medida porque puede añadirse de forma transparente la potencia del proceso de fondo.
Soporte de IPv6: Con Load Balancer para IPv4 e IPv6 está disponible el soporte del esquema de direccionamiento IP ampliado de IPv6. Load Balancer para IPv4 e IPv6 es una imagen de instalación distinta que consta únicamente del componente Dispatcher. Este tipo de instalación proporciona equilibrio de carga para el tráfico IPv4 e IPv6 a servidores configurados dentro de la red mediante reenvío de paquetes basado en MAC de Dispatcher. Es importante tener en cuenta que cualquier Load Balancer anterior se debe desinstalar antes de instalar Load Balancer para IPv4 e IPv6. No pueden instalarse dos Load Balancer en la misma máquina. (Consulte Dispatcher, para obtener una breve visión general del componente Dispatcher).
Load Balancer incluye los componentes siguientes:
Para todos los servicios de Internet, como por ejemplo HTTP, FTP, HTTPS y Telnet, el componente Dispatcher realiza el equilibrio de carga para los servidores que están dentro de una red de área local (LAN) o de una red de área amplia (WAN). Para los servicios HTTP, Dispatcher puede realizar el equilibrio de carga de los servidores basándose en el contenido del URL de la petición del cliente.
El componente Dispatcher permite la gestión estable y eficaz de una red de servidores grande y escalable. Con Dispatcher, puede enlazar muchos servidores individuales en lo que aparentará ser un solo servidor virtual. Así, su sitio aparece como una sola dirección IP ante los demás.
Si utiliza una instalación de Load Balancer para IPv4 e IPv6, consulte el capítulo sobre despliegue de Dispatcher en Load Balancer para IPv4 e IPv6 en el documento WebSphere Application Server Load Balancer Administration Guide, que incluye información sobre limitaciones y diferencias de configuración.
Para los servicios HTTP y HTTPS, el componente Direccionamiento basado en el contenido realiza el equilibrio de carga para los servidores basándose en el contenido de la petición del cliente. El componente Direccionamiento basado en el contenido trabaja junto con el componente Proxy de antememoria de Application Server.
IMPORTANTE: El componente Direccionamiento basado en el contenido (CBR) está disponible en todas las plataformas soportadas, con las siguiente excepciones:
Como alternativa, para este tipo de instalación, puede utilizar el método cbr de reenvío del componente Dispatcher de Load Balancer para proporcionar direccionamiento basado en contenido de peticiones HTTP y HTTPS sin utilizar el Proxy de antememoria. Consulte la publicación WebSphere Application Server Load Balancer Administration Guide para obtener más información.
Load Balancer para IPv4 e IPv6 sólo soporta el método mac de reenvío del componente Dispatcher. No están soportados los métodos nat y cbr de reenvío.
El componente Selector de sitio mejora un sistema de equilibrio de carga al permitir que actúe como nodo de punto de presencia para una red y equilibre la carga de las peticiones entrantes correlacionando nombres del DNS con direcciones IP. Junto con el Servidor de métrica, el Selector de sitio puede supervisar el nivel de actividad de un servidor, detectar si un servidor tiene la carga menos pesada y detectar un servidor anómalo.
Este componente está soportado en todas las instalaciones de Edge Components, con la siguiente excepción:
El componente Cisco CSS Controller genera métricas de carga de servidor que se envían a un conmutador Cisco CSS para la selección de servidor, optimización de la carga y tolerancia de errores.
Este componente está soportado en todas las instalaciones de Edge Components, con la siguiente excepción:
El componente Nortel Alteon Controller genera métricas de carga de servidor que se envían a un conmutador Nortel Alteon para la selección de servidor, optimización de la carga y tolerancia de errores.
Este componente está soportado en todas las instalaciones de Edge Components, con la siguiente excepción:
El componente Servidor de métrica se ejecuta como un daemon en un servidor de carga equilibrada y proporciona información sobre cargas del sistema a los componentes de Load Balancer.
La familia IBM WebSphere está diseñada para ayudar a los usuarios a realizar la promesa de e-business. Es un conjunto de productos de software que permite a los usuarios desarrollar y gestionar sitios Web de alto rendimiento e integrarlos con sistemas de información de empresa nuevos o existentes que no son de la Web.
La familia WebSphere se compone de WebSphere Application Server, incluido el producto Edge Components, y otro software de la familia WebSphere que está muy integrado con WebSphere Application Server y mejora su rendimiento. Obtendrá una visión general de WebSphere Application Server y sus componentes si consulta el Introducción a Edge Components de WebSphere Application Server.
Tivoli Access Manager (anteriormente Tivoli Policy Director) está disponible por separado. Proporciona control del acceso y seguridad centralizada para las aplicaciones Web existentes y ofrece la posibilidad de autenticación de una sola vez con acceso a múltiples recursos Web. Un conector del Proxy de antememoria aprovecha la infraestructura de seguridad de Access Manager a fin de permitir al servidor proxy utilizar los servicios de autorización o autenticación integrados de Access Manager.
WebSphere Portal Server (disponible por separado) ofrece una infraestructura destinada a cumplir los objetivos de presentación, seguridad, escalabilidad y disponibilidad asociados con los portales. Utilizando Portal Server, las compañías pueden crear su propio sitio Web de portal personalizado para servir a las necesidades de los empleados, los business partners y los clientes. Los usuarios podrán iniciar sesión en el portal y recibir páginas Web personalizadas que proporcionen acceso a la información, individuos y aplicaciones a los que necesiten acudir. Este único punto de acceso personalizado a todos los recursos necesarios reduce la sobrecarga de información, acelera la productividad y hace que aumente la utilización del sitio Web.
WebSphere Portal Server se ejecuta en un clúster de WebSphere Application Server para conseguir la escalabilidad y fiabilidad. También es posible utilizar el componente Load Balancer de Application Server para el equilibrio de carga adicional y la alta disponibilidad.
WebSphere Site Analyzer (disponible por separado) ayuda a las empresas a prever los problemas de capacidad y de rendimiento. Con Site Analyzer, pueden utilizarse las anotaciones cronológicas del Proxy de antememoria y de Load Balancer, así como otras ayudas para la gestión, a fin de prever la demanda de recursos adicionales mediante la supervisión, análisis e informes del uso del sitio Web. Además, los componentes de gestión de Site Analyzer sirven a los usuarios que instalan y actualizan Edge Components, a los que gestionan y almacenan las configuraciones, a los que trabajan con Edge Components remotamente y a los que visualizan y notifican los sucesos.
WebSphere Transcoding Publisher (disponible por separado) puede convertir una página Web para su visualización en un dispositivo portátil, como, por ejemplo, un teléfono con capacidad para Internet, puede convertir contenidos Web al idioma nacional deseado por el usuario (invocando WebSphere Translation Server) y puede convertir lenguajes de marcación. Transcoding Publisher mejora las posibilidades del Proxy de antememoria ya que le permite servir contenidos para diferentes dispositivos y usuarios. Después de acceder a los contenidos de un servidor Web, la interfaz Transmogrify del Proxy de antememoria puede configurarse para que invoque Transcoding Publisher con el objeto de transformar los datos y codificarlos para otra colocación en antememoria y posible reutilización. En la interfaz de postautenticación del Proxy de antememoria, Transcoding Publisher comprueba después en el servidor proxy si coinciden los contenidos y los requisitos del usuario y del dispositivo, y en caso de hallar una coincidencia, sirve los contenidos desde la antememoria del servidor proxy.
La documentación siguiente, específica de WebSphere Application Server Edge Components está disponible en el centro de información de Edge Components.
El resto de documentación de WebSphere Application Server se encuentra disponible desde la página de la biblioteca de WebSphere Application Server.
La información sobre soporte técnico para Edge Components está disponible en la página de soporte de WebSphere Application Server.
Consulte la siguiente lista de sitios Web para obtener información sobre Edge Components o información relacionada:
Esta parte incluye descripciones detalladas en las que se resaltan algunas de las funciones disponibles con Edge Components. Consulte el Introducción a Edge Components de WebSphere Application Server para obtener una visión general del componente Proxy de antememoria de Application Server.
Esta parte contiene los capítulos siguientes:
Direccionamiento basado en el contenido
La función de colocación en antememoria del Proxy de antememoria ayuda a minimizar la utilización del ancho de banda de la red y asegura que los usuarios finales reciban un servicio más rápido y fiable. Esto tiene lugar porque la colocación en antememoria realizada por el servidor proxy libera la carga de los servidores finales y enlaces de igual a igual. El Proxy de antememoria puede colocar en antememoria contenido estático y contenido generado dinámicamente por WebSphere Application Server. Para proporcionar una mejora en la colocación en antememoria, el Proxy de antememoria también funciona junto con el componente Load Balancer de Application Server. Consulte el Introducción a Edge Components de WebSphere Application Server para leer una introducción dedicada a estos sistemas.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
El Proxy de antememoria se puede configurar con el rol de un servidor proxy de antememoria inverso (configuración por omisión) o de un servidor proxy de antememoria de envío. Cuando lo utilizan los sistemas principales de contenido, se configura el Proxy de antememoria con el rol de servidor proxy de antememoria inverso, situado entre Internet y los sistemas principales de contenido de empresa. Cuando lo utilizan los proveedores de acceso de Internet, el Proxy de antememoria se configura con el rol de un servidor proxy de antememoria de envío, situado entre un cliente e Internet.
Cuando se utiliza una configuración de proxy inverso, las máquinas de Proxy de antememoria están situadas entre Internet y los sistemas principales de contenido de la empresa. Actuando como sustituto, el servidor proxy intercepta las peticiones de usuario que llegan desde Internet, las reenvía al sistema principal correspondiente que aloja contenidos, coloca los datos devueltos en antememoria y entrega esos datos a los usuarios a través de Internet. La colocación en antememoria permite al Proxy de antememoria satisfacer las peticiones subsiguientes que se refieren a los mismos contenidos directamente desde la antememoria, lo cual es mucho más rápido que recuperarlos otra vez del sistema principal que aloja contenidos. Puede colocarse información en antememoria en función de su caducidad, del tamaño que ha de tener la antememoria y de cuándo debe actualizarse la información. La mayor rapidez en las bajadas para los impactos en antememoria significa una mejor calidad de servicio para los clientes. La Figura 1 ilustra esta función básica del Proxy de antememoria.
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Proxy de antememoria 5--Antememoria 6--Sistema principal de contenidoEn esta configuración, el servidor proxy (4) intercepta peticiones cuyos URL incluyen el nombre de sistema principal del sistema principal que aloja contenidos (6). Cuando un cliente (1) solicita el archivo X, la petición circula a través de Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). El servidor proxy intercepta la petición, genera una nueva petición con su propia dirección IP como dirección origen y envía la nueva petición al sistema principal que aloja contenidos (6).
El sistema principal que aloja contenidos devuelve el archivo X al servidor proxy en vez de devolverlo directamente al usuario final. Si el archivo puede colocarse en antememoria, el Proxy de antememoria almacena una copia en su antememoria (5) antes de pasarlo al usuario final. El ejemplo más destacable de contenidos que pueden colocarse en antememoria son las páginas Web estáticas; no obstante, el Proxy de antememoria también proporciona la posibilidad de colocar en antememoria y servir contenidos generados dinámicamente por WebSphere Application Server.
Proporciona acceso directo a Internet a los usuarios finales de un modo muy eficaz. Todo usuario que captura un archivo determinado desde un servidor Web genera la misma cantidad de tráfico en la red y a través de la pasarela de Internet que el primer usuario que ha capturado el archivo incluso si éste no se ha modificado. La solución es instalar un Proxy de antememoria de envío cerca de la pasarela.
Cuando se utiliza una configuración de proxy de envío, las máquinas de Proxy de antememoria están situadas entre el cliente e Internet. El Proxy de antememoria envía una petición de cliente a los sistemas principales de contenido situados entre Internet, guarda en la antememoria los datos recuperados y entrega los datos recuperados al cliente.
En la Figura 2 se muestra la configuración del Proxy de antememoria de envío. Los programas de navegador de clientes (en las máquinas marcadas con 1) se configuran con peticiones directas al proxy de antememoria de envío (2), que se configura para interceptar las peticiones. Cuando un usuario final solicita el archivo X almacenado en el sistema principal de contenido (6), el proxy de antememoria de envía intercepta la petición, genera una petición nueva con su propia dirección IP como la dirección de origen y envía la nueva petición mediante el direccionador de la empresa (4) a través de Internet (5).
De este modo, el servidor de origen devuelve el archivo X al proxy de antememoria de envío en lugar de devolverlo directamente al usuario final. Si la función de antememoria del proxy de antememoria de envío está habilitada, el proxy de antememoria determina si el archivo X se puede seleccionar para guardarlo en la antememoria comprobando en la cabecera de retorno valores como, por ejemplo, la fecha de caducidad y una indicación de si el archivo se ha generado dinámicamente. Si el archivo se puede colocar en la antememoria, el proxy de antememoria almacena una copia en su antememoria (3) antes de pasarla al usuario final. Por omisión, se inhabilita la colocación en antememoria y el proxy de antememoria de envío utiliza una antememoria, no obstante, puede configurar otros tipos de antememoria.
Para la primera petición del archivo X, el proxy de antememoria de envío no mejora demasiado la eficacia del acceso a Internet. De hecho, el tiempo de respuesta del primer usuario que accede al archivo X es probablemente el más lento sin el proxy de antememoria de envío porque el proxy de antememoria de envío tarda un poco más en procesar el paquete de la petición original y en examinar en la cabecera del archivo X la información de antememoria cuando lo recibe. Utilizar el proxy de antememoria de envío tiene mejores resultados cuando otros usuarios solicitan posteriormente el archivo X. El proxy de antememoria de envío comprueba que su copia en antememoria del archivo X continúa siendo válida (no ha caducado), y si es así, sirve el archivo X directamente desde la antememoria, sin enviar la petición a través de Internet al sistema principal de contenido.
Incluso cuando el proxy de antememoria de envío detecta que un archivo solicitado ha caducado, no necesariamente tiene que volver a obtener el archivo desde el sistema principal de contenido. En su lugar, envía un mensaje de comprobación de estado especial al sistema principal de contenido. Si el sistema principal de contenido indica que el archivo no se ha modificado, el proxy de antememoria de envío puede continuar entregando la versión en antememoria al usuario solicitante.
Si se configura el proxy de antememoria de envío de este modo se considera un proxy de envío porque el proxy de antememoria actúa en nombre de los navegadores y envía sus peticiones a los sistemas principales de contenido a través de Internet. Las ventajas del proxy de envío con la función de colocación en antememoria son de dos tipos:
El proxy de antememoria puede ejecutar varios protocolos de transferencia de red, incluidos HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) y Gopher.
Una variación del Proxy de antememoria de envío es el Proxy de antememoria transparente. En este rol, el Proxy de antememoria efectúa la misma función que el Proxy de antememoria de envío básico pero lo hace sin que el cliente sea consciente de su presencia. La configuración del Proxy de antememoria transparente está soportada sólo en sistemas Linux.
En la configuración descrita en Proxy de antememoria de envío, cada navegador de cliente se configura por separado para dirigir peticiones a un Proxy de antememoria de envío determinado. Mantener dicha configuración puede resultar poco práctico, sobretodo para grandes números de máquinas cliente. El Proxy de antememoria da soporte a varias alternativas que simplifican la administración. Una posibilidad es configurar el Proxy de antememoria para el proxy transparente como se describe en Figura 3. Del mismo modo que con el Proxy de antememoria de envío regular, el Proxy de antememoria transparente se instala junto a una máquina cerca de la pasarela pero los programas del navegador de cliente no se configuran para dirigir peticiones a un Proxy de antememoria de envío. Los clientes desconocen que existe un proxy en la configuración. En su lugar, se configura un direccionador para interceptar las peticiones de cliente y dirigirlas al Proxy de antememoria transparente. Cuando un cliente trabaja en una de las máquinas, marcada con un 1, solicita el archivo X almacenado en un sistema principal de contenido (6), el direccionador (2) pasa la petición al Proxy de antememoria. El Proxy de antememoria genera una petición nueva con su propia dirección IP como la dirección de origen y envía la petición nueva mediante el direccionador (2) a través de Internet (5). Cuando llega el archivo X, el Proxy de antememoria coloca el archivo en antememoria si resulta adecuado (según las condiciones descritas en Proxy de antememoria de envío) y pasa el archivo al cliente que lo solicita.
Para las peticiones HTTP, otra alternativa posible para mantener la información de configuración del proxy de cada navegador es utilizar la función de configuración del proxy automáticamente disponible en diferentes programas de navegador, incluido Netscape Navigator versión 2.0 y superior y Microsoft Internet Explorer versión 4.0 y superior. En este caso, cree uno o varios archivos PAC (Proxy Automatic Configuration) centrales y configure los navegadores para que hagan referencia a uno de ellos, en lugar de a la información de configuración del proxy local. El navegador observa automáticamente los cambios en el PAC y ajusta el uso del proxy como corresponde. Esto no sólo elimina la necesidad de mantener información de configuración separada en cada navegador, sino que también facilita el redireccionamiento de las peticiones cuando un servidor proxy pasa a no estar disponible.
Una tercera alternativa es utilizar el mecanismo WPAD (Web Proxy Auto Discovery) disponible en algunos programas de navegador como, por ejemplo, Internet Explorer versión 5.0 y superior. Cuando habilita esta característica en el navegador, automáticamente localiza un servidor proxy compatible con WPAD en su red y dirige allí sus peticiones Web. No es necesario que mantenga los archivos de configuración del proxy central en este caso. El Proxy de antememoria es compatible con WPAD.
Para proporcionar funciones de antememoria avanzadas, utilice el Proxy de antememoria como un proxy inverso junto con el componente Load Balancer. Integrando las posibilidades de colocación en antememoria y equilibrio de carga, podrá crear una infraestructura de rendimiento en la Web que será eficaz y muy manejable.
La Figura 4 ilustra cómo puede combinar el Proxy de antememoria con Load Balancer para entregar contenidos Web eficazmente aunque se produzca una gran demanda. En esta configuración, el servidor proxy (4) está configurado para interceptar peticiones cuyos URL incluyen el nombre de sistema principal de un clúster de sistemas principales que alojan contenidos (7), para los cuales Load Balancer (6) realiza el equilibrio de carga.
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Proxy de antememoria 5--Antememoria 6--Load Balancer 7--Sistema que aloja contenidosCuando un cliente (1) solicita el archivo X, la petición circula a través de Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). El servidor proxy intercepta la petición, genera una nueva petición con su propia dirección IP como dirección origen y envía la nueva petición a Load Balancer en la dirección de clúster. Load Balancer utiliza su algoritmo de equilibrio de carga a fin de determinar cuál de los sistemas principales que alojan contenidos es actualmente el más capacitado para satisfacer la petición del archivo X. El sistema principal que aloja contenidos elegido devolverá el archivo X al servidor proxy en lugar de utilizar Load Balancer. El servidor proxy determina si lo coloca en antememoria y lo entrega al usuario final, siguiendo el mismo procedimiento descrito anteriormente.
La función de colocación en antememoria avanzada también se proporciona mediante el conector de Colocación en antememoria dinámica del Proxy de antememoria. Cuando se utiliza junto con WebSphere Application Server, el Proxy de antememoria tiene la posibilidad de colocar en antememoria, servir e invalidar contenidos dinámicos en forma de JavaServer Pages (JSP) y respuestas de servlet generadas por WebSphere Application Server.
Generalmente, los contenidos dinámicos con una caducidad indefinida deben marcarse como "no colocar en antememoria" porque la lógica estándar de caducidad de antememoria temporal no asegura su eliminación oportuna. La lógica de caducidad controlada por sucesos del conector de Colocación en antememoria dinámica permite que el servidor proxy coloque en antememoria los contenidos con una caducidad indefinida. La colocación en antememoria de este tipo de contenidos en el extremo de la red libera a los sistemas principales que alojan contenidos de tener que invocar repetidamente Application Server para satisfacer las peticiones de los clientes. Esto puede aportar las ventajas siguientes:
La colocación en antememoria de respuestas de servlet es ideal para las páginas Web producidas dinámicamente que caducan basándose en la lógica de la aplicación o en un suceso, tal como un mensaje de una base de datos. Aunque la duración de una página de este tipo es finita, el valor de tiempo de vida no puede establecerse en el momento de la creación porque no puede conocerse de antemano el desencadenante de la caducidad. Cuando el tiempo de vida de estas páginas se establece en cero, los sistemas principales que alojan contenidos incurren en un gran error al servir contenidos dinámicos.
La responsabilidad de sincronizar la antememoria dinámica del Proxy de antememoria y de Application Server está compartida por ambos sistemas. Por ejemplo, una página Web pública creada dinámicamente por una aplicación que facilita el pronóstico del tiempo actual puede exportarse mediante Application Server y colocarse en antememoria en el Proxy de antememoria. Entonces el Proxy de antememoria puede servir los resultados de ejecución de la aplicación repetidamente a muchos usuarios distintos hasta que se le notifique que la página no es válida. Los contenidos existentes en la antememoria de respuestas de servlet del Proxy de antememoria serán válidos hasta que el servidor proxy elimine una entrada porque la antememoria está congestionada, hasta que caduque el tiempo de espera excedido por omisión establecido por la directriz ExternalCacheManager del archivo de configuración del Proxy de antememoria o hasta que el Proxy de antememoria reciba un mensaje de invalidación indicándole que depure los contenidos de su antememoria. Los mensajes de invalidación se originan en el WebSphere Application Server que posee los contenidos y se propagan a cada Proxy de antememoria configurado.
El Proxy de antememoria ofrece otras funciones avanzadas clave de colocación en antememoria:
La introducción de la funcionalidad del Proxy de antememoria afecta al rendimiento de la red. Utilice el Proxy de antememoria solo o junto con Load Balancer a fin de mejorar dicho rendimiento. Consulte el Introducción a Edge Components de WebSphere Application Server para leer una introducción dedicada a estos sistemas.
El rendimiento del Proxy de antememoria dentro de la empresa simplemente igualará al del hardware en el que se ejecute y al de la arquitectura general del sistema que lo incorpore. Para optimizar el rendimiento de la red, adapte el hardware y la arquitectura general de la red a las características de los servidores proxy.
La configuración y administración básicas del software del Proxy de antememoria, así como los ajustes al nivel del sistema operativo, también contribuyen en gran manera al rendimiento del Proxy de antememoria. Pueden efectuarse muchos cambios en la configuración del software para brindar un aumento del rendimiento; entre éstos se incluyen, pero sin limitarse a ellos, ajustes en las directrices de anotación cronológica, reglas de correlación, conectores, valores de tiempo de espera excedido, valores de configuración de antememoria y valores de hebras activas. Se presenta información detallada sobre la configuración del software del Proxy de antememoria en el manual Caching Proxy Administration Guide.
También es posible efectuar numerosos cambios en la configuración del sistema operativo para brindar un aumento del rendimiento; entre éstos se incluyen, pero sin limitarse a ellos, ajustes en TCP y ARP, aumento de los límites de descriptor de archivo, sincronización de los relojes del sistema, ajustes en las Tarjetas de interfaz de red (las NIC) y seguimiento de una buena práctica habitual al realizar las tareas de administración del sistema.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
En este apartado se describen cuestiones relacionadas con el hardware de la red que deben tomarse en consideración a la hora de incorporar la funcionalidad del Proxy de antememoria a la red.
Debe dedicarse una gran cantidad de memoria al servidor proxy. El Proxy de antememoria puede consumir 2 GB de espacio de direcciones virtuales cuando se configura una gran antememoria de sólo memoria. También es necesaria memoria para el kernel, las bibliotecas compartidas y los almacenamientos intermedios de red. Por lo tanto, es posible tener un servidor proxy que consuma 3 ó 4 GB de memoria física. Tenga en cuenta que una antememoria de sólo memoria es significativamente más rápida que una antememoria de disco sin procesar, y que este cambio de la configuración puede considerarse en sí una mejora en el rendimiento.
Es importante tener una gran cantidad de espacio de disco en la máquina en la que se instale el Proxy de antememoria. Esto es especialmente cierto cuando se utilizan antememorias de disco. Leer y grabar en un disco duro es un proceso intensivo para un sistema. Aunque los procedimientos de E/S del Proxy de antememoria son eficaces, las limitaciones mecánicas de las unidades de disco duro pueden reducir el rendimiento cuando el Proxy de antememoria se configura para que utilice una antememoria de disco. Es posible minimizar los cuellos de botella producidos en la E/S de disco con prácticas tales como el uso de diversos discos duros para los dispositivos de antememoria sin procesar y archivos de anotaciones cronológicas y el uso de unidades de discos con rapidez en los tiempos de búsqueda, velocidades rotacionales y velocidades de transferencia.
Los requisitos de red como velocidad, tipo y número de NIC, así como la velocidad de la conexión de red con el servidor proxy, afectan al rendimiento del Proxy de antememoria. En general, lo más interesante para el rendimiento es utilizar dos NIC en una máquina de servidor proxy: una para el tráfico de entrada y otra para el tráfico de salida. Es probable que una sola NIC pueda alcanzar su límite máximo en función del tráfico de peticiones HTTP y respuestas individualmente. Además, las NIC deben llegar, como mínimo, hasta los 100 MB, y siempre deben configurarse para el funcionamiento en dúplex. Esto es porque, posiblemente, la negociación automática entre los equipos de direccionamiento y conmutación causará errores y mermará la productividad. Finalmente, la velocidad de la conexión de red tiene una gran importancia. Por ejemplo, no puede esperar atender a una elevada carga de peticiones y conseguir una óptima productividad si la conexión con la máquina Proxy de antememoria es una portadora T1 saturada.
Es posible que la unidad central de proceso (CPU) de una máquina de Proxy de antememoria se convierta en un factor limitador. La potencia de la CPU afecta al período de tiempo que tardan en procesarse las peticiones y el número de CPU existentes en la red afecta a la escalabilidad. Es importante que coincidan los requisitos de CPU del servidor proxy con el entorno, especialmente para adaptarse a la carga de peticiones punta a las que atenderá el servidor proxy.
Para el rendimiento global, resulta generalmente beneficioso escalar la arquitectura y no sólo añadir partes individuales de hardware. Por mucha cantidad de hardware que se añada a una sola máquina, ese hardware tiene un nivel máximo de rendimiento.
En este apartado se describen cuestiones relacionadas con la arquitectura de la red que deben tomarse en consideración a la hora de incorporar la funcionalidad del Proxy de antememoria a la red.
Si el sitio Web de la empresa es popular, es posible que exista una mayor demanda de sus contenidos de la que pueda satisfacer un único servidor proxy eficazmente, lo que ocasionará una lentitud en los tiempos de respuesta. Para optimizar el rendimiento de la red, considere la inclusión de máquinas de Proxy de antememoria agrupadas en clúster de carga equilibrada o el uso de una arquitectura de antememoria compartida con Acceso remoto a antememoria (RCA) en la arquitectura general de la red.
Una forma de escalar la arquitectura es agrupar en clúster los servidores proxy y utilizar el componente Load Balancer para equilibrar la carga entre ellos. La agrupación en clúster de los servidores proxy es una consideración de diseño beneficiosa no sólo por razones de rendimiento y escalabilidad, sino también para los objetivos de redundancia y de fiabilidad. Un único servidor proxy representa un único punto de anomalía; si éste falla o se vuelve inaccesible a causa de una anomalía en la red, los usuarios no podrán acceder al sitio Web.
Considere asimismo una arquitectura de antememoria compartida con RCA. Una arquitectura de antememoria compartida reparte toda la antememoria virtual entre diversos servidores de Proxy de antememoria que, normalmente, utilizan un protocolo entre antememorias como el Protocolo de antememoria de Internet (ICP) o el Protocolo de direccionamiento de matriz de antememorias (CARP). El RCA está diseñado para maximizar la proporción de impactos en las antememorias agrupadas en clúster al facilitar una gran antememoria virtual.
Las ventajas para el rendimiento resultan de la utilización de una matriz RCA de servidores proxy frente a un único Proxy de antememoria autónomo o incluso un clúster de máquinas de Proxy de antememoria autónomas. En su mayor parte, las ventajas para el rendimiento vienen dadas por el aumento del tamaño de toda la antememoria virtual, lo que maximiza la proporción de impactos en antememoria y minimiza la incoherencia y latencia de la antememoria. Con el RCA, sólo reside en la antememoria una copia de un documento determinado. Con un clúster de servidores proxy, aumenta el tamaño de la antememoria total, pero es probable que diversos servidores proxy recuperen y coloquen en antememoria la misma información. Por lo tanto, no aumenta la proporción total de impactos en antememoria.
El RCA suele utilizarse en los escenarios de sistemas principales que alojan contenidos de grandes empresas. No obstante, la utilidad del RCA no está limitada a los despliegues de empresas de dimensiones extremas. Tome en consideración el uso del RCA si la carga de la red requiere un clúster de servidores de antememoria y si la mayoría de las peticiones representan impactos en antememoria. Según la configuración de la red, el RCA no siempre mejorará el rendimiento de la empresa debido a un aumento del número de conexiones TCP que utiliza un cliente en la configuración del RCA. Es así porque un miembro RCA no es responsable solamente de atender a los URL para los que tiene la puntuación más alta, sino que también debe reenviar las peticiones a otros miembros o clústeres si obtiene una petición referente a un URL para el que no tiene la puntuación más alta. Esto significa que cualquier miembro determinado de una matriz RCA puede tener más conexiones TCP abiertas de las que tendría si funcionara como un servidor autónomo.
Las contribuciones principales a una mejora del rendimiento parten de las posibilidades de antememoria del Proxy de antememoria. No obstante, la antememoria del servidor proxy puede convertirse en un cuello de botella si no se configura correctamente. Para determinar la mejor configuración de la antememoria, será necesario hacer un esfuerzo significativo a fin de analizar las características del tráfico. El tipo, tamaño, cantidad y atributos de los contenidos afectan al rendimiento del servidor proxy por lo que respecta al tiempo que tardan en recuperarse los documentos de los servidores de origen y por lo que respecta a la carga del servidor. Cuando se sepa el tipo de tráfico que el Proxy de antememoria va a permitir o a servir desde su antememoria, podrán incluirse como factor estas características al configurar el servidor proxy. Por ejemplo, saber que el 80% de los objetos que se colocarán en antememoria son imágenes (*.gif o *.jpg) y que tienen, aproximadamente, 200 KB de tamaño puede realmente servir de ayuda para ajustar los parámetros de la antememoria y para determinar el tamaño de la misma. Además, el hecho de conocer que la mayoría de los contenidos son páginas dinámicas personalizadas que no son candidatas a colocarse en antememoria también es pertinente a la hora de ajustar el Proxy de antememoria.
El análisis de las características del tráfico le permite determinar si el uso de una antememoria de disco o de memoria puede optimizar el rendimiento de la antememoria. Asimismo, familiarizarse con las características del tráfico de la red le permite determinar si puede significar una mejora en el rendimiento el uso de la función de colocación en antememoria dinámica del Proxy de antememoria.
Las antememorias de disco son apropiadas para sitios con gran cantidad de información a colocar en antememoria. Por ejemplo, si los contenidos del sitio son de un volumen elevado (superior a los 5 GB) y existe un índice de impactos en antememoria del 80 al 90%, es recomendable una antememoria de disco. No obstante, se sabe que utilizar una antememoria de memoria (RAM) es más rápido y que hay muchos escenarios en que utilizar una antememoria de sólo memoria es factible para los sitios grandes. Por ejemplo, si el índice de impactos en antememoria del Proxy de antememoria no tiene tanta importancia o si ha de utilizarse una configuración de antememoria compartida, resultará práctica una antememoria de memoria.
El Proxy de antememoria puede colocar en antememoria e invalidar contenidos dinámicos (JSP y resultados de servlet) generados por la antememoria dinámica de WebSphere Application Server, lo que proporciona una extensión virtual de la antememoria de Application Server en antememorias basadas en la red. Habilitar la colocación en antememoria de contenidos generados dinámicamente es beneficioso para el rendimiento de la red en un entorno en que se efectúen muchas peticiones de páginas Web públicas producidas dinámicamente, las cuales caduquen basándose en la lógica de la aplicación o en un suceso, tal como un mensaje de base de datos. La duración de la página es finita, pero no puede establecerse un desencadenante de caducidad en el momento de crearla; por lo tanto, los sistemas principales sin una función de colocación en antememoria dinámica e invalidación deben designar este tipo de página con un valor de tiempo de vida de cero.
Si uno o varios usuarios solicitan esta página generada dinámicamente más de una vez a lo largo de su duración, la colocación en antememoria dinámica proporciona una liberación valiosa de la carga a fin de reducir la carga de trabajo en los sistemas principales que alojan contenidos de la red. Utilizar la colocación en antememoria dinámica también mejora el rendimiento de la red brindando una mayor rapidez de respuesta a los usuarios al eliminar retardos en la red y reduciendo el uso del ancho de banda debido a la disminución de viajes a través de Internet.
Funcionando junto con sistemas principales que alojan contenidos, como WebSphere Application Server, o con el componente Proxy de antememoria de Application Server, el componente Load Balancer de Application Server le permite mejorar la disponibilidad y la escalabilidad de la red. (Consulte el Introducción a Edge Components de WebSphere Application Server para leer una introducción dedicada a Edge Components.) Load Balancer se utiliza en las redes de la empresa y se instala entre Internet y los servidores finales de la empresa. Load Balancer actúa como el único punto de presencia de la empresa en Internet aunque la empresa utilice varios servidores finales a causa de la alta demanda o de grandes volúmenes de contenido.
La disponibilidad se consigue mediante el equilibrio de carga y el soporte de sustitución por anomalía.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
El equilibrio de carga mejora la disponibilidad y escalabilidad del sitio Web al agrupar en clúster y de forma transparente los servidores proxy y los servidores de aplicaciones. La escalabilidad de una infraestructura IT mejorará en gran medida porque puede añadirse de forma transparente la potencia del proceso de fondo.
Puede satisfacer la alta demanda duplicando los contenidos en varios sistemas principales, pero, a continuación, necesita una manera de equilibrar la carga entre ellos. El DNS (Servicio de nombres de dominio) puede proporcionar un equilibrio básico de carga de modalidad rotatoria, pero existen varias situaciones en las que no da buen rendimiento.
Una solución más sofisticada para equilibrar la carga entre varios sistemas principales que alojan contenidos es utilizar el componente Dispatcher de Load Balancer, tal como se ilustra en la Figura 5. En esta configuración, todos los sistemas principales que alojan contenidos (las máquinas marcadas como 5) almacenan los mismos contenidos. Están definidos para formar un clúster de carga equilibrada y una de las interfaces de red de la máquina de Load Balancer (4) tiene asignados un nombre de sistema principal y una dirección IP dedicados al clúster. Cuando un usuario final que trabaja en una de las máquinas marcadas como 1 solicita el archivo X, la petición atraviesa Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). Dispatcher intercepta la petición, porque el URL en ella está correlacionado con el nombre de sistema principal y la dirección IP de Dispatcher. Dispatcher determina cuál de los sistemas principales que alojan contenidos del clúster es actualmente el más capacitado para atender a la petición y reenvía la petición a este sistema principal, que, una vez configurado el método de reenvío MAC, devuelve el archivo X directamente al cliente (es decir, el archivo X no pasa por Load Balancer).
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Dispatcher 5--Sistema que aloja contenidosPor omisión, Dispatcher utiliza el equilibrio de carga de modalidad rotatoria como lo hace el DNS, pero incluso así trata algunas de las insuficiencias del DNS. De manera diferente al DNS, rastrea si un sistema principal que aloja contenidos está inaccesible o no disponible y no continúa dirigiendo a los clientes a un sistema principal que aloja contenidos no disponible. Además, considera la carga actual del sistema principal que aloja contenidos rastreando las conexiones nuevas, activas y finalizadas. Es posible seguir optimizando el equilibrio de carga mediante la activación de los componentes de gestor y consejero opcionales de Load Balancer, que rastrean el estado de un sistema principal que aloja contenidos incluso de forma más precisa e incorporan la información adicional al proceso de decisiones del equilibrio de carga. El gestor le permite asignar diferentes pesos a los diferentes factores utilizados en el proceso de decisiones, a fin de personalizar más el equilibrio de carga para el sitio.
El componente Dispatcher de Load Balancer también puede realizar el equilibrio de carga para varias máquinas de Proxy de antememoria. Si el sitio Web de la empresa es popular, es posible que exista una mayor demanda de sus contenidos de la que pueda satisfacer un único servidor proxy eficazmente, lo cual degrada potencialmente el rendimiento del servidor proxy.
Puede tener varios sistemas Proxy de antememoria realizando funciones de proxy para un único sistema principal que aloja contenidos (similar a la configuración que se ilustra en la Figura 1), pero si el sitio es lo suficientemente popular como para necesitar varios servidores proxy, probablemente necesitará también varios sistemas principales que alojan contenidos entre los que Load Balancer realizará el equilibrio de carga. La Figura 6 ilustra esta configuración. El Dispatcher marcado como 4 equilibra la carga de un clúster de dos servidores proxy (5) y el Dispatcher marcado como 7 equilibra la carga de un clúster de tres sistemas principales que alojan contenidos (8).
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Dispatcher 5--servidor proxy 6--Antememoria 7--Dispatcher 8--Sistema que aloja contenidosEl nombre de sistema principal del clúster del Dispatcher marcado como 4 es el nombre de sistema principal que aparece en los URL para los contenidos Web de la empresa (es decir, es el nombre del sitio Web como se ve en Internet). El nombre de sistema principal del clúster para el Dispatcher marcado como 7 no está visible en Internet y así puede ser cualquier valor que desee. Por ejemplo, en la Empresa ABC, un nombre de sistema principal adecuado para el Dispatcher marcado como 4 es www.abc.com, mientras que el Dispatcher marcado como 7 puede tener un nombre del estilo http-balancer.abc.com.
Suponga que un navegador en una de las máquinas de cliente marcadas como 1 necesita acceder al archivo X almacenado en los servidores de contenido marcados como 8. La petición HTTP atraviesa Internet (2) y entra en la red interna de la empresa mediante la pasarela (3). El direccionador dirige la petición al Dispatcher marcado como 4, el cual la pasará al servidor proxy (5) que actualmente esté más capacitado para manejarla según el algoritmo de equilibrio de carga. Si el servidor proxy tiene el archivo X en su antememoria (6), lo devolverá directamente al navegador, evitando el Dispatcher marcado como 4.
Si el servidor proxy no tiene una copia del archivo X en su antememoria, crea una nueva petición que tiene su propio nombre de sistema principal en el campo origen de la cabecera y la envía al Dispatcher marcado como 7. Load Balancer determina cuál de los sistemas principales que alojan contenidos (8) es actualmente el más capacitado para satisfacer la petición y dirige hacia allí la petición. El sistema principal que aloja contenidos recupera el archivo X del almacenamiento y lo devuelve directamente al servidor proxy, evitando el Dispatcher marcado como 7. El servidor proxy colocará el archivo X en antememoria, si procede, para reenviarlo al navegador, evitando el Dispatcher marcado como 4.
Si proporciona acceso de Internet a un gran número de clientes, pueden generar más demanda de acceso a Internet de la que puede proporcionar un solo proxy de forma eficaz. A medida que se sobrecarga el proxy de antememoria con peticiones, los clientes pueden experimentar tiempos de respuesta peores que con el acceso directo a Internet. Y si el proxy de antememoria falla o pasa a estar inaccesible debido a un error de red, el acceso a Internet se hace imposible. La solución es instalar varias máquinas de proxy de antememoria y utilizar el Dispatcher de Load Balancer para equilibrar la carga entre ellos.
Sin el Dispatcher, puede proporcionar un proxy verdaderamente transparente con varias máquinas proxy de antememoria sólo si los direccionadores puede direccionar el mismo tipo de tráfico a más de un proxy de antememoria; no todos los direccionadores dan soporte al mismo. Se puede proporcionar un servicio de proxy de envío regular en varias máquinas de proxy de antememoria sin el Dispatcher pero debe configurar explícitamente los navegadores de cliente para que utilicen una de las máquinas de proxy de antememoria como su proxy primario. Si dicho proxy de antememoria falla, o se sobrecarga o no se puede acceder al mismo, los usuarios no pueden acceder a Internet. Para evitar esta situación, puede crear un archivo PAC (Proxy Automatic Configuration), como se describe en Proxy de antememoria de envío transparente (sólo sistemas Linux), que indica al navegador que efectúe la sustitución por anomalía en uno o más proxies de antememoria secundarios. Un archivo PAC no cubre la necesidad de equilibrar la carga entre las máquinas de proxy de antememoria, no obstante, si un proxy de antememoria recibe muchas más peticiones que otro, su rendimiento puede disminuir y someter de este modo a los clientes del navegador a tiempos de respuesta más lentos. Para que todos los clientes experimenten un rendimiento similar, debe configurar un número de aproximadamente igual de navegadores que utilicen cada proxy de antememoria y realizar manualmente un seguimiento de la distribución para así poder mantener la carga equilibrada mientras añade o suprime navegadores.
Figura 7 muestra una configuración de red en la que Dispatcher equilibra la carga en un clúster de máquinas de proxy de antememoria. Una de las interfaces de red de la máquina de Dispatcher se configura para que tenga el nombre de sistema principal dedicado del clúster y la dirección IP. Los navegadores de cliente se configuran para dirigir las peticiones de Internet al nombre de sistema principal del clúster. Cuando, por ejemplo, una navegador de una de las máquinas de cliente marcada con el 1 necesita acceder al archivo X de un sistema principal de contenido (7), dirige las peticiones al nombre de sistema principal del clúster o dirección en la que Dispatcher (2) la intercepta y la dirige al proxy de antememoria adecuado (3). El proxy de antememoria crea una petición nueva, la pasa a través de la pasarela de la empresa (5) y a través de Internet (6) y, si corresponde, almacena el archivo devuelto en la antememoria (4) como se describe más detalladamente en Proxy de antememoria de envío
Dispatcher detecta cuando una de las máquinas de proxy de antememoria no está disponible y automáticamente direcciona las peticiones al otro. Esto permite concluir una máquina de proxy de antememoria para labores de mantenimiento sin interrumpir el acceso a Internet. Dispatcher tiene muchas opciones de configuración que puede utilizar para controlar los factores que tiene en cuenta en la toma de decisiones de equilibrio de carga. También puede instalar programas de Dispatcher auxiliares en las máquinas de proxy de antememoria para supervisar su estado y devolver la información a Dispatcher. Para obtener información detallada, consulte la publicación WebSphere Application Server Load Balancer Administration Guide. Si se utilizan varios proxies de antememoria puede restar eficacia, ya que más de un proxy de antememoria puede colocar en la antememoria el mismo archivo si varios clientes solicitan el archivo a través de diferentes máquinas de proxy de antememoria. Para eliminar la redundancia, puede configurar RCA (Remote Cache Access) lo que permite que todos los proxies de un grupo definido compartan el contenido de sus antememorias entre sí. Todos los proxies del grupo RCA utilizan el mismo algoritmo para determinar qué proxy de antememoria es responsable de un URL determinado. Cuando un proxy de antememoria intercepta un URL del que no es responsable, pasa la petición al proxy de antememoria responsable. El proxy de antememoria responsable efectúa el trabajo necesario para satisfacer la petición, recuperándola de su antememoria o dirigiendo la petición al sistema principal de contenido relevante y almacenando en la antememoria el archivo devuelto, si corresponde. A continuación, el proxy de antememoria responsable pasa el archivo al proxy de antememoria original, que lo entrega al usuario final de la petición.
En el grupo RCA, si el proxy de antememoria responsable de un URL determinado falla, entonces el proxy de antememoria original que ha recibido la petición del cliente, accederá directamente el sistema principal de contenido (o un servidor de proxy de antememoria de reservad, si se ha definido). Esto significa que los usuarios pueden acceder a los archivos siempre que como mínimo un proxy de antememoria de un grupo RCA funcione correctamente.
Esta configuración satisface una demanda elevada de acceso a Internet ya que utiliza Dispatcher para equilibrar la carga de peticiones a través de varias máquinas de proxy de antememoria. Un problema potencial es que Dispatcher es un punto de anomalía individual. Si falla o pasa a estar inaccesible debido a un error de la red, los clientes del navegador no pueden conectar con el proxy de antememoria o con Internet. La solución es configurar otro Dispatcher como reserva para el Dispatcher primario, como se describe en Figura 8.
Aquí, un navegador que se ejecuta en una de las máquinas marcadas con 1 dirige normalmente su petición de un archivo X al Dispatcher primario (2), que direcciona la petición al proxy de antememoria (4) dependiendo del criterio de equilibrio de carga de Dispatcher. El proxy de antememoria crea una petición nueva, la direcciona a través de la pasarela de la empresa (6,) a través de Internet (7), hasta el sistema principal de contenido (8) y almacena el archivo X devuelto en su antememoria (5), si resulta adecuado (para obtener una descripción más detallada de esta parte del proceso, consulte Proxy de antememoria de envío).
En esta configuración, el Dispatcher (3) de reserva no efectúa el equilibrio de carga siempre que el primario esté operativo. Los Dispatcher primario y de reserva efectúan un seguimiento del estado del otro intercambiando periódicamente mensajes denominados pulsos. Si el Dispatcher de reserva detecta que el primario ha fallado, automáticamente toma la responsabilidad del equilibrio de carga interceptando las peticiones dirigidas al nombre de sistema principal y dirección IP del primario. También se puede configurar dos Dispatcher para obtener una alta disponibilidad mutua. En este caso, cada uno de ellos efectúa activamente el equilibrio de carga para un clúster de proxies de antememoria diferente, actuando simultáneamente como reserva para su colega. Para obtener una descripción adicional, consulte la publicación WebSphere Application Server Load Balancer Administration Guide.
Generalmente, Dispatcher no consume muchos procesos o recursos de memoria y otras aplicaciones pueden ejecutarse en la máquina de Dispatcher. Si resulta importante minimizar los costes del equipo, es incluso posible ejecutar el Dispatcher de reserva en la misma máquina que el proxy de antememoria. La Figura 9 describe una configuración en la que el Dispatcher de reserva se ejecuta en la misma máquina (3) que el proxy de antememoria.
Load Balancer actúa como el único punto de presencia para los sistemas principales que alojan contenidos de la empresa. Esto es beneficioso porque se anuncia el nombre de sistema principal y la dirección del clúster en el DNS en lugar del nombre de sistema principal y dirección de cada sistema principal que aloja contenidos, lo que proporciona un nivel de protección contra ataques accidentales y un aspecto unificado para el sitio Web de la empresa. Para seguir mejorando la disponibilidad del sitio Web, configure otro Load Balancer que actúe como reserva del Load Balancer primario, tal como se ilustra en la Figura 10. Si un Load Balancer falla o se vuelve inaccesible por una anomalía de la red, los usuarios finales todavía podrán llegar a los sistemas principales que alojan contenidos.
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Dispatcher primario 5--Dispatcher de reserva 6--Sistema que aloja contenidosNormalmente, un navegador que se ejecuta en una de las máquinas marcadas como 1 dirige su petición de un archivo X al nombre de sistema principal del clúster que está correlacionado con el Load Balancer primario (4). Dispatcher direcciona la petición al sistema principal que aloja contenidos (6) seleccionado tomando como base los criterios de equilibrio de carga de Dispatcher. El sistema principal que aloja contenidos envía el archivo X directamente al navegador, direccionándolo a través de la pasarela de la empresa (3) por Internet (2), pero evitando Load Balancer.
El Dispatcher de reserva (5) no realizará el equilibrio de carga mientras el primario esté operativo. El Dispatcher primario y el de reserva rastrean mutuamente su estado intercambiando de forma periódica mensajes denominados pulsaciones. Si el Dispatcher de reserva detecta que el primario ha fallado, automáticamente asume la responsabilidad del equilibrio de carga interceptando las peticiones dirigidas a la dirección IP y nombre de sistema principal del clúster del primario.
También es posible configurar dos Dispatcher para la alta disponibilidad mutua. En este caso, cada uno realiza activamente el equilibrio de carga para un clúster diferente de sistemas principales que alojan contenidos, actuando simultáneamente como reserva de su compañero.(En instalaciones de Load Balancer para IPv4 e IPv6 se soporta alta disponibilidad simple, pero no mutua).
Dispatcher no consume normalmente muchos recursos de proceso o de memoria, y pueden ejecutarse otras aplicaciones en la máquina de Load Balancer. Si es vital minimizar los costes del equipo, es posible incluso ejecutar el Dispatcher de reserva en una de las máquinas del clúster donde realice el equilibrio de carga. La Figura 11 ilustra tal configuración, en la que el Dispatcher de reserva se ejecuta en uno de los sistemas principales que alojan contenidos (5) del clúster.
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Dispatcher primario 5--Dispatcher de reserva y sistema que aloja contenidos 6--Sistema que aloja contenidosIMPORTANTE: El componente Direccionamiento basado en el contenido (CBR) está disponible en todas las plataformas soportadas, con las siguiente excepciones:
Como alternativa, para este tipo de instalación, puede utilizar el método cbr de reenvío del componente Dispatcher de Load Balancer para proporcionar direccionamiento basado en contenido de peticiones HTTP y HTTPS sin utilizar el Proxy de antememoria. Consulte la publicación WebSphere Application Server Load Balancer Administration Guide para obtener más información.
Load Balancer para IPv4 e IPv6 sólo soporta el método mac de reenvío del componente Dispatcher. No están soportados los métodos nat y cbr de reenvío.
Funcionando junto con el componente Proxy de antememoria de Application Server, el componente Load Balancer de Application Server le permite distribuir peticiones a varios servidores finales que alojan distintos contenidos. (Consulte el Introducción a Edge Components de WebSphere Application Server para leer una introducción dedicada a Edge Components.)
Si se instala el componente Direccionamiento basado en el contenido (CBR) de Load Balancer junto con el Proxy de antememoria, pueden distribuirse peticiones HTTP basándose en el URL o en otras características determinadas por el administrador, lo que eliminará la necesidad de almacenar contenidos idénticos en todos los servidores finales.
La utilización de CBR es particularmente apropiada si los servidores Web necesitan realizar varias funciones diferentes u ofrecer varios tipos de servicios. Por ejemplo, un sitio Web de un minorista en línea debe mostrar su catálogo, una gran parte del cual es estático, además de aceptar pedidos, lo que significa ejecutar una aplicación interactiva como, por ejemplo, un script CGI (Common Gateway Interface) para aceptar números de artículos e información del cliente. A menudo es más eficaz tener dos conjuntos de máquinas diferentes para que realicen las distintas funciones y utilizar CBR para direccionar los diferentes tipos de tráfico a las diferentes máquinas. De forma similar, una empresa puede utilizar CBR para proporcionar un mejor servicio a los clientes de pago que a los visitantes esporádicos del sitio Web, direccionando las peticiones de pago a servidores Web más potentes.
CBR direcciona las peticiones según las reglas que se escriban. El tipo más común es la regla de contenido, que dirige las peticiones según el nombre de vía de acceso en el URL. Por ejemplo, la Empresa ABC puede escribir reglas que dirijan las peticiones del URL http://www.abc.com/catalog_index.html a un clúster de servidores y de http://www.abc.com/orders.html a otro clúster. También hay reglas que direccionan las peticiones según la dirección IP del cliente que las envía y según otras características. Para obtener una explicación, consulte los capítulos del manual WebSphere Application Server Load Balancer Administration Guide acerca de la configuración de CBR y de las funciones avanzadas de Load Balancer y de CBR. Para obtener las definiciones de sintaxis de las reglas, consulte el apéndice del manual WebSphere Application Server Load Balancer Administration Guide acerca de los tipos de reglas de CBR.
La Figura 12 ilustra una configuración simple en la que el componente CBR de Load Balancer y el Proxy de antememoria están instalados juntos en la máquina marcada como 4 y direccionan las peticiones a tres sistemas principales que alojan contenidos (6, 7 y 8), los cuales alojan contenidos diferentes. Cuando un usuario final que trabaja en una de las máquinas marcadas como 1 solicita el archivo X, la petición atraviesa Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). El servidor proxy intercepta la petición y la pasa al componente CBR de la misma máquina, el cual analiza el URL en la petición y determina que el sistema principal que aloja contenidos 6 contiene el archivo X. El servidor proxy genera una nueva petición del archivo X y, si su función de colocación en antememoria está habilitada, determina si el archivo puede colocarse en antememoria cuando el sistema principal 6 lo devuelva. Si el archivo puede colocarse en antememoria, el servidor proxy almacena una copia en su antememoria (5) antes de pasarlo al usuario final. El direccionamiento de otros archivos funciona de la misma manera: las peticiones del archivo Y van al sistema principal que aloja contenidos 7 y las peticiones del archivo Z van al sistema principal que aloja contenidos 8.
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Proxy de antememoria y componente CBR de Load Balancer 5--Antememoria 6, 7, 8--Sistema que aloja contenidosLa Figura 13 representa una configuración más compleja que es posiblemente adecuada para un minorista en línea. El componente CBR de Load Balancer y el servidor proxy están instalados juntos en la máquina marcada como 4 y direccionan las peticiones a dos máquinas de Load Balancer. La máquina de Load Balancer marcada como 6 equilibra la carga de un clúster de sistemas principales que alojan contenidos (8), los cuales alojan los contenidos mayoritariamente estáticos del catálogo del minorista, mientras que el Load Balancer marcado como 7 equilibra la carga de un clúster de servidores Web que manejan pedidos (9).
Cuando un usuario final que trabaja en una de las máquinas marcadas como 1 accede al URL del catálogo del minorista, la petición atraviesa Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). El servidor proxy intercepta la petición y la pasa al componente CBR de la misma máquina, el cual analiza el URL y determina que la máquina de Load Balancer marcada como 6 maneje este URL. El servidor proxy crea una nueva petición de acceso y la envía a Load Balancer, que determina cuál de los sistemas principales que alojan contenidos, marcados como 8, es actualmente el más capacitado para atender a la petición (según los criterios definidos). Este sistema principal que aloja contenidos pasará el contenido del catálogo directamente al servidor proxy, evitando Load Balancer. Como en el ejemplo anterior, el servidor proxy determina si el contenido puede colocarse en antememoria y, si éste es el caso, lo almacena en su antememoria (5).
Cuando el usuario final ya está preparado para hacer un pedido, éste accede al URL de pedidos del minorista, probablemente mediante un hiperenlace en el catálogo. La petición realiza el mismo recorrido que la petición de acceso al catálogo, excepto que el componente CBR de la máquina 4 la direcciona a la máquina de Load Balancer marcada como 7. Load Balancer la reenvía al servidor Web marcado como 9 que esté más capacitado, el cual responde directamente al servidor proxy. Debido a que la información de pedidos se genera normalmente de forma dinámica, el servidor proxy probablemente no la coloca en la antememoria.
Descripción: 1--Cliente 2--Internet 3--Direccionador/Pasarela 4--Proxy de antememoria y componente CBR de Load Balancer 5--Antememoria 6, 7--Load Balancer 8--Sistema que aloja contenidos 9--Servidor WebLa función CBR de Load Balancer da soporte a la afinidad de cookie. Esto significa que la identidad del servidor que ha atendido a la primera petición de un usuario final se registra en un paquete de datos especial (una cookie) incluido en la respuesta del servidor. Cuando el usuario final accede al mismo URL de nuevo en un período de tiempo establecido y la petición incluye la cookie, CBR direcciona la petición al servidor original en lugar de volver a aplicar las reglas estándares. Normalmente esto mejora el tiempo de respuesta si el servidor tiene información almacenada acerca del usuario final que no necesita obtener de nuevo (por ejemplo, un número de tarjeta de crédito).
Esta parte describe escenarios comerciales en los que se utiliza el producto Edge Components de IBM WebSphere Application Server. Son soluciones arquitectónicamente seguras y comprobadas que pueden proporcionar un excelente nivel de rendimiento, disponibilidad, escalabilidad y fiabilidad.
Esta parte contiene los capítulos siguientes:
Red de la empresa al consumidor
Solución de banca de la empresa al cliente
El sitio Web de comercio electrónico básico constituye una red de la empresa al consumidor. En la primera fase de crecimiento en Internet, las empresas suelen centrarse en crear simplemente una presencia en la Web. Los catálogos de información y productos corporativos se convierten a formatos digitales y pasan a estar disponibles en el sitio Web. Se da pie a que se realicen compras al proporcionar direcciones de correo electrónico, números de teléfono y fax e incluso formularios automatizados. Sin embargo, no están disponibles realmente las compras en línea. Todas las transacciones tienen una latencia inherente dado que las personas tienen que procesar el orden de los pedidos.
En la segunda fase, las empresas eliminan esta latencia y agilizan la operación de ventas implementando carros de la compra seguros para que se produzca la compra en línea directa. La sincronización con bases de datos de depósito y la integración con los sistemas bancarios resultan cruciales para completar estas transacciones comerciales. Un producto que no esté disponible no puede venderse y dicho artículo no podrá cargarse a la cuenta de un cliente. Asimismo, no es posible tomar un producto de inventario y entregarlo a un cliente hasta que no se efectúe una transacción financiera válida.
En la tercera fase, el sitio Web corporativo se desarrollará como un sitio de presentación dinámica en el que el consumidor empieza a adquirir el aspecto de un cliente y se le proporcionan contenidos personalizados.
El ejemplo siguiente incluye Load Balancer y Proxy de antememoria.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
La Figura 14 muestra un sitio Web comercial de pequeñas dimensiones que está diseñado para proporcionar una navegación eficaz a través de los catálogos. Todas las peticiones de cliente pasan por el cortafuegos hacia Dispatcher, el cual las direcciona a un clúster de servidores proxy con antememorias activas que actúan como servidores sustitutos para los servidores Web. Se han colocado Servidores de métrica con los servidores proxy para facilitar a Dispatcher el equilibrio de carga de los datos. Esta organización reducirá la carga de la red en los servidores Web y los aislará del contacto directo con Internet.
La Figura 15 muestra la segunda fase de evolución de un sitio Web comercial que se ha diseñado para proporcionar una navegación eficaz a través de los catálogos, así como carros de la compra rápidos y seguros para los clientes potenciales. Todas las peticiones de cliente se direccionan a la rama correspondiente de la red mediante Dispatcher, que separa las peticiones basándose en el protocolo de Internet. Las peticiones HTTP van al sitio Web estático; las peticiones HTTPS van a la red de compras. El sitio Web estático primario está servido todavía por un clúster de servidores proxy con antememorias activas que actúa como sustituto para los servidores Web. Esta parte de la red refleja la red en la primera fase.
La parte de comercio electrónico del sitio Web también está servida por un clúster de servidores proxy. No obstante, los nodos Proxy de antememoria se han ampliado con varios módulos de conector. El reconocimiento de SSL se descarga en una tarjeta de hardware criptográfico y la autenticación se realiza mediante el conector Access Manager (anteriormente Policy Director). Un conector de Colocación en antememoria dinámica reduce la carga de trabajo en WebSphere Application Server almacenando datos comunes. Un conector en el servidor de aplicaciones invalida objetos de la antememoria dinámica cuando resulta necesario.
Todas las aplicaciones de carros de la compra están enlazadas a la base de datos del cliente que se utilizó para autenticar al usuario. De esta forma se evita que el usuario tenga que escribir la información personal dos veces en el sistema, una para su autenticación y otra para realizar la compra.
Esta red divide el tráfico en función del uso del cliente, eliminando la autenticación SSL intensiva del procesador y los carros de la compra de comercio electrónico del sitio Web primario. Este sitio Web de dos pistas permite que el administrador de red ajuste los diversos servidores para que den un rendimiento excelente según la función que tenga el servidor en la red.
La Figura 16 muestra la tercera fase de la evolución de una red de la empresa al consumidor, en que la Web estática adopta un método de presentación dinámica. El clúster de servidores proxy se ha ampliado para que dé soporte a la colocación en antememoria de contenidos Web dinámicos y al ensamblaje de fragmentos de página escritos de acuerdo con el protocolo ESI (Edge Side Includes). En lugar de utilizar mecanismos de inclusión de la parte del servidor para crear páginas Web en los servidores de contenido y luego propagar estas páginas específicas del cliente, que no pueden colocarse en antememoria, por toda la red, los mecanismos ESI permiten ensamblar páginas a partir de contenidos colocados en antememoria en el extremo de la red y, de este modo, reducir el consumo del ancho de banda y disminuir el tiempo de respuesta.
Los mecanismos ESI son cruciales en este escenario de la tercera fase, en que cada cliente recibe una página de presentación personalizada del sitio Web. Los bloques de creación de estas páginas se recuperan de una serie de servidores WebSphere Application Server. Los servidores de aplicaciones que contienen una lógica de empresa sensible y enlaces a bases de datos seguras se aíslan detrás de un cortafuegos.
La Figura 17 muestra una solución eficaz de banca en línea que es similar a la red de la empresa al consumidor descrita en el Red de la empresa al consumidor. Todas las peticiones de cliente pasan a través del cortafuegos hacia Dispatcher, el cual separa el tráfico según el protocolo de Internet. Las peticiones HTTP pasan a un clúster de servidores proxy con antememorias activas que actúan como servidores sustitutos para los servidores Web. Se han colocado Servidores de métrica con los servidores proxy para facilitar a Dispatcher el equilibrio de carga de los datos. Esta organización reduce la carga de la red en los servidores Web y crea un almacenamiento intermedio adicional entre ellos e Internet.
Las peticiones HTTPS pasan a una red segura diseñada para proporcionar a los clientes información financiera personal y permitir transacciones bancarias en línea. Un clúster de servidores proxy ampliados proporciona escalabilidad al sitio. Estos servidores proxy dan soporte a la colocación en antememoria de contenidos Web dinámicos y al ensamblaje de fragmentos de página escritos de acuerdo con el protocolo ESI (Edge Side Includes). Una tarjeta de hardware criptográfico gestiona los reconocimientos de SSL, a fin de reducir significativamente el proceso necesario del sistema principal de servidor proxy, y Access Manager (anteriormente Policy Director) dirige la autenticación de cliente.
Un conjunto de clústeres de servidores de aplicaciones distribuyen el proceso de las peticiones separando la lógica de empresa, incluida en los componentes EJB, de esta capa de presentación, incluida en servlets y archivos JSP. Cada uno de estos clústeres está gestionado por un servidor de sesiones por separado.
El ejemplo siguiente incluye Load Balancer y Proxy de antememoria.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
La Figura 18 muestra una red de portal Web diseñada para dar soporte a un gran volumen de tráfico a la vez que se proporcionan contenidos personalizados a cada cliente. Para minimizar la carga del proceso en los diversos servidores, ninguna parte de la red transporta tráfico SSL. Puesto que el portal no entrega datos sensibles, la seguridad no representa un asunto importante. Importa que las bases de datos que contienen ID, contraseñas y valores del cliente permanezcan medianamente seguras y sin corrupción, pero este requisito no afecta al rendimiento del resto del sitio Web.
Todas las peticiones de cliente pasan por el cortafuegos hacia Dispatcher, el cual equilibra la carga de la red a través de un clúster de servidores proxy con antememorias activas que actúan como servidores sustitutos para los servidores Web. Se han colocado Servidores de métrica con los servidores proxy para facilitar a Dispatcher el equilibrio de carga de los datos.
El sitio Web dinámico real es un clúster de servidores de aplicaciones que generan fragmentos ESI que pasan a los servidores proxy para el ensamblaje. A causa de una menor preocupación por la seguridad, cada servidor de aplicaciones lleva a cabo todas las funciones necesarias para construir el sitio Web. Todos los servidores de aplicaciones son idénticos. Si un servidor de aplicaciones queda fuera de servicio, el servidor de sesiones puede direccionar las peticiones a los otros servidores, lo que proporcionará una alta disponibilidad para el sitio completo. Asimismo, esta configuración permite una pronta escalada del sitio Web en caso de producirse demasiado tráfico, por ejemplo, el alojamiento de un suceso especial por parte del portal. Pueden configurarse rápidamente servidores proxy y servidores de aplicaciones adicionales en el sitio.
Todos los contenidos estáticos, tales como archivos de imágenes y texto plano, se almacenan en servidores Web por separado y, de esta forma, pueden actualizarse a medida que sea necesario sin riesgo de corrupción para los servidores de aplicaciones más complejos.
El ejemplo siguiente incluye Load Balancer y Proxy de antememoria.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
Esta parte proporciona los procedimientos para la instalación de Edge Components.
Esta parte contiene los capítulos siguientes:
Instalación de Edge Components utilizando el programa de instalación
Instalación del Proxy de antememoria utilizando herramientas de empaquetado del sistema
Instalación de Load Balancer utilizando herramientas de empaquetado del sistema
Este tema proporciona un enlace hacia los requisitos de hardware y software de Edge Components y describe las directrices para la utilización de los navegadores Web con los formularios del Proxy de antememoria de Configuración y Administración y con la ayuda en línea de Load Balancer.
Para obtener información sobre los requisitos de hardware y software para WebSphere Application Server, Versión 6.1 Edge Components, vaya a la página Web siguiente: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Instalación del SDK: Java 2 SDK se instala automáticamente con Load Balancer en todas las plataformas.
Requisitos mínimos relativos al navegador
Para configurar el Proxy de antememoria utilizando los formularios de Configuración y Administración, el navegador debe cumplir con las tareas siguientes:
Para los sistemas Linux y UNIX: Para las versiones recomendadas de los navegadores Mozilla y Firefox, consulte el sitio Web siguiente y siga los enlaces con la página Web de software soportada: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
En sistemas Windows: Para obtener información acerca de las versiones recomendadas de los navegadores Internet Explorer, Mozilla y Firefox, consulte el sitio Web siguiente y siga los enlaces con la página Web de software soportada: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
LIMITACIÓN: Es posible que no se visualice la barra de desplazamiento de la izquierda del formulario de administración si el número de elementos ampliados es demasiado grande para poder visualizarlos en la ventana del navegador. Esto hace que los elementos ampliados de la parte inferior de la lista queden fuera de la ventana de visualización actual del navegador y resulten inaccesibles. Para solucionar este problema, limite el número de elementos ampliados en el menú de la izquierda. Si el número de elementos ampliados es elevado, contraiga algunos de los elementos hasta que los elementos de la parte inferior de la lista figuren en la ventana del navegador.
A fin de visualizar correctamente los formularios, el sistema operativo que actualmente esté visualizando el formulario (aquél en el que reside el navegador) debe contener los juegos de fonts correspondientes al idioma en que esté escrito el formulario. Sin embargo, la interfaz del navegador no necesariamente tiene que estar en el mismo idioma que los formularios.
Por ejemplo, en un sistema Solaris 9 está en ejecución una versión china del servidor proxy. En el sistema principal Solaris, se carga un navegador Mozilla con una interfaz en el idioma inglés. Este navegador se puede utilizar localmente para editar los formularios de Configuración y Administración. (Los formularios se sirven al navegador en el juego de caracteres que utiliza el servidor proxy--en este ejemplo, en chino; sin embargo, puede que los formularios no se visualicen de manera correcta si el navegador y su sistema operativo subyacente no se han configurado bien para que visualicen el juego de caracteres enviado por el servidor proxy.)
Como alternativa, si hay disponible una estación de trabajo Windows con soporte de idioma chino para conectarse remotamente al servidor proxy, es posible cargar una versión china de un navegador Netscape en la estación de trabajo Windows y utilizar este navegador para entrar valores en los formularios. Esta segunda solución tiene la ventaja de mantener una interfaz de idioma coherente para el administrador.
Los juegos de fonts específicos del sistema operativo afectan considerablemente a la visualización de una variedad de idiomas, en particular los de caracteres de doble byte, en los navegadores. Por ejemplo, un juego de fonts chinos en concreto de AIX no tiene exactamente el mismo aspecto que un juego de fonts chinos de plataformas Windows. Esto provoca ciertas irregularidades en el aspecto del texto HTML y los applets de Java en los formularios de Configuración y Administración. Para conseguir un aspecto óptimo, sólo se recomiendan navegadores que se ejecuten en sistemas operativos Windows.
Nota acerca del navegador Mozilla 1.4 en S/390 y PowerPC
El plug-in Java instalado con Mozilla 1.4 debe actualizarse a la versión 1.4.2 o superior para que pueda visualizarse correctamente el formulario de administración. Utilice los pasos siguientes para actualizar el plug-in:
Para utilizar la ayuda en línea de Load Balancer, el navegador debe dar soporte a lo siguiente:
Si utiliza un navegador que no dé soporte a estos requisitos, puede que el resultado sean páginas con formato incorrecto y funciones que quizá no funcionen como es debido.
Este tema proporciona instrucciones para instalar Edge Components por medio del programa de instalación.
Java 2 SDK se instala automáticamente con Load Balancer en todas las plataformas.
Después de la instalación, los scripts del paquete del Proxy de antememoria intentarán iniciar el servidor proxy utilizando la configuración por omisión. Si el puerto 80 está en uso, porque, por ejemplo, lo utiliza otro servidor Web, el servidor proxy no podrá iniciarse.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
Utilice el programa de instalación para instalar Edge Components en el sistema Windows, como se indica a continuación:
Si Edge Components ya está instalado, se abrirá la ventana Opciones de mantenimiento antes de que lo haga la ventana Selección de componentes. Seleccione el botón de selección Modificar y, a continuación, pulse Siguiente. Se abrirá la ventana Selección de componentes.
Limitación: Si utiliza la tecla de tabulación en la ventana del acuerdo de licencia puede cambiar entre las opciones Acepto y No acepto. No obstante, no puede utilizar la tecla de tabulación para las opciones de navegación Atrás, Siguiente o Cancelar. Como solución alternativa, utilice las teclas de Mayúsculas y tabulación para conmutar entre estas opciones de navegación. Asimismo, la tecla Intro sólo funciona en los botones de navegación, por lo tanto, debe utilizar la barra espaciadora para seleccionar las opciones Acepto o No acepto.
Si instala desde el CD, puede utilizar el programa de instalación para instalar el producto Edge Components en los sistemas Linux y UNIX, como se indica a continuación:
# ./installSe abrirá la ventana Bienvenido.
El programa de instalación comienza la instalación de los Edge Components seleccionados y los paquetes necesarios.
Limitación: Si utiliza la tecla de tabulación en la ventana del acuerdo de licencia puede cambiar entre las opciones Acepto y No acepto. No obstante, no puede utilizar la tecla de tabulación para las opciones de navegación Atrás, Siguiente o Cancelar. Como solución alternativa, utilice las teclas de Mayúsculas y tabulación para conmutar entre estas opciones de navegación. Asimismo, la tecla Intro sólo funciona en los botones de navegación, por lo tanto, debe utilizar la barra espaciadora para seleccionar las opciones Acepto o No acepto.
En Red Hat Linux 3.0 Update 3: Cuando ejecuta el programa de instalación para Edge Components, los botones no funcionarán si el panel de la GUI se maximiza y, a continuación, se restaura. Para resolver este problema haga lo siguiente:
En sistemas Linux y UNIX: Si se utiliza el programa de configuración para instalar Edge Components, se puede utilizar el programa de desinstalación de la GUI para desinstalar los Edge Components. No obstante, el programa de desinstalación de la GUI de Edge Components no se puede utilizar para desinstalar un paquete de renovación que se ha instalado utilizando los mandatos nativos. En primer lugar, debe desinstalar el paquete de renovación utilizando los mandatos nativos (los mandatos del sistema operativo) antes de desinstalar los componentes utilizando el programa de desinstalación de la GUI.
Para obtener información sobre cómo utilizar los mandatos nativos, consulte Instalación del Proxy de antememoria utilizando herramientas de empaquetado del sistema y Instalación de Load Balancer utilizando herramientas de empaquetado del sistema.
Este tema proporciona instrucciones para instalar el Proxy de antememoria utilizando las herramientas de empaquetado del sistema.
Después de la instalación, los scripts del paquete del Proxy de antememoria intentarán iniciar el servidor proxy utilizando la configuración por omisión. Si el puerto 80 está en uso, porque, por ejemplo, lo utiliza otro servidor Web, el servidor proxy no podrá iniciarse.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
Mediante el sistema de instalación de paquetes de su sistema operativo, instale los paquetes siguiendo el orden listado en la Tabla 2. El procedimiento especificado a continuación facilita detalles sobre los pasos típicos necesarios para completar esta tarea.
su - root Contraseña: contraseña
cd punto_montaje/directorio_paquete/
En AIX:
installp -acXd ./nombre_paquete
En HP-UX:
swinstall -s source/ nombre_paquete
En Linux:
rpm -i ./nombre_paquete
En Solaris:
pkgadd -d ./nombre_paquete
Componente | Paquetes instalados (en el orden recomendado) |
---|---|
Proxy de antememoria |
|
Documentación de Edge Components |
doc-en_US1 |
Notas:
|
El paquete de documentación contiene sólo la versión en inglés. Las traducciones de la documentación de Edge Components se encuentran en el sitio Web siguiente: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Para desinstalar los paquetes:
En AIX:
installp -u nombre_paquete
Para desinstalar todos los paquetes del proxy de antememoria, utilice el mandato:
installp -u wses
En HP-UX:
swremove nombre_paquete
Para consultar los paquetes del proxy de antememoria instalados, utilice el mandato:
swlist | grep WSES
Los paquetes se deben eliminar por orden inverso al orden en que se han instalado.
En Linux:
rpm -e nombre_paquete
Para consultar los paquetes del proxy de antememoria instalados, utilice el mandato:
rpm -qa |grep -i wses
Los paquetes se deben eliminar por orden inverso al orden en que se han instalado.
En Solaris:
pkgrm nombre_paquete
Para consultar los paquetes del proxy de antememoria instalados, utilice el mandato:
pkginfo | grep WSES
Los paquetes se deben eliminar por orden inverso al orden en que se han instalado.
Este tema describe la instalación de Load Balancer en sistemas AIX, HP-UX, Linux y Solaris:
Dependiendo del tipo de instalación, no se proporcionan todos los paquetes de componentes de Load Balancer que aparecen en esta sección.
El orden recomendado para la instalación de paquetes es ligeramente diferente para las instalaciones de Load Balancer para IPv4 e IPv6. Es importante tener en cuenta que el paquete de componentes de administración se debe instalar después del paquete del componente de Dispatcher. El orden recomendado para la instalación de paquetes para Load Balancer para IPv4 e IPv6 utilizando las herramientas del sistema es: base, licencia, componente Dispatcher, administración, documentación, Metric Server.
Si va a migrar desde una versión anterior de Load Balancer, o si va a volver a instalar un sistema operativo, antes de la instalación puede guardar cualquier archivo de configuración anterior o archivo de script para Load Balancer.
Si finaliza la sesión en una máquina una vez instalado Load Balancer, deberá reiniciar todos los servicios de Load Balancer cuando vuelva a iniciarla.
La Tabla 5 lista los conjuntos de archivos AIX para Load Balancer y el orden de instalación recomendado utilizando la herramienta de instalación de paquetes del sistema.
Componentes de Load Balancer | Catálogos de archivos de AIX |
---|---|
Base | ibmlb.base.rte |
Administración (con mensajes) |
|
Controlador de dispositivo | ibmlb.lb.driver |
Licencia | ibmlb.lb.license |
Componentes de Load Balancer (con los mensajes) |
|
Documentación (con los mensajes) |
|
Servidor de métrica | ibmlb.ms.rte |
El paquete de documentación contiene sólo la versión en inglés. Las traducciones de la documentación de Edge Components se encuentran en el sitio Web siguiente: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Antes de instalar Load Balancer para AIX, asegúrese de lo siguiente:
installp -u ibmlbo, para las versiones anteriores, entre el mandato siguiente:
installp -u ibmndPara desinstalar catálogos de archivos determinados, deberá listarlos específicamente en lugar de indicar el nombre de paquete ibmlb.
Cuando instala el producto, tiene la opción de instalar cualquiera de los elementos siguientes o todos ellos:
Es recomendable utilizar la herramienta SMIT para instalar Load Balancer para AIX porque la SMIT asegura la instalación automática de todos los mensajes.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Paquetes | Mandatos |
---|---|
Base | installp -acXgd dispositivo ibmlb.base.rte |
Administración (con los mensajes) | installp -acXgd dispositivo ibmlb.admin.rte ibmlb.msg.idioma.admin |
Controlador de dispositivo | installp -acXgd dispositivo ibmlb.lb.driver |
Licencia | installp -acXgd dispositivo ibmlb.lb.license |
Componentes de Load Balancer (con los mensajes). Incluye: Dispatcher, CBR, Selector de sitio, Cisco CSS Controller y Nortel Alteon Controller |
installp -acXgd dispositivo ibmlb.componente.rte ibmlb.msg.idioma.lb |
Documentos (con los mensajes) | installp -acXgd dispositivo ibmlb.doc.rte ibmlb.msg.en_US.lb |
Servidor de métrica | installp -acXgd dispositivo ibmlb.ms.rte |
installp -ld dispositivo
Si va a instalar desde un CD, entre el mandato siguiente para desmontar el CD:
unmount /cdrom
Verifique si el producto está instalado entrando el mandato siguiente:
lslpp -h | grep ibmlb
Si se ha instalado todo el producto, este mandato devolverá el resultado indicado a continuación:
ibmlb.base.rte
ibmlb.admin.rte
ibmlb.lb.driver
ibmlb.lb.license
ibmlb.componente.rte
ibmlb.doc.rte
ibmlb.ms.rte
ibmlb.msg.idioma.admin
ibmlb.msg.en_US.doc
ibmlb.msg.idioma.lb
Las vías de acceso de instalación de Load Balancer incluyen:
Este apartado explica cómo instalar Load Balancer en HP-UX utilizando el CD del producto.
Antes de comenzar el procedimiento de instalación, asegúrese de que tiene autorización de raíz para instalar el software:
Si tiene una versión anterior instalada, debería desinstalar esa copia antes de instalar la versión actual. En primer lugar, asegúrese de que ha detenido el ejecutor y el servidor. A continuación, para desinstalar Load Balancer, consulte el apartado Instrucciones para desinstalar los paquetes.
En la Tabla 7 se enumeran los nombres de los paquetes de instalación de Load Balancer y el orden que debe seguir para instalarlos utilizando la herramienta de instalación de paquetes del sistema.
HP-UX no da soporte al entorno local de portugués brasileño (pt_BR). Los entornos locales soportados en HP-UX son:
El procedimiento especificado a continuación facilita detalles sobre los pasos necesarios para completar esta tarea.
su - root Contraseña: contraseña
Emita el mandato de instalación
swinstall -s /origen nombre_paquete
donde origen es la vía absoluta del directorio de la ubicación del paquete, y nombre_paquete es el nombre del paquete.
Por ejemplo, para instalar el paquete base de Load Balancer (ibmlb.base), si realiza la instalación desde la raíz del CD:
swinstall -s /origen ibmlb.base
Para instalar todos los paquetes para Load Balancer emita el mandato siguiente, si va a realizar la instalación desde la raíz del CD:
swinstall -s /origen ibmlb
Emita swlist para enumerar todos los paquetes que ha instalado. Por ejemplo,
swlist -l fileset ibmlb
Utilice el mandato swremove para desinstalar los paquetes. Los paquetes se deben eliminar en el orden inverso al que se han instalado. Por ejemplo, emita lo siguiente:
swremove ibmlbPara desinstalar un paquete individual (por ejemplo, Cisco CSS Controller)
swremove ibmlb.cco
Las vías de acceso de instalación de Load Balancer incluyen:
Este apartado explica cómo instalar Load Balancer en Linux utilizando el CD de Edge Components.
Antes de instalar Load Balancer, asegúrese de lo siguiente:
rpm -e nombrepaqueteAl desinstalar, invierta el orden utilizado para la instalación de los paquetes asegurándose de que los paquetes de administración se desinstalen los últimos.
La imagen de instalación es un archivo que tiene el formato lblinux-versión.tar.
tar -xf lblinux-versión.tarEl resultado es el siguiente conjunto de archivos con la extensión .rpm:
Donde --
El paquete de documentación contiene sólo la versión en inglés. Las traducciones de la documentación de Edge Components se encuentran en el sitio Web siguiente: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
rpm -i paquete.rpm
Sistemas Red Hat Linux: Debido a un problema conocido de Red Hat Linux, debe suprimir los archivos _db* RPM o se producirá un error.
Es importante instalar los paquetes según el orden mostrado en la siguiente lista de los paquetes necesarios de cada componente.
rpm -i --nodeps paquete.rpm
rpm -qa | grep ibmlb
La instalación de todo el producto genera la salida siguiente:
Las vías de acceso de instalación de Load Balancer incluyen:
Si tiene que desinstalar los paquetes, invierta el orden utilizado para la instalación de los mismos asegurándose de que los paquetes de administración se desinstalen los últimos.
Este apartado explica cómo instalar Load Balancer en Solaris utilizando el CD de Edge Components.
Antes de comenzar el procedimiento de instalación, asegúrese de que ha iniciado la sesión como root y de que ha desinstalado cualquier versión anterior del producto.
Para la desinstalación, asegúrese de que se han detenido todos los ejecutores y servidores. Después, entre el mandato siguiente:
pkgrm nombrepaquete
pkgadd -d nombrevíaaccesodonde -d nombrevíaacceso es el nombre de dispositivo de la unidad de CD-ROM o el directorio de la unidad de disco duro donde está ubicado el paquete; por ejemplo: -d /cdrom/cdrom0/.
La siguiente es una lista de los paquetes visualizados y el orden de instalación recomendado.
El paquete de documentación (ibmlbdoc) sólo contiene la versión en inglés. Las traducciones de la documentación de Edge Components se encuentran en el sitio Web siguiente: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Si desea instalar todos los paquetes, escriba simplemente all y pulse Intro. Si desea instalar algunos de los componentes, entre el nombre o nombres correspondientes a los paquetes a instalar, separados por un espacio o una coma, y pulse Intro. Puede que se le solicite que cambie permisos de directorios o archivos existentes. Pulse simplemente Intro o bien responda yes. Es necesario instalar los paquetes que son requisito previo (porque la instalación sigue un orden alfabético, no según los requisitos previos). Si escribe all, responda luego yes a todas las solicitudes y la instalación se completará satisfactoriamente.
Si desea instalar simplemente los componentes de Dispatcher con la documentación y el servidor de métrica, debe instalar los paquetes siguientes: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc e ibmlbms.
pkginfo | grep ibm
Las vías de acceso de instalación de Load Balancer incluyen:
Esta parte proporciona procedimientos para crear varias redes de demostración básicas utilizando Edge Components. No se pretende que se utilicen estas redes en entornos de producción. El proceso de configuración inicial de una red puede aclarar muchos conceptos sobre el extremo de la red a aquellos administradores que no hayan utilizado el producto anteriormente. Si desea información completa acerca de todas las funciones de los componentes así como información de configuración más extensa, consulte los manuales Caching Proxy Administration Guide y Load Balancer Administration Guide.
Los procedimientos permiten que cualquier sistema soportado por el componente se utilice en cualquier nodo.
Esta parte contiene los capítulos siguientes:
Creación de una red de Proxy de antememoria.
Creación de una red de Load Balancer.
La Figura 19 muestra una red de servidor proxy básica que utiliza tres sistemas ubicados en tres nodos de red. Esta red enlaza el servidor proxy a un sistema principal que aloja contenidos dedicado (Servidor HTTP de IBM), el cual se encuentra en el Servidor 2, y el servidor proxy sirve al sistema principal. Esta idea se representa visualmente mediante la situación de Internet entre la estación de trabajo y el Servidor 1.
IMPORTANTE: El Proxy de antememoria está disponible en todas las instalaciones de Edge Components, con las siguientes excepciones:
Para crear una red de Proxy de antememoria, realice estos procedimientos siguiendo el orden indicado a continuación:
Son necesarios los siguientes componentes de sistemas y software:
Instale y configure el Proxy de antememoria tal como se indica a continuación:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
Cuando se le solicite, proporcione al programa htadm un nombre de usuario, una contraseña y un nombre real para el administrador.
Instale y configure el Proxy de antememoria tal como se indica a continuación:
cd "Archivos de programa\IBM\edge\cp\server_root\protect" htadm -adduser webadmin.passwd"
Cuando se le solicite, proporcione al programa htadm un nombre de usuario, una contraseña y un nombre real para el administrador.
Desde la estación de trabajo, realice lo siguiente:
Desde la estación de trabajo, realice lo siguiente:
La Figura 20 muestra una red de Load Balancer básica con tres estaciones de trabajo conectadas localmente en que se utiliza el método de reenvío MAC del componente Dispatcher para equilibrar la carga del tráfico Web entre dos servidores Web. La configuración es similar cuando se realiza el equilibrio de carga de cualquier otro tráfico de aplicaciones UDP sin estado o TCP.
Para crear una red de Load Balancer, realice estos procedimientos siguiendo el orden indicado a continuación:
Son necesarios los siguientes componentes de sistemas y software:
Estación de trabajo | Nombre | Dirección IP |
---|---|---|
1 | servidor1.compañía.com | 9.67.67.101 |
2 | servidor2.compañía.com | 9.67.67.102 |
3 | servidor3.compañía.com | 9.67.67.103 |
Máscara de red = 255.255.255.0 |
Nombre= www.compañía.com IP=9.67.67.104
Añada un alias para www.compañía.com a la interfaz loopback en servidor2.compañía.com y en servidor3.compañía.com.
ifconfig lo0 alias www.compañía.com netmask 255.255.255.0
ifconfig lo0:1 www.compañía.com 127.0.0.1 up
Ahora ha completado todos los pasos de configuración que son necesarios en las dos estaciones de trabajo de servidor Web.
Con Dispatcher, puede crear una configuración utilizando la línea de mandatos, el asistente de configuración o la interfaz gráfica de usuario (GUI).
Si va a utilizar la línea de mandatos, siga estos pasos:
dscontrol executor start
dscontrol cluster add www.compañía.com
dscontrol port add www.compañía.com:80
dscontrol server add www.compañía.com:80:servidor2.compañía.com
dscontrol server add www.compañía.com:80:servidor3.compañía.com
dscontrol executor configure www.compañía.com
dscontrol manager start
Ahora Dispatcher realizará el equilibrio de carga basándose en el rendimiento de servidor.
dscontrol advisor start http 80
Ahora Dispatcher se asegurará de que las peticiones de cliente no se envíen a un servidor Web anómalo.
Ya se ha completado la configuración básica con los servidores conectados localmente.
IMPORTANTE: Con la instalación de Load Balancer para IPv4 e IPv6 la sintaxis del mandato de Dispatcher (dscontrol) es idéntica con una excepción importante. El delimitador para los mandatos dscontrol es el signo de arroba (@) y el signo de dos puntos (:). (Era necesario definir un delimitador que no fuese dos puntos porque el formato IPv6 utiliza dos puntos dentro de su esquema de direccionamiento).
Por ejemplo (del ejemplo de configuración anterior de Dispatcher)
dscontrol port add www.compañía.com@80
dscontrol server add www.compañía.com@80@servidor2.compañía.com
dscontrol server add www.compañía.com@80@servidor3.compañía.com
Para obtener más información, si utiliza una instalación de Load Balancer para IPv4 e IPv6, consulte el capítulo sobre el despliegue de Dispatcher en Load Balancer para IPv4 e IPv6, que incluye información sobre las limitaciones y las diferencias de configuración, en el documento WebSphere Application Server Load Balancer Administration Guide.
Si va a utilizar el asistente de configuración, siga estos pasos:
dsserver
El asistente le guiará, paso a paso, a través del proceso de creación de una configuración básica para el componente Dispatcher. Formula preguntas sobre la red y le orienta a lo largo de la configuración de un clúster para que Dispatcher equilibre la carga del tráfico de un grupo de servidores.
El asistente de configuración contiene los paneles siguientes:
Para iniciar la GUI, siga estos pasos:
dsserver