WebSphere Application Server

Conceitos, Planejamento e Instalação para o Edge Components

Versão 6.1
G517-8445-00
Primeira Edição (Maio de 2006)

Esta edição aplica-se ao:

e a todos os releases e modificações subseqüentes, até que seja indicado de outra forma em novas edições.

Solicite publicações através de um representante IBM ou do escritório da IBM de sua localidade.

Direitos Autorais International Business Machines Corporation 2006. Todos os direitos reservados.

Índice

Figuras
Sobre Este Manual
Quem Deve Ler Este Manual
Acessibilidade
Convenções e Terminologia Utilizados Neste Manual
Visão Geral
Introduzindo o Edge Components do WebSphere Application Server
Caching Proxy
Load Balancer
Dispatcher
Content Based Routing
Site Selector
Cisco CSS Controller
Nortel Alteon Controller
Metric Server
Edge Components e a Família WebSphere
Tivoli Access Manager
WebSphere Portal Server
WebSphere Site Analyzer
WebSphere Transcoding Publisher
Informações Adicionais sobre o Application Server e o Edge Components
Conceitos e Discussões sobre o Edge Components
Armazenamento em Cache
Configurações de Caching Proxy Básico
Caching Proxy Reverso (Configuração Padrão)
Caching Proxy de Redirecionamento
Armazenamento em Cache Avançado
Clusters do Caching Proxy com Equilíbrio de Carga
Armazenamento em Cache de Conteúdo Dinâmico
Recursos Adicionais de Armazenamento em Cache
Desempenho da Rede
Hardware de Rede
Considerações sobre Memória
Considerações sobre Disco Rígido
Considerações sobre Rede
Considerações sobre CPU
Arquitetura de Rede
Considerações sobre Popularidade do Web Site e de Carga do Servidor Proxy
Considerações sobre Tipos de Tráfego
Disponibilidade
Equilíbrio de Carga
Equilíbrio de Carga de Vários Hosts de Conteúdo
Equilíbrio de Carga de Vários Servidores Proxy Reversos
Balanceador de Carga com Vários Servidores Proxy de Redirecionamento
Suporte à Failover
Content Based Routing
Cenários
Rede Business-to-Consumer
Fase 1
Fase 2
Fase 3
Solução Bancária Business-to-Client
Rede do Portal da Web
Instalando o Edge Components
Requisitos para o Edge Components
Pré-requisitos de Hardware e Software
Utilizando Navegadores com os Formulários Configuração e Administração Caching Proxy
Utilizando Navegadores com a Ajuda On-line do Load Balancer
Instalando o Edge Components Utilizando o Programa de Instalação
Utilizando o Programa de Instalação para Windows
Utilizando o Programa de Instalação para Linux e UNIX
Instalando o Caching Proxy Utilizando Ferramentas de Empacotamento de Sistema
Desinstalação do Caching Proxy Utilizando Ferramentas do Sistema
Instalando o Load Balancer Utilizando Ferramentas de Empacotamento de Sistema
Instalando para AIX
Antes de Instalar
Procedimento de Instalação
Instalando para HP-UX
Antes de Instalar
Procedimento de Instalação
Instalando para Linux
Antes de Instalar
Etapas de Instalação
Instalando para Solaris
Antes de Instalar
Etapas de Instalação
Construindo Redes com o Edge Components
Construir uma Rede Caching Proxy
Fluxo de Trabalho
Rever os Sistemas de Computador e Software Requeridos
Servidor de Construção 1 (Sistemas Linux e UNIX)
Servidor de Construção 1 (Sistema Windows)
Configurar o Servidor 1
Testar a Rede do Caching Proxy
Construir uma Rede Load Balancer
Fluxo de Trabalho
Rever os Sistemas de Computador e Software Requeridos
Configurar a Rede
Configurar o Dispatcher
Configurando a Utilização da Linha de Comandos
Configurando a Utilização do Assistente para Configuração
Configurando a Utilização da GUI (Interface Gráfica com o Usuário)
Testar a Rede do Load Balancer
Apêndices

Figuras

  1. Caching Proxy Agindo como um Proxy Reverso
  2. Caching Proxy Agindo como um Proxy de Redirecionamento
  3. O Caching Proxy Agindo como um Proxy de Redirecionamento Transparente
  4. Caching Proxy Agindo como Servidor Proxy para um Cluster com Equilíbrio de Carga
  5. Equilíbrio de Carga de Vários Hosts de Conteúdo
  6. Equilíbrio de Carga de Vários Servidores Proxy Reversos e Hosts de Conteúdo
  7. Utilizando o Dispatcher para Equilibrar Carga de Vários Proxies de Armazenamento em Cache.
  8. Utilizando um Dispatcher Principal e de Backup para Oferecer Acesso à Internet Altamente Disponível.
  9. Localizando o Dispatcher de Backup em uma Máquina do Caching Proxy.
  10. Utilizando um Load Balancer Principal e de Backup para Tornar o Conteúdo da Web Altamente Disponível
  11. Localizando o Load Balancer de Backup em um Host de Conteúdo
  12. Roteando Pedidos de HTTP com o CBR
  13. Equilíbrio de Carga de Pedidos de HTTP Roteados com o CBR
  14. Rede Business-to-Consumer (Fase 1)
  15. Rede Business-to-Consumer (Fase 2)
  16. Rede Business-to-Consumer (Fase 3)
  17. Solução Bancária Business-to-Consumer
  18. Portal da Web
  19. Rede de Demonstração do Caching Proxy
  20. Rede de Demonstração do Load Balancer

Sobre Este Manual

Este manual, Conceitos, Planejamento e Instalação para Edge Components do WebSphere Application Server, serve como uma introdução ao Edge Components do WebSphere Application Server. Ele fornece visões gerais de alto nível, discussões detalhadas de funcionalidade para componentes principais, cenários de extremidade da rede, informações de instalação e configuração inicial e redes de demonstração.

Quem Deve Ler Este Manual

O manual Conceitos, Planejamento e Instalação para Edge Components do WebSphere Application Server foi desenvolvido para administradores de rede e de sistema experientes que estão familiarizados com seus sistemas operacionais e com o fornecimento de serviços da Internet. Não é necessário ter conhecimento anterior sobre o WebSphere Application Server ou Edge Components do WebSphere Application Server.

Acessibilidade

Os recursos de acessibilidade ajudam usuários com alguma deficiência física, como restrição motora ou deficientes visuais a utilizarem produtos de software com êxito. Estes são os principais recursos de acessibilidade do WebSphere Application Server, Versão 6.1:

Convenções e Terminologia Utilizados Neste Manual

Esta documentação utiliza as seguintes convenções tipográficas e de símbolos.

Tabela 1. Convenções Utilizadas Neste Manual
Convenção Significado
Negrito Ao fazer referência a GUIs (Interfaces Gráficas com o Usuário), o negrito também indica menus, itens de menu, rótulos, botões, ícones e pastas. Ele também pode ser utilizado para enfatizar nomes de comandos que, de outra forma, podem ser confundidos com o texto ao redor.
Monoespaçado Indica texto que deve ser digitado em um prompt de comandos. O monoespaçado também indica texto de tela, exemplos de códigos e extrações de arquivos.
Itálico Indica valores variáveis que você deve fornecer (por exemplo, você fornece o nome de um arquivo para fileName). Itálico também indica ênfase e títulos de manuais.
Ctrl-x Em que x é o nome de uma tecla, indica uma seqüência de caracteres de controle. Por exemplo, Ctrl-c significa manter pressionada a tecla Ctrl enquanto pressiona a tecla c.
Return Refere-se à tecla rotulada com a palavra Return, Enter, ou com uma seta para a esquerda.
% Representa o prompt do shell de comandos do Linux e UNIX para um comando que não exija privilégios de root.
# Representa o prompt de shell de comandos do Linux e UNIX para um comando que exige privilégios de root.
C:\ Representa o prompt de comandos do Windows.
Digitando comandos Quando for instruído a "digitar" ou "emitir" um comando, digite o comando e, em seguida, pressione Return. Por exemplo, a instrução "Digite o comando ls" significa digitar ls em um prompt de comandos e, em seguida, pressionar Return.
[ ] Itens opcionais em descrições de sintaxe aparecem entre esses símbolos.
{ } Listas nas quais você deve escolher um item em descrições de sintaxe aparecem entre esses símbolos.
| Separa itens em uma lista de opções entre { }(chaves) em descrições de sintaxe.
... Reticências em descrições de sintaxe indicam que você pode repetir o item anterior uma ou mais vezes. Reticências em exemplos indicam que foram omitidas informações do exemplo para torná-lo mais curto.

Visão Geral

Esta parte apresenta o Edge Components, o Caching Proxy e Load Balancer do WebSphere Application Server e discute sua integração com o Application Server. Ela também define os componentes do Caching Proxy e do Load Balancer. Além disso, esta seção apresenta outros produtos relacionados da família WebSphere.

Esta parte contém os seguintes capítulos:

Introduzindo o Edge Components do WebSphere Application Server

O WebSphere é um software de infra-estrutura da Internet que permite que empresas desenvolvam, implementem e integrem aplicativos de e-business de última geração, como os destinados ao e-commerce business-to-business. O middleware WebSphere suporta aplicativos desde negócios de simples publicação na Web ao processamento de transações em escala corporativa.

Como base da plataforma WebSphere, o WebSphere Application Server oferece um conjunto abrangente de middleware que permite que usuários projetem, implementem, desenvolvam e gerenciem aplicativos de negócios. Estes aplicativos podem variar de uma simples fachada de loja de um Web site a uma revisão completa de infra-estrutura de informática de uma organização.

Recursos intensivos do processador, como personalização, oferecem uma vantagem competitiva a cada e-business. Porém, remover estes recursos de servidores centrais pode impedir que funções importantes sejam escaladas nas proporções da Internet. Conseqüentemente, com a constante inclusão de novos aplicativos da Web, uma infra-estrutura da Internet de uma empresa deve aumentar em escopo e em impacto. Além disso, confiança e segurança são extremamente importantes para um e-business. Mesmo uma interrupção mínima no serviço pode resultar em uma perda de negócios.

O Edge Components (anteriormente Edge Server) agora fazem parte da oferta do WebSphere Application Server. Edge Components podem ser utilizados junto com o WebSphere Application Server para controlar o acesso de clientes a servidores Web e para permitir que empresas forneçam melhores serviços a usuários que acessam conteúdo baseado na Web pela Internet ou uma intranet corporativa. Utilizar Edge Components pode reduzir congestionamento em servidores Web, aumentar a disponibilidade de conteúdo e melhorar o desempenho de servidores Web. Como o nome indica, Edge Components geralmente são executados em máquinas que estão próximas (no sentido de configuração de rede) ao limite entre a intranet de uma empresa e a Internet.

O WebSphere Application Server inclui os Edge Components Caching Proxy e Load Balancer.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Caching Proxy

O Caching Proxy reduz a utilização da largura de banda e melhora a velocidade e segurança de um Web site, fornecendo um nó de ponto de presença para um ou mais servidores de conteúdo de backend. O Caching Proxy pode armazenar em cache e atender ao conteúdo estático e ao conteúdo gerado dinamicamente pelo WebSphere Application Server.

O Caching Proxy pode ser configurado na função de um servidor de proxy reverso (configuração padrão) ou de um servidor de proxy de redirecionamento, oferecendo um ponto de acesso para uma rede ou para um servidor de rede interna com a tarefa de aprimorar o tempo de pedidos e de resposta. Para obter informações adicionais sobre as configurações reversa e de redirecionamento, consulte Configurações de Caching Proxy Básico.

O Servidor Proxy intercepta pedidos de dados de um cliente, recupera as informações solicitadas de máquina de host de conteúdo e envia esse conteúdo de volta para o cliente. Mais comumente, os pedidos são para documentos armazenados em máquinas de servidores Web (também chamados de servidores de origem ou hosts de conteúdo) e entregues utilizando HTTP (Hypertext Transfer Protocol). No entanto, você pode configurar o Servidor Proxy para tratar outros protocolos, como o FTP (File Transfer Protocol) e Gopher.

O Servidor Proxy armazena conteúdo em uma cache local antes de enviá-lo ao solicitante. Exemplos de conteúdo que podem ser armazenados em cache incluem páginas da Web estáticas e arquivos JavaServer Pages que contêm informações geradas dinamicamente, mas que são alteradas com pouca freqüência. O armazenamento em cache permite que o Servidor Proxy atenda a pedidos posteriores para o mesmo conteúdo, enviando-o diretamente da cache local, o que é muito mais rápido do que recuperá-los novamente do host de conteúdo.

Os plug-ins para Caching Proxy adicionam funcionalidade ao Servidor Proxy.

Você pode estender ainda mais as funções do Caching Proxy gravando módulos de plug-in personalizados em uma API (Application Programming Interface). A API é flexível, fácil de utilizar e independente de plataforma. O proxy executa uma seqüência de etapas para cada pedido de cliente que ele processa. Um aplicativo de plug-in modifica ou substitui uma etapa no fluxo de trabalho de processamento de pedidos, como uma autenticação de cliente ou filtragem de pedidos. A potente interface Transmogrify, por exemplo, fornece acesso a dados de HTTP e permite a substituição ou transformação de URLs e de conteúdo da Web. Os plug-ins podem modificar ou substituir etapas de processamento designadas e você pode chamar mais de um plug-in para uma etapa específica.

Load Balancer

O Load Balancer cria sistemas de extremidade da rede que direcionam o fluxo do tráfego da rede, reduzindo o congestionamento e equilibrando a carga em vários outros serviços e sistemas. O Load Balancer fornece seleção de sites, gerenciamento de carga de trabalho, autorização de sessão e failover transparente.

O Load Balancer é instalado entre a Internet e os servidores de backend da empresa, que podem ser hosts de conteúdo ou máquinas do Caching Proxy. O Load Balancer age como o único nó de ponto de presença da empresa na Internet, mesmo que a empresa utilize muitos servidores de backend de grande demanda ou uma grande quantidade de conteúdo. Também é possível garantir alta disponibilidade instalando um Load Balancer de backup, que assume no caso de falha temporária do principal.

O Load Balancer intercepta pedidos de dados de clientes e encaminha cada pedido para o servidor que, no momento, tem melhor capacidade de atender ao pedido. Em outras palavras, ele equilibra a carga de pedidos que chegam entre um conjunto definido de máquinas que atendem ao mesmo tipo de pedidos. O Load Balancer pode distribuir pedidos para muitos tipos de servidores, incluindo WebSphere Application Server e máquinas do Caching Proxy. O equilíbrio de carga pode ser personalizado para um aplicativo específico ou plataforma, utilizando consultores personalizados. Os consultores de finalidades especiais estão disponíveis para a obtenção de informações para o equilíbrio de carga de WebSphere Application Server.

Se o componente Content Based Routing for instalado junto com o Caching Proxy, os pedidos HTTP e HTTPS podem até ser distribuídos com base em URLs ou em outras características determinadas pelo administrador, eliminando a necessidade de armazenar conteúdo idêntico em todos os servidores de backend. O componente Dispatcher também pode fornecer a mesma função para pedidos HTTP.

O equilíbrio de carga melhora a disponibilidade e escalabilidade de seu Web site fazendo cluster de servidores de conteúdo de forma transparente, incluindo servidores HTTP, servidores de aplicativos e servidores proxy, que são servidores de conteúdo substitutos. A disponibilidade é alcançada por meio de paralelismo, equilíbrio de carga e suporte a failover. Quando o servidor pára de funcionar, os negócios não são interrompidos. A escalabilidade de uma infra-estrutura é melhorada significativamente porque a força do processamento de backend pode ser incluída de forma transparente.

Suporte para IPv6: Suporte para o esquema de endereços IP do IPv6 disponível com o "Load Balancer para IPv4 e IPv6." O Load Balancer para IPv4 e IPv6 é uma imagem de instalação à parte, constituída apenas pelo componente Dispatcher. Este tipo de instalação oferece equilíbrio de carga para tráfego IPv4 e IPv6 para servidores configurados dentro de sua rede utilizando o redirecionamento de pacotes baseado em MAC do Dispatcher. É importante observar que versões anteriores do Load Balancer devem ser desinstaladas antes de instalar o Load Balancer para IPv4 e IPv6. Dois Load Balancers não podem estar instalados na mesma máquina. Consulte Dispatcher para ver uma breve visão geral do componente Dispatcher.

O Load Balancer inclui os seguintes componentes:

Dispatcher

Para todos os serviços de Internet, tais como HTTP, FTP, HTTPS e Telnet, o componente Dispatcher executa equilíbrio de carga para servidores em uma LAN (Local Area Network) ou uma WAN (Wide Area Network). Para dispositivos HTTP, o Dispatcher pode executar equilíbrio de carga de servidores com base no conteúdo de URL do pedido do cliente.

O componente Dispatcher permite o gerenciamento estável e eficiente de uma grande rede escalável de servidores. Com o Dispatcher, você pode ligar muitos servidores individuais ao qual parece ser um único servidor virtual. Assim, seu site parecerá ser um único endereço IP para todos.

Se estiver utilizando uma instalação do Load Balancer para IPv4 e IPv6, consulte o capítulo sobre implementação do Dispatcher no Load Balancer para IPv4 e IPv6 em WebSphere Application Server Load Balancer Administration Guide, que inclui informações sobre limitações e diferenças de configuração.

Content Based Routing

Para serviços HTTP e HTTPS, o componente Content Based Routing realiza o equilíbrio de carga para servidores baseados no conteúdo do pedido do cliente. O componente Content Based Routing funciona junto com o componente Caching Proxy do Application Server.

IMPORTANTE: O componente CBR (Content Based Routing) está disponível em todas as plataformas suportadas, com as seguintes exceções:

Site Selector

O componente Site Selector melhora um sistema de equilíbrio de carga, permitindo que ele aja como o nó de ponto de presença para uma rede e equilibra a carga de pedidos de entrada, mapeando nomes DNS para endereços IP. Junto com o Metric Server, o Site Selector pode monitorar o nível de atividade em um servidor, detectar quando um servidor tem a menor carga e detectar um servidor com falha.

Este componente é suportado em todas as instalações do componente Edge, com a seguinte exceção:

Cisco CSS Controller

O componente Cisco CSS Controller gera métricas de carga do servidor que são enviadas para um comutador Cisco CSS para seleção de servidor, otimização de carga e tolerância a falhas.

Este componente é suportado em todas as instalações do componente Edge, com a seguinte exceção:

Nortel Alteon Controller

O componente Nortel Alteon Controller gera métricas de carga do servidor que são enviadas para um comutador Nortel Alteon para seleção de servidor, otimização de carga e tolerância a falhas.

Este componente é suportado em todas as instalações do componente Edge, com a seguinte exceção:

Metric Server

O componente Metric Server é executado como um daemon em um servidor de equilíbrio de carga e fornece informações sobre cargas do sistema para componentes do Load Balancer.

Edge Components e a Família WebSphere

A família IBM WebSphere foi desenvolvida para ajudar os usuários a cumprir o compromisso de e-business. É um conjunto de produtos de software que ajuda os usuários a desenvolver e gerenciar Web sites de alto desempenho e a integrar Web sites com sistemas novos ou existentes de informações de negócios que não são da Web.

A família WebSphere consiste no WebSphere Application Server, incluindo os Edge Components e outro software da família WebSphere que está fortemente integrado com o WebSphere Application Server e melhora seu desempenho. Para obter uma visão geral do WebSphere Application Server e de seus componentes, consulte o Introduzindo o Edge Components do WebSphere Application Server.

Tivoli Access Manager

O Tivoli Access Manager (anteriormente denominado Tivoli Policy Director) está disponível separadamente. Ele oferece controle de acesso e segurança centralizada para aplicativos da Web existentes e oferece uma capacidade de autenticação de uma etapa com acesso a vários recursos da Web. Um plug-in do Caching Proxy explora a estrutura de segurança do Access Manager, permitindo que o Servidor Proxy utilize os serviços integrados de autorização e autenticação do Access Manager.

WebSphere Portal Server

O WebSphere Portal Server (disponível separadamente) oferece uma estrutura para atender a questões de apresentação, segurança, escalabilidade e disponibilidade associadas a portais. Utilizando o Portal Server, as empresas podem construir seu próprio Web site do portal personalizado para atender às necessidades de funcionários, parceiros de negócios e de clientes. Os usuários podem se conectar ao portal e receber páginas da Web personalizadas que fornecem acesso a informações, pessoas e aplicativos de que eles precisam. Este único ponto de acesso personalizado a todos os recursos necessários reduz a sobrecarga de informações, acelera a produtividade e aumenta o uso do Web site.

O WebSphere Portal Server é executado em um cluster do WebSphere Application Server para obter escalabilidade e confiança. O componente Load Balancer do Application Server também pode ser utilizado para equilíbrio de carga adicional e alta disponibilidade.

WebSphere Site Analyzer

O WebSphere Site Analyzer (disponível separadamente) ajuda as empresas a prever seus problemas de capacidade e desempenho. Com o Site Analyzer, os logs do Caching Proxy e do Load Balancer e outras ajudas de gerenciamento podem ser utilizados para prever a demanda por recursos adicionais monitorando, analisando e gerando relatórios de uso de seu Web site. Além disso, os componentes de gerenciamento do Site Analyzer ajudam os usuários que instalam e fazem upgrade de Edge Components, gerenciam e armazenam configurações, operam Edge Components remotamente, exibem e relatam eventos.

WebSphere Transcoding Publisher

O WebSphere Transcoding Publisher (disponível separadamente) pode converter uma página da Web para visualização em um dispositivo móvel, como um celular adaptado para Internet, traduzir o conteúdo da Web no idioma nacional preferido do usuário (chamando o WebSphere Translation Server) e converter linguagens de marcações. O Transcoding Publisher aperfeiçoa as capacidades do Caching Proxy permitindo que ele sirva conteúdo para diferentes dispositivos e usuários. Depois de acessar o conteúdo de um servidor Web, a interface Transmogrify do Caching Proxy pode ser configurada para chamar o Transcoding Publisher para transformar os dados e marcá-los para armazenamento em cache variável e possível reutilização. Na interface de pós-autenticação do Caching Proxy, o Transcoding Publisher verifica então no Servidor Proxy se existe conteúdo correspondente ao usuário e requisitos de dispositivos e, se encontrar uma correspondência, serve o conteúdo a partir da cache do Servidor Proxy.

Informações Adicionais sobre o Application Server e o Edge Components

A documentação específica a seguir para o WebSphere Application Server Edge Components está disponível no do Edge Components Information Center.

Outras documentações do WebSphere Application Server estão disponíveis a partir da página da biblioteca do WebSphere Application Server.

As informações de suporte de Technote no Edge Components estão disponíveis a partir da página de suporte do WebSphere Application Server.

A seguir está uma lista de Web sites para obter informações sobre o Edge Components ou informações relacionadas:

Conceitos e Discussões sobre o Edge Components

Esta parte inclui discussões detalhadas que destacam algumas das funcionalidades disponíveis com o Edge Components. Consulte o Introduzindo o Edge Components do WebSphere Application Server para obter uma visão geral do componente Caching Proxy do Application Server.

Esta parte contém os seguintes capítulos:

Armazenamento em Cache

Desempenho da Rede

Disponibilidade

Content Based Routing

Armazenamento em Cache

A funcionalidade de armazenamento em cache do Caching Proxy ajuda a reduzir a utilização da largura de banda da rede e assegura que os usuários finais recebam um serviço mais rápido e mais seguro. Isto é feito porque o armazenamento em cache executado pelo Servidor Proxy reduz a carga de servidores de backend e de links de mesmo nível. O Caching Proxy pode armazenar em cache o conteúdo estático e o conteúdo gerado dinamicamente pelo WebSphere Application Server. Para oferecer armazenamento em cache avançado, o Caching Proxy também funciona junto com o componente Load Balancer do Application Server. Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes sistemas.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Configurações de Caching Proxy Básico

O Caching Proxy pode ser configurado na função de um servidor de proxy de armazenamento em cache reverso (configuração padrão) ou de um servidor de proxy de armazenamento em cache de redirecionamento. Quando utilizado por hosts de conteúdo, o Caching Proxy é configurado na função de servidor de proxy de armazenamento em cache reverso, localizado entre a Internet e os hosts de conteúdo corporativos. Quando utilizado por provedores de acesso à Internet, o Caching Proxy é configurado na função de um servidor de proxy de armazenamento em cache de redirecionamento, localizado entre um cliente e a Internet.

Caching Proxy Reverso (Configuração Padrão)

Quando utilizam uma configuração de proxy reverso, as máquinas do Caching Proxy ficam localizadas entre a Internet e os hosts de conteúdo corporativo. Agindo como um substituto, o Servidor Proxy intercepta pedidos do usuário que chegam da Internet, encaminha-os para o host de conteúdo apropriado, armazena em cache os dados retornados e entrega esses dados a usuários na Internet. O armazenamento em cache permite que o Caching Proxy atenda a pedidos subseqüentes do mesmo conteúdo diretamente da cache, o que é muito mais rápido do que recuperá-lo novamente do host de conteúdo. As informações podem ser armazenadas em cache dependendo de quando expirarão, do tamanho máximo da cache e de quando as informações devem ser atualizadas. Tempos de download mais rápidos para correspondências da cache significa melhor qualidade de serviço para clientes. A Figura 1 descreve a funcionalidade básica do Caching Proxy.

Figura 1. Caching Proxy Agindo como um Proxy Reverso
Essa figura descreve a configuração básica de proxy reverso
Legenda:1--Cliente   2--Internet   3--Roteador/Gateway   4--Proxy de Armazenamento em Cache   5--Cache   6--Host de Conteúdo

Nesta configuração, o Servidor Proxy (4) intercepta pedidos cujas URLs incluem o nome de host do host de conteúdo (6). Quando um cliente (1) solicita um arquivo X, o pedido cruza a Internet (2) e entra na rede interna da empresa através de seu gateway de Internet (3). O Servidor Proxy intercepta o pedido, gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido para o host de conteúdo (6).

O host de conteúdo retorna o arquivo X ao Servidor Proxy em vez de retornar diretamente ao usuário final. Se o arquivo puder ser armazenado em cache, o Caching Proxy armazena uma cópia em seu cache (5) antes de transmiti-lo ao usuário final. O exemplo mais importante de conteúdo que pode ser armazenado em cache são páginas da Web estáticas; porém, o Caching Proxy também oferece a capacidade de armazenar em cache e serve o conteúdo gerado dinamicamente pelo WebSphere Application Server.

Caching Proxy de Redirecionamento

Oferecer acesso direto à Internet para usuários finais pode ser muito ineficiente. Cada usuário que buscar um determinado arquivo de um servidor da Web irá gerar a mesma quantidade de tráfego em sua rede e em seu gateway de Internet como se fosse o primeiro usuário a buscar o arquivo, mesmo que o arquivo não tenha sido alterado. A solução é instalar um Caching Proxy de redirecionamento próximo ao gateway.

Quando utilizam uma configuração de proxy de redirecionamento, as máquinas do Caching Proxy ficam localizadas entre o cliente e a Internet. O Caching Proxy encaminha os pedidos de clientes para hosts de conteúdo localizados em toda a Internet, armazena os dados recuperados em cache e oferece os dados recuperados para o cliente.

Figura 2. Caching Proxy Agindo como um Proxy de Redirecionamento
Este Gráfico Descreve a Configuração Básica do Proxy de Redirecionamento

A Figura 2 descreve a configuração de Caching Proxy de redirecionamento. Os programas de navegadores dos clientes (nas máquinas marcadas com 1) estão configurados para direcionar pedidos para o proxy de armazenamento em cache de redirecionamento (2), que está configurado para interceptar os pedidos. Quando um usuário final solicita o arquivo X armazenado no host de conteúdo (6), o proxy de armazenamento em cache de redirecionamento intercepta o pedido, gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido através do roteador corporativo (4) através da Internet (5).

Dessa forma o servidor de origem retorna o arquivo X para o proxy de armazenamento em cache de redirecionamento ao invés de retornar diretamente para o usuário final. Se o recurso de armazenamento em cache do Caching Proxy de redirecionamento estiver ativado, o Caching Proxy determina se o arquivo X é apropriado para armazenamento em cache verificando configurações em seu cabeçalho de retorno, como a data de expiração e um indicador se o arquivo foi ou não gerado dinamicamente. Se o arquivo puder ser armazenado em cache, o Caching Proxy armazena uma cópia em sua cache (3) antes de o transmitir para o usuário. Por padrão, o armazenamento em cache é ativado e o Caching Proxy de redirecionamento utiliza a memória cache. No entanto, é possível configurar outros tipos de armazenamento em cache.

No primeiro pedido pelo arquivo X, o Caching Proxy de redirecionamento não aprimora muito a eficiência de acesso à Internet. Na verdade, é provável que o tempo de resposta do primeiro usuário que acessa o arquivo X seja mais lento do que seria sem o proxy de armazenamento em cache de redirecionamento, porque demora um pouco mais para o Caching Proxy de redirecionamento processar o pacote de pedido original e examinar o cabeçalho do arquivo X para obter informações sobre as possibilidades de armazenamento em cache quando ele for recebido. O uso do proxy de armazenamento em cache de redirecionamento traz benefícios quando outros usuários subseqüentemente solicitam o arquivo X. O Caching Proxy de redirecionamento verifica se a cópia em cache do arquivo X ainda é válida (não expirou) e, se for o caso, serve o arquivo X diretamente da cache, sem redirecionar o pedido através da Internet para o host de conteúdo.

Mesmo que o Caching Proxy de redirecionamento descubra que um arquivo solicitado expirou, não significa que será necessário buscar o arquivo novamente a partir do host de conteúdo. Em vez disso, ele envia ao host de conteúdo uma mensagem de verificação de status especial. Se o host de conteúdo indica que o arquivo não foi alterado, o proxy de armazenamento em cache de redirecionamento ainda pode oferecer a versão em cache ao usuário solicitante.

A configuração do Caching Proxy de redirecionamento dessa forma é denominada proxy de redirecionamento, porque o Caching Proxy age em nome de navegadores, redirecionando seus pedidos aos hosts de conteúdo através da Internet. Os benefícios do proxy de redirecionamento com armazenamento em cache são dois:

O Caching Proxy pode lidar com vários protocolos de transferência em rede, incluindo HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) e Gopher.

Caching Proxy de Redirecionamento Transparente (apenas Sistemas Linux)

Uma variação do Caching Proxy de redirecionamento é um Caching Proxy transparente. Nessa função, o Caching Proxy desempenha as mesmas funções do Caching Proxy de redirecionamento básico, mas o faz sem que o cliente perceba sua presença. A configuração do Caching Proxy transparente é suportada apenas em sistemas Linux.

Na configuração descrita em Caching Proxy de Redirecionamento, cada navegador do cliente é configurado separadamente para direcionar pedidos para um determinado Caching Proxy de redirecionamento. A manutenção desse tipo de configuração pode se tornar inconveniente, especialmente para grandes números de máquinas cliente. O Caching Proxy suporta várias alternativas que simplificam a administração. Uma possibilidade é configurar o Caching Proxy para proxy transparente, conforme descrito em Figura 3. Como no Caching Proxy de redirecionamento regular, o Caching Proxy transparente é instalado em uma máquina próxima ao gateway, mas os programas navegadores do cliente não são configurados para direcionar pedidos para um Caching Proxy de redirecionamento. Os clientes não têm conhecimento de que existe um proxy na configuração. Em vez disso, um roteador é configurado para interceptar os pedidos dos clientes e direcioná-los para o Caching Proxy transparente. Quando um cliente trabalhando em uma das máquinas, marcada como 1, solicita o arquivo X armazenado em um host de conteúdo (6), o roteador (2) transmite o pedido para o Caching Proxy. O Caching Proxy gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido pelo roteador (2) através da Internet (5). Quando o arquivo X chega, o Caching Proxy armazena o arquivo em cache se apropriado (sujeito às condições descritas em Caching Proxy de Redirecionamento) e transmite o arquivo para o cliente que o solicitou.

Figura 3. O Caching Proxy Agindo como um Proxy de Redirecionamento Transparente
Este Gráfico Descreve a Configuração Básica do Proxy de Redirecionamento

Para pedidos HTTP, outra alternativa possível para manter informações de configuração de proxy em cada navegador é utilizar o recurso de configuração de proxy automático disponível em vários programas de navegadores, incluindo o Netscape Navigator versão 2.0 e superior e o Microsoft Internet Explorer versão 4.0 e superior. Nesse caso, você cria um ou mais arquivos PAC (Proxy Automatic Configuration) centrais e configura os navegadores para fazerem referência a um deles, ao invés das informações de configuração de proxy locais. O navegador percebe automaticamente as mudanças no PAC e ajusta seu uso de proxy de forma apropriada. Isso não apenas elimina a necessidade de manter informações de configuração separadas em cada navegador, mas também facilita o novo roteamento de pedidos quando um servidor proxy se tornar indisponível.

Uma terceira alternativa é utilizar o mecanismo WPAD (Web Proxy Auto Discovery) disponível em alguns programas navegadores, como o Internet Explorer versão 5.0 e superior. Quando você ativa esse recurso no navegador, ele localiza automaticamente um servidor proxy compatível com WPAD em sua rede e direciona seus pedidos da Web ali. Nesse caso, não é necessário manter arquivos centrais de configuração de proxy. O Caching Proxy é compatível com WPAD.

Armazenamento em Cache Avançado

Clusters do Caching Proxy com Equilíbrio de Carga

Para oferecer uma funcionalidade de armazenamento em cache mais avançada, utilize o Caching Proxy como um proxy reverso junto com o componente Load Balancer. Integrando os recursos de armazenamento em cache e de equilíbrio de carga, você pode criar uma infra-estrutura de desempenho da Web eficiente e altamente gerenciável.

A Figura 4 descreve como você pode combinar o Caching Proxy com o Load Balancer para entregar conteúdo da Web de forma eficiente, mesmo em circunstâncias de grande demanda. Nesta configuração, o Servidor Proxy (4) está configurado para interceptar pedidos cujas URLs incluem o nome do host para um cluster de hosts de conteúdo (7) que está recebendo equilíbrio de carga do Load Balancer (6).

Figura 4. Caching Proxy Agindo como Servidor Proxy para um Cluster com Equilíbrio de Carga
O gráfico que aparece aqui descreve o Servidor Proxy agindo como um substituto para um cluster com equilíbrio de carga
Legenda: 1--Cliente   2--Internet   3--Roteador/Gateway   4--Caching Proxy   5--Cache   6--Load Balancer   7--Host de Conteúdo

Quando um cliente (1) solicita um arquivo X, o pedido cruza a Internet (2) e entra na rede interna da empresa através de seu gateway de Internet (3). O Servidor Proxy intercepta o pedido, gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido para o Load Balancer no endereço do cluster. O Load Balancer utiliza seu algoritmo de equilíbrio de carga para determinar qual host de conteúdo tem mais capacidade, no momento, para atender ao pedido do arquivo X. Esse host de conteúdo retorna o arquivo X ao Servidor Proxy e não através do Load Balancer. O Servidor Proxy determina se deve armazená-lo e entregá-lo ao usuário final da forma descrita anteriormente.

Armazenamento em Cache de Conteúdo Dinâmico

A funcionalidade de armazenamento em cache avançado também é fornecida pelo plug-in de Armazenamento em Cache Dinâmico do Caching Proxy. Quando utilizado com o WebSphere Application Server, o Caching Proxy tem a capacidade de armazenar em cache, servir e invalidar conteúdo dinâmico em forma de JSP (JavaServer Pages) e de respostas de servlet geradas por um WebSphere Application Server.

Geralmente, um conteúdo dinâmico com tempo de expiração indefinido deve ser marcado como "não armazenar em cache", porque a lógica padrão de expiração da cache baseada em tempo não assegura sua remoção na hora certa. A lógica de expiração orientada a eventos do plug-in do Armazenamento em Cache Dinâmico permite que o conteúdo com um tempo de expiração indefinido seja armazenado em cache pelo Servidor Proxy. Armazenar em cache tal conteúdo na extremidade da rede evita que hosts de conteúdo chamem repetidamente um Application Server para atender a pedidos de clientes. Isto pode oferecer os seguintes benefícios:

O armazenamento em cache de respostas de servlet é excelente para páginas da Web geradas dinamicamente que expiram com base na lógica do aplicativo ou em um evento como uma mensagem de um banco de dados. Embora a duração de tal página seja finita, o valor de tempo de duração não pode ser definido no tempo de criação porque o disparo de expiração não pode ser conhecido antecipadamente. Quando o tempo de duração para tais páginas for definido como zero, os hosts de conteúdo obterão uma grande penalidade quando servindo conteúdo dinâmico.

A responsabilidade de sincronizar a cache dinâmica do Caching Proxy e Application Server é compartilhada por ambos os sistemas. Por exemplo, uma página da Web pública gerada dinamicamente por um aplicativo que fornece a previsão do tempo atual pode ser exportada pelo Application Server e armazenada em cache pelo Caching Proxy. O Caching Proxy pode então servir os resultados de execução do aplicativo repetidamente para muitos usuários diferentes, até ser notificado de que a página é inválida. O conteúdo na cache de resposta do servlet do Caching Proxy será invalida até que o Servidor Proxy remova uma entrada porque a cache está congestionada, o tempo limite padrão definido pela diretriz ExternalCacheManager no arquivo de configuração do Caching Proxy expire ou o Caching Proxy receba uma mensagem de Invalidação instruindo-o a eliminar o conteúdo de seu cache. As mensagens de Invalidação são originadas no WebSphere Application Server que possui o conteúdo e são propagadas para cada Caching Proxy configurado.

Nota:
As páginas privadas geradas dinamicamente (como uma página que mostra o conteúdo do carrinho de compras de um usuário) geralmente não podem e não devem ser armazenadas em cache pelo Caching Proxy. O Caching Proxy pode armazenar em cache e servir páginas privadas somente quando estiver configurado para executar autenticação e autorização para assegurar que as páginas privadas sejam servidas apenas a seus usuários pretendidos.

Recursos Adicionais de Armazenamento em Cache

O Caching Proxy oferece outros importantes recursos de armazenamento em cache avançados:

Desempenho da Rede

O desempenho da rede é afetado pela introdução da funcionalidade do Caching Proxy. Utilize o Caching Proxy sozinho ou junto com o Load Balancer para melhorar o desempenho de sua rede. Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes sistemas.

O desempenho do Caching Proxy em sua empresa é tão bom quanto o hardware no qual ele é executado e a arquitetura geral do sistema no qual ele foi introduzido. Para otimizar o desempenho da rede, modele o hardware e a arquitetura geral da rede para as características de Servidor Proxy.

A configuração e administração básicas do software do Caching Proxy e o ajuste no nível do sistema operacional também contribuem muito para o desempenho do Caching Proxy. Muitas alterações de configuração do software podem ser feitas para aumentar o desempenho; elas incluem, mas não estão limitadas ao ajuste de diretrizes de registros, regras de mapeamento, plug-ins, valores de tempo limite, valores de configuração da cache e valores de thread ativos. Detalhes sobre a configuração do software Caching Proxy são apresentados no Caching Proxy Administration Guide.

Muitas alterações na configuração do sistema operacional também podem ser feitas para aumentar o desempenho; elas incluem, mas não estão limitadas ao ajuste de TCP e ARP, ao aumento de limites do descritor de arquivo, à sincronização de clocks do sistema, ao ajuste de placas NIC (Network Interface Cards) e à realização de boas práticas comuns ao executar tarefas de administração do sistema.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Hardware de Rede

Esta seção discute os problemas de hardware de rede a serem considerados ao apresentar a funcionalidade do Caching Proxy em sua rede.

Considerações sobre Memória

Uma grande quantidade de memória deve ser dedicada ao Servidor Proxy. O Caching Proxy pode consumir 2 GB de espaço de endereço virtual quando uma grande cache somente memória é configurada. A memória também é necessária para o kernel, bibliotecas compartilhadas e buffers de rede. Portanto, é possível ter um Servidor Proxy que consuma 3 ou 4 GB de memória física. Observe que a cache somente memória é significativamente mais rápida do que uma cache de disco bruta e somente esta alteração pode ser considerada uma melhoria no desempenho.

Considerações sobre Disco Rígido

É importante ter uma grande quantidade de espaço em disco na máquina onde o Caching Proxy está instalado. Isto se aplica principalmente quando são utilizadas caches de disco. A leitura e gravação em um disco rígido são um processo intensivo para um computador. Embora os procedimentos de E/S do Caching Proxy sejam eficientes, as limitações mecânicas de unidades de disco rígido podem restringir o desempenho quando o Caching Proxy estiver configurado para utilizar uma cache de disco. O gargalo de E/S de disco pode ser reduzido com práticas como a utilização de vários discos rígidos para dispositivos de cache brutos e arquivos de log e com a utilização de unidades de disco com tempos de procura, velocidades rotacionais e taxas de transferência rápidos.

Considerações sobre Rede

Os requisitos de rede, tais como velocidade, tipo de número de NICs e a velocidade da conexão de rede com o Servidor Proxy afetam o desempenho do Caching Proxy. Geralmente, é muito importante para o desempenho utilizar duas NICs em uma máquina do Servidor Proxy: uma para o tráfego de entrada e uma para o tráfego de saída. Provavelmente, uma única NIC pode atingir seu limite máximo somente pelo tráfego de pedidos e respostas de HTTP. Além disso, as NICs devem ter pelo menos 100 MB e devem ser sempre configuradas para uma operação full-duplex. Isto ocorre porque a negociação automática entre o roteamento e o equipamento de chave provavelmente pode causar erros e prejudicar o desempenho. Por último, a velocidade da conexão de rede é muito importante. Por exemplo, você não pode esperar atender a uma alta carga de pedidos e alcançar um ótimo rendimento se a conexão com a máquina do Caching Proxy for uma portadora T1 saturada.

Considerações sobre CPU

A CPU (Central Processing Unit) de uma máquina do Caching Proxy provavelmente pode se tornar um fator limitante. A potência da CPU afeta a quantidade de tempo gasto para processar pedidos e o número de CPUs na rede afeta a escalabilidade. É importante corresponder os requisitos da CPU do Servidor Proxy ao ambiente, principalmente para modelar a carga máxima de pedidos que o Servidor Proxy atenderá.

Arquitetura de Rede

Para desempenho geral, geralmente é útil escalar a arquitetura e não apenas incluir partes de hardware individuais. Não importa a quantidade de hardware incluída em uma única máquina, esse hardware ainda terá um nível máximo de desempenho.

A seção discute os problemas de arquitetura de rede a serem considerados durante a introdução da funcionalidade do Caching Proxy em sua rede.

Considerações sobre Popularidade do Web Site e de Carga do Servidor Proxy

Se o Web site de sua empresa for popular, poderá haver maior demanda por seu conteúdo do que um único Servidor Proxy possa atender de forma eficiente, resultando em tempos de resposta lentos. Para otimizar o desempenho da rede, considere incluir máquinas do Caching Proxy com cluster, com equilíbrio de carga ou utilizar uma arquitetura de cache compartilhada com RCA (Remote Cache Access) em sua arquitetura de rede geral.

Considerações sobre Tipos de Tráfego

As principais contribuições para um melhor desempenho resultam das capacidades de armazenamento em cache do Caching Proxy. No entanto, a cache do Servidor Proxy pode se tornar um gargalo se não estiver configurada corretamente. Para determinar a melhor configuração da cache, deve ser feito um grande esforço para analisar as características do tráfego. O tipo, tamanho, quantidade e atributos do conteúdo afetam o desempenho do Servidor Proxy em termos de tempo gasto para recuperar documentos de servidores de origem e a carga no servidor. Quando você conhece o tipo de tráfego que o Caching Proxy vai aceitar ou atender a partir de seu cache, é possível incluir como fatores essas características durante a configuração do Servidor Proxy. Por exemplo, sabendo que 80% dos objetos que estão sendo armazenados em cache são imagens (*.gif ou *.jpg) e que têm aproximadamente 200 KB de tamanho pode ajudar a ajustar os parâmetros de armazenamento em cache e determinar o tamanho da cache. Além disso, saber que a maioria do conteúdo são páginas dinâmicas personalizadas que não são candidatas a armazenamento em cache também é relativo ao ajuste do Caching Proxy.

Analisar as características do tráfego permite determinar se é preciso utilizar uma memória ou cache de disco para otimizar o desempenho de seu cache. Além disso, a familiaridade com as características de tráfego da rede permite determinar se o desempenho aumentado pode resultar da utilização do recurso de armazenamento em cache dinâmico do Caching Proxy.

Disponibilidade

Funcionando junto com hosts de conteúdo, tais como WebSphere Application Server ou com o componente Caching Proxy do Application Server, o componente Load Balancer do Application Server permite melhorar a disponibilidade e escalabilidade de sua rede. (Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes Edge Components). O Load Balancer é utilizado por redes corporativas e é instalado entre a Internet e os servidores de backend da empresa. O Load Balancer age como o único ponto de presença da empresa na Internet, mesmo que a empresa utilize muitos servidores de backend de alta demanda ou uma grande quantidade de conteúdo.

A disponibilidade é alcançada por meio do equilíbrio de carga e de suporte a failover.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Equilíbrio de Carga

O equilíbrio de carga melhora a disponibilidade e escalabilidade do Web site fazendo cluster de servidores proxy e de servidores de aplicativos de forma transparente. A escalabilidade de uma infra-estrutura de TI é melhorada significativamente porque a força do processamento de backend pode ser incluída de forma transparente.

Equilíbrio de Carga de Vários Hosts de Conteúdo

A grande demanda pode ser atendida duplicando-se o conteúdo em vários hosts, mas será preciso uma maneira de equilibrar a carga entre eles. O DNS (Domain Name Service) pode fornecer equilíbrio de carga em rodízio básico, mas há várias situações em que seu desempenho não é satisfatório.

Uma solução mais sofisticada para o equilíbrio de carga de vários hosts de conteúdo é utilizar o componente Dispatcher do Load Balancer, conforme descrito na Figura 5. Nesta configuração, todos os hosts de conteúdo (as máquinas marcadas com o número 5) armazenam o mesmo conteúdo. Eles são definidos para formar um cluster com equilíbrio de carga e uma das interfaces de rede da máquina do Load Balancer (4) recebe atribuição de um nome de host e de um endereço IP dedicado ao cluster. Quando um usuário final que trabalha em uma das máquinas marcadas com o número 1 solicita o arquivo X, o pedido passa pela Internet (2) e entra na rede interna da empresa através de seu gateway da Internet (3). O Dispatcher intercepta o pedido porque sua URL é mapeada para o nome do host e o endereço IP do Dispatcher. O Dispatcher determina qual dos hosts de conteúdo no cluster tem melhor capacidade para atender ao pedido e encaminha o pedido para esse host que, quando o método de encaminhamento MAC é configurado, retorna o arquivo X diretamente ao cliente (ou seja, o arquivo X não passa pelo Load Balancer).

Figura 5. Equilíbrio de Carga de Vários Hosts de Conteúdo
O gráfico que aparece aqui descreve o equilíbrio de carga de vários hosts de conteúdo
Legenda: 1--Cliente   2--Internet   3--Roteador/Gateway   4--Dispatcher   5--Host de Conteúdo
Nota:
O Dispatcher fornece três métodos de encaminhamento:

Por padrão, o Dispatcher utiliza equilíbrio de carga em rodízio como o DNS, mas, ainda assim, cuida de várias das imperfeições do DNS. Ao contrário do DNS, ele acompanha se um host de conteúdo está indisponível ou inacessível e pára de direcionar clientes para um host de conteúdo indisponível. Além disso, ele leva em consideração a carga atual nos hosts de conteúdo rastreando conexões novas, ativas e finalizadas. Você pode otimizar ainda mais o equilíbrio de carga ativando o consultor opcional e os componentes do gerenciador do Load Balancer, que rastreiam um status do host de conteúdo com maior precisão e incorporam as informações adicionais no processo de decisão de equilíbrio de carga. O gerenciador permite que você atribua pesos diferentes aos diferentes fatores utilizados no processo de decisão, personalizando, adicionalmente, o equilíbrio de carga de seu site.

Equilíbrio de Carga de Vários Servidores Proxy Reversos

O Dispatcher do Load Balancer também pode executar o equilíbrio de carga de várias máquinas do Caching Proxy. Se o Web site de sua empresa for popular, poderá haver maior demanda para seu conteúdo do que um único Servidor Proxy possa atender de forma eficiente, diminuindo potencialmente o desempenho do Servidor Proxy.

Você pode ter vários sistemas Caching Proxy executando funções de proxy para um único host de conteúdo (semelhante à configuração descrita na Figura 1), mas se seu site for popular o suficiente para precisar de vários Servidores Proxy, provavelmente você também precise de vários hosts de conteúdo cujas cargas sejam equilibradas pelo Load Balancer. A Figura 6 descreve esta configuração. O Dispatcher marcado com o número 4 faz o equilíbrio de carga de um cluster de dois Servidores Proxy (5) e o Dispatcher marcado com o número 7 faz o equilíbrio de carga de um cluster de três hosts de conteúdo (8).

Figura 6. Equilíbrio de Carga de Vários Servidores Proxy Reversos e Hosts de Conteúdo
O gráfico que aparece aqui descreve o equilíbrio de carga de vários Servidores Proxy e hosts de conteúdo
Legenda: 1--Cliente   2--Internet   3--Roteador/Gateway   4--Dispatcher   5--Servidor Proxy   6--Cache   7--Dispatcher   8--Host de Conteúdo

O nome do host do cluster do Dispatcher marcado com o número 4 é o nome do host que aparece nas URLs do conteúdo da Web da empresa (ou seja, é o nome do Web site visível na Internet). O nome do host do cluster do Dispatcher marcado com o número 7 não fica visível na Internet e, portanto, pode ser qualquer valor desejado. Por exemplo, para a ABC Corporation, um nome de host apropriado para o Dispatcher marcado com o número 4 é www.abc.com, enquanto o Dispatcher marcado com o número 7 pode ser chamado de algo como http-balancer.abc.com.

Suponha que um navegador em uma das máquinas clientes marcadas com o número 1 precise acessar o arquivo X armazenado nos servidores de conteúdo marcados com o número 8. O pedido de HTTP passa pela Internet (2) e entra na rede interna da empresa no gateway (3). O roteador direciona o pedido para o Dispatcher marcado com o número 4, que o transmite ao Servidor Proxy (5), que tem, no momento, melhor capacidade para tratá-lo, de acordo com o algoritmo de equilíbrio de carga. Se o Servidor Proxy tiver o arquivo X em seu cache (6), ele o retornará diretamente ao navegador, ignorando o Dispatcher marcado com o número 4.

Se o Servidor Proxy não tiver uma cópia do arquivo X em seu cache, ele cria um novo pedido que tenha seu próprio nome de host no campo de origem do cabeçalho e o envia ao Dispatcher marcado com o número 7. O Load Balancer determina qual host de conteúdo (8) tem, no momento, melhor capacidade de atender ao pedido e direciona o pedido para lá. O host de conteúdo obtém o arquivo X do armazenamento e o retorna diretamente para o Servidor Proxy, ignorando o Dispatcher marcado com o número 7. O Servidor Proxy armazena em cache o arquivo X, se apropriado e o envia para o navegador, ignorando o Dispatcher marcado com o número 4.

Balanceador de Carga com Vários Servidores Proxy de Redirecionamento

Se você fornece acesso à Internet para um grande número de clientes, eles podem gerar mais demanda de acesso à Internet do que um único proxy pode oferecer com eficiência. À medida que o Caching Proxy torna-se sobrecarregado com pedidos, o tempo de resposta dos clientes pode se tornar pior do que seria com acesso direto à Internet. E, caso o Caching Proxy falhe ou fique inacessível devido a uma falha de rede, o acesso à Internet se torna impossível. A solução é instalar várias máquinas do Caching Proxy e utilizar o Load Balancer's Dispatcher para equilibrar a carga entre eles.

Sem o Dispatcher, você pode oferecer proxy transparente verdadeiro com várias máquinas do Caching Proxy apenas se seus roteadores puderem rotear o mesmo tipo de tráfego para mais de um Caching Proxy; nem todos os roteadores suportam isso. É possível oferecer serviço de proxy de redirecionamento regular em várias máquinas do Caching Proxy sem o Dispatcher, mas é necessário configurar explicitamente os navegadores do cliente para utilizar uma das máquinas do Caching Proxy como o proxy principal. Se esse Caching Proxy falhar ou se tornar sobrecarregado ou inacessível, os usuários finais podem não ser capazes de acessar a Internet. Para evitar essa situação, você pode criar um arquivo PAC (Proxy Automatic Configuration), conforme descrito em Caching Proxy de Redirecionamento Transparente (apenas Sistemas Linux), que direcione o navegador para failover em um ou mais proxies de armazenamento em cache secundários. Um arquivo PAC não atende às necessidades de equilíbrio da carga entre as máquinas do Caching Proxy, dessa forma, se um Caching Proxy receber muito mais pedidos que outro, é provável que tenha uma redução no desempenho, sujeitando seus clientes de navegador a tempos de resposta mais lentos. Para que todos os clientes tenham desempenhos semelhantes, você deve configurar um número aproximadamente igual de navegadores para utilizar cada Caching Proxy, e rastrear a distribuição manualmente para que possa manter a carga equilibrada mesmo quando incluir ou remover navegadores.

A Figura 7 descreve uma configuração de rede em que o Dispatcher equilibra a carga de um cluster de máquinas do Caching Proxy. Uma das interfaces de rede da máquina do Dispatcher é configurada para ter o nome do host e o endereço IP dedicados do cluster. Navegadores clientes são configurados para direcionar seus pedidos de Internet para o nome do host do cluster. Quando, por exemplo, um navegador em uma das máquinas cliente marcadas com 1 precisar acessar o arquivo X em um host de conteúdo (7), ele direcionará seu pedido para o nome do host ou endereço do cluster, onde o Dispatcher (2) o interceptará e o direcionará para o Caching Proxy (3) apropriado. O Caching Proxy irá criar um novo pedido, transmitir através do gateway corporativo (5) e pela Internet (6) e, se apropriado, o armazenará no arquivo retornado em sua cache (4), conforme descrito com maiores detalhes em Caching Proxy de Redirecionamento

Nota:
O recurso de proxy transparente está disponível apenas em sistemas Linux.
Figura 7. Utilizando o Dispatcher para Equilibrar Carga de Vários Proxies de Armazenamento em Cache.
Essa Figura Descreve o Equilíbrio de Carga de Vários Proxies

O Dispatcher detecta quando uma das máquinas do Caching Proxy estiver indisponível e roteia automaticamente pedidos para as outras. Isso permite a você encerrar uma máquina do Caching Proxy para manutenção sem interromper o acesso à Internet. O Dispatcher possui várias opções de configuração que podem ser utilizadas para controlar os fatores que ele considera ao tomar decisões em relação ao equilíbrio de carga. Você também pode instalar programas Dispatcher auxiliares nas máquinas do Caching Proxy para monitorar seu status e retornar as informações para o Dispatcher. Para obter detalhes, consulte a publicação WebSphere Application Server Load Balancer Administration Guide. Utilizar vários Caching Proxys apresenta uma possível ineficiência, porque mais de um Caching Proxy pode armazenar em cache o mesmo arquivo se diferentes clientes solicitarem o arquivo através de diferentes máquinas do Caching Proxy. Para eliminar a redundância, você pode configurar um RCA (Remote Cache Access), que permite que todos os proxies de um grupo definido compartilhem o conteúdo de suas caches uns com os outros. Todos os proxies de um grupo de RCA utilizam o mesmo algoritmo para determinar qual Caching Proxy é responsável por uma determinada URL. Quando um Caching Proxy intercepta uma URL pela qual não é responsável, ele transmite o pedido para o Caching Proxy responsável. O Caching Proxy responsável realiza o trabalho necessário para atender ao pedido, seja recuperando-o de sua cache ou encaminhando o pedido para o host de conteúdo relevante e armazenando em cache o arquivo retornado, se apropriado. O Caching Proxy responsável, então, transmite o arquivo para o Caching Proxy original, que o entrega para o usuário final solicitante.

No grupo RCA, se o Caching Proxy responsável por uma determinada URL falhar, o Caching Proxy original, que recebeu o pedido do cliente, irá acessar diretamente o host do conteúdo (ou um servidor de backup do Caching Proxy, se houver um definido). Isso significa que os usuários podem acessar arquivos desde que pelo menos um Caching Proxy em um grupo RCA esteja funcionando corretamente.

Essa configuração satisfaz a alta demanda por acesso à Internet utilizando o Dispatcher para equilibrar a carga de pedidos entre várias máquinas do Caching Proxy. Um possível problema é o fato do Dispatcher ser um ponto único de falha. Se ele falhar ou tornar-se inacessível devido a uma falha de rede, clientes de navegador não poderão alcançar os Caching Proxies ou a Internet. A solução é configurar outro Dispatcher para agir como backup para o Dispatcher principal, conforme descrito na Figura 8.

Figura 8. Utilizando um Dispatcher Principal e de Backup para Oferecer Acesso à Internet Altamente Disponível.
Essa Figura Apresenta um Dispatcher Principal e um de Backup para Equilibrar a Carga de Vários Proxies

Aqui um navegador executando em uma das máquinas marcadas com 1 normalmente direciona seu pedido de um arquivo X para o Dispatcher principal (2), que roteia o pedido para o Caching Proxy (4) selecionado com base nos critérios de equilíbrio de carga do Dispatcher. O Caching Proxy cria um novo pedido, o roteia através do gateway corporativo (6) através da Internet (7) até o host de conteúdo (8) e armazena o arquivo X retornado em sua cache (5), se apropriado (para obter uma descrição mais detalhada dessa parte do processo, consulte Caching Proxy de Redirecionamento).

Nessa configuração, o Dispatcher de backup (3) não realiza equilíbrio de carga, desde que o principal esteja operacional. Os Dispatchers principal e de backup rastreiam o status um do outro, trocando periodicamente mensagens denominadas pulsações. Se o Dispatcher de backup detectar que o principal falhou, ele automaticamente assume a responsabilidade pelo equilíbrio de carga, interceptando pedidos direcionados ao nome de host e endereço IP do principal. Também é possível configurar dois Dispatchers para alta disponibilidade mútua. Neste caso, cada um executará ativamente o equilíbrio de carga para um cluster separado de proxies de armazenamento em cache, agindo ao mesmo tempo como o backup para seu parceiro. Para obter explicações adicionais, consulte a publicação WebSphere Application Server Load Balancer Administration Guide.

O Dispatcher geralmente não consome muitos recursos de processamento ou de memória e outros aplicativos podem ser executados na máquina do Dispatcher. Caso seja importante minimizar os custos com equipamento, é também possível executar o Dispatcher de backup na mesma máquina do Caching Proxy. A Figura 9 apresenta essa configuração, na qual o Dispatcher de backup é executado na mesma máquina (3) do Caching Proxy.

Figura 9. Localizando o Dispatcher de Backup em uma Máquina do Caching Proxy.
Essa Figura Apresenta um Dispatcher Principal e um de Backup para Equilibrar a Carga de Vários Proxies

Suporte à Failover

O Load Balancer age como um único ponto de presença para os hosts de conteúdo de sua empresa. Isto é útil porque você informa o nome do host e o endereço do cluster no DNS, em vez do nome do host e do endereço de cada host de conteúdo, que fornece um nível de proteção contra ataques casuais e fornece uma aparência unificada para o Web site de sua empresa. Para aperfeiçoar ainda mais a disponibilidade do Web site, configure outro Load Balancer para agir como um backup para o Load Balancer principal, conforme descrito na Figura 10. Se um Load Balancer falhar ou ficar inacessível devido a uma falha na rede, os usuários finais ainda poderão acessar os hosts de conteúdo.

Figura 10. Utilizando um Load Balancer Principal e de Backup para Tornar o Conteúdo da Web Altamente Disponível
O gráfico que aparece aqui representa a utilização de Dispatcher principal e de backup para tornar o conteúdo da Web altamente disponível
Legenda: 1--Cliente   2--Internet   3--Roteador/Gateway   4--Principal Dispatcher   5--Backup Dispatcher   6--Host de Conteúdo

No caso normal, um navegador em execução em uma das máquinas marcadas com o número 1 direciona seu pedido de um arquivo X para o nome de host do cluster que está mapeado para o Load Balancer principal (4). O Dispatcher roteia o pedido para o host de conteúdo (6) selecionado com base nos critérios de equilíbrio de carga do Dispatcher. O host de conteúdo envia o arquivo X diretamente para o navegador, roteando-o para o gateway da empresa (3) pela Internet (2), mas ignorando o Load Balancer.

O backup Dispatcher (5) não executa o equilíbrio de carga, desde que o principal esteja operacional. Os Dispatcher principal e de backup acompanham seus status trocando mensagens chamadas pulsações, periodicamente. Se o Dispatcher de backup detectar que o principal falhou, ele automaticamente assume a responsabilidade de fazer o equilíbrio de carga, interceptando pedidos direcionados ao nome do host e endereço IP de cluster do principal.

Há também a possibilidade de se configurar dois Dispatcher para a alta disponibilidade mútua. Neste caso, cada um executará ativamente o equilíbrio de carga para um cluster separado de hosts de conteúdo, agindo ao mesmo tempo como o backup para seu parceiro. (Em instalações do Load Balancer para IPv4 e IPv6, a alta disponibilidade simples é suportada, mas a alta disponibilidade mútua não é).

O Dispatcher geralmente não consome muitos recursos de processamento ou de memória e outros aplicativos podem ser executados na máquina do Load Balancer. Se for importante reduzir custos com o equipamento, será possível até mesmo executar o backup do Dispatcher em uma das máquinas do cluster na qual ele está fazendo o equilíbrio de carga. A Figura 11 representa essa configuração, na qual o Dispatcher de backup é executado em um dos hosts de conteúdo (5) do cluster.

Figura 11. Localizando o Load Balancer de Backup em um Host de Conteúdo
O gráfico que aparece aqui representa o backup Dispatcher executando em um host de conteúdo
Legenda: 1--Cliente   2--Internet   3--Roteador/Gateway   4--Principal Dispatcher   5--Backup Dispatcher e Host de Conteúdo   6--Host de Conteúdo

Content Based Routing

IMPORTANTE: O componente CBR (Content Based Routing) está disponível em todas as plataformas suportadas, com as seguintes exceções:

Funcionando com o componente Caching Proxy do Application Server, o componente Load Balancer do Application Server permite distribuir pedidos para vários servidores de backend que hospedam conteúdo diferente. (Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes Edge Components).

Se o componente CBR (Content Based Routing) do Load Balancer for instalado junto com o Caching Proxy, os pedidos HTTP podem ser distribuídos com base na URL ou outras características determinadas pelo administrador, eliminando a necessidade de armazenar conteúdo idêntico em todos os servidores backend.

O uso do CBR será especialmente apropriado se os servidores da Web precisarem executar várias funções diferentes ou oferecer vários tipos de serviços. Por exemplo, o site de um varejista on-line na Web deve exibir seu catálogo, em que uma grande parte é estática e aceitar pedidos, o que significa executar um aplicativo interativo, tal como um script CGI (Commom Gateway Interface) para aceitar números de itens e informações do cliente. É sempre mais eficiente ter dois conjuntos diferentes de máquinas para executar as funções distintas e utilizar o CBR para rotear os diferentes tipos de tráfego para as diferentes máquinas. Da mesma forma, uma empresa pode utilizar o CBR para fornecer um serviço melhor para clientes pagantes do que para visitantes casuais de seu site na Web, roteando os pedidos pagos para servidores da Web mais potentes.

O CBR roteia pedidos com base em regras que você escreve. O tipo mais comum é a regra de conteúdo, que direciona pedidos com base no nome do caminho na URL. Por exemplo, a ABC Corporation pode escrever regras que direcionem pedidos da URL http://www.abc.com/catalog_index.html para um cluster de servidores e http://www.abc.com/orders.html para outro cluster. Há também regras que roteiam pedidos com base no endereço IP do cliente que os enviou ou em outras características. Para saber mais, consulte os capítulos do WebSphere Application Server Load Balancer Administration Guide sobre configuração do CBR e sobre funções avançadas do Load Balancer e do CBR. Para obter as definições de sintaxe das regras, consulte o apêndice do WebSphere Application Server Load Balancer Administration Guide sobre os tipos de regras do CBR.

A Figura 12 descreve uma configuração simples na qual o componente CBR do Load Balancer e o Caching Proxy são instalados juntos na máquina marcada com o número 4 e roteia pedidos para três hosts de conteúdo (6, 7 e 8) que hospedam conteúdo diferente. Quando um usuário final que trabalha em uma das máquinas marcadas com o número 1 solicita o arquivo X, o pedido passa pela Internet (2) e entra na rede interna da empresa através de seu gateway da Internet (3). O Servidor Proxy intercepta o pedido e transmite-o ao componente CBR na mesma máquina, que analisa a URL no pedido e determina qual host de conteúdo 6 hospeda o arquivo X. O Servidor Proxy gera um novo pedido para o arquivo X, e se seu recurso de armazenamento em cache estiver ativado, determina se o arquivo é elegível para armazenamento em cache quando o host 6 o retorna. Se o arquivo puder ser armazenado em cache, o Servidor Proxy armazenará uma cópia em seu cache (5) antes de transmiti-lo para o usuário final. O roteamento para outros arquivos funciona da mesma forma: pedidos para o arquivo Y vão para o host de conteúdo 7, e pedidos para o arquivo Z vão para o host de conteúdo 8.

Figura 12. Roteando Pedidos de HTTP com o CBR
O gráfico que aparece aqui representa o roteamento de pedidos HTTP com CBR
Legenda: 1--Cliente   2--Internet   3--Roteador/Gateway   4--Caching Proxy e componente CBR do Load Balancer   5--Cache   6, 7, 8--Host de Conteúdo

A Figura 13 representa uma configuração mais complexa que tem a possibilidade de se adequar a um varejista on-line. O componente CBR do Load Balancer e o Servidor Proxy são instalados juntos na máquina marcada com o número 4 e roteiam pedidos para duas máquinas do Load Balancer. A máquina do Load Balancer marcada com o número 6 equilibra a carga de um cluster de hosts de conteúdo (8) que hospeda o conteúdo mais estático do catálogo do varejista, enquanto o Load Balancer marcado com o número 7 equilibra a carga de um cluster de servidores Web que tratam pedidos (9).

Quando um usuário final que trabalha em uma das máquinas marcadas com o número 1 acessa a URL do catálogo do varejista, o pedido passa pela Internet (2) e entra na rede interna da empresa através de seu gateway da Internet (3). O Servidor Proxy intercepta o pedido o transmite-o ao componente CBR na mesma máquina, que analisa a URL e determina se a máquina do Load Balancer marcada com o número 6 tratará essa URL. O Servidor Proxy cria um novo pedido de acesso e envia-o ao Load Balancer, que determina qual dos hosts de conteúdo marcado com o número 8 tem, no momento, melhor capacidade de atender ao pedido (com base nos critérios definidos). Esse host de conteúdo transmite o conteúdo do catálogo diretamente para o Servidor Proxy, ignorando o Load Balancer. Como no exemplo anterior, o Servidor Proxy determina se o conteúdo pode ser armazenado em cache e o armazena em seu cache (5), se apropriado.

O usuário final faz um pedido acessando a URL do varejista para pedidos, presumivelmente por meio de um hyperlink no catálogo. O pedido faz o mesmo caminho que o pedido de acesso do catálogo, exceto que o componente CBR na máquina 4 roteia-o para a máquina do Load Balancer marcada com o número 7. O Load Balancer encaminha-o ao mais apropriado dos servidores Web marcado com o número 9, que responde diretamente ao Servidor Proxy. Como as informações do pedido são geralmente geradas de forma dinâmica, o Servidor Proxy provavelmente não as armazena em cache.

Figura 13. Equilíbrio de Carga de Pedidos de HTTP Roteados com o CBR
O gráfico que aparece aqui representa o balanceamento de carga de pedidos HTTP roteados com CBR
Legenda: 1--Cliente   2--Internet   3--Roteador/Gateway   4--Caching Proxy e componente CBR do Load Balancer   5--Cache   6, 7--Load Balancer   8--Host de Conteúdo   9--Servidor Web

A função do CBR do Load Balancer suporta autorização de cookie. Isso significa que a identidade do servidor que atendeu ao primeiro pedido de um usuário final foi registrada em um pacote de dados especial (um cookie) incluído na resposta do servidor. Quando o usuário final acessa a mesma URL novamente dentro de um período que você define, e o pedido inclui o cookie, o CBR roteia o pedido para o servidor original em vez de reaplicar suas regras padrão. Geralmente, isso melhorará o tempo de resposta se o servidor tiver armazenado informações sobre o usuário final que não tenha que obter novamente (tal como o número do cartão de crédito).

Cenários

Esta parte discute cenários de negócios que utilizam o Edge Components do IBM WebSphere Application Server. Essas são soluções de arquitetura examinadas e testadas que podem fornecer desempenho, disponibilidade, escalabilidade e confiabilidade excelentes.

Esta parte contém os seguintes capítulos:

Rede Business-to-Consumer

Solução Bancária Business-to-Client

Rede do Portal da Web

Rede Business-to-Consumer

O Web site de e-commerce básico é uma rede business-to-consumer. Na primeira fase de crescimento da Internet, os negócios geralmente focalizam apenas a criação de uma presença na Web. As informações corporativas e os catálogos de produtos são convertidos em formatos digitais e disponibilizados no Web site. A compra pode estar disponível pelo fornecimento de endereços de e-mail, números de telefone e de fax e até mesmo formulários automatizados. Porém, a verdadeira compra on-line não está disponível. Todas as transações têm uma latência inerente, porque seres humanos precisam processar o pedido.

Na fase dois, os negócios eliminam esta latência e otimizam sua operação de vendas implementando carrinhos de compras seguros para direcionar as compras on-line. A sincronização com bancos de dados de warehouse e a integração com sistemas bancários são importantes para a conclusão destas transações de vendas. O produto que não está disponível não pode ser vendido e não pode haver débito na conta de um cliente para esse item. Da mesma forma, um produto não pode ser tirado do estoque e enviado para um cliente até que ocorra uma transação financeira válida.

Na terceira etapa, o Web site corporativo envolve um site de apresentação dinâmica, em que o consumidor começa a aceitar os aspectos de um cliente e recebe um conteúdo personalizado.

O cenário a seguir inclui tanto o Load Balancer quanto o Caching Proxy.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Fase 1

A Figura 14 mostra um pequeno Web site de comércio projetado para fornecer uma navegação eficiente por catálogos. Todos os pedidos de clientes são passados do firewall para um Dispatcher que roteia esses pedidos para um cluster de Servidores Proxy com caches ativas, que agem como servidores substitutos para os servidores Web. Os servidores de métrica são colocados com Servidores Proxy para fornecer equilíbrio de carga de dados para o Dispatcher. Esta disposição reduz a carga da rede em servidores Web e isola-os do contato direto com a Internet.

Figura 14. Rede Business-to-Consumer (Fase 1)
Este gráfico descreve uma rede business-to-consumer básica de exemplo

Fase 2

A Figura 15 mostra a segunda fase de evolução de um Web site de comércio projetado para fornecer navegação eficiente por catálogos e carrinhos de compras rápidos e seguros para possíveis clientes. Todos os pedidos de clientes são roteados para a ramificação apropriada da rede por um Dispatcher que separa pedidos com base no protocolo Internet. Os pedidos HTTP vão para o Web site estático; os pedidos HTTPS vão para a rede de compras. O Web site principal e estático ainda é servido por um cluster de Servidores Proxy com caches ativas que agem como substitutas para servidores Web. Esta parte da rede espelha a rede na primeira fase.

A parte de e-commerce do Web site também é servida por um cluster de Servidores Proxy. No entanto, os nós do Caching Proxy são aperfeiçoados com vários módulos de plug-in. O protocolo de reconhecimento SSL é descarregado em uma placa de hardware de criptografia e a autenticação é feita por meio do plug-in do Access Manager (anteriormente denominado Policy Director). O plug-in Dynamic Caching reduz a carga de trabalho no WebSphere Application Server armazenando dados comuns. Um plug-in no servidor de aplicativo invalida objetos no Dynacache quando necessário.

Todos os aplicativos de carrinho de compras são amarrados ao banco de dados de cliente que foi utilizado para autenticar o usuário. Isso evita que o usuário tenha de inserir informações pessoais no sistema duas vezes, uma para autenticação e outra para fazer as compras.

Essa rede divide o tráfego de acordo com a utilização pelo cliente, removendo autenticação SSL intensiva de processador e carrinhos de compras de e-commerce do Web site principal. Esse Web site de trilha dupla permite ao administrador da rede ajustar os diversos servidores para fornecer excelente desempenho com base na função do servidor dentro da rede.

Figura 15. Rede Business-to-Consumer (Fase 2)
Este gráfico descreve uma rede business- to-consumer de exemplo

Fase 3

A Figura 16 mostra a terceira fase da evolução de uma rede business-to-consumer, com a Web estática adotando um método dinâmico de apresentação. O cluster do servidor proxy foi aperfeiçoado para suportar o armazenamento em cache de conteúdo dinâmico da Web e a montagem de fragmentos de páginas gravados para compatibilidade com o protocolo ESI (Edge Side Includes). Em vez de utilizar mecanismos de inclusão do lado do servidor para construir páginas da Web nos servidores de conteúdo e, em seguida, propagar estas páginas específicas de cliente, não armazenáveis em cache por toda a rede, os mecanismos de ESI permitem que as páginas sejam montadas a partir do conteúdo armazenado em cache na extremidade da rede, reduzindo, assim, o consumo de largura de banda e diminuindo o tempo de resposta.

Os mecanismos de ESI são importantes neste cenário da terceira fase, em que cada cliente recebe uma home page personalizada do Web site. Os blocos de construção destas páginas são recuperados de uma série de WebSphere Application Servers. Os servidores de aplicativos que contêm a lógica de negócios sensitiva e se ligam a bancos de dados seguros são isolados atrás de um firewall.

Figura 16. Rede Business-to-Consumer (Fase 3)
Este gráfico descreve uma rede business- to-consumer de exemplo

Solução Bancária Business-to-Client

A Figura 17 mostra uma solução bancária eficiente que é semelhante à rede business-to-consumer descrita no Rede Business-to-Consumer. Todos os pedidos de clientes são passados do firewall para um Dispatcher que separa o tráfego de acordo com o protocolo Internet. Os pedidos HTTP são transmitidos para um cluster de servidores proxy com caches ativas que agem como servidores substitutos para os servidores Web. Os servidores de métrica são colocados com os servidores proxy para oferecer equilíbrio de carga de dados para o Dispatcher. Esta disposição reduz a carga da rede nos servidores Web e cria um buffer adicional entre eles e a Internet.

Os pedidos HTTPS são transmitidos para uma rede segura projetada para oferecer aos clientes informações financeiras pessoais e permitir transações bancárias on-line. Um cluster de servidores proxy avançados fornece escalabilidade para o site. Estes servidores proxy suportam o armazenamento em cache de conteúdo dinâmico da Web e a montagem de fragmentos de páginas gravados para compatibilidade com o protocolo ESI (Edge Side Includes). Uma placa de hardware criptográfica gerencia protocolos de reconhecimento SSL, o que reduz significativamente o processamento requerido do host do servidor proxy e um Access Manager (anteriormente denominado Policy Director) gerencia a autenticação do cliente.

Uma coleção de cluster de servidores de aplicativos distribui o processamento de pedidos, separando a lógica de negócios, contida em componentes EJB, desta camada de apresentação, contida em servlets e arquivos JSP. Cada um destes clusters é gerenciado por um servidor de sessão separado.

O cenário a seguir inclui tanto o Load Balancer quanto o Caching Proxy.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Figura 17. Solução Bancária Business-to-Consumer
Este gráfico descreve uma solução bancária business-to-consumer de exemplo

Rede do Portal da Web

A Figura 18 mostra uma rede de portal da Web projetada para suportar um grande volume de tráfego enquanto oferece a cada cliente um conteúdo personalizado. Para reduzir a carga de processamento nos diversos servidores, nenhuma parte da rede realiza o tráfego de SSL. Como o portal não entrega dados sensitivos, a segurança não é uma questão importante. É importante para os bancos de dados que contêm IDs, senhas e definições de clientes, permanecerem moderadamente seguros e íntegros, mas este requisito não afeta o desempenho do restante do Web site.

Todos os pedidos de clientes são passados do firewall para um Dispatcher que equilibra a carga da rede em um cluster de servidores proxy com caches ativas que agem como servidores substitutos para os servidores Web. Os servidores de métrica são colocados com os servidores proxy para oferecer equilíbrio de carga de dados para o Dispatcher.

O Web site real dinâmico é um cluster de servidores de aplicativos que geram fragmentos de ESI que são transmitidos aos servidores proxy para montagem. Devido a questões de segurança reduzida, cada servidor de aplicativo executa todas as funções necessárias para construir o Web site. Todos os servidores de aplicativos são idênticos. Se um servidor de aplicativo parar de funcionar, o servidor da sessão poderá rotear pedidos para os outros servidores, fornecendo grande disponibilidade para todo o site. Esta configuração também permite a rápida escalada do Web site se houver tráfego excessivo, por exemplo, a hospedagem de um evento especial pelo portal. Os servidores proxy e servidores de aplicativos adicionais podem ser rapidamente configurados no site.

Todo o conteúdo estático, como arquivos de imagens e texto padronizado é armazenado em servidores Web separados, permitindo que seja atualizado conforme necessário, sem risco de danos aos servidores de aplicativos mais complexos.

O cenário a seguir inclui tanto o Load Balancer quanto o Caching Proxy.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Figura 18. Portal da Web
Este gráfico descreve um portal da Web de exemplo

Instalando o Edge Components

Esta parte oferece os procedimentos para instalar o Edge Components.

Esta parte contém os seguintes capítulos:

Requisitos para o Edge Components

Instalando o Edge Components Utilizando o Programa de Instalação

Instalando o Caching Proxy Utilizando Ferramentas de Empacotamento de Sistema

Instalando o Load Balancer Utilizando Ferramentas de Empacotamento de Sistema

Requisitos para o Edge Components

Este tópico oferece um link para requisitos de hardware e software para o Edge Components e descreve as diretrizes para utilizar navegadores da Web com formulários Caching Proxy Configuração e Administração e com a ajuda on-line de Load Balancer.

Pré-requisitos de Hardware e Software

Para obter informações sobre os requisitos de hardware e software suportados para o WebSphere Application Server, Versão 6.1 Edge Components, acesse a seguinte página da Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.

Instalação de SDK: O Java 2 SDK é instalado automaticamente com o Load Balancer em todas as plataformas.

Utilizando Navegadores com os Formulários Configuração e Administração Caching Proxy

Requisitos mínimos do navegador

Para configurar o Caching Proxy utilizando os formulários de Configuração e Administração, seu navegador deve fazer o seguinte:

Para sistemas Linux e UNIX: Para obter as versões recomendadas dos navegadores Mozilla e Firefox, consulte o seguinte Web site e siga os links para a página da Web do software suportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.

Para sistemas Windows: Para obter as versões recomendadas dos navegadores Internet Explorer, Mozilla e Firefox, consulte o seguinte Web site e siga os links para a página da Web do software suportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

Nota:
Em sistemas Linux PowerPC de 64 bits, não será possível acessar formulários Configuração e Administração com o navegador Mozilla, pois não existe um SDK disponível para esta arquitetura. Alternativamente, você pode acessar os formulários de Configuração e Administração de uma máquina diferente com um navegador da Web suportado.

LIMITAÇÃO: A barra de rolagem vertical esquerda dos formulários de administração pode não ser exibida pelo navegador se o número de elementos expandidos for muito grande para ser exibido na janela do navegador. Isso faz com que os elementos expandidos no fim da lista sejam tirados da janela de visualização atual do navegador e fiquem inacessíveis. Para solucionar este problema, limite o número de elementos expandidos no menu esquerdo. Se o número de elementos expandidos for grande, reduza alguns dos elementos até que os do fim da lista sejam exibidos na janela do navegador.

Para exibir corretamente os formulários, o sistema operacional que está exibindo o formulário (aquele em que o navegador reside) deve conter os conjuntos de fontes apropriados para o idioma em que o formulário está escrito. No entanto, a interface do navegador não precisa estar no mesmo idioma que os formulários.

Por exemplo, uma versão em chinês do servidor proxy está executando em um sistema Solaris 9. Um navegador Mozilla com uma interface de idioma em inglês é carregado no host Solaris. Esse navegador pode ser utilizado localmente para editar os formulários Configuração e Administração. (Os formulários são servidos ao navegador no conjunto de caracteres utilizado pelo servidor proxy -- neste exemplo, chinês; no entanto, os formulários poderão não ser exibidos corretamente se o navegador e o seu sistema operacional subjacente não estiverem configurados devidamente para exibir o conjunto de caracteres enviado pelo servidor proxy).

Como alternativa, se uma estação de trabalho do Windows com suporte ao idioma chinês estiver disponível para conectar-se remotamente ao servidor proxy, será possível carregar uma versão em chinês de um navegador Netscape na estação de trabalho do Windows e utilizar esse navegador para inserir valores nos formulários. Esta segunda solução tem a vantagem de manter uma interface de idioma consistente para o administrador.

Os conjuntos de fontes específicos do sistema operacional afetam muito a exibição de vários idiomas, principalmente os caracteres de byte duplo, nos navegadores. Por exemplo, um conjunto específico de fontes chinesas no AIX não tem exatamente a mesma aparência que um conjunto de fontes chinesas nas plataformas Windows. Isso causa algumas irregularidades na aparência de texto HTML e applets Java dentro dos formulários de Configuração e Administração. Para obter a melhor aparência, somente os navegadores em execução nos sistemas operacionais Windows são recomendados.

Nota sobre o navegador Mozilla 1.4 no S/390 e PowerPC

O plugin Java instalado com o Mozilla 1.4 deve ser atualizado para a versão 1.4.2 ou superior para que os Formulários de Administração sejam exibidos corretamente. Use as seguintes etapas para atualizar o plugin:

  1. Visite o link http://plugindoc.mozdev.org
  2. Selecione a plataforma na seção "Documentação"
  3. Siga as instruções listadas na seção "Java Runtime Environment" para atualizar o plugin

Utilizando Navegadores com a Ajuda On-line do Load Balancer

Para utilizar a ajuda on-line do Load Balancer, seu navegador deve suportar:

Utilizar um navegador que não suporta estes requisitos pode resultar em páginas formatadas incorretamente e em funções que podem não funcionar corretamente.

Instalando o Edge Components Utilizando o Programa de Instalação

Este tópico fornece instruções para instalar Edge Components utilizando o Programa de Instalação.

O Java 2 SDK é instalado automaticamente com o Load Balancer em todas as plataformas.

Após a instalação, scripts do pacote do Caching Proxy tentam iniciar o Servidor Proxy utilizando a configuração padrão. Se a porta 80 estiver sendo utilizada por outro servidor Web, o Servidor Proxy falhará ao iniciar.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Utilizando o Programa de Instalação para Windows

Utilize o Programa de Instalação para instalar o Edge Components em seu sistema Windows da seguinte maneira:

  1. Certifique-se de que o sistema Windows atenda a todos os requisitos de hardware e software (Requisitos para o Edge Components).
  2. Efetue login como usuário com privilégios de administrador.
  3. Insira o CD-ROM do Edge Components na unidade de CD-ROM da máquina. A Barra de Lançamento é iniciada automaticamente.
  4. Clique em Ativar o assistente de instalação do WebSphere Application Server - Edge Components. O Programa de Instalação inicia automaticamente. Ele prepara o Assistente InstallShield e abre a janela Bem-vindo.
    Nota:
    Se sua máquina não suportar a opção Auto-reprodução ou se estiver desativada, inicie o Programa de Instalação manualmente executando o programa setup.exe, localizado no diretório de nível superior do CD-ROM.
  5. Clique em Avançar para continuar com a instalação. A janela Contrato de Licença de Software é exibida.
  6. Leia o Contrato de Licença e clique em Sim para aceitar todos os seus termos. A janela Seleção de Componentes é exibida.

    Se o Edge Components já estiver instalado, a janela Opções de Manutenção será aberta antes da janela Seleção de Componentes ser aberta. Selecione o botão de rádio Modificar e clique em Avançar. A janela Seleção de Componentes é exibida.

  7. Selecione os componentes a serem instalados.
  8. Para alterar a seleção de subcomponentes a serem instalados para um determinado componente, clique no nome do componente para selecioná-lo e clique em Alterar Subcomponentes. Outra janela Seleção de Componentes é exibida, mostrando os subcomponentes do componente ativo. Utilize esses mesmos procedimentos para selecionar os subcomponentes a serem instalados, o idioma dos componentes e a localização onde os componentes deverão ser instalados.
  9. Utilize os menus Idioma Atual para selecionar o idioma ou os idiomas no qual deseja instalar os Edge Components. Os idiomas disponíveis estão relacionados no menu da esquerda. Os idiomas que estão selecionados estão listados no menu à direita.
  10. Utilize a janela Seleção de Componentes para verificar a localização da instalação do Edge Components. Você pode aceitar o valor padrão ou especificar uma nova localização clicando em Alterar Pasta.
    Nota:
    Se você escolher uma localização da instalação diferente do padrão, verifique se não há espaços em branco no nome do caminho, por exemplo, evite nomes de caminho como C:\Meus Arquivos\edgeserver\.
  11. Utilize a janela Seleção de Componentes para verificar se há espaço disponível suficiente na localização da instalação selecionada. Se não houver espaço disponível suficiente na localização selecionada, clique em Alterar Pasta e especifique uma nova localização da instalação.
  12. Depois de selecionar Edge Components, a localização da instalação e idiomas, clique em Avançar. Reveja as informações na janela Confirmação de Instalação que é aberta. Para alterar a opção ou as opções, clique em Voltar para retornar à janela Seleção de Componentes e, em seguida, fazer as alterações. Depois de verificar as opções, clique em Concluir.
  13. O Programa de Instalação de Edge Components começa a instalar os Edge Components selecionados e o GSK, se necessário, na localização de instalação especificada.
  14. A janela Instalação Concluída é exibida. Para ler o arquivo Leia-me do Edge Components, verifique se a caixa de entrada Sim, desejo exibir o arquivo Leia-me está selecionada. O arquivo Leia-me é exibido no navegador padrão.
  15. Verifique se a caixa de entrada Sim, desejo iniciar novamente o meu computador está selecionada e clique em Concluir. Se você optou por exibir o arquivo Leia-me, a máquina é iniciada novamente quando você fecha a janela do navegador que exibe o arquivo. Caso contrário, o Programa de Instalação de Edge Components fecha imediatamente e a máquina inicia novamente. Observe que você deve reiniciar sua máquina antes de utilizar os Edge Components instalados recentemente.

Limitação: Utilizar a tecla Tab na janela do contrato de licença alterna entre as opções Eu aceito e Eu não aceito. No entanto, não é possível utilizar a tecla Tab para chegar às opções de navegação Voltar, Avançar ou Cancelar. Como solução alternativa, utilize Shift+Tab para alcançar essas opções de navegação. Além disso, a tecla Enter funciona apenas nos botões de navegação, portanto, você deve utilizar a barra de espaços para selecionar as opções Eu aceito ou Eu não aceito.

Utilizando o Programa de Instalação para Linux e UNIX

Se estiver instalando a partir de um CD, você poderá utilizar o Programa de Instalação para instalar o Edge Components em seus sistemas Linux e UNIX da seguinte maneira:

  1. Verifique se o servidor de computador atende a todos os requisitos de hardware e software descritos no Requisitos para o Edge Components.
  2. Efetue login como superusuário, normalmente root.
  3. Insira o CD-ROM de Edge Components na unidade de CD-ROM da máquina. Se necessário, monte o CD-ROM.
  4. Mude o diretório de trabalho para o diretório superior do CD-ROM.
  5. Chame o Programa de Instalação digitando o seguinte comando:
    # ./install
    A janela Bem-vindo é exibida.
  6. Clique em Avançar para continuar com a instalação. A janela Contrato de Licença de Software é exibida.
  7. Leia o Contrato de Licença e clique em Sim para aceitar todos os seus termos. A janela Seleção de Idioma é exibida.
  8. Selecione os idiomas a serem suportados por essa instalação do Edge Components. Clique em Avançar. A janela Seleção de Componentes é exibida.
  9. Selecione os componentes a serem instalados.
  10. Clique em Avançar. A janela Confirmação da Instalação é exibida.
  11. Reveja as informações na janela Confirmação da Instalação. Para alterar uma ou mais opções, clique em Voltar para retornar à janela Seleção de Componentes e fazer as alterações. Depois de verificar as opções, clique em Continuar.

    O Programa de Instalação começa a instalar os Edge Components selecionados e os pacotes requeridos.

  12. A janela Resumo dos Resultados da Instalação é exibida. Reveja os resultados e clique em Concluir.

Limitação: Utilizar a tecla Tab na janela do contrato de licença alterna entre as opções Eu aceito e Eu não aceito. No entanto, não é possível utilizar a tecla Tab para chegar às opções de navegação Voltar, Avançar ou Cancelar. Como solução alternativa, utilize Shift+Tab para alcançar essas opções de navegação. Além disso, a tecla Enter funciona apenas nos botões de navegação, portanto, você deve utilizar a barra de espaços para selecionar as opções Eu aceito ou Eu não aceito.

No Red Hat Linux 3.0 Atualização 3: Ao executar o programa instalador para componentes Edge, os botões não funcionarão se o painel da GUI for maximizado e, então, restaurado. Para resolver esse problema, faça o seguinte:

  1. Clique no botão X no canto superior direito do painel para fechar o programa instalador.
  2. Responda Sim para a pergunta "Deseja sair?".
  3. Reative o programa instalador sem maximizar e restaurar o tamanho do painel.

Em sistemas Linux e UNIX: Se o programa de configuração for utilizado para instalar componentes Edge, o desinstalador da GUI pode ser utilizado para desinstalar componentes Edge. No entanto, o desinstalador de GUI dos componentes Edge não pode ser utilizado para desinstalar um pacote de atualização que é instalado utilizando comandos nativos. Você deve primeiro desinstalar o pacote de atualização utilizando comandos nativos (os comandos do sistema operacional) para que seja possível desinstalar componentes utilizando o desinstalador da GUI.

Para obter informações sobre a utilização de comandos nativos, consulte o Instalando o Caching Proxy Utilizando Ferramentas de Empacotamento de Sistema e o Instalando o Load Balancer Utilizando Ferramentas de Empacotamento de Sistema.

Instalando o Caching Proxy Utilizando Ferramentas de Empacotamento de Sistema

Este tópico fornece instruções para instalar o Caching Proxy utilizando ferramentas de empacotamento do sistema.

Após a instalação, scripts do pacote do Caching Proxy tentam iniciar o Servidor Proxy utilizando a configuração padrão. Se a porta 80 estiver sendo utilizada por outro servidor Web, o Servidor Proxy falhará ao iniciar.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Utilizando o sistema de instalação do pacote do sistema operacional, instale os pacotes na ordem listada na Tabela 2. O procedimento a seguir detalha as etapas necessárias para concluir esta tarefa.

  1. Insira o CD do Edge Components na unidade de CD-ROM e monte a unidade, se necessário.
  2. Torne-se o superusuário root local.
    su - root
    
    Senha: senha
  3. Vá para o diretório apropriado no CD.
    cd mount_point/package_directory/
  4. Instale os pacotes.

    Em AIX:

    installp -acXd ./packagename

    No HP-UX:

    swinstall -s source/ packagename

    No Linux:

    rpm -i ./packagename

    No Solaris:

    pkgadd -d ./packagename
Tabela 2. Componentes do Caching Proxy
Componente Pacotes Instalados (na Ordem Recomendada)
Caching Proxy
  1. gskit7
  2. icu
  3. admin
  4. msg-cp-lang
  5. cp
Documentação do Edge Component

doc-en_US1

Notas:
  1. A documentação do Load Balancer é fornecida em dois pacotes. O pacote doc-en_US inclui toda documentação da Edge Components, incluindo os documentos do Load Balancer e os coloca no diretório ../edge/doc/. O pacote de documentação associado às instalações do Load Balancer (Instalando o Load Balancer Utilizando Ferramentas de Empacotamento de Sistema) instala apenas os documentos do Load Balancer e os coloca em um subdiretório de ../edge/lb/.
Tabela 3. Nomes dos Arquivos de Pacote do AIX, HP-UX e Solaris
Nome do Pacote Genérico Conjunto de Arquivos AIX Conjunto de Arquivos do HP-UX Nome do Arquivo 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-lang wses_cp.msg.lang1 .base WSES-cpmlang2 WSEScpmlang3
Notas:
  1. No AIX, a variável lang faz referência à substituição de um dos seguintes códigos específicos de idioma: 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. No HP-UX, a variável lang faz referência à substituição de um dos seguintes códigos específicos de idioma: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW. (HP-UX não suporta o idioma português do Brasil (pt_BR).)
  3. No Solaris, a variável lang refere-se à substituição de um dos seguintes códigos específicos de idioma: br, cn, cw, de, en, es, fr, it, ja, kr.
Tabela 4. Nomes de Arquivos de Pacote do Linux
Nome do Pacote Genérico Nome do Arquivo Linux
admin WSES_Admin_Runtime-release-version1.hardw2.rpm
cp WSES_CachingProxy-release-version1.hardw2.rpm
doc WSES_Doc_en_US-release-version1.hardw2.rpm
gskit7 gsk7bas.rpm
icu WSES_ICU_Runtime-release-version1.hardw2.rpm
msg-cp-lang WSES_CachingProxy_msg_lang3-release-version1.hardw2.rpm
Notas:
  1. release-version é o release atual, por exemplo: 6.1.0-0
  2. A variável hardw refere-se à substituição de um dos seguintes: i686, s390, ppc64.
  3. A variável lang faz referência à substituição de um dos seguintes códigos específicos de idioma: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, pt_BR, zh_CN, zh_TW.

O pacote de documentação contém apenas o idioma inglês. O conjunto de documentação do Edge Component traduzido pode ser encontrado no seguinte Web site: www.ibm.com/software/webservers/appserv/ecinfocenter.html.

Desinstalação do Caching Proxy Utilizando Ferramentas do Sistema

Para desinstalar os pacotes:

Em AIX:

installp -u packagename

Para desinstalar todos os pacotes do Caching Proxy, utilize o comando:

installp -u wses

No HP-UX:

swremove packagename

Para consultar os pacotes do Caching Proxy instalados, utilize o comando:

swlist | grep WSES

Os pacotes deveriam ser removidos na ordem inversa em que foram instalados.

No Linux:

rpm -e packagename

Para consultar os pacotes do Caching Proxy instalados, utilize o comando:

rpm -qa |grep -i  wses

Os pacotes deveriam ser removidos na ordem inversa em que foram instalados.

No Solaris:

pkgrm packagename

Para consultar os pacotes do Caching Proxy instalados, utilize o comando:

pkginfo | grep WSES

Os pacotes deveriam ser removidos na ordem inversa em que foram instalados.

Instalando o Load Balancer Utilizando Ferramentas de Empacotamento de Sistema

Este tópico documenta a instalação do Load Balancer nos sistemas AIX, HP-UX, Linux e Solaris:

Dependendo do tipo de instalação, nem todos os pacotes do componente Load Balancer listados nesta seção serão fornecidos.

Se estiver migrando de uma versão anterior do Load Balancer ou se estiver reinstalando um sistema operacional, antes da instalação, poderá salvar quaisquer um dos seus arquivos de configuração anteriores ou arquivos de script do Load Balancer.

Se efetuar logoff de uma máquina após a instalação do Load Balancer, você deverá reiniciar todos os serviços do Load Balancer quando efetuar logon novamente.

Instalando para AIX

Tabela 5 lista os conjuntos de arquivo do AIX para o Load Balancer e a ordem recomendada de instalação utilizando a ferramenta de instalação do pacote do sistema.

Tabela 5. Conjuntos de Arquivos do AIX
Componentes do Load Balancer Conjuntos de Arquivos do AIX
Base ibmlb.base.rte
Administração (com mensagens)
  • ibmlb.admin.rte
  • ibmlb.msg.lang.admin
Driver de Dispositivo ibmlb.lb.driver
Licença ibmlb.lb.license
Componentes do Load Balancer (com mensagens)
  • ibmlb.component.rte
  • ibmlb.msg.lang.lb
Documentação (com mensagens)
  • ibmlb.doc.rte
  • ibmlb.msg.en_US.doc
Metric Server ibmlb.ms.rte
Notas:
  1. O item a seguir pode ser substituído pela variável componente: disp (dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) ou nal (Nortel Alteon Controller).
  2. A variável lang pode ser substituída por: 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

O pacote de documentação contém apenas o idioma inglês. O conjunto de documentação do Edge Component traduzido pode ser encontrado no seguinte Web site: www.ibm.com/software/webservers/appserv/ecinfocenter.html.

Antes de Instalar

Antes de instalar o Load Balancer para AIX, certifique-se de:

Quando instala o produto, você tem a opção de instalar qualquer um ou todos os seguintes itens:

Procedimento de Instalação

É recomendável utilizar a SMIT para instalar o Load Balancer para AIX porque a SMIT assegura que todas as mensagens sejam instaladas automaticamente.

Utilizando o SMIT para Instalar o Load Balancer para AIX

  1. Selecione Instalação e Manutenção de Software.
  2. Selecione Instalar e Atualizar Software.
  3. Selecione Instalar e Atualizar a partir da Última Versão Disponível.
  4. Digite o dispositivo ou diretório contendo os conjuntos de arquivos.
  5. No campo *SOFTWARE para Instalação, digite as informações apropriadas para especificar opções (ou selecione Listar).
  6. Pressione OK.
  7. Quando o comando estiver concluído, pressione Concluído.
  8. Feche a SMIT selecionando Exit Smit a partir do menu Exit ou pressionando F12. Se estiver utilizando SMITTY, pressione F10 para fechar o programa.

Instalando o Load Balancer a partir da Linha de Comandos

  1. Se estiver instalando a partir de um CD, digite os seguintes comandos para montar o CD:
    mkdir /cdrom
    
    mount -v cdrfs -p -r /dev/cd0 /cdrom
  2. Consulte a tabela a seguir para determinar qual comando ou quais comandos devem ser digitados para instalar os pacotes do Load Balancer para AIX desejados:
    Tabela 6. Comandos de Instalação do AIX
    Pacotes Comandos
    Base installp -acXgd device ibmlb.base.rte
    Administration (com mensagens) installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin
    Driver de Dispositivo installp -acXgd device ibmlb.lb.driver
    Licença installp -acXgd device ibmlb.lb.license
    Componentes do Load Balancer (com mensagens). Inclui: Dispatcher, CBR, Site Selector, Cisco CSS Controller e Nortel Alteon Controller

    installp -acXgd device ibmlb.component.rte

    ibmlb.msg.language.lb

    Documentos (com mensagens) installp -acXgd device ibmlb.doc.rte ibmlb.msg.en_US.lb
    Metric Server installp -acXgd device ibmlb.ms.rte
    em que device é:
  3. Certifique-se de que a coluna de resultados no resumo contenha SUCCESS para cada parte do Load Balancer que esteja sendo instalada (APPLYing). Não continue até que todas as partes que deseja instalar tenham sido aplicadas com êxito.
    Nota:
    Para gerar uma lista de conjuntos de arquivos em um dispositivo especificado, incluindo todos os catálogos de mensagens disponíveis, digite
    installp -ld device

Se estiver instalando a partir de um CD, para desmontar o CD, digite o seguinte comando:

unmount /cdrom

Verifique se o produto está instalado digitando o seguinte comando

lslpp -h | grep ibmlb

Se você instalou o produto completo, este comando retorna o seguinte:

ibmlb.base.rte

ibmlb.admin.rte

ibmlb.lb.driver

ibmlb.lb.license

ibmlb.component.rte

ibmlb.doc.rte

ibmlb.ms.rte

ibmlb.msg.language.admin

ibmlb.msg.en_US.doc

ibmlb.msg.language.lb

Os caminhos de instalação do Load Balancer incluem:

Instalando para HP-UX

Esta seção explica como instalar o Load Balancer no HP-UX utilizando o CD do produto.

Antes de Instalar

Antes de iniciar o procedimento de instalação, certifique-se de ter autoridade root para instalar o software.

Se você tiver uma versão anterior instalada, deve desinstalar essa cópia para instalar a versão atual. Primeiro, assegure-se de ter parado tanto o executor quanto o servidor. Depois, para desinstalar o Load Balancer, consulte Instrução para a Desinstalação de Pacotes.

Procedimento de Instalação

A Tabela 7 lista os nomes dos pacotes de instalação do Load Balancer e a ordem recomendada para instalação dos pacotes utilizando a ferramenta de instalação do pacote do sistema.

Tabela 7. Detalhes de Instalação do Pacote do HP-UX para o Load Balancer
Descrição do Pacote Nome do Pacote do HP-UX
Base ibmlb.base
Administração e mensagens ibmlb.admin ibmlb.nlv-lang
Licença do Load Balancer ibmlb.lic
Componentes do Load Balancer ibmlb.component
Documentação ibmlb.doc
Metric Server ibmlb.ms
Notas:
  1. A variável lang faz referência à substituição de um dos seguintes códigos específicos de idioma: de_DE, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW.
  2. A variável component refere-se à substituição de uma das opções a seguir: disp (dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) ou nal (Nortel Alteon Controller).
  3. O pacote de documentação (ibmlb.doc) contém apenas o idioma inglês. O conjunto de documentação do Edge Component traduzido pode ser encontrado no seguinte Web site: www.ibm.com/software/webservers/appserv/ecinfocenter.html.

O HP-UX não suporta o locale Português do Brasil (pt_BR). Os locales suportados no HP-UX são:

Instrução para a Instalação de Pacotes

O procedimento a seguir detalha as etapas necessárias para concluir essa tarefa.

  1. Torne-se o superusuário root local.
    su - root
    
    Senha: senha
  2. Emita o comando install para instalar os pacotes

    Emita o comando install

    swinstall -s /source package_name

    em que source é o caminho do diretório absoluto do local do pacote e package_name o nome do pacote.

    O exemplo a seguir instala o pacote base do Load Balancer (ibmlb.base), se você estiver instalando a partir da raiz do CD

    swinstall -s /source ibmlb.base

    Para instalar todos os pacotes do Load Balancer emita o seguinte comando, se estiver instalando a partir da raiz do CD:

    swinstall -s /source ibmlb
  3. Verifique a instalação dos pacotes do Load Balancer

    Emita o comando swlist para listar todos os pacotes que você instalou. Por exemplo:

    swlist -l fileset ibmlb
    
    

Instrução para a Desinstalação de Pacotes

Utilize o comando swremove para desinstalar os pacotes. Os pacotes devem ser removidos na ordem contrária na qual foram instalados. Por exemplo, emita o seguinte:

Os caminhos de instalação do Load Balancer incluem:

Instalando para Linux

Esta seção explica como instalar o Load Balancer no Linux utilizando o CD Edge Components.

Antes de Instalar

Antes de instalar o Load Balancer, certifique-se de:

Etapas de Instalação

  1. Insira a mídia do Edge Components ou faça download do produto a partir do Web site e instale a imagem de instalação utilizando o RPM (Red Hat Packaging Manager).

    A imagem de instalação é um arquivo em formato lblinux-version.tar.

  2. Descompacte o arquivo em um diretório temporário digitando o seguinte comando:
    tar -xf lblinux-versão.tar
    O resultado é o seguinte conjunto de arquivos com a extensão .rpm:

    Em que --

    O pacote de documentação contém apenas o idioma inglês. O conjunto de documentação do Edge Component traduzido pode ser encontrado no seguinte Web site: www.ibm.com/software/webservers/appserv/ecinfocenter.html.

  3. No diretório em que os arquivos RPM estão localizados, emita o comando para instalar cada pacote. Exemplo:
    rpm -i package.rpm

    Sistemas Red Hat Linux: Devido a um problema conhecido do Red Hat Linux, também será necessário excluir os arquivos _db* RPM, ou ocorrerá um erro.

    É importante instalar todos os pacotes na ordem mostrada na seguinte lista de pacotes necessários para cada componente.

    Nota:
    Pelo menos um dos arquivos RPM requer que o Java esteja instalado e registrado no banco de dados RPM. Se o Java estiver instalado mas não registrado no banco de dados RPM, utilize o comando de instalação com uma opção sem dependências, conforme a seguir:
    rpm -i --nodeps package.rpm 
  4. Verifique se o produto está instalado. Digite o seguinte comando:
    rpm -qa | grep ibmlb

    Instalar o produto completo gera a seguinte saída:

Os caminhos de instalação do Load Balancer incluem:

Se precisar desinstalar os pacotes, inverta a ordem utilizada para a instalação do pacote, assegurando que os pacotes de administração sejam desinstalados por último.

Instalando para Solaris

Esta seção explica como instalar o Load Balancer no Solaris utilizando o CD Edge Components.

Antes de Instalar

Antes de iniciar o procedimento de instalação, certifique-se de que tenha efetuado login como root e que todas as versões anteriores do produto estejam desinstaladas.

Para desinstalar, certifique-se de que todos os executores e os servidores estejam parados. Em seguida, digite o seguinte comando:

pkgrm pkgname

Etapas de Instalação

  1. Insira o CD-ROM que contém o software Load Balancer na unidade apropriada.
  2. No prompt de comandos, digite o seguinte comando:
    pkgadd -d pathname
    em que -d pathname é o nome do dispositivo da unidade de CD-ROM ou o diretório na unidade de disco rígido na qual o pacote está localizado, por exemplo: -d /cdrom/cdrom0/.

    A lista a seguir apresenta os pacotes exibidos e a ordem recomendada para que sejam instalados.

    O pacote de documentação (ibmlbdoc) contém apenas o idioma inglês. O conjunto de documentação do Edge Component traduzido pode ser encontrado no seguinte Web site: www.ibm.com/software/webservers/appserv/ecinfocenter.html.

    Se desejar instalar todos os pacotes, basta digitar all e pressionar Return. Se desejar instalar alguns dos componentes, digite o nome ou nomes correspondentes aos pacotes a serem instalados, separados por espaço ou vírgula e pressione Return. Poderá ser solicitado que altere as permissões em diretórios ou arquivos existentes. Basta pressionar Return ou responder yes. Você precisa instalar os pacotes de pré-requisito (porque a instalação segue a ordem alfabética, não de pré-requisito). Se você digitar all, responda yes a todas as perguntas e a instalação será concluída com êxito.

    Se quiser instalar apenas o componente Dispatcher com a documentação e o Metric Server, é necessário instalar os seguintes pacotes: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc e ibmlbms.

  3. Verifique se o produto está instalado. Emita o seguinte comando:
    pkginfo | grep ibm

Os caminhos de instalação do Load Balancer incluem:

Construindo Redes com o Edge Components

Esta seção fornece procedimentos para construir redes de demonstração básicas utilizando o Edge Components. Essas redes não são para utilização em ambientes de produção. O processo de configurar inicialmente uma rede pode esclarecer conceitos de extremidade da rede para administradores que não estão familiarizados com o produto. Para obter uma descrição completa de todos os recursos de componentes e para obter informações detalhadas, consulte o Caching Proxy Administration Guide e o Load Balancer Administration Guide.

Os procedimentos permitem que qualquer sistema de computador suportado pelo componente seja utilizado em qualquer nó.

Esta parte contém os seguintes capítulos:

Construir uma Rede Caching Proxy.

Construir uma Rede Load Balancer.

Construir uma Rede Caching Proxy

A Figura 19 mostra uma rede básica do Servidor Proxy utilizando três sistemas de computadores localizados em três nós de rede. Esta rede liga o servidor proxy a um host de conteúdo dedicado (IBM HTTP Server), que está localizado no Servidor 2 e o servidor proxy serve o host. Isso é representado visualmente pela Internet sendo localizada entre a estação de trabalho e o Servidor 1.

IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:

Figura 19. Rede de Demonstração do Caching Proxy
Rede de Demonstração do Caching Proxy

Fluxo de Trabalho

Para construir uma rede Caching Proxy, execute estes procedimentos na seguinte ordem:

  1. Rever os Sistemas de Computador e Software Requeridos.
  2. Servidor de Construção 1 (Sistemas Linux e UNIX) ou Servidor de Construção 1 (Sistema Windows).
  3. Configurar o Servidor 1.
  4. Testar a Rede do Caching Proxy.

Rever os Sistemas de Computador e Software Requeridos

Os seguintes sistemas de computador e componentes de software são necessários:

Servidor de Construção 1 (Sistemas Linux e UNIX)

Instale e configure o Caching Proxy da seguinte maneira:

  1. Certifique-se de que o servidor de computador atenda a todos os requisitos de hardware e de software.
  2. Efetue login como superusuário, normalmente root.
  3. Instale o componente Caching Proxy.
  4. Crie uma identificação de administrador e uma senha para acessar os formulários Configuração e Administração digitando o seguinte comando:
    # htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd

    Quando solicitado, forneça ao programa htadm um nome do usuário, uma senha e um nome real do administrador.

  5. Continue com Configurar o Servidor 1.

Servidor de Construção 1 (Sistema Windows)

Instale e configure o Caching Proxy da seguinte maneira:

  1. Certifique-se de que os sistemas operacionais Windows 2000 e Windows 2003 atendam a todos os requisitos de hardware e de software.
  2. Efetue login como usuário com privilégios de administrador.
  3. Instale o componente Caching Proxy.
  4. Crie uma identificação de administrador e uma senha para acessar os formulários Configuração e Administração digitando o seguinte comando:
    cd "Arquivos de Programas\IBM\edge\cp\server_root\protect"
    
    htadm -adduser webadmin.passwd"

    Quando solicitado, forneça ao programa htadm um nome do usuário, uma senha e um nome real do administrador.

  5. Continue com Configurar o Servidor 1.

Configurar o Servidor 1

Na estação de trabalho, faça o seguinte:

  1. Inicie um navegador da Web.
  2. No campo Endereço no navegador, digite http://server_1 , em que server_1 refere-se ao nome do host ou endereço IP real da máquina designada como Servidor 1.
  3. Clique em Formulários Configuração e Administração.
  4. Digite seu nome de administrador e sua senha. Os formulários Configuração e Administração são abertos em seu navegador.
  5. Clique em Configuração do Servidor-->Processamento de Pedido-->Roteamento de Pedido.
  6. Insira uma nova regra de mapeamento de caractere curinga antes da existente, selecionando o botão de opção Inserir Antes e o valor de índice da regra de mapeamento de curinga existente.
  7. Selecione Proxy na caixa drop-down Ação.
  8. Digite /* no campo de modelo de pedido de URL.
  9. Digite o nome do host para o site ao qual deseja redirecionar pedidos HTTP no campo Endereço IP do Servidor ou nome do host. Anteceda este valor com http://.
  10. Clique em Submeter.
  11. Crie uma regra de mapeamento que permita acesso aos formulários Configuração e Administração selecionando o botão de rádio Inserir Antes e o valor de índice da regra de mapeamento criada na Etapa 6.
  12. Selecione Passar na caixa drop-down Ação.
  13. Digite /pub/* no campo de modelo de pedido de URL.
  14. Informe a localização dos formulários Configuração e Administração:
  15. Clique em Submeter.
  16. Clique no ícone Reiniciar o Servidor, na parte superior do formulário de configuração.
  17. Continue com Testar a Rede do Caching Proxy.

Testar a Rede do Caching Proxy

Na estação de trabalho, faça o seguinte:

  1. Inicie um navegador da Web.
  2. Digite http://server_1 no campo Endereço no navegador. As páginas HTML do Servidor 2 serão colocadas em proxy pelo Servidor 1 e entregues ao navegador da Web.
  3. Para acessar os formulários Configuração e Administração, digite http://server_1/pub/ no campo Endereço do navegador. A home page dos formulários Configuração e Administração é exibida.

Construir uma Rede Load Balancer

A Figura 20 mostra uma rede básica de Load Balancer com três estações de trabalho conectadas localmente utilizando o método de encaminhamento MAC do Dispatcher para equilibrar a carga do tráfego da Web entre dois servidores Web. A configuração é semelhante ao equilíbrio de carga de qualquer outro tráfego de TCP ou de aplicativo UDP sem estado.

Figura 20. Rede de Demonstração do Load Balancer
Um gráfico mostra um Cliente, uma nuvem da Internet, uma máquina do Load Balancer e dois servidores conectados localmente com endereços identificados.
Nota:
Esta configuração pode ser concluída utilizando apenas duas estações de trabalho com o Dispatcher localizado em uma das estações de trabalho do servidor da Web. Isto representa uma configuração colocada.

Fluxo de Trabalho

Para construir uma rede Load Balancer, execute estes procedimentos na seguinte ordem:

  1. Rever os Sistemas de Computador e Software Requeridos.
  2. Configurar a Rede.
  3. Configurar o Dispatcher.
  4. Testar a Rede do Load Balancer.

Rever os Sistemas de Computador e Software Requeridos

Os seguintes sistemas de computador e componentes de software são necessários:

Configurar a Rede

  1. Configure suas estações de trabalho para que elas fiquem no mesmo segmento da LAN. Certifique-se de que o tráfego da rede entre as três máquinas não tenha que passar por quaisquer roteadores ou pontes.
  2. Configure os adaptadores de rede para as três estações de trabalho. Para este exemplo, suponha que você tenha a seguinte configuração de rede:
    Estação de Trabalho Nome Endereço 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 rede = 255.255.255.0
    Cada uma das estações de trabalho contém somente uma placa padrão de interface de rede Ethernet.
  3. Certifique-se de que server1.company.com pode executar ping para server2.company.com e server3.company.com.
  4. Certifique-se de que server2.company.com e server3.company.com possam executar ping para server1.company.com.
  5. Certifique-se de que o conteúdo seja idêntico nos dois servidores Web (Servidor 2 e Servidor 3). Isto pode ser feito replicando-se os dados nas duas estações de trabalho, utilizando um sistema de arquivos compartilhado como NFS, AFS, ou DFS ou por qualquer outro meio apropriado para seu site.
  6. Certifique-se de que os servidores Web em server2.company.com e server3.company.com estejam funcionando. Utilize um navegador da Web para solicitar páginas diretamente de http://server2.company.com e http://server3.company.com.
  7. Obtenha outro endereço IP válido para este segmento da LAN. Este é o endereço fornecido para clientes que desejam acessar seu site. Para este exemplo, as informações são as seguintes:
    Name= www.company.com
    
    IP=9.67.67.104  
  8. Configure as duas estações de trabalho do servidor Web para aceitar tráfego para www.company.com.

    Inclua um alias para www.company.com na interface loopback em server2.company.com e server3.company.com.

  9. Exclua qualquer rota extra que possa ter sido criada como resultado de criação de alias da interface de circuito fechado.

    Agora você concluiu todas as etapas de configuração requeridas nas duas estações de trabalho do Web.

Configurar o Dispatcher

Com o Dispatcher, você pode criar uma configuração utilizando a linha de comandos, o assistente para configuração ou a GUI (Interface Gráfica com o Usuário).

Nota:
Os valores de parâmetro devem ser digitados em caracteres do idioma inglês. As únicas exceções são os valores de parâmetros para nomes de hosts e nomes de arquivos.

Configurando a Utilização da Linha de Comandos

Se estiver utilizando a linha de comandos, siga estas etapas:

  1. Inicie o dsserver no Dispatcher:

  2. Inicie a função de executor do Dispatcher:
    dscontrol executor start
  3. Inclua o endereço do cluster na configuração do Dispatcher:
    dscontrol cluster add www.company.com
  4. Inclua a porta do protocolo http na configuração do Dispatcher:
    dscontrol port add www.company.com:80
  5. Inclua cada um dos servidores Web na configuração do Dispatcher:
    dscontrol server add www.company.com:80:server2.company.com
    dscontrol server add www.company.com:80:server3.company.com
  6. Configure a estação de trabalho para aceitar tráfego para o endereço de cluster:
    dscontrol executor configure www.company.com
  7. Inicie a função de gerenciador do Dispatcher:
    dscontrol manager start

    Agora o Dispatcher faz o equilíbrio de carga com base no desempenho do servidor.

  8. Inicie a função de consultor do Dispatcher:
    dscontrol advisor start http 80

    O Dispatcher agora assegura que os pedidos do cliente não sejam enviados para um servidor Web com falha.

Sua configuração básica com servidores conectados localmente agora está concluída.

IMPORTANTE: Com a instalação do Load Balancer para IPv4 e IPv6, a sintaxe do comando do Dispatcher (dscontrol) é idêntica, com uma importante exceção. O delimitador para os comandos dscontrol é um símbolo de arroba (@), em vez de dois-pontos (:). Foi necessário definir um delimitador diferente de dois pontos, pois o formato do IPv6 utiliza dois pontos em seus esquemas de endereço.

Por exemplo (a partir do exemplo anterior de configuração do Dispatcher)

Para obter mais informações, se você estiver utilizando uma instalação do Load Balancer para IPv4 e IPv6, consulte o capítulo para implementação do Dispatcher no Load Balancer para IPv4 e IPv6, que inclui informações sobre as limitações e diferenças de configuração, na publicação WebSphere Application Server Load Balancer Administration Guide.

Configurando a Utilização do Assistente para Configuração

Se estiver utilizando o assistente para configuração, siga estas etapas:

  1. Inicie o dsserver no Dispatcher:

  2. Inicie a função de assistente do Dispatcher, dswizard.

O assistente o orienta passo a passo pelo processo de criação de uma configuração básica para o componente Dispatcher. Ele faz perguntas sobre sua rede e o orienta na configuração de um cluster para o Dispatcher para o equilíbrio de carga do tráfego para um grupo de servidores.

O assistente para configuração contém os seguintes painéis:

Configurando a Utilização da GUI (Interface Gráfica com o Usuário)

Para iniciar a GUI, siga estas etapas:

  1. Certifique-se de que o processo dsserver esteja em execução:
  2. Em seguida, execute um dos seguintes procedimentos:

Testar a Rede do Load Balancer

  1. Em um navegador da Web vá para http://www.company.com para verificar se aparece uma página.
  2. Recarregue a página no navegador da Web.
  3. Emita o seguinte comando: dscontrol server report www.company.com:80:. Verifique se a coluna de conexões totais dos dois servidores inclui até 2.

Apêndices