Conceitos, Planejamento e Instalação de IPv4 Edge Components

WebSphere Application Server
Conceitos, Planejamento e Instalação de Edge Components

Versão 7.0

Primeira Edição (Junho de 2008)

Esta edição aplica-se ao:

WebSphere Edge Components, Versão 7.0

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 da filial IBM que atende sua localidade.

(C) Copyright International Business Machines Corporation 2008. Todos os direitos reservados.
Direitos Restritos para Usuários do Governo dos EUA -- Uso, duplicação e divulgação restritos pelo GSA ADP Schedule Contract com a IBM Corp.


Conteúdo

  • Figuras

  • Sobre Este Manual
  • Quem Deve Ler este Manual
  • Acessibilidade
  • Convenções e Terminologia Utilizados Neste Manual

  • Visão Geral

  • Apresentando o WebSphere Application Server Edge Components
  • 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
  • Mais Informações sobre o Application Server e Edge Components

  • Discussões e Conceitos do Edge Component

  • Armazenamento em Cache
  • Configurações Básicas de Proxy do Armazenamento em Cache
  • Caching Proxy Reverso (Configuração Padrão)
  • Caching Proxy de Redirecionamento
  • Armazenamento em Cache Avançado
  • Clusters do Caching Proxy de Carga Balanceada
  • Armazenando o Conteúdo Dinâmico em Cache
  • Recursos Adicionais de Armazenamento em Cache
  • Desempenho da Rede
  • Hardware da Rede
  • Considerações sobre Memória
  • Considerações sobre Disco Rígido
  • Considerações sobre Rede
  • Considerações sobre CPU
  • Arquitetura da Rede
  • Considerações sobre Carga do Servidor Proxy e Popularidade do Web Site
  • Considerações sobre Tipos de Tráfego
  • Disponibilidade
  • Balanceamento de Carga
  • Balanceamento de Carga de Vários Hosts de Conteúdo
  • Balanceamento de Carga de Vários Servidores Proxy Reversos
  • Load Balancer com Vários Servidores Proxy de Redirecionamento
  • Suporte a Failover
  • Content Based Routing

  • Cenários

  • Rede de Transações entre Empresas e Consumidores
  • Fase 1
  • Fase 2
  • Fase 3
  • Solução Bancária Business-to-Client

  • Rede do Portal da Web

  • Instalando Edge Components

  • Requisitos de Edge Components
  • Pré-requisitos de Hardware e Software
  • Usando Navegadores com Formulários de Administração e Configuração do Caching Proxy
  • Usando Navegadores com a Ajuda Online do Load Balancer
  • Instalando Edge Components Usando o Programa de Configuração
  • Usando o Programa de Configuração para Windows
  • Usando o Programa de Configuração para Linux e UNIX
  • Instalando o Caching Proxy Usando as Ferramentas de Pacote do Sistema
  • Desinstalando o Caching Proxy Usando as Ferramentas do Sistema
  • Instalando o Load Balancer Usando as Ferramentas de Pacote do 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

  • Atualizando Edge Components

  • Atualizando o Caching Proxy para Sistemas Operacionais AIX, HP-UX, Linux e Solaris
  • Antes de iniciar
  • Instalando os Pacotes para o Caching Proxy nos Sistemas Operacionais AIX, HP-UX, Linux ou Solaris
  • Atualizando o Caching Proxy para Sistemas Operacionais Windows

  • Rejeitando uma Atualização

  • Criando Redes com Edge Components

  • Criando uma Rede de Caching Proxy
  • Fluxo de Trabalho
  • Rever os Sistemas de Computador e Software Requeridos
  • Criar Servidor 1 (Sistema Linux e UNIX)
  • Criar Servidor 1 (Sistema Windows)
  • Configurar o Servidor 1
  • Testar a Rede do Caching Proxy
  • Criar uma Rede do 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 Usando a GUI (Interface Gráfica com o Usuário)
  • Testar a Rede do Load Balancer

  • 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 Carga Balanceada
    5. Balanceamento de Carga de Vários Hosts de Conteúdo
    6. Balanceamento de Carga de Vários Servidores Proxy Reversos e Hosts de Conteúdo
    7. Utilizando o Dispatcher para Equilibrar Carga de Vários Caching Proxies.
    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. Usando um Load Balancer de Backup ou Primário para Tornar o Conteúdo 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. Balanceamento 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 do WebSphere(R) Application Server para Edge Components, é uma introdução ao WebSphere Application Server Edge Components. 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 do WebSphere Application Server para Edge Components é escrito para administradores de sistema e rede experientes que estão familiarizados com seus sistemas operacionais e em fornecer serviços de Internet. Exposição anterior ao WebSphere Application Server ou ao WebSphere Application Server Edge Components não é requerida.


    Acessibilidade

    Os recursos de acessibilidade ajudam os usuários com deficiência física, como mobilidade restrita ou visão limitada, a utilizarem os produtos de software com êxito. Esses são os principais recursos de acessibilidade no WebSphere Application Server, Versão 7.0:


    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 Usadas Neste Manual

    ConvençãoSignificado
    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çamento 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.
    RetornarRefere-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(R) para um comando que não requer privilégios de administrador.
    # Representa o prompt do shell de comandos do Linux e UNIX para um comando que requer privilégios de administrador.
    C:\ Representa o prompt de comandos do Windows.
    Digitando ComandosQuando 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 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 WebSphere Application Server Edge Components, o Caching Proxy e o Load Balancer, e abrange sua integração com o Application Server. Também define os componentes do Caching Proxy e o Load Balancer. Além disso, essa seção apresenta outros produtos relacionados à família WebSphere.

    Esta parte contém os seguintes capítulos:


    Apresentando o WebSphere Application Server Edge Components

    O WebSphere é um software de infra-estrutura de Internet que permite que as empresas desenvolvam, implementem e integrem aplicativos de e-business de última geração, como e-commerce entre empresas. O middleware WebSphere suporta aplicativos de negócios de publicação simples da Web através do processamento de transação de escala comercial.

    Como base da plataforma WebSphere, o WebSphere Application Server oferece um conjunto abrangente de middleware que permite que os usuários criem, implementem e gerenciem aplicativos de negócios. Esses aplicativos podem variar de uma simples fachada de loja no site na Web a uma revisão completa da infra-estrutura de computação 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.

    Edge Components (anteriormente conhecido como Edge Server) agora fazem parte da oferta do WebSphere Application Server. Edge Components podem ser usados em conjunto com o WebSphere Application Server para controlar o acesso do cliente a servidores da Web e para permitir que empresas forneçam melhores serviços para os usuários que acessam o conteúdo baseado na Web pela Internet ou por uma intranet corporativa. Usar Edge Components pode reduzir o tráfego do servidor da Web, aumentar a disponibilidade de conteúdo e melhorar o desempenho do servidor da Web. Como o nome diz, geralmente os Edge Components são executados em máquinas que estão próximas (em uma configuração de rede) ao limite entre uma intranet corporativa e a Internet.

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


    Caching Proxy

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

    O Caching Proxy pode ser configurado em função de um servidor proxy reverso (configuração padrão) ou de um servidor proxy de redirecionamento, fornecendo um ponto de presença para uma rede e um servidor de rede interno com função de melhorar o pedido e o tempo de resposta. Para obter informações sobre configurações reversas e de redirecionamento, consulte Configurações Básicas do Caching Proxy.

    O servidor proxy intercepta pedidos de dados de um cliente, recupera as informações solicitadas de máquinas que hospedam conteúdo e fornece esse conteúdo novamente ao cliente. Mais comumente, os pedidos são para documentos armazenados em máquinas de servidores da 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 lidar com outros protocolos, como FTP (File Transfer Protocol) e Gopher.

    O servidor proxy armazena conteúdo que pode ser armazenado em cache em um cache local antes de distribuí-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 satisfaça pedidos subseqüentes com o mesmo conteúdo, distribuindo-o diretamente do cache local, o que é muito mais rápido do que recuperá-lo novamente do host de conteúdo.

    Os plug-ins do Caching Proxy incluem funcionalidade para o servidor proxy.

    Você também pode estender as funções do Caching Proxy criando módulos de plug-in customizados para 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 rede de ponta que direcionam o fluxo do tráfego de rede, reduzindo o congestionamento e o balanceamento da carga em vários outros serviços e sistemas. O Load Balancer fornece seleção de site, gerenciamento de carga de trabalho, afinidade de sessão e failover transparente.

    O Load Balancer é instalado entre os servidores backend corporativos e da Internet, que podem ser hosts de conteúdo ou máquinas do Caching Proxy. O Load Balancer atua como o único nó de ponto de presença corporativo na Internet, mesmo se a empresa usar vários servidores backend devido a alta demanda ou grande quantidade de conteúdo. Você também pode garantir alta disponibilidade instalando um Load Balancer de backup para controlar se o primário falha temporariamente.

    O Load Balancer intercepta pedidos de dados de clientes e redireciona cada pedido para o servidor que está atualmente mais capacitado para 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 máquinas do WebSphere Application Servers e do Caching Proxy. O balanceamento de carga pode ser personalizado para um aplicativo específico ou plataforma, utilizando consultores personalizados. Orientadores de objetivos especiais estão disponíveis para obter informações para o balanceamento de carga de WebSphere Application Servers.

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

    O balanceamento 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, balanceamento 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.

    O Load Balancer inclui os seguintes componentes:

    Dispatcher

    Para todos os serviços da Internet, como HTTP, FTP, HTTPS e Telnet, o componente Dispatcher desempenha o balanceamento de carga para servidores dentro de uma LAN (Local Area Network) ou WAN (Wide Area Network). Para serviços HTTP, o Dispatcher pode desempenhar o balanceamento de carga de servidores com base no conteúdo da 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.

    Content Based Routing

    Para serviços HTTP e HTTPS, o componente Content Based Routing desempenha o balanceamento de carga para servidores com base no conteúdo do pedido do cliente. O componente Content Based Routing trabalha em conjunto com o componente Application Server Caching Proxy.

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

    Seletor de Site

    O componente Site Selector melhora um sistema de balanceamento 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 Edge Component, com a seguinte exceção:

    Cisco CSS Controller

    Nota:
    O componente Cisco CSS Controller é enviado com a Versão 7.0 do Load Balancer para IPv4, mas esse componente pode não suportar um hardware mais novo. Consulte a página de pré-requisitos para o hardware suportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

    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 Edge Component, com a seguinte exceção:

    Nortel Alteon Controller

    Nota:
    O componente Nortel Alteon Controller é enviado com a Versão 7.0 do Load Balancer para IPv4, mas esse componente pode não suportar um hardware mais novo. Consulte a página de pré-requisitos para o hardware suportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

    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 Edge Component, com a seguinte exceção:

    Metric Server

    O componente Metric Server é executado como um daemon em um servidor com carga balanceada e fornece informações sobre cargas do sistema para os componentes Load Balancer.


    Edge Components e a Família WebSphere

    A família IBM WebSphere foi criada para auxiliar os usuários a alcançarem a promessa 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 do WebSphere Application Server, incluindo Edge Components e outros softwares da família WebSphere que estão muito integrados com o WebSphere Application Server e que aperfeiçoam seu desempenho. Para uma visão geral do WebSphere Application Server e de seus componentes, consulte Apresentando o WebSphere Application Server Edge Components.


    Tivoli Access Manager

    O Tivoli Access Manager (anteriormente 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. O plug-in do Caching Proxy explora a estrutura de segurança do Access Manager, permitindo que o servidor proxy use os serviços de autorização ou autenticação integrados do Access Manager.


    WebSphere Portal Server

    O WebSphere Portal Server (disponível separadamente) oferece uma estrutura para resolver problemas de apresentação, segurança, escalabilidade e disponibilidade associados aos 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 confiabilidade. O componente Load Balancer do Application Server também pode ser usado para balanceamento de carga adicional e alta disponibilidade.


    WebSphere Site Analyzer

    O WebSphere Site Analyzer (disponível separadamente) ajuda empresas a anteciparem problemas de capacidade e desempenho. Com o Site Analyzer, logs e outros recursos de gerenciabilidade do Caching Proxy e do Load Balancer podem ser usados para antecipar a demanda por recursos adicionais monitorando, analisando e registrando o uso do Web site. Além disso, os componentes de gerenciabilidade do Site Analyzer ajudam os usuários que instalam e fazem upgrade de Edge Components, gerenciam e armazenam configurações, operam Edge Components remotamente e visualizam e registram 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 telefone para Internet, conversão de conteúdo da Web para o idioma nacional preferido pelo usuário (chamando o WebSphere Translation Server) e conversão de linguagens de marcação. O Transcoding Publisher aperfeiçoa os recursos do Caching Proxy, permitindo que ele sirva o conteúdo para diferentes dispositivos e usuários. Depois de acessar o conteúdo de um servidor da 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 o servidor proxy quanto ao conteúdo que corresponde aos requisitos de usuário e dispositivo e, se uma correspondência for encontrada, serve o conteúdo do cache do servidor proxy.


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

    A seguinte documentação específica para o WebSphere Application Server Edge Components está disponível no Centro de Informações de Edge Components.

    Outra documentação do WebSphere Application Server está disponível a partir da página da biblioteca do WebSphere Application Server.

    As informações de suporte de nota técnica de Edge Components está disponível a partir da página de suporte do WebSphere Application Server.

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


    Discussões e Conceitos do Edge Component

    Esta parte inclui discussões detalhadas que destacam algumas das funcionalidades disponíveis com Edge Components. Consulte Apresentando o WebSphere Application Server Edge Components 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 minimizar a utilização da largura de banda da rede e garantir que usuários finais recebam serviços mais rápidos e confiáveis. Isso é obtido porque o armazenamento em cache executado pelo servidor proxy controla servidores backend e links ponto-a-ponto. O Caching Proxy pode armazenar em cache o conteúdo estático e o conteúdo gerado dinamicamente pelo WebSphere Application Server. Para fornecer armazenamento em cache aperfeiçoado, o Caching Proxy também atua em conjunto com o componente Load Balancer do Application Server. Consulte Apresentando o WebSphere Application Server Edge Components para obter uma introdução desses sistemas.

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


    Configurações de Caching Proxy Básico

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

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

    Ao usar uma configuração de proxy reverso, as máquinas do Caching Proxy estão localizadas entre os hosts de conteúdo da Internet e da empresa. Atuando como um substituto, o servidor proxy intercepta pedidos do usuário que chegam da Internet, os encaminha para o host de conteúdo apropriado, armazena em cache os dados retornados e fornece os dados para os usuários através da Internet. O armazenamento em cache permite que o Caching Proxy satisfaça pedidos subseqüentes com o mesmo conteúdo diretamente do cache, o que é muito mais rápido do que recuperá-los novamente do host de conteúdo. As informações podem ser armazenadas em cache dependendo de quando expirarão, do tamanho máximo do cache e de quando as informações devem ser atualizadas. Tempos de download mais rápidos para correspondências do cache significa melhor qualidade de serviço para clientes. A Figura 1 mostra esta funcionalidade básica do Caching Proxy.

    Figura 1. Caching Proxy atuando como um proxy reverso

    Este gráfico mostra a configuração básica do proxy reverso

    Nesta configuração, o servidor proxy (4) intercepta pedidos cujas URLs incluem o nome 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 para o servidor proxy em vez de retorná-lo 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 o transmitir para o usuário final. O exemplo mais conhecido de conteúdo que pode ser armazenado em cache é a página da Web estática; no entanto, o Caching Proxy também fornece capacidade de armazenar em cache e servir 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 do gateway.

    Ao usar uma configuração de proxy de redirecionamento, as máquinas do Caching Proxy estão localizadas entre o cliente e a Internet. O Caching Proxy redireciona um pedido do cliente para os hosts de conteúdo localizados na Internet, armazena em cache os dados recuperados e fornece os dados recuperados para o cliente.

    Figura 2. Caching Proxy atuando como um proxy de redirecionamento

    Este gráfico mostra a configuração básica do proxy de redirecionamento

    A Figura 2 mostra a configuração do Caching Proxy de redirecionamento. Os programas do navegador de clientes (na máquina marcada como 1) são configurados para direcionar pedidos para o Caching Proxy de redirecionamento (2), que é configurado para interceptar os pedidos. Quando o usuário solicita o arquivo X armazenado no host de conteúdo (6), o Caching Proxy 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 para fora usando o roteador da empresa (4) via Internet (5).

    Dessa forma o servidor de origem retorna o arquivo X para o Caching Proxy 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 seu cache (3) antes de o transmitir para o usuário final. Por padrão, o armazenamento em cache é ativado e o Caching Proxy de redirecionamento utiliza um cache de memória. 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, o tempo de resposta para o primeiro usuário que acessa o arquivo X é possivelmente mais lento do que aquele sem o Caching Proxy de redirecionamento, pois leva mais tempo para o Caching Proxy de redirecionamento processar o pacote de pedido original e examinar o cabeçalho do arquivo X quanto a informações de possibilidade de armazenamento em cache quando ele é recebido. O uso do Caching Proxy 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 do 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 Caching Proxy 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. Nesta função, o Caching Proxy executa a mesma função de um Caching Proxy de redirecionamento básico, mas não faz isso sem o cliente ser avisado de sua presença. A configuração do Caching Proxy transparente é suportada somente nos sistemas Linux.

    Na configuração descrita no 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 o proxy transparente, como descrito na Figura 3. Como com o Caching Proxy de redirecionamento comum, 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 pedidos do cliente e direcioná-los ao Caching Proxy transparente. Quando um cliente que trabalha 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 ao 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 para fora usando o roteador (2) via Internet (5). Quando o arquivo X chega, o Caching Proxy armazena em cache o arquivo, se adequado (sujeito às condições descritas em Caching Proxy de Redirecionamento) e transmite o arquivo para o cliente que solicita.

    Figura 3. O Caching Proxy atuando como um proxy de redirecionamento transparente

    Este gráfico mostra a configuração básica de 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

    Cluster do Caching Proxy com Carga Balanceada

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

    A Figura 4 mostra como você pode combinar o Caching Proxy com o Load Balancer para distribuir conteúdo da Web efetivamente mesmo em circunstâncias de alta demanda. Nesta configuração, o servidor (4) é configurado para interceptar pedidos cujas URLs incluem o nome do host para um cluster de hosts de conteúdo (7) com carga balanceada pelo Load Balancer (6).

    A Figura 4. Caching Proxy atuando como servidor proxy para um cluster com carga balanceada

    O gráfico que aparece aqui mostra o servidor proxy atuando como um substituto para um cluster com carga balanceada

    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 pedido para o Load Balancer no endereço do cluster. O Load Balancer usa seu algoritmo de balanceamento de carga para determinar qual host de conteúdo é mais adequado no momento para satisfazer o pedido para o arquivo X. Esse host de conteúdo retorna o arquivo X para o servidor proxy em vez de retorná-lo via Load Balancer. O servidor proxy determina se deve armazená-lo em cache e enviá-lo ao usuário final, da mesma forma descrita anteriormente.

    Armazenando o Conteúdo Dinâmico em Cache

    A funcionalidade de armazenamento em cache avançada também é fornecida pelo plug-in de armazenamento em cache dinâmico do Caching Proxy. Quando usado em conjunto com o WebSphere Application Server, o Caching Proxy pode armazenar em cache, servir e invalidar o conteúdo dinâmico na forma de JSPs (JavaServer Pages) e 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 do 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 de armazenamento em cache dinâmico ativa o conteúdo com um tempo de expiração indefinido para armazenamento 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 pela sincronização do cache dinâmico do Caching Proxy e do Application Server é compartilhada pelos dois sistemas. Por exemplo, uma página da Web dinâmica criada 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 resultados da execução do aplicativo repetidamente para muitos usuários diferentes até que seja notificado de que a página é inválida. O conteúdo no cache de resposta do servlet do Caching Proxy é válido até que o servidor proxy remova uma entrada, pois o cache está congestinado, até que o tempo limite padrão configurado pela diretiva ExternalCacheManager no arquivo de configuração do Caching Proxy expire ou até que o Caching Proxy receba uma mensagem de invalidação direcionando-o a limpar o conteúdo de seu cache. As mensagens de invalidação são originárias do WebSphere Application Server que possui o conteúdo e propagadas a cada Caching Proxy configurado.

    Nota:
    Páginas privadas geradas dinamicamente (como uma página mostrando o conteúdo de um 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 é configurado para executar autenticação e autorização para garantir que as páginas privadas sejam servidas apenas pelos usuários pretendidos.

    Recursos Adicionais de Armazenamento em Cache

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


    Desempenho da Rede

    O desempenho da rede é afetado pela apresentação da funcionalidade do Caching Proxy. Use o Caching Proxy sozinho ou em conjunto com o Load Balancer para melhorar o desempenho de sua rede. Consulte Apresentando o WebSphere Application Server Edge Components para obter uma introdução desses sistemas.

    O desempenho do Caching Proxy em sua empresa é tão bom quanto o hardware no qual ele executa e a arquitetura geral do sistema no qual ele é apresentado. Para otimizar o desempenho da rede, modele o hardware e a arquitetura geral da rede para as características dos servidores proxy.

    A configuração e administração básica do software do Caching Proxy e o ajuste do 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 do cache e valores de encadeamentos ativos. Detalhes sobre a configuração do software do 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 relógios 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 Edge Component, com as seguintes exceções:


    Hardware de Rede

    Esta seção aborda problemas de hardware da rede para considerar quando introduzir a funcionalidade do Caching Proxy em sua rede.

    Considerações sobre Memória

    Uma grande quantidade de memória deve ser dedicada para o 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. Então, é possível ter um servidor proxy que consuma 3 ou 4 GB de memória física. Observe que o cache somente memória é significativamente mais rápido do que um cache de disco bruto 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 na qual o Caching Proxy está instalado. Isto se aplica principalmente quando são utilizados 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 das unidades de disco podem limitar o desempenho quando o Caching Proxy estiver configurado para usar um cache do 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

    Requisitos de rede como a velocidade, o tipo e o número de NICs, e a velocidade da conexão de rede para o servidor proxy afetam o desempenho do Caching Proxy. Geralmente o desempenho usa dois NICs em uma máquina do servidor proxy: uma para tráfego que chega e outra para o que sai. 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 possivelmente pode ser um fator de limitação. 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 atender aos requisitos da CPU do servidor proxy para o ambiente, especialmente para modelar a carga de solicitação de pico que o servidor proxy servirá.


    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.

    Esta seção aborda problemas de arquitetura da rede levando em consideração quando introduzir a funcionalidade do Caching Proxy em sua rede.

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

    Se o Web site de sua empresa for popular, pode haver maior demanda de conteúdo do que um servidor proxy simples pode satisfazer efetivamente, resultando em tempos de respostas mais lentos. Para otimizar o desempenho da rede, considere incluir máquinas do Caching Proxy com carga balanceada, em cluster, ou usar uma arquitetura de cache compartilhada com RCA (Remote Cache Access) em toda sua arquitetura de rede.

    Considerações sobre Tipos de Tráfego

    As principais contribuições para aumentar o desempenho derivam os recursos de armazenamento em cache do Caching Proxy. No entanto, o servidor proxy pode ser um gargalo se não for configurado corretamente. Para determinar a melhor configuração do cache, deve ser feito um grande esforço para analisar as características do tráfego. O tipo, a quantidade e os atributos de conteúdo afetam o desempenho do servidor proxy em termos de tempo necessário para recuperar documentos de servidores de origem e carga no servidor. Quando você entende o tipo de tráfego no qual o Caching Proxy fará proxy ou servirá de seu cache, pode avaliar essas características ao configurar o 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 do cache. Adicionalmente, entender que a maioria do conteúdo são páginas da Web personalizadas que não são candidatas ao armazenamento em cache também é pertinente para ajustar o 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 familiarização com as características do tráfego de rede permite que você determine se o desempenho aperfeiçoado pode resultar do uso do recurso de armazenamento em cache dinâmico do Caching Proxy.


    Disponibilidade

    Funcionando em conjunto com hosts de conteúdo, como o WebSphere Application Server, ou com o componente Caching Proxy do Application Server, o componente Load Balancer do Application Server permite que você aperfeiçoe sua disponibilidade e escalabilidade da rede. (Consulte Apresentando o WebSphere Application Server Edge Components para obter uma introdução para esses Edge Components.) O Load Balancer é utilizado por redes corporativas e é instalado entre a Internet e os servidores de backend da empresa. O Load Balancer atua como o único ponto de presença corporativo na Internet, mesmo se a empresa usa vários servidores backend devido a alta demanda ou grande quantidade de conteúdo.

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

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


    Balanceamento de Carga

    O balanceamento 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.

    Balanceamento 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 balanceamento 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 balanceamento de carga de vários hosts de conteúdo é usar o componente Dispatcher do Load Balancer, como descrito na Figura 5. Nesta configuração, todos os hosts de conteúdo (as máquinas marcadas como 5) armazenam o mesmo conteúdo. Eles são definidos para formar um cluster com carga balanceada e um nome de host e endereço IP dedicados ao cluster são designados a uma das interfaces de rede da máquina do Load Balancer (4). 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 endereço IP do Dispatcher. O Dispatcher determina qual dos hosts de conteúdo no cluster é mais adequado no momento para servir ao pedido e redireciona o pedido para esse host, que, quando o método de redirecionamento MAC é configurado, retorna o arquivo X diretamente para o cliente (ou seja, o arquivo X não é transmitido através do Load Balancer).

    Figura 5. Balanceamento de carga de vários hosts de conteúdo

    O gráfico que aparece aqui mostra o balanceamento de carga de vários hosts de conteúdo

    Nota:
    O Dispatcher fornece três métodos de redirecionamento:

    Por padrão, o Dispatcher usa balanceamento de carga round-robin como DNS, mas mesmo assim resolve muitas das inadequaçõ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ê também pode otimizar o balanceamento de carga ativando componentes do gerenciador e orientador otimizados do Load Balancer, que rastreiam o status de um host de conteúdo mais precisamente e incorporam as informações adicionais no processo de decisão do balanceamento de carga. O gerenciador permite que você atribua pesos diferentes aos diferentes fatores utilizados no processo de decisão, personalizando, adicionalmente, o balanceamento de carga de seu site.

    Balanceamento de Carga de Vários Servidores Proxy Reversos

    O Dispatcher do Load Balancer também pode desempenhar balanceamento de carga para várias máquinas do Caching Proxy. Se o Web site de sua empresa for popular, pode haver maior demanda de conteúdo do que um servidor proxy simples pode satisfazer efetivamente, degradando potencialmente o desempenho do servidor proxy.

    Você pode ter vários sistemas do Caching Proxy desempenhando funções do proxy para um único host de conteúdo (semelhante à configuração descrita na Figura 1), mas se seu site for popular bastante para precisar de vários servidores proxy, provavelmente você também precisará de vários hosts de conteúdo cujas cargas são balanceadas pelo Load Balancer. A Figura 6 mostra esta configuração. O Dispatcher marcado como 4 faz o balanceamento de carga de um cluster de dois servidores proxy (5) e o Dispatcher marcado como 7 faz o balanceamento de carga de um cluster de três hosts de conteúdo (8).

    Figura 6. Balanceamento de carga de vários servidores proxy reversos e hosts de conteúdo

    O gráfico que aparece aqui mostra o balanceamento de carga de vários servidores proxy e hosts de conteúdo

    O nome do host do cluster do Dispatcher marcado como 4 não é 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 de host do cluster para o Dispatcher marcado como 7 não é visível na Internet e portanto pode ser qualquer valor desejado. Como exemplo, para a ABC Corporation, um nome de host adequado para o Dispatcher marcado como 4 é www.abc.com, considerando que o Dispatcher marcado como 7 pode ser chamado de 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 como 4, que o transmite para o servidor proxy (5), que é atualmente mais adequado para lidar com ele, de acordo com o algoritmo do balanceamento de carga. Se o servidor proxy tiver o arquivo X em seu cache (6), ele o retornará diretamente para o navegador, ignorando o Dispatcher marcado como 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 para o Dispatcher marcado como 7. O Load Balancer determina qual host de conteúdo (8) é atualmente mais capaz de satisfazer o pedido e direciona o pedido ali. O host de conteúdo recupera o arquivo X do armazenamento e o retorna diretamente ao servidor proxy, ignorando o Dispatcher marcado como 7. O servidor proxy armazena em cache o arquivo X, se adequado, e o redireciona para o navegador, ignorando o Dispatcher marcado como 4.

    Load Balancer 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 usar o Dispatcher do Load Balancer para balancear o carga entre elas.

    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 PCA (proxy automatic configuration) (como descrito em Caching Proxy de Redirecionamento Transparente (Somente Sistemas Linux)) que direciona o navegador para failover de um ou mais Caching Proxies secundários. Um arquivo PAC não atende às necessidades de balanceamento 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 mostra uma configuração de rede na qual o Dispatcher faz o balanceamento de 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 de host e endereço IP dedicados ao 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 cria um novo pedido, o transmite através do gateway da empresa (5) e pela Internet (6), e, se adequado, armazena o arquivo retornado em seu cache (4), como descrito mais detalhadamente em Caching Proxy de Redirecionamento

    Nota:
    O recurso de proxy transparente está disponível apenas em sistemas Linux.

    Figura 7. Usando o Dispatcher para balancear vários Caching Proxies.

    Este gráfico mostra vários proxies de balanceamento de carga

    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 balanceamento 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 o WebSphere Application Server Load Balancer Administration Guide. Usar vários Caching Proxies pode gerar possíveis resultados ineficientes, pois mais de um Caching Proxy pode armazenar em cache o mesmo arquivo se clientes diferentes solicitarem o arquivo via máquinas diferentes 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 seus 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 seu cache ou redirecionando 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 falhar ou se tornar inacessível devido a uma falha na rede, os clientes do navegador alcançarão o Caching Proxy ou a Internet. A solução é configurar outro Dispatcher para atuar como um backup para o Dispatcher primário, como descrito na Figura 8.

    Figura 8. Usando um Dispatcher primário e de backup para fornecer acesso à Internet altamente disponível.

    Este gráfico mostra um Dispatcher primário e de backup para o balanceamento de carga de vários proxies

    Aqui, um navegador executando uma das máquinas marcadas como 1 normalmente direciona seu pedido para um arquivo X para o Dispatcher primário (2), que roteia o pedido para o Caching Proxy (4) selecionado na base do critério de balanceamento de carga do Dispatcher. O Caching Proxy cria um novo pedido, o roteia através do gateway da empresa (6) pela Internet (7) para o host de conteúdo (8), e armazena o arquivo X retornado em seu cache (5), se adequado (para 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 balanceamento de carga, desde que o principal esteja operacional. Os Dispatchers primário e de backup rastreiam o status um do outro trocando periodicamente mensagens chamadas de pulsações. Se o Dispatcher de backup detectar que o primário falhou, ele automaticamente ficará responsável pelo balanceamento de carga interceptando pedidos direcionados para o nome de host e endereço IP do primário. Também é possível configurar dois Dispatchers para alta disponibilidade mútua. Neste caso, cada um executará ativamente o balanceamento de carga para um cluster separado de proxies de armazenamento em cache, agindo ao mesmo tempo como o backup para seu parceiro. Para mais discussão, consulte 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 mostra essa configuração, na qual o Dispatcher de backup executa na mesma máquina (3) do Caching Proxy.

    Figura 9. Localizando o Dispatcher de backup em uma máquina do Caching Proxy.

    Este gráfico mostra um Dispatcher primário e de backup para o balanceamento de carga de vários proxies


    Suporte à falha inversa

    O Load Balancer atua 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 atuar como um backup para o Load Balancer primário, como descrito na Figura 10. Se um Load Balancer falhar ou se tornar inacessível devido a uma falha na rede, os usuários finais ainda poderão alcançar os hosts de conteúdo.

    Figura 10. Usando um Load Balancer primário ou de backup para tornar o conteúdo da Web altamente disponível

    O gráfico que aparece aqui mostra o uso de um Dispatcher primário e de backup para tornar o conteúdo da Web altamente disponível

    Em um caso normal, um navegador executando em uma das máquinas marcadas como 1 direciona seu pedido para um arquivo X para o nome de host do cluster mapeado para o Load Balancer primário (4). O Dispatcher roteia o pedido para o host de conteúdo (6) selecionado na base do critério de balanceamento de carga do Dispatcher. O host de conteúdo envia o arquivo X diretamente para o navegador, roteando-o através do gateway da empresa (3) pela Internet (2), mas ignorando o Load Balancer.

    O Dispatcher de backup (5) não executa o balanceamento de carga até que o primário esteja operacional. Os Dispatchers primário e de backup rastreiam o status um do outro trocando periodicamente mensagens chamadas de pulsações. Se o Dispatcher de backup detectar que o primário falhou, ele automaticamente ficará responsável pelo balanceamento de carga interceptando pedidos direcionados para o nome de host do cluster e endereço IP do primário.

    Também é possível configurar dois Dispatchers para alta disponibilidade mútua. Neste caso, cada um executará ativamente o balanceamento de carga para um cluster separado de hosts de conteúdo, agindo ao mesmo tempo como o backup para seu parceiro. (Nas instalações do Load Balancer para IPv4 e IPv6, a alta disponibilidade simples é suportada, mas a mútua não.)

    O Dispatcher geralmente não consome muitos recursos de processamento ou memória e outros aplicativos podem executar na máquina do Load Balancer. Caso seja importante minimizar os custos com equipamento, é também possível executar o Dispatcher de backup em uma das máquinas do cluster no qual seu balanceamento de carga está sendo feito. A Figura 11 mostra essa configuração, na qual o Dispatcher de backup executa um dos hosts de conteúdo (5) no cluster.

    Figura 11.Localizando o Load Balancer de backup em um host de conteúdo

    O gráfico que aparece aqui mostra o Dispatcher de backup em execução em um 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 em conjunto com o componente Caching Proxy do Application Server, o componente Load Balancer do Application Server permite que você distribua pedidos para vários servidores backend que hospedam conteúdo diferente. (Consulte Apresentando o WebSphere Application Server Edge Components para obter uma introdução para esses Edge Components.)

    Se o componente CBR (Content Based Routing) do Load Balancer estiver 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 mais discussão, consulte os capítulos sobre como configurar o CBR e sobre as funções avançadas do Load Balancer e do CBR no WebSphere Application Server Load Balancer Administration Guide. Para definições de sintaxe para as regras, consulte o apêndice sobre os tipos de regras do CBR do WebSphere Application Server Load Balancer Administration Guide.

    A Figura 12 mostra uma configuração simples na qual o componente CBR do Load Balancer e o Caching Proxy são instalados juntos na máquina marcada como 4 e roteiam 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 o transmite para o componente CBR na mesma máquina, que transmite a URL no pedido e determina que o host de conteúdo 6 hospede o arquivo X. O servidor proxy gera um novo pedido para o arquivo X e, se o recurso de armazenamento em cache estiver ativado, determina se o arquivo está qualificado para armazenamento em cache quando o host 6 o retorna. Se o arquivo puder ser armazenado em cache, o servidor proxy armazena 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 HTTP com o CBR

    O gráfico que aparece aqui mostra o roteamento de pedidos HTTP com o CBR

    A Figura 13 mostra uma configuração mais complexa que é possivelmente adequada para um varejista online. O componente CBR do Load Balancer e o servidor proxy são instalados juntos na máquina marcada como 4 e roteiam pedidos para duas máquinas do Load Balancer. A máquina do Load Balancer marcada como 6 faz o balanceamento de carga de um cluster dos hosts de conteúdo (8) que hospedam o conteúdo mais estático do catálogo do varejista, considerando que o Load Balancer marcado como 7 faz o balanceamento de carga de um cluster dos servidores da Web que lidam com 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 e o transmite para o componente CBR na mesma máquina, que analisa a URL e determina que a máquina do Load Balancer marcada como 6 lide com essa URL. O servidor proxy cria um novo pedido de acesso e o envia ao Load Balancer, que determina qual dos hosts de conteúdo marcados como 8 é atualmente mais adequado para servir ao pedido (com base no critério que você define). Esse host de conteúdo analisa 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 adequado.

    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 percorre o mesmo caminho do pedido de acesso do catálogo, exceto pelo fato de que o componente CBR na máquina 4 o roteia para a máquina do Load Balancer marcada como 7. O Load Balancer o redireciona para o servidor da Web mais adequado, marcado como 9, que responde diretamente ao servidor proxy. Como as informações de pedido geralmente são geradas dinamicamente, o servidor proxy provavelmente não o armazena em cache.

    Figura 13. Balanceamento de carga de pedidos HTTP com o CBR

    O gráfico que aparece aqui mostra o balanceamento de carga de pedidos HTTP roteados com o CBR

    A função CBR do Load Balancer suporta afinidade 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 usam IBM WebSphere Application Server Edge Components. 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 seguinte cenário inclui o Load Balancer e o Caching Proxy.

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


    Fase 1

    A Figura 14 mostra um Web site comercial pequeno criado para fornecer navegação de catálogo eficiente. Todos os pedidos de clientes são transmitidos do firewall para um Dispatcher que roteia os pedidos para um cluster dos servidores proxy com caches ativos que agem como servidores substitutos para os servidores da Web. Os servidores de métrica são colocados com os servidores proxy para oferecer balanceamento de carga de dados para o Dispatcher.Esta disposição reduz a carga da rede em servidores da Web e isola-os do contato direto com a Internet.

    Figura 14. Rede Business-to-consumer (Fase 1)

    Este gráfico mostra um exemplo de rede business-to-consumer básica


    Fase 2

    A Figura 15 mostra a segunda fase de evolução de um Web site comercial criado para fornecer navegação de catálogo eficiente e rápida e compras seguras para possíveis clientes. Todos os pedidos dos clientes são roteados para a ramificação adequada da rede por um Dispatcher que separa pedidos com base no protocolo da 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 estático, primário, ainda é servido por um cluster dos servidores proxy com caches ativos que agem como substitutos para os servidores da Web. Esta parte da rede espelha a rede na primeira fase.

    A parte de comércio eletrônico do Web também é servida por um cluster dos 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). Um plug-in de armazenamento em cache dinâmico 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 mostra um exemplo de rede business-to-consumer


    Fase 3

    A Figura 16 mostra a terceira fase de evolução de uma rede business-to-consumer, com a Web estática adotando um método de apresentação dinâmico. 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 criação dessas 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 mostra um exemplo de rede business-to-consumer


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

    A Figura 17 mostra uma solução bancária on-line eficiente que é semelhante à rede business-to-consumer descrita em 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 da Web. Os servidores de métrica são colocados com os servidores proxy para oferecer balanceamento de carga de dados para o Dispatcher. Esta disposição reduz a carga da rede nos servidores da 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 seguinte cenário inclui o Load Balancer e o Caching Proxy.

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

    Figura 17. Solução Bancária Business-to-consumer

    Este gráfico mostra um exemplo de solução bancária business-to-consumer


    Rede do Portal da Web

    A Figura 18 mostra uma rede do portal da Web criada para suportar o alto volume de tráfego ao fornecer a cada cliente 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 da Web. Os servidores de métrica são colocados com os servidores proxy para oferecer balanceamento 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 da Web separados, permitindo que seja atualizado conforme necessário, sem risco de danos aos servidores de aplicativos mais complexos.

    O seguinte cenário inclui o Load Balancer e o Caching Proxy.

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

    Figura 18. Portal da Web

    Este gráfico mostra um exemplo de portal da Web


    Instalando Edge Components

    Esta parte fornece os procedimentos para instalar Edge Components.

    Esta parte contém os seguintes capítulos:

    Requisitos de Edge Components

    Instalando Edge Components Usando o Programa de Configuração

    Instalando o Caching Proxy Usando as Ferramentas de Pacote do Sistema

    Instalando o Load Balancer Usando as Ferramentas de Pacote do Sistema


    Requisitos de Edge Components

    Fornece um link para requisitos de hardware e software para Edge Components e descreve diretrizes para usar navegadores da Web com os formulários de administração e configuração do Caching Proxy e com a ajuda on-line do 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 Edge Components, Versão 7.0, vá para a seguinte página da Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.

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


    Usando Navegadores com os Formulários de Administração e Configuração do Caching Proxy

    Requisitos mínimos do navegador

    Para configurar o Caching Proxy utilizando os formulários de Administração e Configuraçã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:
    Nos sistemas PowerPC Linux de 64 bits, não é possível acessar os formulários de administração e configuração com o navegador Mozilla, pois não há nenhum SDK disponível para esta arquitetura. Como alternativa, você pode acessar os formulários de administração e configuraçã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 usado localmente para editar os formulários de administração e configuração. (Formulários servem ao navegador no conjunto de caracteres usado pelo servidor proxy--neste exemplo, chinês; no entanto, os formulários podem não ser exibidos corretamente se o navegador e seu sistema operacional subjacente não forem configurados corretamente para exibirem 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 do texto HTML e applets Java dentro dos formulários de administração e configuraçã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

    Usando Navegadores com a Ajuda On-line do Load Balancer

    Para usar a ajuda on-line do Load Balancer, seu navegador deve suportar o seguinte:

    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 Edge Components Usando o Programa de Configuração

    Fornece instruções para instalar Edge Components usando o programa de configuração.

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

    Após a instalação, os scripts no pacote do Caching Proxy tentam iniciar o servidor proxy usando a configuração padrão. Se a porta 80 estiver sendo usada, por exemplo por outro servidor da Web, o servidor proxy falhará ao iniciar.

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


    Usando o Programa de Configuração para Windows

    Use o programa de configuração para instalar Edge Components em seu sistema Windows(R), como a seguir:

    1. Verifique se o sistema Windows atende a todos os requisitos de hardware e software (Requisitos de 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 para o WebSphere Application Server - Edge Components. O programa de configuraçã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 de Reprodução Automática, ou se estiver desligada, inicie o programa de configuraçã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. Use os menus Idioma Atual para selecionar o idioma ou os idiomas nos quais deseja instalar 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. Use a janela Seleção de Componente para verificar o local de instalação de 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 seus Edge Components, o local de instalação e os 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 Configuração do Produto Edge Components começa a instalar os Edge Components selecionados e o GSK, se necessário, no local de instalação que você especificou.
    14. A janela Instalação Concluída é exibida. Se quiser ler o arquivo Leia-me dos Edge Components, verifique se a caixa de opção Sim, eu desejo visualizar 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 Configuração dos Edge Components fechará imediatamente e a máquina será reiniciada. Observe que você deve reiniciar sua máquina antes de poder usar os Edge Components recentemente instalados.

    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.


    Usando o Programa de Configuração para Linux e UNIX

    Ao instalar do CD, você pode usar o programa de configuração para instalar Edge Components em seus sistemas Linux e UNIX, como a seguir:

    1. Verifique se o servidor de computador atende a todos os requisitos de hardware e software descritos em Requisitos de 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 configuraçã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 que serão suportados por esta instalação dos 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 configuraçã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.

    Em sistemas Linux e UNIX: Se o programa de configuração for utilizado para instalar Edge Components, o desinstalador da GUI pode ser utilizado para desinstalar Edge Components. No entanto, o desinstalador da GUI de Edge Components 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 como usar comandos nativos, consulte Instalando o Caching Proxy Usando Ferramentas de Pacote do Sistema e Instalando o Load Balancer Usando Ferramentas de Pacote do Sistema.


    Instalando o Caching Proxy Usando Ferramentas de Pacote do Sistema

    Fornece instruções para instalar o Caching Proxy usando as ferramentas de pacote do sistema.

    Após a instalação, os scripts no pacote do Caching Proxy tentam iniciar o servidor proxy usando a configuração padrão. Se a porta 80 estiver sendo usada, por exemplo por outro servidor da Web, o servidor proxy falhará ao iniciar.

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

    Usando o sistema de instalação de pacote do sistema operacional, instale os pacotes na ordem listada na Tabela 2. O seguinte procedimento detalha as etapas típicas 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: password
      
    3. Vá para o diretório apropriado no CD.
      cd mount_point/package_directory/
      
    4. Instale os pacotes.

      No AIX(R):

      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_US 1

    Notas:

    1. A documentação do Load Balancer é fornecida em dois pacotes. O pacote doc-en_US inclui toda a documentação de Edge Components, incluindo os documentos do Load Balancer, os coloca no diretório ../edge/doc/. O pacote de documentação associado com as instalações do Load Balancer (Instalando o Load Balancer Usando as Ferramentas de Pacote do Sistema) instala somente os documentos do Load Balancer e os coloca em um subdiretório no diretório ../edge/lb/.


    Tabela 3. Nomes de Arquivos do Pacote AIX, HP-UX e Solaris

    Nome do Pacote GenéricoConjunto de Arquivos do AIX Conjunto de Arquivos do HP-UXNome do Arquivo Solaris
    admin wses_admin.rteWSES-ADMINWSESadmin
    cpwses_cp.baseWSES-CPWSEScp
    docwses_doc.en_US WSES-DOC-en_US WSESdocen
    gskit7gskkm.rtegsk7basgsk7bas
    icuwses_icu.rteWSES-ICUWSESicu
    msg-cp-lang wses_cp.msg.lang 1 .baseWSES-cpmlang2 WSEScpmlang3

    Notas:

    1. No AIX, a variável lang refere-se à 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. (O HP-UX não suporta 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 Linux

    Nome do Pacote GenéricoNome do Arquivo Linux
    admin WSES_Admin_Runtime-release-version 1.hardw2.rpm
    cpWSES_CachingProxy-release-version 1.hardw2.rpm
    docWSES_Doc_en_US-release-version1.hardw2.rpm
    gskit7gsk7bas.rpm
    icuWSES_ICU_Runtime-release-version 1.hardw2.rpm
    msg-cp-lang WSES_CachingProxy_msg_lang3-release-version 1.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:

    No 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 nome_do_pacote
    

    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 Usando as Ferramentas de Pacote do Sistema

    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 você efetuar logoff de uma máquina depois que o Load Balancer é instalado, deverá reiniciar todos os serviços do Load Balancer quando efetuar logon novamente.


    Instalando para AIX

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

    Tabela 5. Conjuntos de Arquivos do AIX

    Componentes do Load Balancer Conjuntos de Arquivos do AIX
    Base ibmlb.base.rte
    Administration (com mensagens)
    • ibmlb.admin.rte
    • ibmlb.msg.lang.admin

    Driver de Dispositivoibmlb.lb.driver
    Licençaibmlb.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 do seguinte:

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

    Procedimento de Instalação

    Recomenda-se o uso de SMIT para instalar o Load Balancer para AIX pois o SMIT garante que todas as mensagens sejam instaladas automaticamente.

    Usando 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 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 seguinte tabela para determinar qual comando ou comandos digitar para instalar os pacotes desejados do Load Balancer para AIX:

      Tabela 6. Comandos de Instalação do AIX

      PacotesComandos
      Base installp -acXgd device ibmlb.base.rte
      Administration (com mensagens) installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin
      Driver de Dispositivoinstallp -acXgd device ibmlb.lb.driver
      Licençainstallp -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. Verifique se a coluna de resultados no sumário contém SUCCESS para cada parte do Load Balancer que você está instalando (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.docibmlb.msg.language.lb
     
    

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


    Instalando para HP-UX

    Esta seção explica como instalar o Load Balancer no HP-UX usando 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ções para Desinstalar os Pacotes.

    Procedimento de Instalação

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

    Tabela 7. Detalhes de Instalação do Pacote 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 Balanceribmlb.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 código do idioma Português do Brasil (pt_BR). Os códigos de idiomas 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: password
      
    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 o seguinte:


    Instalando para Linux

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

    Antes de Instalar

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

    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 exigem que o Java(TM) esteja instalado e registrado no banco de dados RPM. Se o Java estiver instalado mas não estiver registrado no banco de dados RPM, use o comando de instalação com uma opção de dependência, como 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 o seguinte:

    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 usando o CD de 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 do Load Balancer na unidade adequada.
    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 o seguinte:


    Atualizando Edge Components

    Você pode obter o fix pack dos Edge Components para os sistemas operacionais AIX, HP-UX, Linux e Solaris ou Microsoft Windows a partir de:

    Para obter informações sobre os sistemas operacionais suportados, consulte Requisitos Detalhados do Sistema do WebSphere Application Server.

    Você pode localizar o link para os pacotes de atualização dos Edge Components no site de suporte do WebSphere Application Server.

    1. Localize o release de serviço corretivo ao qual você está fazendo upgrade e siga o link para o site de download.
    2. Siga as instruções no site para fazer download do pacote de atualização dos Edge Components.
    Nota:
    Você também pode fazer download dos fix packs mais recentes dos Edge Components a partir do Servidor FTP dos Edge Components.

    Consulte as seguintes seções para obter instruções de atualização:

    Para obter instruções sobre como atualizar o Load Balancer, consulte o Load Balancer for IPv4 Administration Guide ou o Load Balancer for IPv4 and IPv6 Administration Guide.


    Atualizando o Caching Proxy para Sistemas Operacionais AIX, HP-UX, Linux e Solaris


    Antes de Iniciar

    Considere os seguintes itens antes de continuar com a instalação da atualização ou fix pack.


    Instalando os Pacotes do Caching Proxy nos Sistemas Operacionais AIX, HP-UX, Linux ou Solaris

    Usando as ferramentas de instalação do pacote de seu sistema operacional, instale os pacotes do Caching Proxy na ordem correta. Consulte a Tabela 4 para obter uma lista de todos os pacotes de Edge Components e a ordem na qual instalá-los. O seguinte procedimento detalha as etapas típicas necessárias para concluir esta tarefa.

    1. Torne-se o superusuário local root.
      su - root
      Senha: password
      
    2. Pare o processo do Caching Proxy.
    3. Vá para o diretório que contém os arquivos de instalação.Por exemplo, digite o seguinte em um prompt de comandos:
      cd download_package_directory/
      
    4. Instale os pacotes usando os comandos de instalação da tabela a seguir. A ordem da instalação dos pacotes para a atualização ou fix pack é:
      1. gskit - kit de segurança global
      2. icu - tempo de execução de ICU
      3. admin - tempo de execução administrativo
      4. cp messages - mensagens do Caching Proxy
      5. cp - Caching Proxy
      6. documentation - opcional

      Tabela 8. Diretivas específicas do sistema para instalar o Caching Proxy

      Diretivas específicas do sistema para instalar o Caching Proxy
      Sistema Operacional Comandos
      AIX
      installp -acXd source package_name
      

      em que source é o diretório onde o pacote está localizado e package_name é o nome do pacote.

      Exemplo:

      1. O seguinte comando instala o pacote admin, que é chamado de wses_admin.rte, quando os pacotes residem no diretório atual:
        installp -acXd . wses_admin.rte
      2. O seguinte comando instala o pacote admin quando os pacotes residem no diretório /tmp.
        installp -acXd /tmp wses_admin.rte

      Se você estiver usando a SMIT (System Management Interface Tool):

      1. Selecione a opção install_latest.
      2. Configure o valor no campo de atualizações do software COMMIT como yes.
      HP-UX
      swinstall -s /source package_name
      

      em que source é o diretório onde o pacote está localizado e package_name é o nome do pacote.

      Por exemplo, o seguinte comando instala o pacote de administração para o Caching Proxy, que é chamado de WSES-ADMIN, quando os pacotes residem no diretório atual:

      swinstall -s /admin WSES-ADMIN 
      

      Para verificar a instalação dos pacotes, emita o comando swlist para listar todos os pacotes que você instalou. Por exemplo, emita os seguintes comandos para listar todos os pacotes que são instalados para o Caching Proxy:

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

      em que package_name é o nome do pacote.

      Por exemplo, utilize o seguinte comando:

      rpm -iv --replacefiles WSES_Admin_Runtime-6.1.0-1.686.rpm
      
      Nota:
      Não utilize a opção -U. A opção --replacefiles é requerida para a maioria dos pacotes. Usar esta opção com os pacotes que não a requerem não afetará a instalação deles. Depois da instalação, as versões dos novos pacotes instaladas anteriormente ainda estarão na máquina. Não as desinstale.
      Solaris
      pkgadd -d source package_name
      

      em que source é o diretório onde o pacote está localizado e package_name é o nome do pacote.

      Exemplo:

      • O seguinte comando instala o pacote admin, que é chamado de WSESadmin, quando o pacote reside no diretório atual:
        pkgadd -d . WSESadmin
      • O seguinte comando instala o pacote admin quando os pacotes residem no diretório /tmp:
        pkgadd -d /tmp WSESadmin
      • Para instalar o GSKit, o seguinte comando instalará o pacote sobre uma versão anterior:
        pkgadd -a ./admin -d . gsk7bas

      Para utilizar a instalação silenciosa, utilize a opção -a e especifique um arquivo de administração. Um arquivo de administração, que é chamado de instadm, é fornecido com os pacotes que você está instalando.

      Depois da instalação, as versões dos novos pacotes instaladas anteriormente ainda estarão na máquina. Não as desinstale.

    Esta tabela lista todos os pacotes que são fornecidos com o Caching Proxy e a ordem requerida de instalação. Instale os pacotes que foram incluídos na atualização ou fix pack de acordo com a ordem especificada na tabela seguinte.

    Nota:
    Nem todos os pacotes listados aqui são distribuídos com a atualização ou fix pack. Atualize somente os pacotes distribuídos com a atualização ou fix pack e que foram anteriormente instalados em seu sistema.

    Tabela 9. Lista de Pacotes

    Lista de Pacotes
    Componentes Instalados Atualize os Pacotes (Listados Genericamente) Nesta Ordem
    Caching Proxy
    1. gskit7 - kit de segurança global
    2. icu - tempo de execução de ICU
    3. admin - tempo de execução administrativo
    4. msg-cp-lang -- mensagens
    5. cp -- Caching Proxy

    Documentação de Edge Componentsdoc-lang

    Depois de instalar uma atualização para Edge Components, a configuração anterior dos Edge Components é mantida. Quando novas funções ou aperfeiçoamentos são fornecidos com uma atualização ou fix pack, pode ser necessário incluir diretivas para os arquivos de configuração para ativar os recursos.


    Atualizando Caching Proxy para Sistemas Operacionais Windows

    Use o programa de configuração do Caching Proxy como a seguir:

    1. Para evitar que o Load Balancer atualmente instalado inicie, edite todos os scripts criados para suprimir temporariamente os comandos que iniciarão o Load Balancer na reinicialização.
    2. Verifique se o serviço do Load Balancer está configurado como Manual.
    3. Reinicie sua máquina Windows.
    4. Faça download da atualização ou fix pack de Edge Components.
    5. Utilize Adicionar/Remover programas para desinstalar o componente Load Balancer atual, se ele existir.
    6. Execute o programa de instalação efetuando uma das seguintes ações:
    7. Digite as informações conforme solicitado pelo programa de instalação.

    Depois de instalar uma atualização para Edge Components, a configuração anterior dos Edge Components é mantida. Quando novas funções ou aperfeiçoamentos são fornecidos com uma atualização ou fix pack, pode ser necessário incluir diretivas para os arquivos de configuração para ativar os recursos.


    Rejeitando uma Atualização

    Para rejeitar uma atualização:

    Para a maioria dos componentes, quando a atualização ou o fix pack é removido, os arquivos de configuração são salvos no diretório de componentes/arquivos antigos. Você pode usar esses arquivos de configuração com a versão reinstalada do produto para manter a configuração do pacote na versão de pré-correção.


    Criando Redes com Edge Components

    Esta parte fornece procedimentos para criar redes de demonstração básicas usando 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:

    Criar uma Rede do Caching Proxy.

    Criar uma Rede do Load Balancer.


    Criar uma Rede do Caching Proxy

    A Figura 19 mostra uma rede do servidor proxy básica usando três sistemas de computador localizados em três nós de rede. Essa 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 Edge Component, 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 criar uma rede do Caching Proxy, execute estes procedimentos na seguinte ordem:

    1. Rever Sistemas e Softwares de Computador Requeridos.
    2. Criar Servidor 1 (sistemas Linux e UNIX) ou Criar Servidor 1 (Sistema Windows).
    3. Configurar 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:


    Criar Servidor 1 (Sistemas Linux e UNIX)

    Instale e configure o Caching Proxy como a seguir:

    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 senha para acessar os formulários de administração e configuraçã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 Servidor 1.

    Criar Servidor 1 (Sistema Windows)

    Instale e configure o Caching Proxy como a seguir:

    1. Verifique se os sistemas operacionais Windows 2000 e Windows 2003 atendem a todos os requisitos de hardware e 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 senha para acessar os formulários de administração e configuraçã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 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 do seu navegador, digite http://server_1, em que server_1 refere-se ao nome de host ou endereço IP real da máquina designada como Servidor 1.
    3. Clique em Formulários de Administração e Configuração.
    4. Digite seu nome de administrador e sua senha. Os formulários de administração e configuração são abertos em seu navegador.
    5. Clique em Configuração de 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 Enviar.
    11. Crie uma regra de mapeamento que permita acesso aos formulários de administração e configuraçã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. Digite o local dos formulários de administração e configuração:
    15. Clique em Enviar.
    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 de administração e configuração, digite http://server_1/pub/ no campo Endereço do seu navegador. A página inicial dos formulários de administração e configuração é exibida.

    Criar uma Rede do Load Balancer

    A Figura 20 mostra uma rede básica do Load Balancer com três estações de trabalho conectadas localmente usando o método de redirecionamento MAC do componente Dispatcher para efetuar o balanceamento de carga do tráfego da Web entre dois servidores da Web. A configuração é semelhante ao balanceamento 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 mostrando um cliente, um conjunto de 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 criar uma rede do Load Balancer, execute estes procedimentos na seguinte ordem:

    1. Rever Sistemas e Softwares de Computador 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
      1server1.company.com9.67.67.101
      2server2.company.com9.67.67.102
      3server3.company.com9.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 da Web (Servidor 2 e Servidor 3). Isso pode ser feito substituindo dados nas duas estações de trabalho usando um sistema de arquivo compartilhado, como NFS, AFS(R) ou DFS(TM), ou por qualquer outro meio apropriado para seu site.
    6. Certifique-se de que os servidores da 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 da 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 roteamento extra que possa ter sido criado como resultado do alias da interface de auto-retorno.

      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 de cluster para a configuração do Dispatcher:
      dscontrol cluster add www.company.com
      
    4. Inclua a porta de protocolo http para a configuração do Dispatcher:
      dscontrol port add www.company.com:80
    5. Inclua cada um dos servidores da Web para a 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 não faz o balanceamento de carga no desempenho do servidor.

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

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

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

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