Versão 7.0
Primeira Edição (Junho de 2008)
Esta edição aplica-se ao:
e a todos os releases e modificações subseqüentes, até que seja indicado de outra forma em novas edições.
Solicite publicações através de um representante IBM ou 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.
Discussões e Conceitos do Edge Component
Criando Redes com Edge Components
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.
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.
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:
Esta documentação utiliza as seguintes convenções tipográficas e de
símbolos.
Tabela 1. Convenções Usadas Neste Manual
Convenção | Significado |
---|---|
Negrito | Ao fazer referência a GUIs (Interfaces Gráficas com o Usuário), o negrito também indica menus, itens de menu, rótulos, botões, ícones e pastas. Ele também pode ser utilizado para enfatizar nomes de comandos que, de outra forma, podem ser confundidos com o texto ao redor. |
Monoespaç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. |
Retornar | Refere-se à tecla rotulada com a palavra Return, Enter, ou com uma seta para a esquerda. |
% | Representa o prompt do shell de comandos do Linux e UNIX(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 Comandos | Quando for instruído a "digitar" ou "emitir" um comando, digite o comando e, em seguida, pressione Return. Por exemplo, a instrução "Digite o comando ls" significa digitar ls em um prompt de comandos e 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. |
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:
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.
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.
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:
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.
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:
Como alternativa, para este tipo de instalação, você pode usar o método de redirecionamento cbr do componente Dispatcher do Load Balancer para fornecer roteamento baseado em conteúdo dos pedidos HTTP e HTTPS sem o uso do Caching Proxy. Consulte o WebSphere Application Server Load Balancer Administration Guide para obter mais informações.
O Load Balancer para IPv4 e IPv6 suporta apenas o método de redirecionamento mac do componente Dispatcher. Os métodos de redirecionamento nat e cbr não são suportados.
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:
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:
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:
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.
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.
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.
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.
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.
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.
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:
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:
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:
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.
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
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.
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
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.
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
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.
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
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.
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.
O Caching Proxy oferece outros recursos principais e avançados de armazenamento em cache:
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:
Esta seção aborda problemas de hardware da rede para considerar quando introduzir a funcionalidade do Caching Proxy em sua rede.
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.
é 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.
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.
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á.
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.
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.
Uma forma de escalar a arquitetura é armazenar os servidores proxy em cluster e usar o componente Load Balancer para balancear a carga entre eles. Armazenar os servidores proxy em cluster é uma consideração de design benéfica não apenas por razões de desempenho e escalabilidade, mas também por motivos de redundância e confiabilidade. Um único servidor proxy representa um único ponto de falha; se ele falha ou se torna inacessível por causa de uma falha na rede, os usuários não podem acessar seu Web site.
Considere também uma arquitetura de cache com RCA. Uma arquitetura de cache compartilhada divide o cache virtual total entre vários servidores do Caching Proxy que geralmente usam um protocolo entre caches, como o ICP (Internet Cache Protocol) ou o CARP (Cache Array Routing Protocol). O RCA foi projetado para aumentar as proporções de correspondências do cache com cluster, fornecendo um grande cache virtual.
Benefícios no desempenho resultam do uso de uma matriz RCA dos servidores proxy, em oposição a um único Caching Proxy independente ou mesmo um cluster de máquinas independentes do Caching Proxy. Geralmente, os benefícios de desempenho são causados pelo aumento do tamanho do cache virtual total, que maximiza a proporção de correspondência do cache e minimiza a inconsistência e a latência do cache. Com o RCA, somente uma cópia de um documento específico reside no cache. Com um cluster de servidores proxy, o tamanho total do cache é aumentado, mas vários servidores proxy buscam e armazenam em cache as mesmas informações. Portanto, a proporção de correspondência do cache total não é aumentada.
O RCA é comumente utilizado em grandes cenários de hospedagem de conteúdo corporativo. No entanto, a utilidade do RCA não está limitada a implementações corporativas extremamente grandes. Considere utilizar o RCA se a carga de sua rede exigir um cluster de servidores do cache e se a maioria dos pedidos for correspondências do cache. Dependendo da configuração de sua rede, o RCA nem sempre melhora o desempenho corporativo devido a um aumento no número de conexões TCP que um cliente utiliza quando o RCA é configurado. Isto ocorre porque um membro do RCA é responsável não apenas por atender às URLs para as quais ele tem a melhor pontuação, mas também deve encaminhar pedidos para outros membros ou clusters se obtiver um pedido para uma URL para a qual ele não tem a melhor pontuação. Isto significa que qualquer membro de uma matriz RCA pode ter mais conexões TCP abertas do que teria se funcionasse como um servidor independente.
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.
Os caches de disco são apropriados para sites com grandes quantidades de informações a serem armazenadas em cache. Por exemplo, se o conteúdo do site for grande (maior do que 5 GB) e houver uma taxa de correspondência do cache de 80 a 90%, isto indica que é recomendada um cache de disco. No entanto, sabe-se que utilizar o cache de memória (RAM) é mais rápido e a existência de muitos cenários ao utilizar um cache somente memória é recomendável para grandes sites. Por exemplo, se a taxa de ocorrência de cache do Caching Proxy não for tão importante ou se a configuração de cache compartilhada estiver sendo usada, um cache de memória será prático.
O Caching Proxy pode armazenar em cache e invalidar o conteúdo dinâmico (resultados de JSP e servlet) gerado pelo cache dinâmico do WebSphere Application, fornecendo uma extensão virtual do cache do Application Server nos caches baseados na rede. Ativar o armazenamento em cache de conteúdo gerado dinamicamente é útil para o desempenho da rede em um ambiente no qual há muitos pedidos por páginas da Web públicas geradas dinamicamente, que expiram com base na lógica de aplicativo ou em um evento como uma mensagem de um banco de dados. A duração da página é finita, mas um disparo de expiração não pode ser definido no momento de sua criação; portanto, hosts sem um armazenamento em cache dinâmico e um recurso de invalidação devem designar este tipo de página como tendo um valor de tempo de vida zero.
Se tal página gerada dinamicamente for solicitada mais de uma vez durante seu ciclo de vida por um ou mais usuários, o armazenamento em cache dinâmico fornecerá uma grande remoção de trabalho e reduzirá a carga de trabalho nos hosts de conteúdo de sua rede. A utilização de armazenamento em cache dinâmico também melhora o desempenho da rede, fornecendo resposta rápida aos usuários, eliminando atrasos da rede e reduzindo o uso de largura de banda devido a um tráfego menos intenso na Internet.
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:
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.
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
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.
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 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.
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
Figura 7. Usando o Dispatcher para balancear vários Caching Proxies.
O Dispatcher detecta quando uma das máquinas do Caching Proxy estiver indisponível e roteia automaticamente pedidos para as outras. Isso permite a você encerrar uma máquina do Caching Proxy para manutenção sem interromper o acesso à Internet. O Dispatcher possui várias opções de configuração que podem ser utilizadas para controlar os fatores que ele considera ao tomar decisões em relação ao 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.
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.
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.
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
IMPORTANTE: O componente CBR (Content Based Routing) está disponível em todas as plataformas suportadas, com as seguintes exceções:
Como alternativa, para este tipo de instalação, você pode usar o método de redirecionamento cbr do componente Dispatcher do Load Balancer para fornecer roteamento baseado em conteúdo dos pedidos HTTP e HTTPS sem o uso do Caching Proxy. Consulte o WebSphere Application Server Load Balancer Administration Guide para obter mais informações.
O Load Balancer para IPv4 e IPv6 suporta apenas o método de redirecionamento mac do componente Dispatcher. Os métodos de redirecionamento nat e cbr não são suportados.
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
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
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).
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:
Solução Bancária Business-to-Client
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:
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)
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)
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)
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
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:
Esta parte fornece os procedimentos para instalar Edge Components.
Esta parte contém os seguintes capítulos:
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
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.
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.
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
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:
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.
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:
Use o programa de configuração para instalar Edge Components em seu sistema Windows(R), como a seguir:
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.
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.
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:
# ./installA janela Bem-vindo é exibida.
O programa de configuração começa a instalar os Edge Components selecionados e os pacotes requeridos.
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.
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.
su - root Senha: password
cd mount_point/package_directory/
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 |
|
Documentação do Edge Component |
doc-en_US
1
|
Notas:
|
Tabela 3. Nomes de Arquivos do Pacote AIX, HP-UX e Solaris
Nome do Pacote Genérico | Conjunto de Arquivos do AIX | Conjunto de Arquivos do HP-UX | Nome do Arquivo Solaris |
---|---|---|---|
admin | wses_admin.rte | WSES-ADMIN | WSESadmin |
cp | wses_cp.base | WSES-CP | WSEScp |
doc | wses_doc.en_US | WSES-DOC-en_US | WSESdocen |
gskit7 | gskkm.rte | gsk7bas | gsk7bas |
icu | wses_icu.rte | WSES-ICU | WSESicu |
msg-cp-lang | wses_cp.msg.lang 1 .base | WSES-cpmlang2 | WSEScpmlang3 |
Notas:
|
Tabela 4. Nomes de Arquivos de Pacote Linux
Nome do Pacote Genérico | Nome do Arquivo Linux |
---|---|
admin | WSES_Admin_Runtime-release-version 1.hardw2.rpm |
cp | WSES_CachingProxy-release-version 1.hardw2.rpm |
doc | WSES_Doc_en_US-release-version1.hardw2.rpm |
gskit7 | gsk7bas.rpm |
icu | WSES_ICU_Runtime-release-version 1.hardw2.rpm |
msg-cp-lang | WSES_CachingProxy_msg_lang3-release-version 1.hardw2.rpm |
Notas:
|
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.
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.
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.
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) |
|
Driver de Dispositivo | ibmlb.lb.driver |
Licença | ibmlb.lb.license |
Componentes do Load Balancer (com Mensagens) |
|
Documentação (com mensagens) |
|
Metric Server | ibmlb.ms.rte |
Notas:
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 o Load Balancer para AIX, certifique-se do seguinte:
installp -u ibmlb
ou, para versões anteriores, digite o seguinte comando:
installp -u ibmnd
Para desinstalar conjuntos de arquivos específicos, liste-os explicitamente em vez de especificar o nome do pacote ibmlb.
Quando instala o produto, você tem a opção de instalar qualquer um ou todos os seguintes itens:
Recomenda-se o uso de SMIT para instalar o Load Balancer para AIX pois o SMIT garante que todas as mensagens sejam instaladas automaticamente.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Tabela 6. Comandos de Instalação do AIX
Pacotes | Comandos |
---|---|
Base | installp -acXgd device ibmlb.base.rte |
Administration (com mensagens) | installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin |
Driver de Dispositivo | installp -acXgd device ibmlb.lb.driver |
Licença | installp -acXgd device ibmlb.lb.license |
Componentes do Load Balancer (com Mensagens). Inclui: Dispatcher, CBR, Site Selector, Cisco CSS Controller e Nortel Alteon Controller |
installp -acXgd device ibmlb.component.rte ibmlb.msg.language.lb
|
Documentos (com mensagens) | installp -acXgd device ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd device ibmlb.ms.rte |
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:
Esta seção explica como instalar o Load Balancer no HP-UX usando o CD do produto.
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.
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 Balancer | ibmlb.lic |
Componentes do Load Balancer | ibmlb.component |
Documentação | ibmlb.doc |
Metric Server | ibmlb.ms |
Notas:
|
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:
O procedimento a seguir detalha as etapas necessárias para concluir essa tarefa.
su - root Senha: password
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
Emita o comando swlist para listar todos os pacotes que você instalou. Por exemplo:
swlist -l fileset ibmlb
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:
swremove ibmlb
Para desinstalar um pacote individual (por exemplo, o Cisco CSS Controller)
swremove ibmlb.cco
Os caminhos de instalação do Load Balancer incluem o seguinte:
Esta seção explica como instalar o Load Balancer no Linux usando o CD de Edge Components.
Antes de instalar o Load Balancer, certifique-se do seguinte:
rpm -e pkgname
Quando desinstalar, inverta a ordem utilizada para a instalação do pacote, assegurando que os pacotes de administração sejam desinstalados por último.
A imagem de instalação é um arquivo em formato lblinux-version.tar.
tar -xf lblinux-versão.tarO 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.
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.
rpm -i --nodeps package.rpm
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.
Esta seção explica como instalar o Load Balancer no Solaris usando o CD de Edge Components.
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
pkgadd -d pathnameem 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.
pkginfo | grep ibm
Os caminhos de instalação do Load Balancer incluem o seguinte:
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.
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.
Considere os seguintes itens antes de continuar com a instalação da atualização ou fix pack.
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.
su - root Senha: password
stopsrc -c -s ibmproxy
kill -9 proxy_PID
O termo proxy_PID é o identificador de processos para o processo do Caching Proxy. Use o seguinte comando para determinar o PID do Caching Proxy:
ps -e | grep ibmproxy
/etc/init.d/ibmproxy stop
/etc/rc.d/init.d/ibmproxy stop
kill -9 proxy_PID
O termo proxy_PID é o identificador de processos para o processo do Caching Proxy. Use o seguinte comando para determinar o PID do Caching Proxy:
ps -e | grep ibmproxy
cd download_package_directory/
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:
Se você estiver usando a SMIT (System Management Interface Tool):
|
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
|
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:
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.
Lista de Pacotes | |
Componentes Instalados | Atualize os Pacotes (Listados Genericamente) Nesta Ordem |
Caching Proxy |
|
Documentação de Edge Components | doc-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.
Use o programa de configuração do Caching Proxy como a seguir:
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.
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.
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.
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
Para criar uma rede do Caching Proxy, execute estes procedimentos na seguinte ordem:
Os seguintes sistemas de computador e componentes de software são necessários:
Instale e configure o Caching Proxy como a seguir:
# 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.
Instale e configure o Caching Proxy como a seguir:
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.
Na estação de trabalho, faça o seguinte:
Na estação de trabalho, faça o seguinte:
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
Para criar uma rede do Load Balancer, execute estes procedimentos na seguinte ordem:
Os seguintes sistemas de computador e componentes de software são necessários:
Estação de Trabalho | Nome | Endereço IP |
---|---|---|
1 | server1.company.com | 9.67.67.101 |
2 | server2.company.com | 9.67.67.102 |
3 | server3.company.com | 9.67.67.103 |
Máscara de rede = 255.255.255.0 |
Cada uma das estações de trabalho contém somente uma placa padrão de interface de rede Ethernet.
Name= www.company.com IP=9.67.67.104
Inclua um alias para www.company.com na interface loopback em server2.company.com e server3.company.com.
ifconfig lo0 alias www.company.com netmask 255.255.255.0
ifconfig lo0:1 plumb www.company.com netmask 255.255.255.0
Agora você concluiu todas as etapas de configuração requeridas nas duas estações de trabalho do Web.
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).
Se estiver utilizando a linha de comandos, siga estas etapas:
dscontrol executor start
dscontrol cluster add www.company.com
dscontrol port add www.company.com:80
dscontrol server add www.company.com:80:server2.company.com
dscontrol server add www.company.com:80:server3.company.com
dscontrol executor configure www.company.com
dscontrol manager start
Agora o Dispatcher não faz o balanceamento de carga no desempenho do servidor.
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.
Se estiver utilizando o assistente para configuração, siga estas etapas:
dsserver
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:
Para iniciar a GUI, siga estas etapas:
dsserver