Conceptos, planificación e instalación para IPv4 Edge Components

WebSphere Application Server
Conceptos, planificación e instalación de Edge Components

Versión 7.0

Número de documento GC31-6918-00

Primera edición (junio de 2008)

Esta edición se aplica a:

WebSphere Edge Components, Versión 7.0

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.

(C) Copyright International Business Machines Corporation 2008. Reservados todos los derechos.
Derechos Restringidos para los Usuarios del Gobierno de los EE.UU. -- Utilización, duplicación o divulgación restringidas por el GSA ADP Schedule Contract con IBM Corp.


Contenido

  • Figuras

  • Acerca de esta publicación
  • A quién va dirigido este manual
  • Accesibilidad
  • Convenios y terminología utilizados en este manual

  • Visión general

  • Presentación de WebSphere Application Server Edge Components
  • Caching Proxy
  • Load Balancer
  • Dispatcher
  • Direccionamiento basado en el contenido
  • Selector de sitio
  • Cisco CSS Controller
  • Nortel Alteon Controller
  • Servidor de métrica
  • Edge Components y la familia WebSphere
  • Tivoli Access Manager
  • WebSphere Portal Server
  • WebSphere Site Analyzer
  • WebSphere Transcoding Publisher
  • Más información sobre Application Server y Edge Components

  • Conceptos y descripciones de Edge Components

  • Almacenamiento en caché
  • Configuraciones de Caching Proxy básico
  • Proxy de almacenamiento en caché inverso (configuración predeterminada)
  • Caching Proxy de envío
  • Almacenamiento en caché avanzado
  • Clústeres de Caching Proxy con equilibrio de carga
  • Contenido dinámico del almacenamiento en caché
  • Funciones de almacenamiento en caché adicionales
  • Rendimiento de la red
  • Hardware de la red
  • Consideraciones sobre la memoria
  • Consideraciones sobre el disco duro
  • Consideraciones sobre la red
  • Consideraciones sobre la CPU
  • Arquitectura de la red
  • Consideraciones sobre la popularidad del sitio web y sobre la carga del servidor proxy
  • Consideraciones sobre el tráfico de red
  • Disponibilidad
  • Equilibrio de carga
  • Equilibrio de carga entre varios sistemas principales que alojan contenidos
  • Equilibrio de carga entre varios servidores proxy inversos
  • Equilibrio de carga entre varios servidores proxy de envío
  • Soporte de migración tras error
  • Direccionamiento basado en el contenido

  • Escenarios

  • Red de la empresa al consumidor
  • Fase 1
  • Fase 2
  • Fase 3
  • Solución de banca de la empresa al cliente

  • Red de portal web

  • Instalación de Edge Components

  • Requisitos para Edge Components
  • Requisitos previos de hardware y software
  • Utilización de los navegadores con los formularios de configuración y administración del Caching Proxy
  • Utilización de los navegadores con la ayuda en línea de Load Balancer
  • Instalación de Edge Components utilizando el programa de configuración
  • Utilización del programa de configuración para Windows
  • Utilización del programa de configuración para Linux y UNIX
  • Instalación del Caching Proxy utilizando las herramientas de empaquetado de sistemas
  • Desinstalación del Caching Proxy utilizando las herramientas del sistema
  • Instalación de Load Balancer utilizando las herramientas de empaquetado de sistemas
  • Instalación para AIX
  • Antes de instalar
  • Procedimiento de instalación
  • Instalación para HP-UX
  • Antes de instalar
  • Procedimiento de instalación
  • Instalación para Linux
  • Antes de instalar
  • Pasos de instalación
  • Instalación para Solaris
  • Antes de instalar
  • Pasos de instalación

  • Actualización de Edge Components

  • Actualización del Caching Proxy para los sistemas operativos de AIX, HP-UX, Linux y Solaris
  • Antes de empezar
  • Instalación de los paquetes para el Caching Proxy en los sistemas operativos de AIX, HP-UX, Linux o Solaris
  • Actualización del Caching Proxy para los sistemas operativos de Windows

  • Rechazo de una actualización

  • Creación de redes con Edge Components

  • Creación de una red del Caching Proxy
  • Flujo de trabajo
  • Revisión de sistemas y software necesarios
  • Creación del Servidor 1 (sistemas Linux y UNIX)
  • Creación del Servidor 1 (sistemas Windows)
  • Configuración del Servidor 1
  • Prueba de la red del Caching Proxy
  • Creación de una red de Load Balancer
  • Flujo de trabajo
  • Revisión de sistemas y software necesarios
  • Configuración de la red
  • Configuración de Dispatcher
  • Configuración utilizando la línea de mandatos
  • Configuración utilizando el asistente de configuración
  • Configuración utilizando la interfaz gráfica de usuario (GUI)
  • Prueba de la red de Load Balancer

  • Figuras

    1. Caching Proxy que actúa como un proxy inverso
    2. Caching Proxy que actúa como un proxy de envío
    3. Caching Proxy que actúa como un proxy de envío transparente
    4. Caching Proxy que actúa como servidor proxy para un clúster con equilibrio de carga
    5. Equilibrio de carga entre varios sistemas principales que alojan contenidos
    6. Equilibrio de carga entre varios servidores de proxy inverso y sistemas principales que alojan contenido
    7. Utilización de Dispatcher para equilibrar la carga entre varios Caching Proxys
    8. Utilización de un Dispatcher primario y otro de reserva para proporcionar acceso a Internet de alta disponibilidad
    9. Ubicación del Dispatcher de reserva en una máquina de Caching Proxy.
    10. Utilización de un Load Balancer primario y uno de copia de seguridad para hacer que el contenido web esté altamente disponible
    11. Ubicación del Load Balancer de copia de seguridad en un sistema principal de contenido
    12. Direccionamiento de solicitudes HTTP con CBR
    13. Equilibrio de carga de solicitudes HTTP direccionadas con CBR
    14. Red de la empresa al consumidor (Fase 1)
    15. Red de la empresa al consumidor (Fase 2)
    16. Red de la empresa al consumidor (Fase 3)
    17. Solución de banca de la empresa al consumidor
    18. Portal Web
    19. Red de demostración del Caching Proxy
    20. Red de demostración de Load Balancer

    Acerca de este manual

    Este manual, WebSphere(R) Conceptos, planificación e instalación para Edge Components, sirve como introducción para WebSphere Application Server Edge Components. 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.


    A quién va dirigido este manual

    El manual Conceptos, planificación e instalación para Edge Components se ha escrito para los administradores de red y sistemas con experiencia 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 de WebSphere Application Server Edge Components.


    Accesibilidad

    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. Estas son las principales funciones de accesibilidad de WebSphere Application Server, Versión 7.0:


    Convenios y terminología que se utilizan en este manual

    Esta documentación utiliza los siguientes convenios tipográficos y de teclas.

    Tabla 1. Convenios utilizados en este manual

    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.
    Ctrl-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(R) para un mandato que no requiere privilegios root.
    # Representa el indicador de shell de mandatos de Linux y UNIX para 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 "Especifique el mandato ls" significa que debe escribir ls en un indicador de mandatos y, a continuación 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.

    Visión general

    Esta parte presenta WebSphere Application Server Edge Components (el Caching Proxy y Load Balancer) y debate su integración con el servidor de aplicaciones. Define también los componentes del Caching Proxy y Load Balancer. Además, en esta sección se presentan otros productos de la familia WebSphere.

    Esta parte contiene los capítulos siguientes:


    Presentación de WebSphere Application Server Edge Components

    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 conjunto 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 del producto WebSphere Application Server. Edge Components se puede utilizar junto con WebSphere Application Server para controlar el acceso de los clientes a los servidores web y para permitir que las empresas ofrezcan un mejor servicio a los usuarios con acceso al contenido basado en web a través de Internet o de 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 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 los componentes Caching Proxy y Load Balancer de Edge Components.


    Caching Proxy

    El Caching Proxy 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 Caching Proxy puede almacenar en caché y servir contenido estático y contenido generado dinámicamente por WebSphere Application Server.

    El Caching Proxy se puede configurar con el rol de un servidor proxy inverso (configuración predeterminada) 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 solicitud. Para obtener más información sobre las configuraciones de proxy de envío e inverso, consulte el apartado Configuraciones de Caching Proxy básico.

    El servidor proxy intercepta las solicitudes 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 solicitudes 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, puede configurar el servidor proxy para que maneje otros protocolos, como el protocolo de transferencia de archivos (FTP) y el Gopher.

    El servidor proxy almacena el contenido que puede almacenarse en caché en una memoria caché local antes de entregarlos al solicitante. Entre los ejemplos de contenidos que pueden almacenarse en memoria caché 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 memoria caché permite al servidor proxy satisfacer las solicitudes subsiguientes que se refieren a los mismos contenidos entregándolos directamente desde la memoria caché local, lo cual es mucho más rápido que recuperarlos otra vez del sistema principal que aloja contenidos.

    Los conectores del Caching Proxy añaden funciones al servidor proxy.

    Puede ampliar todavía más las funciones del Caching Proxy escribiendo módulos de conector personalizados en una interfaz de programación de aplicaciones (API). La API es flexible, fácil de utilizar e independiente de la plataforma. El proxy realiza una secuencia de pasos para cada solicitud de cliente que procesa. Una aplicación de conector modifica o sustituye un paso dentro del flujo de trabajo de proceso de solicitudes, como la autenticación de un cliente o la filtración de solicitudes. 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

    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 del Caching Proxy. 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 solicitudes de datos de los clientes y reenvía cada solicitud al servidor que actualmente tiene más posibilidades de cumplir la solicitud. Es decir, equilibra la carga de solicitudes entrantes entre un conjunto definido de máquinas que atienden al mismo tipo de solicitudes. Load Balancer puede distribuir solicitudes a muchos tipos de servidores, incluidos WebSphere Application Servers y máquinas del Caching Proxy. 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 Servers de equilibrio de carga.

    Si se instala el componente Direccionamiento basado en el contenido junto con el Caching Proxy, incluso pueden distribuirse las solicitudes 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 solicitudes 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.

    Load Balancer incluye los componentes siguientes:

    Dispatcher

    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 solicitud 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.

    Direccionamiento basado en el contenido

    Para los servicios HTTP y HTTPS, el componente Content Based Routing realiza el equilibrio de carga para los servidores basándose en el contenido de la solicitud del cliente. El componente Direccionamiento basado en el contenido trabaja junto con el componente Caching Proxy del servidor de aplicaciones.

    IMPORTANTE: El componente Content Based Routing (CBR) está disponible en todas las plataformas soportadas, con las excepciones siguientes:

    Selector de sitio

    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 solicitudes 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.

    Se da soporte a este componente en todas las instalaciones de Edge Components, con la siguiente excepción:

    Cisco CSS Controller

    Nota:
    El componente Cisco CSS Controller se proporciona con la versión 7.0 de Load Balancer para IPv4, pero es posible que este componente no dé soporte al hardware más reciente. Consulte la página de requisitos previos para ver el hardware soportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

    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.

    Se da soporte a este componente en todas las instalaciones de Edge Components, con la siguiente excepción:

    Nortel Alteon Controller

    Nota:
    El componente Nortel Alteon Controller se proporciona con la versión 7.0 de Load Balancer para IPv4, pero es posible que este componente no dé soporte al hardware más reciente. Consulte la página de requisitos previos para ver el hardware soportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

    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.

    Se da soporte a este componente en todas las instalaciones de Edge Components, con la siguiente excepción:

    Servidor de métrica

    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.


    Edge Components y la familia WebSphere

    La familia IBM WebSphere está diseñada para ayudar a los usuarios a materializar 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. Para obtener una visión general de WebSphere Application Server y sus componentes, consulte el apartado Presentación de WebSphere Application Server Edge Components.


    Tivoli Access Manager

    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 Caching Proxy 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

    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 se puede utilizar el componente Load Balancer del servidor de aplicaciones para el equilibrio de carga adicional y la alta disponibilidad.


    WebSphere Site Analyzer

    WebSphere Site Analyzer (disponible por separado) ayuda a las empresas a prever los problemas de capacidad y de rendimiento. Con Site Analyzer, pueden utilizarse los registros del Caching Proxy y Load Balancer, así como otras ayudas para la gestión, a fin de prever la demanda de recursos adicionales mediante la supervisión, el análisis y los 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

    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 Caching Proxy, 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 Caching Proxy se puede configurar para que invoque a Transcoding Publisher a fin de transformar los datos y codificarlos para otro almacenamiento en memoria caché y una posible reutilización. En la interfaz de postautenticación del Caching Proxy, Transcoding Publisher comprueba después en el servidor proxy si coinciden los contenidos y los requisitos del dispositivo y, si se halla una coincidencia, sirve el contenido de la memoria caché del servidor proxy.


    Más información sobre Application Server y Edge Components

    La documentación siguiente, específica de WebSphere Application Server Edge Components está disponible en el Information Center de Edge Components.

    Hay otra documentación de WebSphere Application Server disponible desde la página de 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:


    Conceptos y descripciones de Edge Components

    Esta parte incluye descripciones detalladas en las que se resaltan algunas de las funciones disponibles con Edge Components. Consulte el apartado Presentación de WebSphere Application Server Edge Components para obtener una visión general del componente Caching Proxy del servidor de aplicaciones.

    Esta parte contiene los capítulos siguientes:

    Almacenamiento en caché

    Rendimiento de la red

    Disponibilidad

    Direccionamiento basado en el contenido


    Almacenamiento en caché

    La función de almacenamiento en caché del Caching Proxy 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 el almacenamiento en caché realizado por el servidor proxy libera la carga de los servidores finales y enlaces de igual a igual. El Caching Proxy puede almacenar en caché contenido estático y contenido generado dinámicamente por WebSphere Application Server. Para proporcionar una mejora en el almacenamiento en caché, el Caching Proxy funciona también junto con el componente Load Balancer del servidor de aplicaciones. Consulte el apartado Presentación de WebSphere Application Server Edge Components para obtener una introducción a estos sistemas.

    IMPORTANTE: El Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:


    Configuraciones de Caching Proxy básico

    El Caching Proxy se puede configurar con el rol de un servidor Caching Proxy inverso (configuración predeterminada) o de un servidor Caching Proxy de envío. Cuando lo utilizan los sistemas principales que alojan contenido, el Caching Proxy se configura en el rol de servidor Caching Proxy inverso, situado entre Internet y los sistemas principales que alojan contenido de empresa. Cuando lo utilizan los proveedores de acceso de Internet, el Caching Proxy se configura con el rol de un servidor Caching Proxy de envío, situado entre un cliente e Internet.

    Caching Proxy inverso (configuración predeterminada)

    Cuando se utiliza una configuración de proxy inverso, las máquinas del Caching Proxy están situadas entre Internet y los sistemas principales que alojan contenido de la empresa. Actuando como sustituto, el servidor proxy intercepta las solicitudes de usuario que llegan desde Internet, las reenvía al sistema principal correspondiente que aloja contenidos, almacena los datos devueltos en la memoria caché y entrega dichos datos a los usuarios a través de Internet. El almacenamiento en caché permite al Caching Proxy satisfacer las solicitudes subsiguientes que se refieren a los mismos contenidos directamente desde la memoria caché, lo cual es mucho más rápido que recuperarlos otra vez del sistema principal que aloja contenidos. Puede almacenarse información en la memoria caché en función de su caducidad, del tamaño que debe tener la memoria caché y de cuándo debe actualizarse la información. La mayor rapidez en las bajadas para los impactos en la memoria caché significa una mejor calidad de servicio para los clientes. En la Figura 1 se muestra esta función básica del Caching Proxy.

    Figura 1. Caching Proxy que actúa como proxy inverso

    Este gráfico muestra la configuración básica de proxy inverso

    En esta configuración, el servidor proxy (4) intercepta las solicitudes cuyos URL incluyen el nombre de sistema principal del sistema principal que aloja contenidos (6). Cuando un cliente (1) solicita el archivo X, la solicitud 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 solicitud, genera una nueva solicitud con su propia dirección IP como dirección de origen y envía la nueva solicitud al sistema principal que aloja contenidos (6).

    El sistema principal que aloja contenidos devuelve el archivo X al servidor de proxy, en lugar de devolverlo directamente al usuario final. Si el archivo puede almacenarse en caché, el Caching Proxy almacena una copia en su memoria caché (5) antes de pasarlo al usuario final. El ejemplo más destacable de contenidos que pueden almacenarse en caché son las páginas de contenido web estático; no obstante, el Caching Proxy proporciona también la capacidad de almacenar en caché y servir el contenido generado de manera dinámica por WebSphere Application Server.

    Caching Proxy de envío

    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 una Caching Proxy de envío junto a la pasarela.

    Cuando se utiliza una configuración de proxy de envío, las máquinas del Caching Proxy se ubican entre Internet y el cliente. El Caching Proxy envía una solicitud de cliente a los sistemas principales que alojan contenido situados entre Internet, guarda en la memoria caché los datos recuperados y entrega los datos recuperados al cliente.

    Figura 2. Caching Proxy que actúa como proxy de envío

    En este gráfico se muestra la configuración básica del proxy de envío

    En la Figura 2 se muestra la configuración del Caching Proxy de envío. Los programas de navegador de clientes (en las máquinas marcadas con 1) se configuran con solicitudes directas al Caching Proxy de envío (2), configurado para interceptar las solicitudes. Cuando un usuario final solicita el archivo X almacenado en el sistema principal de contenido (6), el Caching Proxy de envía intercepta la solicitud, genera una solicitud nueva con su propia dirección IP como la dirección de origen y envía la nueva solicitud 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 Caching Proxy de envío en lugar de devolverlo directamente al usuario final. Si la función de memoria caché del Caching Proxy de envío está habilitada, el Caching Proxy determina si el archivo X se puede seleccionar para guardarlo en la memoria caché 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 almacenar en la memoria caché, el Caching Proxy almacena una copia en su memoria caché (3) antes de pasarla al usuario final. De manera predeterminada, se inhabilita el almacenamiento en caché y el Caching Proxy de envío utiliza una memoria caché, no obstante, puede configurar otros tipos de memoria caché.

    Para la primera solicitud del archivo X, el Caching Proxy 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 Caching Proxy de envío, porque el Caching Proxy de envío tarda un poco más en procesar el paquete de la solicitud original y en examinar en la cabecera del archivo X la información de la memoria caché cuando lo recibe. Utilizar el Caching Proxy de envío tiene mejores resultados cuando otros usuarios solicitan posteriormente el archivo X. El Caching Proxy de envío comprueba que su copia en memoria caché del archivo X continúa siendo válida (no ha caducado), y si es así, sirve el archivo X directamente desde la memoria caché, sin enviar la solicitud a través de Internet al sistema principal de contenido.

    Incluso cuando el Caching Proxy 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 Caching Proxy de envío puede continuar entregando la versión en memoria caché al usuario solicitante.

    Si se configura el Caching Proxy de envío de este modo se considera un proxy de envío porque el Caching Proxy actúa en nombre de los navegadores y envía sus solicitudes a los sistemas principales que alojan contenido a través de Internet. Las ventajas del proxy de envío con la función de almacenamiento en caché son de dos tipos:

    El Caching Proxy puede ejecutar varios protocolos de transferencia de red, incluidos HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) y Gopher.

    Caching Proxy de envío transparente (sólo sistemas Linux)

    Una variación del Caching Proxy de envío transparente es el Caching Proxy de envío. En este rol, el Caching Proxy efectúa la misma función que el Caching Proxy de envío básico, pero lo hace sin que el cliente sea consciente de su presencia. Sólo se da soporte a la configuración del Caching Proxy transparente en sistemas Linux.

    En la configuración descrita en el apartado Caching Proxy de envío, cada navegador de cliente se configura por separado para dirigir las solicitudes a un Caching Proxy de envío determinado. Mantener dicha configuración puede resultar poco práctico, sobretodo para grandes números de máquinas cliente. El Caching Proxy da soporte a varias alternativas que simplifican la administración. Una posibilidad consiste en configurar el Caching Proxy para un proxy transparente, tal y como se muestra en la Figura 3. Del mismo modo que con el Caching Proxy de envío regular, el Caching Proxy transparente se instala en una máquina cerca de la pasarela, pero los programas de navegador de cliente no se configuran para dirigir solicitudes a un Caching Proxy de envío. Los clientes desconocen que existe un proxy en la configuración. En su lugar, se configura un direccionador para interceptar las solicitudes de cliente y dirigirlas al Caching Proxy 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 solicitud al Caching Proxy. El Caching Proxy genera una solicitud nueva con su propia dirección IP como la dirección de origen y envía la solicitud nueva mediante el direccionador (2) a través de Internet (5). Cuando llega el archivo X, el Caching Proxy lo almacena en caché si resulta adecuado (según las condiciones descritas en Caching Proxy de envío) y pasa el archivo al cliente que lo solicita.

    Figura 3. Caching Proxy que actúa como proxy de envío transparente

    Este gráfico muestra la configuración básica del proxy de envío

    Para las solicitudes 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 solicitudes 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 solicitudes web. No es necesario que mantenga los archivos de configuración del proxy central en este caso. El Caching Proxy es compatible con WPAD.


    Almacenamiento en caché avanzada

    Clústeres de Caching Proxy con equilibrio de carga

    Para proporcionar más funciones avanzadas de almacenamiento en caché, utilice el Caching Proxy como proxy inverso junto con el componente Load Balancer. Integrando las posibilidades de almacenamiento en caché y equilibrio de carga, podrá crear una infraestructura de rendimiento en la web que será eficaz y muy manejable.

    En la Figura 4 se muestra cómo se puede combinar el Caching Proxy con Load Balancer para entregar contenidos web de manera eficaz, aunque se produzca una gran demanda. En esta configuración, el servidor proxy (4) se configura para interceptar las solicitudes cuyos URL incluyan el nombre de sistema principal de un clúster de sistemas principales que alojan contenido (7), para los cuales Load Balancer (6) realiza el equilibrio de carga.

    Figura 4. Caching Proxy que actúa como servidor proxy para un clúster con equilibro de carga

    Este gráfico muestra que el servidor proxy actúa como sustituto para un clúster con equilibrio de carga

    Cuando un cliente (1) solicita el archivo X, la solicitud 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 solicitud, genera una nueva solicitud con su propia dirección IP como dirección origen y envía la nueva solicitud 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 solicitud del archivo X. El sistema principal que aloja contenido devuelve el archivo X al servidor de proxy, en lugar de utilizar Load Balancer. El servidor proxy determina si se almacena en caché y lo entrega al usuario final, siguiendo el mismo procedimiento descrito anteriormente.

    Almacenamiento en caché de contenidos dinámicos

    La función avanzada de almacenamiento en caché también la proporciona el conector de Almacenamiento en caché dinámico del Caching Proxy. Cuando se utiliza junto con WebSphere Application Server, el Caching Proxy tiene la capacidad de almacenar en caché, servir e invalidar el contenido dinámico 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 almacenar en memoria caché" porque la lógica estándar de caducidad de memoria caché temporal no asegura su eliminación oportuna. La lógica de caducidad controlada por sucesos del conector de almacenamiento en caché dinámica permite que el servidor proxy almacene en caché el contenido con una fecha de caducidad indefinida. La almacenamiento en caché 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 solicitudes de los clientes. Esto puede aportar las ventajas siguientes:

    La almacenamiento en caché 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.

    Ambos sistemas comparten la responsabilidad de sincronizar la memoria caché dinámica del Caching Proxy y el servidor de aplicaciones. 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 el servidor de aplicaciones y almacenarse en caché en el Caching Proxy. Entonces, el Caching Proxy 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. El contenido de la memoria caché de respuestas del servlet del Caching Proxy es válido hasta que el servidor proxy elimine una entrada porque la memoria caché esté congestionada, hasta que caduque el tiempo de espera predeterminado establecido por la directiva ExternalCacheManager en el archivo de configuración del Caching Proxy, o hasta que el Caching Proxy reciba un mensaje de invalidación indicándole que depure los contenidos de su memoria caché. Los mensajes de invalidación se originan en el WebSphere Application Server que posee el contenido y se propagan a cada Caching Proxy configurado.

    Nota:
    En general, las páginas privadas generadas dinámicamente (como, por ejemplo, una página que muestre el contenido del carro de la compra de un usuario) no pueden ni deben almacenarse en caché en el Caching Proxy. El Caching Proxy sólo puede almacenar en caché y servir páginas privadas cuando esté configurado para realizar la autenticación y autorización, a fin de asegurarse de que las páginas privadas se servirán únicamente a los usuarios pertinentes.

    Funciones de almacenamiento en caché adicionales

    El Caching Proxy ofrece otras funciones avanzadas clave de almacenamiento en caché:


    Rendimiento de la red

    El rendimiento de la red se ve afectado por la introducción de la funcionalidad del Caching Proxy. Utilice el Caching Proxy solo o junto con el Load Balancer para mejorar el rendimiento de la red. Consulte el apartado Presentación de WebSphere Application Server Edge Components para obtener una introducción a estos sistemas.

    El rendimiento del Caching Proxy dentro de la empresa simplemente igualará al del hardware en el que se ejecute y al de la arquitectura global 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 Caching Proxy, así como los ajustes al nivel del sistema operativo, también contribuyen en gran manera al rendimiento del Caching Proxy. 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 memoria caché y valores de hebras activas. Se presenta información detallada sobre la configuración del software de memoria caché 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 Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:


    Hardware de la red

    En este apartado se describen cuestiones relacionadas con el hardware de la red que deben tenerse en cuenta a la hora de incorporar la funcionalidad del Caching Proxy a la red.

    Consideraciones sobre la memoria

    Debe dedicarse una gran cantidad de memoria al servidor proxy. El Caching Proxy puede consumir 2 GB de espacio de direcciones virtuales cuando se configura una gran memoria caché 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 o 4 GB de memoria física. Tenga en cuenta que una memoria caché de sólo memoria es significativamente más rápida que una memoria caché de disco sin procesar, y que este cambio de la configuración puede considerarse en sí una mejora en el rendimiento.

    Consideraciones sobre el disco duro

    Es importante tener una gran cantidad de espacio en disco en la máquina en la que se instale el Caching Proxy. Esto es especialmente cierto cuando se utilizan memorias caché de disco. Leer y grabar en un disco duro es un proceso intensivo para un sistema. Aunque los procedimientos de E/S del Caching Proxy son eficaces, las limitaciones mecánicas de las unidades de disco duro pueden limitar el rendimiento cuando el Caching Proxy está configurado para utilizar una memoria caché 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 memoria caché 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.

    Consideraciones sobre la red

    Los requisitos de red, como velocidad, tipo y número de NIC, así como la velocidad de las conexiones de red con el servidor proxy, afectan al rendimiento del Caching Proxy. 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 solicitudes 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 solicitudes y conseguir una óptima productividad si la conexión con la máquina Caching Proxy es una portadora T1 saturada.

    Consideraciones sobre la CPU

    La unidad central de proceso (CPU) de una máquina de Caching Proxy se puede convertir en un factor limitador. La potencia de la CPU afecta al período de tiempo que tardan en procesarse las solicitudes y el número de CPU existentes en la red afecta a la escalabilidad. Es importante que coincidan los requisitos de la CPU del servidor proxy con el entorno, especialmente para adaptarse a la carga de solicitudes punta a las que atenderá el servidor proxy.


    Arquitectura de la red

    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 esta sección se discuten cuestiones relacionadas con la arquitectura de la red que deben tenerse en cuenta a la hora de incorporar la funcionalidad del Caching Proxy a la red.

    Consideraciones sobre la popularidad del sitio web y sobre la carga del servidor proxy

    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á cierta lentitud en los tiempos de respuesta. Para optimizar el rendimiento de la red, considere la inclusión de máquinas del Caching Proxy agrupadas en clúster con equilibrio de carga, o el uso de una arquitectura de memoria caché compartida con Acceso remoto a memoria caché (RCA) en la arquitectura general de la red.

    Consideraciones sobre el tipo de tráfico

    Las contribuciones principales a un mejor rendimiento parten de las posibilidades de almacenamiento en caché del Caching Proxy. No obstante, la memoria caché del servidor proxy puede convertirse en un cuello de botella si no se configura correctamente. Para determinar la mejor configuración de la memoria caché, será necesario hacer un esfuerzo significativo a fin de analizar las características del tráfico. El tipo, el tamaño, la cantidad y los 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 conozca el tipo de tráfico que el Caching Proxy va a permitir o a servir desde su memoria caché, podrá incluir como factor estas características al configurar el servidor proxy. Por ejemplo, saber que el 80% de los objetos que se almacenarán en memoria caché 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 memoria caché y para determinar el tamaño de la misma. Además, el hecho de saber que la mayor parte del contenido lo componen páginas dinámicas personalizadas que no son candidatas a almacenarse en la memoria caché es también pertinente a la hora de ajustar el Caching Proxy.

    El análisis de las características del tráfico le permite determinar si el uso de una memoria caché de disco o de memoria puede optimizar el rendimiento de la memoria caché. Asimismo, familiarizarse con las características del tráfico de red le permite determinar si puede significar una mejora en el rendimiento el uso la función de almacenamiento en caché dinámica del Caching Proxy.


    Disponibilidad

    Funcionando con los sistemas principales que alojan contenido, como WebSphere Application Server, o con el componente del Caching Proxy del servidor de aplicaciones, el componente Load Balancer del servidor de aplicaciones le permite mejorar la disponibilidad y escalabilidad de la red. (Consulte el apartado Presentación de WebSphere Application Server Edge Components para obtener una introducción a dichos 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 Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:


    Equilibrio de carga

    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.

    Equilibrio de carga entre varios sistemas principales que alojan contenidos

    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 contenido es utilizar el componente Dispatcher de Load Balancer tal y como se muestra en la Figura 5. En esta configuración, todos los sistemas principales que alojan contenido (las máquinas marcadas con 5) almacenan el mismo contenido. Están definidos para formar un clúster con equilibrio de carga 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 solicitud atraviesa Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). El Dispatcher intercepta la solicitud porque su URL está correlacionado con el nombre del sistema principal y la dirección IP del Dispatcher. El Dispatcher determina cuál de los sistemas principales que alojan contenidos del clúster es actualmente el más capacitado para atender a la solicitud y reenvía la solicitud 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 el Load Balancer).

    Figura 5. Equilibrio de carga entre varios sistemas principales que alojan contenido

    Este gráfico muestra el equilibrio de carga entre varios sistemas principales que alojan contenido

    Nota:
    El Dispatcher proporciona tres métodos de envío:

    De manera predeterminada, el 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 disponibles. 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.

    Equilibrio de carga entre varios servidores proxy inversos

    El componente Dispatcher de Load Balancer también puede realizar el equilibrio de carga para varias máquinas de Caching Proxy. 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 con eficacia, lo que ocasionará cierta lentitud en el rendimiento del servidor proxy.

    Puede tener varios sistemas del Caching Proxy realizando funciones de proxy para un único sistema principal de contenido (similar a la configuración que se muestra en la Figura 1). Sin embargo, si el sitio es lo suficientemente popular como para necesitar varios servidores proxy, es posible que necesite también varios sistemas principales que alojen contenido y cuyas cargas se equilibren mediante Load Balancer. En la Figura 6 se muestra esta configuración. El Dispatcher marcado con un 4 equilibra la carga de un clúster de dos servidores proxy (5) y el Dispatcher marcado con un 7 equilibra la carga de un clúster de tres sistemas principales que alojan contenido (8).

    Figura 6. Equilibrio de carga entre varios servidores de proxy inverso y sistemas principales que alojan contenido

    Este gráfico muestra el equilibrio de carga entre varios servidores proxy y sistemas principales que alojan contenido

    El 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 parecido a 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 solicitud HTTP atraviesa Internet (2) y entra en la red interna de la empresa mediante la pasarela (3). El direccionador dirige la solicitud al Dispatcher marcado como 4, que 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 memoria caché (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 memoria caché, crea una nueva solicitud que tiene su propio nombre de sistema principal en el campo de origen de la cabecera y lo envía al Dispatcher marcado como 7. El Load Balancer determina el sistema principal de contenido (8) que está actualmente más capacitado para satisfacer la solicitud y la envía allí. El sistema principal que aloja contenido recupera el archivo X del almacenamiento y lo devuelve directamente al servidor proxy, evitando el Dispatcher marcado como 7. El servidor proxy almacena el caché el archivo X, si corresponde, y lo envía al navegador, evitando el Dispatcher marcado como 4.

    Equilibrio de carga entre varios servidores proxy de envío

    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 Caching Proxy con solicitudes, los clientes pueden experimentar tiempos de respuesta peores que con el acceso directo a Internet. Y si el Caching Proxy 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 del Caching Proxy 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 Caching Proxy sólo si los direccionadores pueden direccionar el mismo tipo de tráfico a más de un Caching Proxy; no todos los direccionadores dan soporte al mismo. Se puede proporcionar un servicio de proxy de envío regular en varias máquinas de Caching Proxy sin el Dispatcher pero debe configurar explícitamente los navegadores de cliente para que utilicen una de las máquinas de Caching Proxy como su proxy primario. Si dicho Caching Proxy 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), tal y como se describe en el apartado Caching Proxy de envío transparente (sólo sistemas Linux), que indica al navegador que realice la sustitución por anomalía de uno o varios Caching Proxys secundarios. Un archivo PAC no cubre la necesidad de equilibrar la carga entre las máquinas de Caching Proxy, no obstante, si un Caching Proxy recibe muchas más solicitudes 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 Caching Proxy y realizar manualmente un seguimiento de la distribución para así poder mantener la carga equilibrada mientras añade o suprime navegadores.

    En la Figura 7 se muestra una configuración de red en la que el Dispatcher equilibra la carga en un clúster de máquinas de Caching Proxy. Una de las interfaces de red de la máquina de Dispatcher se configura para que tenga el nombre de sistema principal dedicado de clúster y la dirección IP. Los navegadores de cliente se configuran para dirigir las solicitudes 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 solicitudes al nombre de sistema principal del clúster o dirección en la que Dispatcher (2) la intercepta y la dirige al Caching Proxy adecuado (3). El Caching Proxy crea una nueva solicitud, la pasa a través de la pasarela empresarial (5) y a través de Internet (6) y, si corresponde, almacena el archivo retornado en su memoria caché (4), tal y como se describe con detalle en el apartado Caching Proxy de envío

    Nota:
    La función de proxy transparente está disponible únicamente en sistemas Linux.

    Figura 7. Utilización de Dispatcher para equilibrar la carga en varios Caching Proxys.

    En este gráfico se muestra el equilibrio de carga entre varios proxys

    Dispatcher detecta cuando una de las máquinas de Caching Proxy no está disponible y automáticamente direcciona las solicitudes al otro. Esto permite concluir una máquina de Caching Proxy 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 Caching Proxy para supervisar su estado y devolver la información a Dispatcher. Para obtener detalles, consulte el manual WebSphere Application Server Load Balancer Administration Guide. Si se utilizan varios Caching Proxys se puede restar eficacia, ya que más de un Caching Proxy puede almacenar en caché el mismo archivo si varios clientes solicitan el archivo a través de diferentes máquinas del Caching Proxy. Para eliminar la redundancia, puede configurar RCA (Remote Cache Access) lo que permite que todos los proxys de un grupo definido compartan el contenido de sus memorias caché entre sí. Todos los proxys del grupo RCA utilizan el mismo algoritmo para determinar qué Caching Proxy es responsable de un URL determinado. Cuando un Caching Proxy intercepta un URL del que no es responsable, pasa la solicitud al Caching Proxy responsable. El Caching Proxy responsable efectúa el trabajo necesario para satisfacer la solicitud, recuperándola de su memoria caché o dirigiendo la solicitud al sistema principal de contenido relevante y almacenando en la memoria caché el archivo devuelto, si corresponde. A continuación, el Caching Proxy responsable pasa el archivo al Caching Proxy original, que lo entrega al usuario final de la solicitud.

    En el grupo RCA, si el Caching Proxy responsable de un URL determinado falla, entonces el Caching Proxy original que ha recibido la solicitud del cliente, accederá directamente el sistema principal de contenido (o un servidor de Caching Proxy de reservad, si se ha definido). Esto significa que los usuarios pueden acceder a los archivos siempre que como mínimo un Caching Proxy 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 solicitudes a través de varias máquinas de Caching Proxy. 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 Caching Proxy ni con Internet. La solución es configurar otro Dispatcher para que actúe como copia de seguridad para el Dispatcher primario, tal y como se muestra en la Figura 8.

    Figura 8. Utilización de un Dispatcher primario y otro de copia de seguridad para proporcionar acceso a Internet de alta disponibilidad.

    En este gráfico se muestra un Dispatcher primario y de copia de seguridad para cargar varios proxys de equilibrio de carga

    Aquí, un navegador que se ejecuta en una de las máquinas marcadas con 1 dirige normalmente su solicitud de un archivo X al Dispatcher primario (2), que direcciona la solicitud al Caching Proxy (4) dependiendo del criterio de equilibrio de carga de Dispatcher. El Caching Proxy crea una nueva solicitud, la direcciona a través de la pasarela empresarial (6) a través de Internet (7) hasta el sistema principal que aloja contenido (8) y almacena el archivo retornado X en su memoria caché (5), si corresponde (para obtener una descripción más detallada de esta parte del proceso, consulte el apartado Caching Proxy 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. 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 solicitudes dirigidas a la dirección IP y nombre de sistema principal 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 Caching Proxys diferente, actuando simultáneamente como reserva para su colega. Para obtener una descripción más detallada, consulte el manual 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 Caching Proxy. En la Figura 9 se muestra una configuración en la que el Dispatcher se ejecuta en la misma máquina (3) que el Caching Proxy.

    Figura 9. Ubicación del Dispatcher de reserva en una máquina de Caching Proxy.

    En este gráfico se muestra un Dispatcher primario y de reserva para equilibrar la carga de varios proxys


    Soporte de sustitución por anomalía

    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 para que actúe como reserva para el Load Balancer primario, tal y como se muestra en la Figura 10. Si un Load Balancer falla o se vuelve inaccesible por una anomalía en la red, los usuarios finales todavía podrán llegar a los sistemas principales que alojan contenidos.

    Figura 10. Utilización de un Load Balancer primario y de reserva para hacer que el contenido web esté altamente disponible

    Este gráfico muestra el uso de un Dispatcher primario y de reserva para hacer que el contenido web esté altamente disponible

    Normalmente, un navegador que se ejecuta en una de las máquinas marcadas como 1 dirige su solicitud de un archivo X al nombre de sistema principal del clúster que está correlacionado con el Load Balancer primario (4). El Dispatcher direcciona la solicitud al sistema principal que aloja contenido (6) seleccionado tomando como base los criterios de equilibrio de carga del 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 realiza un equilibrio de carga, ya que el primario está operativo. Los Dispatchers primario y 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 solicitudes dirigidas a la dirección IP y al nombre de sistema principal del clúster del primario.

    También es posible configurar dos Dispatchers para obtener una 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 las instalaciones de Load Balancer para IPv4 e IPv6, se da soporte a la alta disponibilidad simple, pero no a la alta disponibilidad mutua.)

    Generalmente, el Dispatcher no consume muchos procesos o recursos de memoria, y otras aplicaciones pueden ejecutarse 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 se realice el equilibrio de carga. En la Figura 11 se muestra una configuración en la que el Dispatcher de reserva se ejecuta en uno de los sistemas principales que aloja contenido (5) en el clúster.

    Figura 11. Ubicación del Load Balancer de reserva en un sistema principal que aloja contenido

    Este gráfico muestra el Dispatcher de copiar de seguridad que se ejecuta en un sistema principal que aloja contenido


    Direccionamiento basado en el contenido

    IMPORTANTE: El componente Content Based Routing (CBR) está disponible en todas las plataformas soportadas, con las excepciones siguientes:

    Funcionando junto con el componente Caching Proxy del servidor de aplicaciones, el componente Load Balancer del servidor de aplicaciones le permite distribuir solicitudes a varios servidores de fondo que alojan distinto contenido. (Consulte el apartado Presentación de WebSphere Application Server Edge Components para obtener una introducción a dichos Edge Components.)

    Si se instala el componente Direccionamiento basado en el contenido (CBR) de Load Balancer junto con el Caching Proxy, pueden distribuirse solicitudes 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 solicitudes de pago a servidores web más potentes.

    CBR direcciona las solicitudes según las reglas que se escriban. El tipo más común es la regla de contenido, que dirige las solicitudes según el nombre de vía de acceso en el URL. Por ejemplo, la Empresa ABC puede escribir reglas que dirijan las solicitudes 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 solicitudes 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 sobre la configuración de CBR y sobre las funciones avanzadas de Load Balancer y CBR. Para obtener las definiciones de sintaxis de las reglas, consulte el apéndice del manual WebSphere Application Server Load Balancer Administration Guide sobre los tipos de reglas CBR.

    En la Figura 12 se muestra una configuración simple en la que el componente CBR de Load Balancer y el Caching Proxy se instalan juntos en la máquina marcada como 4 y direccionan solicitudes a tres sistemas principales (6, 7 y 8) que alojan distinto contenido. Cuando un usuario final que trabaja en una de las máquinas marcadas como 1 solicita el archivo X, la solicitud atraviesa Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). El servidor proxy intercepta la solicitud y la pasa al componente CBR de la misma máquina, que analiza el URL de la solicitud y determina que el sistema principal de contenido 6 aloje el archivo X. El servidor proxy genera una nueva solicitud para el archivo X y, si la función de almacenamiento en caché está habilitada, determina si el archivo se puede elegir para el almacenamiento en caché cuando el sistema principal 6 lo devuelve. Si el archivo se puede almacenar en caché, el servidor proxy almacena una copia en su memoria caché (5) antes de pasarlo al usuario final. El direccionamiento de otros archivos funciona de la misma manera: las solicitudes del archivo Y van al sistema principal que aloja contenidos 7 y las solicitudes del archivo Z van al sistema principal que aloja contenidos 8.

    Figura 12. Direccionamiento de solicitudes HTTP con CBR

    Este gráfico muestra el direccionamiento de solicitudes HTTP con CBR

    En la Figura 13 se muestra una configuración más compleja, 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 solicitudes 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 (8) que alojan el contenido, principalmente estático, del catálogo del minorista, mientras que el Load Balancer marcado como 7 equilibra la carga de un clúster de servidores web que gestiona 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 solicitud atraviesa Internet (2) y entra en la red interna de la empresa mediante su pasarela Internet (3). El servidor proxy intercepta la solicitud 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 solicitud 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 solicitud (según los criterios definidos). Dicho sistema principal de contenido pasa el contenido del catálogo directamente al servidor proxy, evitando el Load Balancer. Como en el ejemplo anterior, el servidor proxy determina si el contenido se puede almacenar en caché y, si es así, lo almacena en su memoria caché (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 solicitud realiza el mismo recorrido que la solicitud de acceso al catálogo, salvo porque el componente CBR de la máquina 4 lo dirige a la máquina de Load Balancer marcada como 7. Load Balancer la envía al servidor web marcado como 9 más adecuado, que responde directamente al servidor proxy. Dado que la información de pedidos se genera, habitualmente, de manera dinámica, es posible que el servidor proxy no lo almacene en caché.

    Figura 13. Equilibro de carga de solicitudes HTTP direccionadas con CBR

    Este gráfico muestra el equilibrio de carga de las solicitudes HTTP direccionadas con CBR

    La función CBR de Load Balancer da soporte a la afinidad de cookies. Esto significa que la identidad del servidor que ha atendido a la primera solicitud 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 solicitud incluye la cookie, CBR direcciona la solicitud 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).


    Escenarios

    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

    Red de portal web


    Red de la empresa al consumidor

    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 caso siguiente incluye al Load Balancer y el Caching Proxy.

    IMPORTANTE: El Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:


    Fase 1

    En la Figura 14 se muestra un pequeño sitio web comercial diseñado para proporcionar una navegación eficaz a través de los catálogos. Todas las solicitudes de cliente pasan por el cortafuegos hacia un Dispatcher que direcciona las solicitudes a un clúster de servidores proxy con memorias caché activas que actúan como servidores sustitutos para los servidores web. Se han almacenado 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.

    Figura 14. Red de la empresa al consumidor (Fase 1)

    Este gráfico muestra una red básica de la empresa al consumidor


    Fase 2

    En la Figura 15 se muestra la segunda fase de la evolución para un sitio web comercial diseñado para proporcionar una navegación eficaz en el catálogo y carros de la compra rápidos y seguros para los clientes potenciales. Todas las solicitudes de cliente se direccionan a la rama correspondiente de la red mediante un Dispatcher, que separa las solicitudes basándose en el protocolo de Internet. Las solicitudes HTTP van al sitio web estático; las solicitudes HTTPS van a la red de compras. El sitio web estático primario está servido todavía por un clúster de servidor proxy con memorias caché 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. Sin embargo, los nodos del Caching Proxy 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 almacenamiento en caché 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 memoria caché 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.

    Figura 15. Red de la empresa al consumidor (Fase 2)

    Este gráfico muestra una red de empresa a consumidor de ejemplo


    Fase 3

    En la Figura 16 se muestra la tercera fase de la evolución de una red de la empresa al consumidor, con la web estática adoptando un método de presentación estática. El clúster de servidores proxy se ha ampliado para que dé soporte al almacenamiento en caché 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 almacenarse en memoria caché, por toda la red, los mecanismos ESI permiten ensamblar páginas a partir de contenidos almacenados en memoria caché 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 de 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.

    Figura 16. Red de la empresa al consumidor (Fase 3)

    En este gráfico se muestra una red de ejemplo de la empresa al consumidor


    Solución de banca de la empresa al cliente

    En la Figura 17 se muestra una solución eficaz de banca en línea parecida a la red de la empresa al consumidor que se describe en el apartado Red de la empresa al consumidor. Todas las solicitudes de cliente pasan a través del cortafuegos hacia Dispatcher, el cual separa el tráfico según el protocolo de Internet. Las solicitudes HTTP pasan a un clúster de servidores proxy con memorias caché 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 solicitudes 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 al almacenamiento en caché 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 solicitudes 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 caso siguiente incluye al Load Balancer y el Caching Proxy.

    IMPORTANTE: El Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:

    Figura 17. Solución de banca de la empresa al consumidor

    Este gráfico muestra una solución de banca de la empresa al consumidor de ejemplo


    Red de portal Web

    En la Figura 18 se 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 solicitudes 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 memorias caché 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 solicitudes 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 caso siguiente incluye al Load Balancer y el Caching Proxy.

    IMPORTANTE: El Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:

    Figura 18. Portal web

    Este gráfico muestra un portal web de ejemplo


    Instalación de Edge Components

    Esta parte proporciona los procedimientos para instalar Edge Components.

    Esta parte contiene los capítulos siguientes:

    Requisitos para Edge Components

    Instalación de Edge Components utilizando el programa de configuración

    Instalación del Caching Proxy utilizando las herramientas de empaquetado de sistemas

    Instalación de Load Balancer utilizando las herramientas de empaquetado de sistemas


    Requisitos para Edge Components

    Proporciona un enlace a los requisitos de hardware y software para Edge Components y describe las directrices para utilizar navegadores web con los formularios de configuración y administración del Caching Proxy y con la ayuda en línea de Load Balancer.


    Requisitos previos de hardware y software

    Para obtener información sobre los requisitos de hardware y software soportados para el producto Edge Components de WebSphere Application Server, Versión 7.0, vaya a la siguiente página web: 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.


    Utilización de los navegadores con los formularios de configuración y administración del Caching Proxy

    Requisitos mínimos relativos al navegador

    Para configurar el Caching Proxy 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.

    Nota:
    En sistemas PowerPC Linux de 64 bits, no será posible acceder a los formularios de configuración y administración con el navegador Mozilla porque no hay un SDK disponible para esta arquitectura. También puede acceder a los formularios de configuración y administración desde una máquina distinta con un navegador web soportado.

    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 administración y configuració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 algunas irregularidades en el aspecto del texto HTML y los applets de Java en los formularios de administración y configuració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:

    1. Enlace con http://plugindoc.mozdev.org
    2. Seleccione la plataforma en el apartado de documentación.
    3. Siga las instrucciones del apartado "Java Runtime Environment" para actualizar el plug-in

    Utilización de navegadores con la ayuda en línea de Load Balancer

    Para utilizar la ayuda en línea de Load Balancer, el navegador debe soportar los siguientes elementos:

    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.


    Instalación de Edge Components utilizando el programa de configuración

    Proporciona instrucciones para instalar Edge Components utilizando el programa de configuració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 Caching Proxy intentarán iniciar el servidor proxy utilizando la configuración predeterminada. Si el puerto 80 está en uso, porque, por ejemplo, lo utiliza otro servidor web, el servidor proxy no podrá iniciarse.

    IMPORTANTE: El Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:


    Utilización del programa de configuración para Windows

    Utilice el programa de configuración para instalar Edge Components en el sistema Windows(R), como se indica a continuación:

    1. Asegúrese de que el sistema Windows cumple todos los requisitos de hardware y software (Requisitos para Edge Components).
    2. Conéctese como un usuario con privilegios de administrador.
    3. Inserte el CD-ROM de Edge Components en la unidad de CD-ROM de la máquina. El área de ejecución se inicia automáticamente.
    4. Pulse Iniciar el asistente de instalación para WebSphere Application Server - Edge Components. El programa de configuración se inicia automáticamente. Prepara el Asistente de InstallShield y se abre la ventana Bienvenido.
      Nota:
      Si su máquina no da soporte a la opción Reproducción automática, o si está desactivada, inicie el programa de configuración manualmente ejecutando el programa setup.exe, que se encuentra en el directorio de nivel superior del CD-ROM.
    5. Pulse Siguiente para continuar con la instalación. Se abrirá la ventana Acuerdo de licencia de software.
    6. Lea el acuerdo de licencia y pulse para aceptar todos los términos. Se abrirá la ventana Selección de componentes.

      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.

    7. Seleccione los componentes que han de instalarse.
    8. A fin de cambiar la selección de los subcomponentes que se instalarán para un componente determinado, pulse el nombre del componente para seleccionarlo y, a continuación, pulse Cambiar subcomponentes. Se abrirá otra ventana Selección de componentes que mostrará los subcomponentes del componente activo. Utilice los mismos procedimientos para seleccionar los subcomponentes que van a instalarse, el idioma de los componentes y la ubicación en la que deben instalarse los componentes.
    9. Utilice los menús Idioma actual para seleccionar el idioma o los idiomas en los que desea instalar Edge Components. Los idiomas disponibles aparecen listados en el menú de la izquierda. Los idiomas seleccionados se listan en el menú de la derecha.
    10. Utilice la ventana Selección de componentes para verificar la ubicación de instalación de Edge Components. Puede aceptar el valor predeterminado o puede especificar una ubicación nueva con sólo pulsar Cambiar carpeta.
      Nota:
      Si elige una ubicación de instalación distinta de la predeterminada, asegúrese de que no haya espacios en blanco en el nombre de la vía de acceso, por ejemplo, evite nombres de vías de acceso del tipo C:\Mis Archivos\edgeserver\.
    11. Utilice la ventana Selección de componentes para verificar que haya espacio disponible suficiente en la ubicación de la instalación que ha seleccionado. Si no hay espacio suficiente en la ubicación seleccionada, pulse Cambiar carpeta y especifique una ubicación de instalación nueva.
    12. Después de seleccionar el producto Edge Components, la ubicación de la instalación y los idiomas, pulse Siguiente. Revise la información en la ventana Confirmación de la instalación que se abre. Si desea cambiar una o más opciones, pulse Anterior para volver a la ventana Selección de componentes y, a continuación, realice los cambios. Tras verificar las opciones, pulse Finalizar.
    13. El programa de configuración del producto Edge Components empieza la instalación de los componentes de Edge Components seleccionados, y de GSK si es necesario, en la ubicación de instalación que se ha especificado.
    14. Se abrirá la ventana Instalación finalizada. Si desea leer el archivo ReadMe (léame) de Edge Components, asegúrese de que esté seleccionado el recuadro de selección Sí, deseo ver el archivo ReadMe. Se abrirá el archivo Léame en el navegador que tenga definido de manera predeterminada.
    15. Asegúrese de tener seleccionado el recuadro de selección Sí, deseo reiniciar el sistema y, a continuación, pulse Finalizar. Si ha optado por ver el archivo Léame, la máquina se reiniciará cuando cierre la ventana del navegador que muestra el archivo. De lo contrario, el programa de configuración del producto Edge Components se cerrará de inmediato y la máquina se reiniciará. Tenga en cuenta que debe reiniciar la máquina antes de poder utilizar los Edge Components que acaba de instalar.

    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.


    Utilización del programa de configuración para Linux y UNIX

    Si está realizando la instalación desde el CD, puede utilizar el programa de configuración para instalar Edge Components en los sistemas Linux y UNIX, como se indica a continuación:

    1. Asegúrese de que el servidor del Compruebe que cumple todos los requisitos de hardware y software descritos en el apartado Requisitos para Edge Components.
    2. Conéctese como superusuario, normalmente root.
    3. Inserte el CD-ROM de Edge Components en la unidad de CD-ROM de la máquina. Si fuera necesario, monte el CD-ROM.
    4. Cambie el directorio de trabajo por el directorio de nivel superior del CD-ROM.
    5. Invoque el programa de configuración especificando el siguiente mandato:
      # ./install
      
      Se abrirá la ventana Bienvenido.
    6. Pulse Siguiente para continuar con la instalación. Se abrirá la ventana Acuerdo de licencia de software.
    7. Lea el acuerdo de licencia y pulse para aceptar todos los términos. Se abrirá la ventana Selección de idioma.
    8. Seleccione los idiomas que debe soportar esta instalación de Edge Components. Pulse Siguiente. Se abrirá la ventana Selección de componentes.
    9. Seleccione los componentes que han de instalarse.
    10. Pulse Siguiente. Se abrirá la ventana Confirmación de la instalación.
    11. Revise la información en la ventana Confirmación de la instalación. Si desea cambiar una o más opciones, pulse Anterior para volver a la ventana Selección de componentes y a continuación realice los cambios. Tras verificar las opciones, pulse Continuar.

      El programa de configuración empieza la instalación de los Edge Components seleccionados y los paquetes necesarios.

    12. Se abrirá la ventana Resumen de los resultados de la instalación. Revise los resultados y, a continuación, pulse Finalizar.

    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 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 mandatos nativos, consulte las secciones Instalación del Caching Proxy utilizando las herramientas de empaquetado de sistemas e Instalación de Load Balancer utilizando las herramientas de empaquetado de sistemas.


    Instalación del Caching Proxy utilizando las herramientas de empaquetado de sistemas

    Proporciona instrucciones para instalar el Caching Proxy utilizando las herramientas de empaquetado del sistema.

    Después de la instalación, los scripts del paquete del Caching Proxy intentarán iniciar el servidor proxy utilizando la configuración predeterminada. Si el puerto 80 está en uso, porque, por ejemplo, lo utiliza otro servidor web, el servidor proxy no podrá iniciarse.

    IMPORTANTE: El Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:

    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 siguiente muestra los pasos típicos necesarios para completar esta tarea.

    1. El CD de Edge Components en la unidad de CD-ROM y monte la unidad, si es necesario.
    2. Conéctese como superusuario local root.
      su - root
      Password: contraseña
      
    3. Cambie al directorio adecuado del CD.
      cd punto_montaje/directorio_paquete/
      
    4. Instale los paquetes.

      En AIX(R):

      installp -acXd ./nombre_paquete
      

      En HP-UX:

      swinstall -s source/ nombre_paquete
      

      En Linux:

      rpm -i ./nombre_paquete
      

      En Solaris:

      pkgadd -d ./nombre_paquete
      

    Tabla 2. Componentes del Caching Proxy

    Componente Paquetes instalados (en el orden recomendado)
    Caching Proxy
    1. gskit7
    2. icu
    3. admin
    4. msg-cp-idioma
    5. cp

    Documentación de Edge Components

    doc-en_US1

    Notas:

    1. La documentación de Load Balancer se suministra en dos paquetes. El paquete doc-en_US incluye toda la documentación de Edge Components, incluidos los documentos de Load Balancer, y los coloca en el directorio ../edge/doc/. El paquete de documentación asociado a las instalaciones de Load Balancer (Instalación de Load Balancer utilizando las herramientas de empaquetado de sistemas) instala sólo los documentos de Load Balancer y los coloca en un subdirectorio del archivo ../edge/lb/.


    Tabla 3. Nombres de archivos de los paquetes de AIX, HP-UX y Solaris

    Nombre de paquete genérico Conjunto de archivos AIX Catálogo de archivos de HP-UX Nombre de archivo Solaris
    admin wses_admin.rte WSES-ADMIN WSESadmin
    cp wses_cp.base WSES-CP WSEScp
    doc wses_doc.en_US WSES-DOC-en_US WSESdocen
    gskit7 gskkm.rte gsk7bas gsk7bas
    icu wses_icu.rte WSES-ICU WSESicu
    msg-cp-idioma wses_cp.msg.idioma 1 .base WSES-cpmidioma2 WSEScpmidioma3

    Notas:

    1. En AIX, la variable idioma hace referencia a uno de los códigos específicos del idioma siguientes: en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW.

    2. En HP-UX, la variable idioma hace referencia a la sustitución de uno de los códigos específicos del idioma: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW. (HP-UX no da soporte al portugués de Brasil (pt_BR).)

    3. En Solaris, la variable idioma hace referencia a la sustitución de uno de los códigos de idioma específicos siguientes: br, cn, cw, de, en, es, fr, it, ja, kr.


    Tabla 4. Nombres de archivo de paquetes de Linux

    Nombre de paquete genérico Nombre de archivo Linux
    admin WSES_Admin_Runtime-versión-release 1.hardw2.rpm
    cp WSES_CachingProxy-versión_release1.hardware2.rpm
    doc WSES_Doc_en_US-versión_release1.hardware2.rpm
    gskit7 gsk7bas.rpm
    icu WSES_ICU_Runtime-release-versión 1.hardw2.rpm
    msg-cp-idioma WSES_CachingProxy_msg_idioma3-release-versión 1.hardw2.rpm

    Notas:

    1. versión_release es el release actual, por ejemplo: 6.1.0-0

    2. La variable hardw hace referencia a la sustitución de uno de los siguientes: i686, s390, ppc64.

    3. La variable idioma hace referencia a la sustitución de uno de los siguientes códigos específicos del idioma: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, pt_BR, zh_CN, zh_TW.

    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.


    Desinstalación del Caching Proxy utilizando las herramientas del sistema

    Para desinstalar los paquetes:

    En AIX:

    installp -u nombre_paquete
    

    Para desinstalar todos los paquetes del Caching Proxy, utilice el mandato:

    installp -u wses
    

    En HP-UX:

    swremove nombre_paquete
    

    Para consultar los paquetes del Caching Proxy 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 Caching Proxy 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 Caching Proxy instalados, utilice el mandato:

    pkginfo | grep WSES
    

    Los paquetes se deben eliminar por orden inverso al orden en que se han instalado.


    Instalación de Load Balancer utilizando las herramientas de empaquetado de sistemas

    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.

    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 termina la sesión en una máquina una vez instalado Load Balancer, tendrá que reiniciar todos los servicios de Load Balancer cuando vuelva a iniciarla.


    Instalación para AIX

    En la Tabla 5 se muestran todos 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.

    Tabla 5. Conjuntos de archivos de AIX

    Componentes de Load Balancer Catálogos de archivos de AIX
    Base ibmlb.base.rte
    Administración (con los mensajes)
    • ibmlb.admin.rte
    • ibmlb.msg.idioma.admin

    Controlador de dispositivo ibmlb.lb.driver
    Licencia ibmlb.lb.license
    Componentes de Load Balancer (con mensajes)
    • ibmlb.componente.rte
    • ibmlb.msg.idioma.lb

    Documentación (con los mensajes)
    • ibmlb.doc.rte
    • ibmlb.msg.en_US.doc

    Servidor de métrica ibmlb.ms.rte

    Notas:

    1. La variable componente puede sustituirse por: disp (dispatcher), cbr (CBR), ss (Selector de sitio), cco (Cisco CSS Controller) o nal (Nortel Alteon Controller).

    2. La variable idioma se puede sustituir por lo siguiente: en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW

    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

    Antes de instalar Load Balancer para AIX, asegúrese de lo siguiente:

    Cuando instala el producto, tiene la opción de instalar cualquiera de los elementos siguientes o todos ellos:

    Procedimiento de instalación

    Se recomienda utilizar la herramienta SMIT para instalar Load Balancer para AIX, porque garantiza que todos los mensajes se instalen automáticamente.

    Utilización de la herramienta SMIT para instalar Load Balancer para AIX

    1. Seleccione Instalación y mantenimiento de software.
    2. Seleccione Instalar y actualizar software.
    3. Seleccione Instalar y actualizar desde el último software disponible.
    4. Entre el dispositivo o el directorio que contenga los catálogos de archivos.
    5. En el campo *SOFTWARE a instalar, entre la información apropiada para especificar las opciones (o seleccione Listar).
    6. Pulse Bien.
    7. Cuando el mandato se complete, pulse Hecho.
    8. Cierre la SMIT seleccionando Salir de Smit en el menú Salir o pulsando la tecla F12. En caso de utilizar SMITTY, pulse la tecla F10 para cerrar el programa.

    Instalación de Load Balancer desde la línea de mandatos

    1. Si va a instalar desde un CD, entre los mandatos siguientes para montar el CD:
      mkdir /cdrom
      mount -v cdrfs -p -r /dev/cd0 /cdrom
      
    2. Consulte la tabla siguiente para determinar qué mandato o mandatos especificar para instalar los paquetes de Load Balancer deseados para AIX:

      Tabla 6. Mandatos de instalación de AIX

      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 mensajes). Incluye: Dispatcher, CBR, Site Selector, 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
      donde dispositivo es:
    3. Asegúrese de que la columna de resultados del resumen contenga SATISFACTORIO para cada componente de Load Balancer que instale (APLICAR). No continúe hasta que todas las partes que desea instalar se hayan aplicado satisfactoriamente.
      Nota:
      Para generar una lista de catálogos de archivos de un dispositivo especificado, incluidos todos los catálogos de mensajes disponibles, entre:
      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
     
    

    Entre las vías de acceso de instalación de Load Balancer se incluyen las siguientes:


    Instalación para HP-UX

    En esta sección se explica cómo instalar Load Balancer en HP-UX utilizando el CD del producto.

    Antes de instalar

    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.

    Procedimiento de instalación

    En la Tabla 7 se muestran los nombres de los paquetes de instalación para Load Balancer y el orden que se debe seguir para instalar los paquetes utilizando la herramienta de instalación de paquetes del sistema.

    Tabla 7. Detalles de instalación de los paquetes de HP-UX para Load Balancer

    Descripción del paquete Nombre del paquete de HP-UX
    Base ibmlb.base
    Administración y mensajes ibmlb.admin ibmlb.nlv-idioma
    Licencia de Load Balancer ibmlb.lic
    Componentes de Load Balancer ibmlb.componente
    Documentación ibmlb.doc
    Servidor de métrica ibmlb.ms

    Notas:

    1. La variable idioma se puede sustituir por uno de los siguientes códigos específicos del idioma: de_DE, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW.

    2. La variable componente hace referencia a la sustitución de una de las siguientes: disp (dispatcher), cbr (CBR), ss (Selector de sitio), cco (Cisco CSS Controller) o nal (Nortel Alteon Controller).

    3. El paquete de documentación (ibmlb.doc) 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.

    HP-UX no da soporte al entorno local de portugués de Brasil (pt_BR). Los entornos locales soportados en HP-UX son:

    Instrucciones para instalar los paquetes

    El procedimiento especificado a continuación facilita detalles sobre los pasos necesarios para completar esta tarea.

    1. Conéctese como superusuario local root.
      su - root
      Password: contraseña
      
    2. Emita el mandato de instalación para instalar los paquetes

      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
      
    3. Compruebe la instalación de los paquetes de Load Balancer

      Emita swlist para enumerar todos los paquetes que ha instalado. Por ejemplo,

      swlist -l fileset ibmlb
       
      

    Instrucciones para desinstalar los paquetes

    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:

    Entre las vías de instalación de Load Balancer se incluyen las siguientes:


    Instalación para Linux

    En esta sección se explica cómo instalar Load Balancer en Linux utilizando el CD de Edge Components.

    Antes de instalar

    Antes de instalar Load Balancer, asegúrese de lo siguiente:

    Pasos de instalación

    1. Inserte el soporte de Edge Components o baje el producto del sitio web e instale la imagen de instalación utilizando RPM (Red Hat Packaging Manager).

      La imagen de instalación es un archivo que tiene el formato lblinux-versión.tar.

    2. Descomprima el archivo tar en un directorio temporal entrando el mandato siguiente:
      tar -xf lblinux-versión.tar
      
      El 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.

    3. Desde el directorio en el que se encuentren los archivos RPM, emita el mandato para instalar cada paquete. Por ejemplo:
      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.

      Nota:
      Como mínimo, uno de los archivos RPM requiere que Java(TM) esté instalado y registrado en la base de datos RPM. Si se ha instalado Java, pero no se ha registrado en la base de datos RPM, utilice el mandato de instalación con la opción sin dependencias, como se indica a continuación:
      rpm -i --nodeps paquete.rpm 
      
    4. Verifique si el producto se ha instalado. Entre el mandato siguiente:
      rpm -qa | grep ibmlb
      

      La instalación de todo el producto genera la salida siguiente:

    Entre las vías de instalación de Load Balancer se incluyen las siguientes:

    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.


    Instalación para Solaris

    En esta sección se explica cómo instalar Load Balancer en Solaris utilizando el CD de Edge Components.

    Antes de instalar

    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. A continuación, especifique el mandato siguiente:

    pkgrm nombre_paquete
    

    Pasos de instalación

    1. Inserte el CD-ROM que contiene el software Load Balancer en la unidad correspondiente.
    2. En el indicador de mandatos, entre el mandato siguiente:
      pkgadd -d nombre_vía_acceso
      
      donde -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.

    3. Verifique si el producto se ha instalado. Emita el mandato siguiente:
      pkginfo | grep ibm
      

    Entre las vías de acceso de instalación de Load Balancer se incluyen las siguientes:


    Actualización de Edge Components

    Puede obtener el fixpack de Edge Components para los sistemas operativos AIX, HP-UX, Linux, Solaris Operating System o Microsoft Windows de las siguientes maneras:

    Para obtener información sobre los sistemas operativos soportados, consulte el documento Requisitos del sistema detallados de WebSphere Application Server.

    Puede encontrar el enlace a los paquetes de renovación o fixpacks para Edge Components en el sitio de soporte para WebSphere Application Server.

    1. Encuentre en release de servicio correctivo al que está realizando la actualización y siga el enlace al sitio de descargas.
    2. Siga las instrucciones del sitio para descargar el paquete de renovación de Edge Components.
    Nota:
    También puede descargarlos últimos fixpacks de Edge Components del servidor FTP de Edge Components.

    Consulte las secciones siguientes para actualizar las instrucciones:

    Para obtener instrucciones sobre cómo actualizar Load Balancer, consulte las publicaciones Load Balancer for IPv4 Administration Guide o Load Balancer for IPv4 and IPv6 Administration Guide.


    Actualización del Caching Proxy para los sistemas operativos de AIX, HP-UX, Linux y Solaris


    Antes de empezar

    Tenga en cuenta los elementos siguientes antes de continuar con la instalación del paquete de renovación o el fixpack.


    Instalación de los paquetes para el Caching Proxy en los sistemas operativos de AIX, HP-UX, Linux o Solaris

    Mediante las herramientas de instalación de paquetes del sistema operativo, instale los paquetes del Caching Proxy en el orden correcto. Consulte la tabla 4 para obtener una lista de todos los paquetes de Edge Components y el orden en que debe instalarlos. El procedimiento siguiente muestra los pasos típicos necesarios para completar esta tarea.

    1. Conéctese como superusuario local root.
      su - root
      Contraseña: contraseña
      
    2. Detenga el proceso del Caching Proxy.
    3. Vaya al directorio que contiene los archivos de instalación. Por ejemplo, escriba lo siguiente en un indicador de mandatos:
      cd download_package_directory/
      
    4. Instale los paquetes utilizando los mandatos de instalación desde la tabla siguiente. El orden de instalación de los paquetes para el paquete de renovación o el fixpack es el siguiente:
      1. gskit - Global Security Kit
      2. icu - Tiempo de ejecución de ICU
      3. admin - Ejecución administrativa
      4. cp messages - Mensajes del Caching Proxy
      5. cp - Caching Proxy
      6. documentation - opcional

      Tabla 8. Directivas específicas del sistema para instalar el Caching Proxy

      Directivas específicas del sistema para instalar el Caching Proxy
      Sistema operativo Mandatos
      AIX
      installp -acXd origen nombre_paquete
      

      donde origen es el directorio de ubicación del paquete y nombre_paquete es el nombre del paquete.

      Por ejemplo:

      1. El mandato siguiente instala el paquete de administración, que se denomina wses_admin.rte, cuando el paquete reside en el directorio actual:
        installp -acXd . wses_admin.rte
        
      2. El mandato siguiente instala el paquete de administración cuando los paquetes residen en el directorio /tmp.
        installp -acXd /tmp wses_admin.rte
        

      Si está utilizando la herramienta SMIT (System Management Interface Tool):

      1. Seleccione la opción install_latest.
      2. Establezca el valor del campo de actualizaciones de software COMMIT en yes.
      HP-UX
      swinstall -s /origen nombre_paquete
      

      donde origen es el directorio de ubicación del paquete y nombre_paquete es el nombre del paquete.

      Por ejemplo, el mandato siguiente instala el paquete de administración para el Caching Proxy, que se denomina WSES-ADMIN, cuando los paquetes residen en el directorio actual:

      swinstall -s /admin WSES-ADMIN 
      

      Para verificar la instalación de los paquetes, emita el mandato swlist para listar todos los paquetes que ha instalado. Por ejemplo, emita los mandatos siguientes para listar todos los paquetes instalados para el Caching Proxy:

      swlist gsk* swlist WSES*
      
      Linux
      rpm -iv --replacefiles nombre_paquete
      

      donde nombre_paquete es el nombre del paquete.

      Por ejemplo, utilice el mandato siguiente:

      rpm -iv --replacefiles WSES_Admin_Runtime-6.1.0-1.686.rpm
      
      Nota:
      No utilice la opción -U. La opción --replacefiles es necesaria para la mayoría de los paquetes. Si utiliza esta opción con paquetes que no la necesita, la instalación no se verá afectada. Tras la instalación, las versiones instaladas anteriormente de los nuevos paquetes seguirán en la máquina. No las desinstale.
      Solaris
      pkgadd -d origen nombre_paquete
      

      donde origen es el directorio de ubicación del paquete y nombre_paquete es el nombre del paquete.

      Por ejemplo:

      • El mandato siguiente instala el paquete de administración, que se denomina WSESadmin, cuando los paquetes se encuentran en el directorio actual:
        pkgadd -d . WSESadmin
        
      • El mandato siguiente instala el paquete de administración cuando los paquetes residen en el directorio /tmp:
        pkgadd -d /tmp WSESadmin
        
      • Para instalar GSKit, el mandato siguiente instalará el paquete sobre una versión anterior:
        pkgadd -a ./admin -d . gsk7bas
        

      Para utilizar la instalación silenciosa, utilice la opción -a y especifique un archivo de administración. Se proporciona un archivo de administración, denominado instadm, con los paquetes que se están instalando.

      Tras la instalación, las versiones instaladas anteriormente de los nuevos paquetes seguirán en la máquina. No las desinstale.

    En esta tabla se muestran todos los paquetes que se entregan con el Caching Proxy y el orden de instalación necesario. Instale los paquetes que se incluyen en el paquete de renovación o el fixpack siguiendo el orden que se especifica en la tabla siguiente.

    Nota:
    No todos los paquetes que aparecen aquí se entregan con el paquete de renovación o el fixpack. Actualice sólo los paquetes que se entregaron con el paquete de renovación o el fixpack y que se han instalado con anterioridad en el sistema.

    Tabla 9. Lista de paquetes

    Lista de paquetes
    Componentes instalados Actualice los paquetes (listados de manera genérica) en este orden
    Caching Proxy
    1. gskit7 -- Global Security Kit
    2. icu - Tiempo de ejecución de ICU
    3. admin -- Ejecución administrativa
    4. msg-cp-lang -- Mensajes
    5. cp -- Caching Proxy

    Documentación de Edge Components doc-lang

    Después de instalar una actualización para Edge Components, se mantiene la configuración anterior para Edge Components. Cuando se proporcionan nuevas funciones o mejoras con un paquete de renovación o un fixpack, es posible que sea necesario añadir directivas a los archivos de configuración para habilitar las funciones.


    Actualización del Caching Proxy para los sistemas operativos de Windows

    Utilice el programa de configuración para el Caching Proxy, como se indica a continuación:

    1. Para evitar que se inicie el Load Balancer actualmente instalado, edite los scripts de inicio que ha creado para suprimir temporalmente todos los mandatos que van a iniciar Load Balancer tras el rearranque.
    2. Asegúrese de que el servicio de Load Balancer se establezca en Manual.
    3. Reinicie la máquina de Windows.
    4. descargue el paquete de renovación o el fixpack de Edge Components.
    5. Utilice Agregar o quitar programas para desinstalar el componente Load Balancer actual, si lo hay.
    6. Ejecute el programa de instalación realizando una de las acciones siguientes:
    7. Especifique la información solicitada por el programa de instalación.

    Después de instalar una actualización para Edge Components, se mantiene la configuración anterior para Edge Components. Cuando se proporcionan nuevas funciones o mejoras con un paquete de renovación o un fixpack, es posible que sea necesario añadir directivas a los archivos de configuración para habilitar las funciones.


    Rechazo de una actualización

    Para rechazar una actualización:

    Para la mayoría de los componentes, cuando se elimina el paquete de renovación o el fixpack, los archivos de configuración se guardan en el directorio de componentes/archivos antiguos. Puede utilizar estos archivos de configuración con la versión reinstalada del producto para mantener la configuración del parche en la versión anterior al parche.


    Creación de redes con Edge Components

    Esta parte proporciona procedimientos para crear 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 del Caching Proxy.

    Creación de una red de Load Balancer.


    Creación de una red del Caching Proxy

    En la figura 19 se muestra una red básica del servidor proxy que utiliza tres sistemas informáticos situados en tres nodos de red. Esta red enlaza el servidor proxy a un sistema principal de 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 Caching Proxy está disponible en todas las instalaciones de Edge Components, con la siguiente excepción:

    Figura 19. Red de demostración del Caching Proxy

    Red de demostración del Caching Proxy


    Flujo de trabajo

    Para crear una red del Caching Proxy, realice estos procedimientos en el orden siguiente:

    1. Revisión de sistemas y software necesarios.
    2. Creación del Servidor 1 (sistemas Linux y UNIX) o Creación del Servidor 1 (sistemas Windows).
    3. Configuración del servidor 1.
    4. Prueba de la red del Caching Proxy.

    Revisión de sistemas y software necesarios

    Son necesarios los siguientes componentes de sistemas y software:


    Creación del Servidor 1 (sistemas Linux y UNIX)

    Instale y configure el Caching Proxy, tal y como se indica a continuación:

    1. Asegúrese de que el servidor del sistema cumple todos los requisitos de hardware y software.
    2. Conéctese como superusuario, normalmente root.
    3. Instale el componente del Caching Proxy.
    4. Cree un identificador de administrador y una contraseña para acceder a los formularios de Configuración y administración especificando el siguiente mandato:
      # 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.

    5. Continúe con el apartado Configuración del servidor 1.

    Creación del Servidor 1 (sistemas Windows)

    Instale y configure el Caching Proxy, tal y como se indica a continuación:

    1. Asegúrese de que los sistemas operativos Windows 2000 y Windows 2003 cumplen todos los requisitos de hardware y software.
    2. Conéctese como un usuario con privilegios de administrador.
    3. Instale el componente del Caching Proxy.
    4. Cree un identificador de administrador y una contraseña para acceder a los formularios de Configuración y administración especificando el siguiente mandato:
      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.

    5. Continúe con el apartado Configuración del servidor 1.

    Configuración del Servidor 1

    Desde la estación de trabajo, realice lo siguiente:

    1. Inicie un navegador web.
    2. En el campo Dirección de su navegador, escriba http://servidor_1, siendo servidor_1 el nombre real del sistema o la dirección IP de la máquina destinada a funcionar de Servidor 1.
    3. Pulse Formularios de configuración y administración.
    4. Entre el nombre y la contraseña de administrador. Los formularios de configuración y administración se abren en el navegador.
    5. Pulse Configuración del servidor --> Proceso de solicitudes --> Direccionamiento de solicitudes.
    6. Inserte una nueva regla de correlación de comodín antes de la ya existente seleccionando el botón de selección Insertar antes y el valor de índice de la regla de correlación de comodín existente.
    7. Seleccione Proxy del recuadro desplegable Acción.
    8. Escriba /* en el campo Plantilla de solicitud de URL.
    9. Escriba el nombre de sistema principal para el sitio al cual desea redirigir solicitudes HTTP en el campo Dirección IP de servidor o nombre de sistema principal. Preceda este valor con http://.
    10. Pulse Someter.
    11. Cree una regla de correlación que permita acceder a los formularios de configuración y administración marcando el botón de selección Insertar antes y el valor de índice de la regla de correlación creada en el paso 6.
    12. Seleccione Pasar del recuadro desplegable Acción.
    13. Escriba /pub/* en el campo Plantilla de solicitud de URL.
    14. Especifique la ubicación de los formularios de configuración y administración:
    15. Pulse Someter.
    16. Pulse el icono Reiniciar servidor situado en la parte superior del formulario de configuración.
    17. Continúe con el apartado Prueba de la red del Caching Proxy.

    Prueba de la red del Caching Proxy

    Desde la estación de trabajo, realice lo siguiente:

    1. Inicie un navegador web.
    2. Escriba http://servidor_1 en el campo Dirección de su navegador. Las páginas HTML del Servidor 2 pasarán por el proxy del Servidor 1 y se enviarán al navegador web.
    3. Para acceder a los formularios de configuración y administración, especifique http://servidor_1/pub/ en el campo Dirección del navegador. Aparece la página inicial de los formularios de configuración y administración.

    Creación de una red de Load Balancer

    En la Figura 20 se muestra una red básica de Load Balancer con tres estaciones de trabajo conectadas localmente en las 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.

    Figura 20. Red de demostración de Load Balancer

    Gráfico que muestra un Cliente, una nube de Internet, una máquina de Load Balancer y dos servidores con conexión local y direcciones identificadas.

    Nota:
    Esta configuración puede completarse utilizando sólo dos estaciones de trabajo con Dispatcher situado en una de las estaciones de trabajo de servidor web. Ésta representa una configuración colocada.

    Flujo de trabajo

    Para crear una red de Load Balancer, realice estos procedimientos en el orden siguiente:

    1. Revisión de sistemas y software necesarios.
    2. Configuración de la red.
    3. Configuración del Dispatcher.
    4. Prueba de la red de Load Balancer.

    Revisión de sistemas y software necesarios

    Son necesarios los siguientes componentes de sistemas y software:


    Configuración de la red

    1. Configure las estaciones de trabajo de manera que se encuentren en el mismo segmento de la LAN. Asegúrese de que el tráfico de red entre las tres máquinas no tenga que pasar por direccionadores o puentes.
    2. Configure los adaptadores de red de las tres estaciones de trabajo. Para este ejemplo, suponga que tiene la configuración de red siguiente:
      Estación de trabajo Nombre Dirección IP
      1 server1.company.com 9.67.67.101
      2 server2.company.com 9.67.67.102
      3 server3.company.com 9.67.67.103
      Máscara de red = 255.255.255.0

      Cada una de las estaciones de trabajo sólo contiene una tarjeta de interfaz de red Ethernet estándar.

    3. Asegúrese de que server1.company.com puede realizar un ping a server2.company.com y a server3.company.com.
    4. Asegúrese de que server2.company.com y server3.company.com pueden realizar un ping para server1.company.com.
    5. Asegúrese de que los contenidos son idénticos en los dos servidores web (Servidor 2 y Servidor 3). Se puede hacer replicando datos en ambas estaciones de trabajo, utilizando un sistema de archivos compartido como NFS, AFS(R) o DFS(TM), o mediante cualquier otro método adecuado para el sitio.
    6. Asegúrese de que funcionan los servidores web de server2.company.com y server3.company.com. Utilice un navegador web para solicitar páginas directamente de http://server2.company.com y http://server3.company.com.
    7. Obtenga otra dirección IP válida para este segmento de la LAN. Ésta es la dirección que se proporciona a los clientes que deseen acceder al sitio. Para este ejemplo, la información es la siguiente:
      Nombre= www.company.com
      IP=9.67.67.104 
      
    8. Configure las dos estaciones de trabajo de servidor web de manera que acepten tráfico para www.company.com.

      Añada un alias para www.company.com a la interfaz loopback en server2.company.com y en server3.company.com.

    9. Suprima cualquier ruta adicional que pueda haberse creado como resultado de añadir un alias a la interfaz loopback.

      Ahora ha completado todos los pasos de configuración que son necesarios en las dos estaciones de trabajo de servidor web.


    Configuración de Dispatcher

    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).

    Nota:
    Los valores de los parámetros deben escribirse en caracteres del idioma inglés. Las únicas excepciones son los valores de parámetros para los nombres de sistemas principales y de archivos.

    Configuración utilizando la línea de mandatos

    Si va a utilizar la línea de mandatos, siga estos pasos:

    1. Inicie dsserver en Dispatcher:

    2. Inicie la función de ejecutor de Dispatcher:
      dscontrol executor start
      
    3. Añada la dirección de clúster a la configuración de Dispatcher:
      dscontrol
      cluster add www.company.com
      
    4. Añada el puerto de protocolo http a la configuración de Dispatcher:
      dscontrol port add www.company.com:80
      
    5. Añada cada uno de los servidores web a la configuración de Dispatcher:
      dscontrol server add www.company.com:80:server2.company.com
      
      dscontrol
      server add www.company.com:80:server3.company.com
      
    6. Configure la estación de trabajo de manera que acepte tráfico para la dirección de clúster:

      dscontrol executor configure www.company.com
      
    7. Inicie la función de gestor de Dispatcher:
      dscontrol manager start
      

      Ahora, Dispatcher realizará el equilibrio de carga en función del rendimiento del servidor.

    8. Inicie la función de consejero del Dispatcher:
      dscontrol advisor start http 80
      

      Ahora Dispatcher se asegurará de que las solicitudes 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.

    Configuración utilizando el asistente de configuración

    Si va a utilizar el asistente de configuración, siga estos pasos:

    1. Inicie dsserver en Dispatcher:

    2. Inicie la función de asistente de Dispatcher, dswizard.

    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:

    Configuración utilizando la interfaz gráfica de usuario (GUI)

    Para iniciar la GUI, siga estos pasos:

    1. Asegúrese de que el proceso dsserver esté en ejecución:
    2. A continuación, realice una de las acciones siguientes:

    Prueba de la red de Load Balancer

    1. Desde un navegador web, vaya a la ubicación http://www.company.com para verificar si aparece una página.
    2. Vuelva a cargar la página en el navegador web.
    3. Emita el mandato siguiente: dscontrol server report www.company.com:80:. Verifique si la columna de conexiones en total de los dos servidores asciende a 2.