Esta edição aplica-se ao:
e a todos os releases e modificações subseqüentes, até que seja indicado de outra forma em novas edições.
Solicite publicações através de um representante IBM ou do escritório da IBM de sua localidade.
Este manual, Conceitos, Planejamento e Instalação para Edge Components do WebSphere Application Server, serve como uma introdução ao Edge Components do WebSphere Application Server. Ele fornece visões gerais de alto nível, discussões detalhadas de funcionalidade para componentes principais, cenários de extremidade da rede, informações de instalação e configuração inicial e redes de demonstração.
O manual Conceitos, Planejamento e Instalação para Edge Components do WebSphere Application Server foi desenvolvido para administradores de rede e de sistema experientes que estão familiarizados com seus sistemas operacionais e com o fornecimento de serviços da Internet. Não é necessário ter conhecimento anterior sobre o WebSphere Application Server ou Edge Components do WebSphere Application Server.
Os recursos de acessibilidade ajudam usuários com alguma deficiência física, como restrição motora ou deficientes visuais a utilizarem produtos de software com êxito. Estes são os principais recursos de acessibilidade do WebSphere Application Server, Versão 6.1:
Esta documentação utiliza as seguintes convenções tipográficas e de símbolos.
Convenção | Significado |
---|---|
Negrito | Ao fazer referência a GUIs (Interfaces Gráficas com o Usuário), o negrito também indica menus, itens de menu, rótulos, botões, ícones e pastas. Ele também pode ser utilizado para enfatizar nomes de comandos que, de outra forma, podem ser confundidos com o texto ao redor. |
Monoespaçado | Indica texto que deve ser digitado em um prompt de comandos. O monoespaçado também indica texto de tela, exemplos de códigos e extrações de arquivos. |
Itálico | Indica valores variáveis que você deve fornecer (por exemplo, você fornece o nome de um arquivo para fileName). Itálico também indica ênfase e títulos de manuais. |
Ctrl-x | Em que x é o nome de uma tecla, indica uma seqüência de caracteres de controle. Por exemplo, Ctrl-c significa manter pressionada a tecla Ctrl enquanto pressiona a tecla c. |
Return | Refere-se à tecla rotulada com a palavra Return, Enter, ou com uma seta para a esquerda. |
% | Representa o prompt do shell de comandos do Linux e UNIX para um comando que não exija privilégios de root. |
# | Representa o prompt de shell de comandos do Linux e UNIX para um comando que exige privilégios de root. |
C:\ | Representa o prompt de comandos do Windows. |
Digitando comandos | Quando for instruído a "digitar" ou "emitir" um comando, digite o comando e, em seguida, pressione Return. Por exemplo, a instrução "Digite o comando ls" significa digitar ls em um prompt de comandos e, em seguida, pressionar Return. |
[ ] | Itens opcionais em descrições de sintaxe aparecem entre esses símbolos. |
{ } | Listas nas quais você deve escolher um item em descrições de sintaxe aparecem entre esses símbolos. |
| | Separa itens em uma lista de opções entre { }(chaves) em descrições de sintaxe. |
... | Reticências em descrições de sintaxe indicam que você pode repetir o item anterior uma ou mais vezes. Reticências em exemplos indicam que foram omitidas informações do exemplo para torná-lo mais curto. |
Esta parte apresenta o Edge Components, o Caching Proxy e Load Balancer do WebSphere Application Server e discute sua integração com o Application Server. Ela também define os componentes do Caching Proxy e do Load Balancer. Além disso, esta seção apresenta outros produtos relacionados da família WebSphere.
Esta parte contém os seguintes capítulos:
O WebSphere é um software de infra-estrutura da Internet que permite que empresas desenvolvam, implementem e integrem aplicativos de e-business de última geração, como os destinados ao e-commerce business-to-business. O middleware WebSphere suporta aplicativos desde negócios de simples publicação na Web ao processamento de transações em escala corporativa.
Como base da plataforma WebSphere, o WebSphere Application Server oferece um conjunto abrangente de middleware que permite que usuários projetem, implementem, desenvolvam e gerenciem aplicativos de negócios. Estes aplicativos podem variar de uma simples fachada de loja de um Web site a uma revisão completa de infra-estrutura de informática de uma organização.
Recursos intensivos do processador, como personalização, oferecem uma vantagem competitiva a cada e-business. Porém, remover estes recursos de servidores centrais pode impedir que funções importantes sejam escaladas nas proporções da Internet. Conseqüentemente, com a constante inclusão de novos aplicativos da Web, uma infra-estrutura da Internet de uma empresa deve aumentar em escopo e em impacto. Além disso, confiança e segurança são extremamente importantes para um e-business. Mesmo uma interrupção mínima no serviço pode resultar em uma perda de negócios.
O Edge Components (anteriormente Edge Server) agora fazem parte da oferta do WebSphere Application Server. Edge Components podem ser utilizados junto com o WebSphere Application Server para controlar o acesso de clientes a servidores Web e para permitir que empresas forneçam melhores serviços a usuários que acessam conteúdo baseado na Web pela Internet ou uma intranet corporativa. Utilizar Edge Components pode reduzir congestionamento em servidores Web, aumentar a disponibilidade de conteúdo e melhorar o desempenho de servidores Web. Como o nome indica, Edge Components geralmente são executados em máquinas que estão próximas (no sentido de configuração de rede) ao limite entre a intranet de uma empresa e a Internet.
O WebSphere Application Server inclui os Edge Components Caching Proxy e Load Balancer.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
O Caching Proxy reduz a utilização da largura de banda e melhora a velocidade e segurança de um Web site, fornecendo um nó de ponto de presença para um ou mais servidores de conteúdo de backend. O Caching Proxy pode armazenar em cache e atender ao conteúdo estático e ao conteúdo gerado dinamicamente pelo WebSphere Application Server.
O Caching Proxy pode ser configurado na função de um servidor de proxy reverso (configuração padrão) ou de um servidor de proxy de redirecionamento, oferecendo um ponto de acesso para uma rede ou para um servidor de rede interna com a tarefa de aprimorar o tempo de pedidos e de resposta. Para obter informações adicionais sobre as configurações reversa e de redirecionamento, consulte Configurações de Caching Proxy Básico.
O Servidor Proxy intercepta pedidos de dados de um cliente, recupera as informações solicitadas de máquina de host de conteúdo e envia esse conteúdo de volta para o cliente. Mais comumente, os pedidos são para documentos armazenados em máquinas de servidores Web (também chamados de servidores de origem ou hosts de conteúdo) e entregues utilizando HTTP (Hypertext Transfer Protocol). No entanto, você pode configurar o Servidor Proxy para tratar outros protocolos, como o FTP (File Transfer Protocol) e Gopher.
O Servidor Proxy armazena conteúdo em uma cache local antes de enviá-lo ao solicitante. Exemplos de conteúdo que podem ser armazenados em cache incluem páginas da Web estáticas e arquivos JavaServer Pages que contêm informações geradas dinamicamente, mas que são alteradas com pouca freqüência. O armazenamento em cache permite que o Servidor Proxy atenda a pedidos posteriores para o mesmo conteúdo, enviando-o diretamente da cache local, o que é muito mais rápido do que recuperá-los novamente do host de conteúdo.
Os plug-ins para Caching Proxy adicionam funcionalidade ao Servidor Proxy.
Você pode estender ainda mais as funções do Caching Proxy gravando módulos de plug-in personalizados em uma API (Application Programming Interface). A API é flexível, fácil de utilizar e independente de plataforma. O proxy executa uma seqüência de etapas para cada pedido de cliente que ele processa. Um aplicativo de plug-in modifica ou substitui uma etapa no fluxo de trabalho de processamento de pedidos, como uma autenticação de cliente ou filtragem de pedidos. A potente interface Transmogrify, por exemplo, fornece acesso a dados de HTTP e permite a substituição ou transformação de URLs e de conteúdo da Web. Os plug-ins podem modificar ou substituir etapas de processamento designadas e você pode chamar mais de um plug-in para uma etapa específica.
O Load Balancer cria sistemas de extremidade da rede que direcionam o fluxo do tráfego da rede, reduzindo o congestionamento e equilibrando a carga em vários outros serviços e sistemas. O Load Balancer fornece seleção de sites, gerenciamento de carga de trabalho, autorização de sessão e failover transparente.
O Load Balancer é instalado entre a Internet e os servidores de backend da empresa, que podem ser hosts de conteúdo ou máquinas do Caching Proxy. O Load Balancer age como o único nó de ponto de presença da empresa na Internet, mesmo que a empresa utilize muitos servidores de backend de grande demanda ou uma grande quantidade de conteúdo. Também é possível garantir alta disponibilidade instalando um Load Balancer de backup, que assume no caso de falha temporária do principal.
O Load Balancer intercepta pedidos de dados de clientes e encaminha cada pedido para o servidor que, no momento, tem melhor capacidade de atender ao pedido. Em outras palavras, ele equilibra a carga de pedidos que chegam entre um conjunto definido de máquinas que atendem ao mesmo tipo de pedidos. O Load Balancer pode distribuir pedidos para muitos tipos de servidores, incluindo WebSphere Application Server e máquinas do Caching Proxy. O equilíbrio de carga pode ser personalizado para um aplicativo específico ou plataforma, utilizando consultores personalizados. Os consultores de finalidades especiais estão disponíveis para a obtenção de informações para o equilíbrio de carga de WebSphere Application Server.
Se o componente Content Based Routing for instalado junto com o Caching Proxy, os pedidos HTTP e HTTPS podem até ser distribuídos com base em URLs ou em outras características determinadas pelo administrador, eliminando a necessidade de armazenar conteúdo idêntico em todos os servidores de backend. O componente Dispatcher também pode fornecer a mesma função para pedidos HTTP.
O equilíbrio de carga melhora a disponibilidade e escalabilidade de seu Web site fazendo cluster de servidores de conteúdo de forma transparente, incluindo servidores HTTP, servidores de aplicativos e servidores proxy, que são servidores de conteúdo substitutos. A disponibilidade é alcançada por meio de paralelismo, equilíbrio de carga e suporte a failover. Quando o servidor pára de funcionar, os negócios não são interrompidos. A escalabilidade de uma infra-estrutura é melhorada significativamente porque a força do processamento de backend pode ser incluída de forma transparente.
Suporte para IPv6: Suporte para o esquema de endereços IP do IPv6 disponível com o "Load Balancer para IPv4 e IPv6." O Load Balancer para IPv4 e IPv6 é uma imagem de instalação à parte, constituída apenas pelo componente Dispatcher. Este tipo de instalação oferece equilíbrio de carga para tráfego IPv4 e IPv6 para servidores configurados dentro de sua rede utilizando o redirecionamento de pacotes baseado em MAC do Dispatcher. É importante observar que versões anteriores do Load Balancer devem ser desinstaladas antes de instalar o Load Balancer para IPv4 e IPv6. Dois Load Balancers não podem estar instalados na mesma máquina. Consulte Dispatcher para ver uma breve visão geral do componente Dispatcher.
O Load Balancer inclui os seguintes componentes:
Para todos os serviços de Internet, tais como HTTP, FTP, HTTPS e Telnet, o componente Dispatcher executa equilíbrio de carga para servidores em uma LAN (Local Area Network) ou uma WAN (Wide Area Network). Para dispositivos HTTP, o Dispatcher pode executar equilíbrio de carga de servidores com base no conteúdo de URL do pedido do cliente.
O componente Dispatcher permite o gerenciamento estável e eficiente de uma grande rede escalável de servidores. Com o Dispatcher, você pode ligar muitos servidores individuais ao qual parece ser um único servidor virtual. Assim, seu site parecerá ser um único endereço IP para todos.
Se estiver utilizando uma instalação do Load Balancer para IPv4 e IPv6, consulte o capítulo sobre implementação do Dispatcher no Load Balancer para IPv4 e IPv6 em WebSphere Application Server Load Balancer Administration Guide, que inclui informações sobre limitações e diferenças de configuração.
Para serviços HTTP e HTTPS, o componente Content Based Routing realiza o equilíbrio de carga para servidores baseados no conteúdo do pedido do cliente. O componente Content Based Routing funciona junto com o componente Caching Proxy do Application Server.
IMPORTANTE: O componente CBR (Content Based Routing) está disponível em todas as plataformas suportadas, com as seguintes exceções:
Como alternativa para este tipo de instalação, você poderá utilizar o método de encaminhamento cbr do componente do Load Balancer' do Dispatcher para oferecer uma rota baseada em conteúdo de pedidos HTTP e HTTPS sem utilizar Caching Proxy. Consulte a publicação WebSphere Application Server Load Balancer Administration Guide para obter mais informações.
Load Balancer para IPv4 e IPv6 suporta apenas o método mac de encaminhamento de componentes Dispatcher. Os métodos de encaminhamento nat e cbr não são suportados.
O componente Site Selector melhora um sistema de equilíbrio de carga, permitindo que ele aja como o nó de ponto de presença para uma rede e equilibra a carga de pedidos de entrada, mapeando nomes DNS para endereços IP. Junto com o Metric Server, o Site Selector pode monitorar o nível de atividade em um servidor, detectar quando um servidor tem a menor carga e detectar um servidor com falha.
Este componente é suportado em todas as instalações do componente Edge, com a seguinte exceção:
O componente Cisco CSS Controller gera métricas de carga do servidor que são enviadas para um comutador Cisco CSS para seleção de servidor, otimização de carga e tolerância a falhas.
Este componente é suportado em todas as instalações do componente Edge, com a seguinte exceção:
O componente Nortel Alteon Controller gera métricas de carga do servidor que são enviadas para um comutador Nortel Alteon para seleção de servidor, otimização de carga e tolerância a falhas.
Este componente é suportado em todas as instalações do componente Edge, com a seguinte exceção:
O componente Metric Server é executado como um daemon em um servidor de equilíbrio de carga e fornece informações sobre cargas do sistema para componentes do Load Balancer.
A família IBM WebSphere foi desenvolvida para ajudar os usuários a cumprir o compromisso de e-business. É um conjunto de produtos de software que ajuda os usuários a desenvolver e gerenciar Web sites de alto desempenho e a integrar Web sites com sistemas novos ou existentes de informações de negócios que não são da Web.
A família WebSphere consiste no WebSphere Application Server, incluindo os Edge Components e outro software da família WebSphere que está fortemente integrado com o WebSphere Application Server e melhora seu desempenho. Para obter uma visão geral do WebSphere Application Server e de seus componentes, consulte o Introduzindo o Edge Components do WebSphere Application Server.
O Tivoli Access Manager (anteriormente denominado Tivoli Policy Director) está disponível separadamente. Ele oferece controle de acesso e segurança centralizada para aplicativos da Web existentes e oferece uma capacidade de autenticação de uma etapa com acesso a vários recursos da Web. Um plug-in do Caching Proxy explora a estrutura de segurança do Access Manager, permitindo que o Servidor Proxy utilize os serviços integrados de autorização e autenticação do Access Manager.
O WebSphere Portal Server (disponível separadamente) oferece uma estrutura para atender a questões de apresentação, segurança, escalabilidade e disponibilidade associadas a portais. Utilizando o Portal Server, as empresas podem construir seu próprio Web site do portal personalizado para atender às necessidades de funcionários, parceiros de negócios e de clientes. Os usuários podem se conectar ao portal e receber páginas da Web personalizadas que fornecem acesso a informações, pessoas e aplicativos de que eles precisam. Este único ponto de acesso personalizado a todos os recursos necessários reduz a sobrecarga de informações, acelera a produtividade e aumenta o uso do Web site.
O WebSphere Portal Server é executado em um cluster do WebSphere Application Server para obter escalabilidade e confiança. O componente Load Balancer do Application Server também pode ser utilizado para equilíbrio de carga adicional e alta disponibilidade.
O WebSphere Site Analyzer (disponível separadamente) ajuda as empresas a prever seus problemas de capacidade e desempenho. Com o Site Analyzer, os logs do Caching Proxy e do Load Balancer e outras ajudas de gerenciamento podem ser utilizados para prever a demanda por recursos adicionais monitorando, analisando e gerando relatórios de uso de seu Web site. Além disso, os componentes de gerenciamento do Site Analyzer ajudam os usuários que instalam e fazem upgrade de Edge Components, gerenciam e armazenam configurações, operam Edge Components remotamente, exibem e relatam eventos.
O WebSphere Transcoding Publisher (disponível separadamente) pode converter uma página da Web para visualização em um dispositivo móvel, como um celular adaptado para Internet, traduzir o conteúdo da Web no idioma nacional preferido do usuário (chamando o WebSphere Translation Server) e converter linguagens de marcações. O Transcoding Publisher aperfeiçoa as capacidades do Caching Proxy permitindo que ele sirva conteúdo para diferentes dispositivos e usuários. Depois de acessar o conteúdo de um servidor Web, a interface Transmogrify do Caching Proxy pode ser configurada para chamar o Transcoding Publisher para transformar os dados e marcá-los para armazenamento em cache variável e possível reutilização. Na interface de pós-autenticação do Caching Proxy, o Transcoding Publisher verifica então no Servidor Proxy se existe conteúdo correspondente ao usuário e requisitos de dispositivos e, se encontrar uma correspondência, serve o conteúdo a partir da cache do Servidor Proxy.
A documentação específica a seguir para o WebSphere Application Server Edge Components está disponível no do Edge Components Information Center.
Outras documentações do WebSphere Application Server estão disponíveis a partir da página da biblioteca do WebSphere Application Server.
As informações de suporte de Technote no Edge Components estão disponíveis a partir da página de suporte do WebSphere Application Server.
A seguir está uma lista de Web sites para obter informações sobre o Edge Components ou informações relacionadas:
Esta parte inclui discussões detalhadas que destacam algumas das funcionalidades disponíveis com o Edge Components. Consulte o Introduzindo o Edge Components do WebSphere Application Server para obter uma visão geral do componente Caching Proxy do Application Server.
Esta parte contém os seguintes capítulos:
A funcionalidade de armazenamento em cache do Caching Proxy ajuda a reduzir a utilização da largura de banda da rede e assegura que os usuários finais recebam um serviço mais rápido e mais seguro. Isto é feito porque o armazenamento em cache executado pelo Servidor Proxy reduz a carga de servidores de backend e de links de mesmo nível. O Caching Proxy pode armazenar em cache o conteúdo estático e o conteúdo gerado dinamicamente pelo WebSphere Application Server. Para oferecer armazenamento em cache avançado, o Caching Proxy também funciona junto com o componente Load Balancer do Application Server. Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes sistemas.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
O Caching Proxy pode ser configurado na função de um servidor de proxy de armazenamento em cache reverso (configuração padrão) ou de um servidor de proxy de armazenamento em cache de redirecionamento. Quando utilizado por hosts de conteúdo, o Caching Proxy é configurado na função de servidor de proxy de armazenamento em cache reverso, localizado entre a Internet e os hosts de conteúdo corporativos. Quando utilizado por provedores de acesso à Internet, o Caching Proxy é configurado na função de um servidor de proxy de armazenamento em cache de redirecionamento, localizado entre um cliente e a Internet.
Quando utilizam uma configuração de proxy reverso, as máquinas do Caching Proxy ficam localizadas entre a Internet e os hosts de conteúdo corporativo. Agindo como um substituto, o Servidor Proxy intercepta pedidos do usuário que chegam da Internet, encaminha-os para o host de conteúdo apropriado, armazena em cache os dados retornados e entrega esses dados a usuários na Internet. O armazenamento em cache permite que o Caching Proxy atenda a pedidos subseqüentes do mesmo conteúdo diretamente da cache, o que é muito mais rápido do que recuperá-lo novamente do host de conteúdo. As informações podem ser armazenadas em cache dependendo de quando expirarão, do tamanho máximo da cache e de quando as informações devem ser atualizadas. Tempos de download mais rápidos para correspondências da cache significa melhor qualidade de serviço para clientes. A Figura 1 descreve a funcionalidade básica do Caching Proxy.
Legenda:1--Cliente 2--Internet 3--Roteador/Gateway 4--Proxy de Armazenamento em Cache 5--Cache 6--Host de ConteúdoNesta configuração, o Servidor Proxy (4) intercepta pedidos cujas URLs incluem o nome de host do host de conteúdo (6). Quando um cliente (1) solicita um arquivo X, o pedido cruza a Internet (2) e entra na rede interna da empresa através de seu gateway de Internet (3). O Servidor Proxy intercepta o pedido, gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido para o host de conteúdo (6).
O host de conteúdo retorna o arquivo X ao Servidor Proxy em vez de retornar diretamente ao usuário final. Se o arquivo puder ser armazenado em cache, o Caching Proxy armazena uma cópia em seu cache (5) antes de transmiti-lo ao usuário final. O exemplo mais importante de conteúdo que pode ser armazenado em cache são páginas da Web estáticas; porém, o Caching Proxy também oferece a capacidade de armazenar em cache e serve o conteúdo gerado dinamicamente pelo WebSphere Application Server.
Oferecer acesso direto à Internet para usuários finais pode ser muito ineficiente. Cada usuário que buscar um determinado arquivo de um servidor da Web irá gerar a mesma quantidade de tráfego em sua rede e em seu gateway de Internet como se fosse o primeiro usuário a buscar o arquivo, mesmo que o arquivo não tenha sido alterado. A solução é instalar um Caching Proxy de redirecionamento próximo ao gateway.
Quando utilizam uma configuração de proxy de redirecionamento, as máquinas do Caching Proxy ficam localizadas entre o cliente e a Internet. O Caching Proxy encaminha os pedidos de clientes para hosts de conteúdo localizados em toda a Internet, armazena os dados recuperados em cache e oferece os dados recuperados para o cliente.
A Figura 2 descreve a configuração de Caching Proxy de redirecionamento. Os programas de navegadores dos clientes (nas máquinas marcadas com 1) estão configurados para direcionar pedidos para o proxy de armazenamento em cache de redirecionamento (2), que está configurado para interceptar os pedidos. Quando um usuário final solicita o arquivo X armazenado no host de conteúdo (6), o proxy de armazenamento em cache de redirecionamento intercepta o pedido, gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido através do roteador corporativo (4) através da Internet (5).
Dessa forma o servidor de origem retorna o arquivo X para o proxy de armazenamento em cache de redirecionamento ao invés de retornar diretamente para o usuário final. Se o recurso de armazenamento em cache do Caching Proxy de redirecionamento estiver ativado, o Caching Proxy determina se o arquivo X é apropriado para armazenamento em cache verificando configurações em seu cabeçalho de retorno, como a data de expiração e um indicador se o arquivo foi ou não gerado dinamicamente. Se o arquivo puder ser armazenado em cache, o Caching Proxy armazena uma cópia em sua cache (3) antes de o transmitir para o usuário. Por padrão, o armazenamento em cache é ativado e o Caching Proxy de redirecionamento utiliza a memória cache. No entanto, é possível configurar outros tipos de armazenamento em cache.
No primeiro pedido pelo arquivo X, o Caching Proxy de redirecionamento não aprimora muito a eficiência de acesso à Internet. Na verdade, é provável que o tempo de resposta do primeiro usuário que acessa o arquivo X seja mais lento do que seria sem o proxy de armazenamento em cache de redirecionamento, porque demora um pouco mais para o Caching Proxy de redirecionamento processar o pacote de pedido original e examinar o cabeçalho do arquivo X para obter informações sobre as possibilidades de armazenamento em cache quando ele for recebido. O uso do proxy de armazenamento em cache de redirecionamento traz benefícios quando outros usuários subseqüentemente solicitam o arquivo X. O Caching Proxy de redirecionamento verifica se a cópia em cache do arquivo X ainda é válida (não expirou) e, se for o caso, serve o arquivo X diretamente da cache, sem redirecionar o pedido através da Internet para o host de conteúdo.
Mesmo que o Caching Proxy de redirecionamento descubra que um arquivo solicitado expirou, não significa que será necessário buscar o arquivo novamente a partir do host de conteúdo. Em vez disso, ele envia ao host de conteúdo uma mensagem de verificação de status especial. Se o host de conteúdo indica que o arquivo não foi alterado, o proxy de armazenamento em cache de redirecionamento ainda pode oferecer a versão em cache ao usuário solicitante.
A configuração do Caching Proxy de redirecionamento dessa forma é denominada proxy de redirecionamento, porque o Caching Proxy age em nome de navegadores, redirecionando seus pedidos aos hosts de conteúdo através da Internet. Os benefícios do proxy de redirecionamento com armazenamento em cache são dois:
O Caching Proxy pode lidar com vários protocolos de transferência em rede, incluindo HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) e Gopher.
Uma variação do Caching Proxy de redirecionamento é um Caching Proxy transparente. Nessa função, o Caching Proxy desempenha as mesmas funções do Caching Proxy de redirecionamento básico, mas o faz sem que o cliente perceba sua presença. A configuração do Caching Proxy transparente é suportada apenas em sistemas Linux.
Na configuração descrita em Caching Proxy de Redirecionamento, cada navegador do cliente é configurado separadamente para direcionar pedidos para um determinado Caching Proxy de redirecionamento. A manutenção desse tipo de configuração pode se tornar inconveniente, especialmente para grandes números de máquinas cliente. O Caching Proxy suporta várias alternativas que simplificam a administração. Uma possibilidade é configurar o Caching Proxy para proxy transparente, conforme descrito em Figura 3. Como no Caching Proxy de redirecionamento regular, o Caching Proxy transparente é instalado em uma máquina próxima ao gateway, mas os programas navegadores do cliente não são configurados para direcionar pedidos para um Caching Proxy de redirecionamento. Os clientes não têm conhecimento de que existe um proxy na configuração. Em vez disso, um roteador é configurado para interceptar os pedidos dos clientes e direcioná-los para o Caching Proxy transparente. Quando um cliente trabalhando em uma das máquinas, marcada como 1, solicita o arquivo X armazenado em um host de conteúdo (6), o roteador (2) transmite o pedido para o Caching Proxy. O Caching Proxy gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido pelo roteador (2) através da Internet (5). Quando o arquivo X chega, o Caching Proxy armazena o arquivo em cache se apropriado (sujeito às condições descritas em Caching Proxy de Redirecionamento) e transmite o arquivo para o cliente que o solicitou.
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 oferecer uma funcionalidade de armazenamento em cache mais avançada, utilize o Caching Proxy como um proxy reverso junto com o componente Load Balancer. Integrando os recursos de armazenamento em cache e de equilíbrio de carga, você pode criar uma infra-estrutura de desempenho da Web eficiente e altamente gerenciável.
A Figura 4 descreve como você pode combinar o Caching Proxy com o Load Balancer para entregar conteúdo da Web de forma eficiente, mesmo em circunstâncias de grande demanda. Nesta configuração, o Servidor Proxy (4) está configurado para interceptar pedidos cujas URLs incluem o nome do host para um cluster de hosts de conteúdo (7) que está recebendo equilíbrio de carga do Load Balancer (6).
Legenda: 1--Cliente 2--Internet 3--Roteador/Gateway 4--Caching Proxy 5--Cache 6--Load Balancer 7--Host de ConteúdoQuando um cliente (1) solicita um arquivo X, o pedido cruza a Internet (2) e entra na rede interna da empresa através de seu gateway de Internet (3). O Servidor Proxy intercepta o pedido, gera um novo pedido com seu próprio endereço IP como o endereço de origem e envia o novo pedido para o Load Balancer no endereço do cluster. O Load Balancer utiliza seu algoritmo de equilíbrio de carga para determinar qual host de conteúdo tem mais capacidade, no momento, para atender ao pedido do arquivo X. Esse host de conteúdo retorna o arquivo X ao Servidor Proxy e não através do Load Balancer. O Servidor Proxy determina se deve armazená-lo e entregá-lo ao usuário final da forma descrita anteriormente.
A funcionalidade de armazenamento em cache avançado também é fornecida pelo plug-in de Armazenamento em Cache Dinâmico do Caching Proxy. Quando utilizado com o WebSphere Application Server, o Caching Proxy tem a capacidade de armazenar em cache, servir e invalidar conteúdo dinâmico em forma de JSP (JavaServer Pages) e de respostas de servlet geradas por um WebSphere Application Server.
Geralmente, um conteúdo dinâmico com tempo de expiração indefinido deve ser marcado como "não armazenar em cache", porque a lógica padrão de expiração da cache baseada em tempo não assegura sua remoção na hora certa. A lógica de expiração orientada a eventos do plug-in do Armazenamento em Cache Dinâmico permite que o conteúdo com um tempo de expiração indefinido seja armazenado em cache pelo Servidor Proxy. Armazenar em cache tal conteúdo na extremidade da rede evita que hosts de conteúdo chamem repetidamente um Application Server para atender a pedidos de clientes. Isto pode oferecer os seguintes benefícios:
O armazenamento em cache de respostas de servlet é excelente para páginas da Web geradas dinamicamente que expiram com base na lógica do aplicativo ou em um evento como uma mensagem de um banco de dados. Embora a duração de tal página seja finita, o valor de tempo de duração não pode ser definido no tempo de criação porque o disparo de expiração não pode ser conhecido antecipadamente. Quando o tempo de duração para tais páginas for definido como zero, os hosts de conteúdo obterão uma grande penalidade quando servindo conteúdo dinâmico.
A responsabilidade de sincronizar a cache dinâmica do Caching Proxy e Application Server é compartilhada por ambos os sistemas. Por exemplo, uma página da Web pública gerada dinamicamente por um aplicativo que fornece a previsão do tempo atual pode ser exportada pelo Application Server e armazenada em cache pelo Caching Proxy. O Caching Proxy pode então servir os resultados de execução do aplicativo repetidamente para muitos usuários diferentes, até ser notificado de que a página é inválida. O conteúdo na cache de resposta do servlet do Caching Proxy será invalida até que o Servidor Proxy remova uma entrada porque a cache está congestionada, o tempo limite padrão definido pela diretriz ExternalCacheManager no arquivo de configuração do Caching Proxy expire ou o Caching Proxy receba uma mensagem de Invalidação instruindo-o a eliminar o conteúdo de seu cache. As mensagens de Invalidação são originadas no WebSphere Application Server que possui o conteúdo e são propagadas para cada Caching Proxy configurado.
O Caching Proxy oferece outros importantes recursos de armazenamento em cache avançados:
O desempenho da rede é afetado pela introdução da funcionalidade do Caching Proxy. Utilize o Caching Proxy sozinho ou junto com o Load Balancer para melhorar o desempenho de sua rede. Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes sistemas.
O desempenho do Caching Proxy em sua empresa é tão bom quanto o hardware no qual ele é executado e a arquitetura geral do sistema no qual ele foi introduzido. Para otimizar o desempenho da rede, modele o hardware e a arquitetura geral da rede para as características de Servidor Proxy.
A configuração e administração básicas do software do Caching Proxy e o ajuste no nível do sistema operacional também contribuem muito para o desempenho do Caching Proxy. Muitas alterações de configuração do software podem ser feitas para aumentar o desempenho; elas incluem, mas não estão limitadas ao ajuste de diretrizes de registros, regras de mapeamento, plug-ins, valores de tempo limite, valores de configuração da cache e valores de thread ativos. Detalhes sobre a configuração do software Caching Proxy são apresentados no Caching Proxy Administration Guide.
Muitas alterações na configuração do sistema operacional também podem ser feitas para aumentar o desempenho; elas incluem, mas não estão limitadas ao ajuste de TCP e ARP, ao aumento de limites do descritor de arquivo, à sincronização de clocks do sistema, ao ajuste de placas NIC (Network Interface Cards) e à realização de boas práticas comuns ao executar tarefas de administração do sistema.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
Esta seção discute os problemas de hardware de rede a serem considerados ao apresentar a funcionalidade do Caching Proxy em sua rede.
Uma grande quantidade de memória deve ser dedicada ao Servidor Proxy. O Caching Proxy pode consumir 2 GB de espaço de endereço virtual quando uma grande cache somente memória é configurada. A memória também é necessária para o kernel, bibliotecas compartilhadas e buffers de rede. Portanto, é possível ter um Servidor Proxy que consuma 3 ou 4 GB de memória física. Observe que a cache somente memória é significativamente mais rápida do que uma cache de disco bruta e somente esta alteração pode ser considerada uma melhoria no desempenho.
É importante ter uma grande quantidade de espaço em disco na máquina onde o Caching Proxy está instalado. Isto se aplica principalmente quando são utilizadas caches de disco. A leitura e gravação em um disco rígido são um processo intensivo para um computador. Embora os procedimentos de E/S do Caching Proxy sejam eficientes, as limitações mecânicas de unidades de disco rígido podem restringir o desempenho quando o Caching Proxy estiver configurado para utilizar uma cache de disco. O gargalo de E/S de disco pode ser reduzido com práticas como a utilização de vários discos rígidos para dispositivos de cache brutos e arquivos de log e com a utilização de unidades de disco com tempos de procura, velocidades rotacionais e taxas de transferência rápidos.
Os requisitos de rede, tais como velocidade, tipo de número de NICs e a velocidade da conexão de rede com o Servidor Proxy afetam o desempenho do Caching Proxy. Geralmente, é muito importante para o desempenho utilizar duas NICs em uma máquina do Servidor Proxy: uma para o tráfego de entrada e uma para o tráfego de saída. Provavelmente, uma única NIC pode atingir seu limite máximo somente pelo tráfego de pedidos e respostas de HTTP. Além disso, as NICs devem ter pelo menos 100 MB e devem ser sempre configuradas para uma operação full-duplex. Isto ocorre porque a negociação automática entre o roteamento e o equipamento de chave provavelmente pode causar erros e prejudicar o desempenho. Por último, a velocidade da conexão de rede é muito importante. Por exemplo, você não pode esperar atender a uma alta carga de pedidos e alcançar um ótimo rendimento se a conexão com a máquina do Caching Proxy for uma portadora T1 saturada.
A CPU (Central Processing Unit) de uma máquina do Caching Proxy provavelmente pode se tornar um fator limitante. A potência da CPU afeta a quantidade de tempo gasto para processar pedidos e o número de CPUs na rede afeta a escalabilidade. É importante corresponder os requisitos da CPU do Servidor Proxy ao ambiente, principalmente para modelar a carga máxima de pedidos que o Servidor Proxy atenderá.
Para desempenho geral, geralmente é útil escalar a arquitetura e não apenas incluir partes de hardware individuais. Não importa a quantidade de hardware incluída em uma única máquina, esse hardware ainda terá um nível máximo de desempenho.
A seção discute os problemas de arquitetura de rede a serem considerados durante a introdução da funcionalidade do Caching Proxy em sua rede.
Se o Web site de sua empresa for popular, poderá haver maior demanda por seu conteúdo do que um único Servidor Proxy possa atender de forma eficiente, resultando em tempos de resposta lentos. Para otimizar o desempenho da rede, considere incluir máquinas do Caching Proxy com cluster, com equilíbrio de carga ou utilizar uma arquitetura de cache compartilhada com RCA (Remote Cache Access) em sua arquitetura de rede geral.
Uma forma de escalar a arquitetura é fazer cluster de Servidor Proxy e utilizar o componente Load Balancer para equilibrar a carga entre eles. Fazer cluster de Servidor Proxy é uma consideração de design útil não apenas por razões de desempenho e escalabilidade, mas também por motivos de redundância e confiança. Um único Servidor Proxy representa um único ponto de falha; se ele falhar ou ficar inacessível devido a uma falha na rede, os usuários não poderão acessar seu Web site.
Considere também uma arquitetura de cache com RCA. Uma arquitetura de cache compartilhada espalha a cache virtual total entre vários servidores Caching Proxy que geralmente utilizam 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 da cache com cluster, fornecendo uma grande cache virtual.
Os benefícios de desempenho resultam da utilização de uma matriz RCA de Servidor Proxy em contraste com um único Caching Proxy independente ou até mesmo um cluster de máquinas do Caching Proxy independentes. Geralmente, os benefícios de desempenho são causados pelo aumento do tamanho da cache virtual total, que maximiza a proporção de correspondência da cache e minimiza a inconsistência e a latência da cache. Com o RCA, somente uma cópia de um documento específico reside na cache. Com um cluster de Servidor Proxy, o tamanho da cache total é aumentado, mas vários servidores proxy provavelmente buscarão e armazenarão em cache as mesmas informações. Portanto, a proporção de correspondência da 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 da cache e se a maioria dos pedidos for correspondências da 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 um melhor desempenho resultam das capacidades de armazenamento em cache do Caching Proxy. No entanto, a cache do Servidor Proxy pode se tornar um gargalo se não estiver configurada corretamente. Para determinar a melhor configuração da cache, deve ser feito um grande esforço para analisar as características do tráfego. O tipo, tamanho, quantidade e atributos do conteúdo afetam o desempenho do Servidor Proxy em termos de tempo gasto para recuperar documentos de servidores de origem e a carga no servidor. Quando você conhece o tipo de tráfego que o Caching Proxy vai aceitar ou atender a partir de seu cache, é possível incluir como fatores essas características durante a configuração do Servidor Proxy. Por exemplo, sabendo que 80% dos objetos que estão sendo armazenados em cache são imagens (*.gif ou *.jpg) e que têm aproximadamente 200 KB de tamanho pode ajudar a ajustar os parâmetros de armazenamento em cache e determinar o tamanho da cache. Além disso, saber que a maioria do conteúdo são páginas dinâmicas personalizadas que não são candidatas a armazenamento em cache também é relativo ao ajuste do Caching Proxy.
Analisar as características do tráfego permite determinar se é preciso utilizar uma memória ou cache de disco para otimizar o desempenho de seu cache. Além disso, a familiaridade com as características de tráfego da rede permite determinar se o desempenho aumentado pode resultar da utilização do recurso de armazenamento em cache dinâmico do Caching Proxy.
As caches de disco são apropriadas 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 da cache de 80 a 90%, isto indica que é recomendada uma cache de disco. No entanto, sabe-se que utilizar a cache de memória (RAM) é mais rápido e a existência de muitos cenários ao utilizar uma cache somente memória é recomendável para grandes sites. Por exemplo, se a taxa de correspondência da cache do Caching Proxy não for tão importante ou se estiver sendo utilizada uma configuração de cache compartilhada, a cache de memória será útil.
O Caching Proxy pode armazenar em cache e invalidar o conteúdo dinâmico (resultados de JSP e de servlet) gerado pela cache dinâmica do WebSphere Application Server, fornecendo uma extensão virtual da cache do Application Server para caches baseadas em 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 junto com hosts de conteúdo, tais como WebSphere Application Server ou com o componente Caching Proxy do Application Server, o componente Load Balancer do Application Server permite melhorar a disponibilidade e escalabilidade de sua rede. (Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes Edge Components). O Load Balancer é utilizado por redes corporativas e é instalado entre a Internet e os servidores de backend da empresa. O Load Balancer age como o único ponto de presença da empresa na Internet, mesmo que a empresa utilize muitos servidores de backend de alta demanda ou uma grande quantidade de conteúdo.
A disponibilidade é alcançada por meio do equilíbrio de carga e de suporte a failover.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
O equilíbrio de carga melhora a disponibilidade e escalabilidade do Web site fazendo cluster de servidores proxy e de servidores de aplicativos de forma transparente. A escalabilidade de uma infra-estrutura de TI é melhorada significativamente porque a força do processamento de backend pode ser incluída de forma transparente.
A grande demanda pode ser atendida duplicando-se o conteúdo em vários hosts, mas será preciso uma maneira de equilibrar a carga entre eles. O DNS (Domain Name Service) pode fornecer equilíbrio de carga em rodízio básico, mas há várias situações em que seu desempenho não é satisfatório.
Uma solução mais sofisticada para o equilíbrio de carga de vários hosts de conteúdo é utilizar o componente Dispatcher do Load Balancer, conforme descrito na Figura 5. Nesta configuração, todos os hosts de conteúdo (as máquinas marcadas com o número 5) armazenam o mesmo conteúdo. Eles são definidos para formar um cluster com equilíbrio de carga e uma das interfaces de rede da máquina do Load Balancer (4) recebe atribuição de um nome de host e de um endereço IP dedicado ao cluster. Quando um usuário final que trabalha em uma das máquinas marcadas com o número 1 solicita o arquivo X, o pedido passa pela Internet (2) e entra na rede interna da empresa através de seu gateway da Internet (3). O Dispatcher intercepta o pedido porque sua URL é mapeada para o nome do host e o endereço IP do Dispatcher. O Dispatcher determina qual dos hosts de conteúdo no cluster tem melhor capacidade para atender ao pedido e encaminha o pedido para esse host que, quando o método de encaminhamento MAC é configurado, retorna o arquivo X diretamente ao cliente (ou seja, o arquivo X não passa pelo Load Balancer).
Legenda: 1--Cliente 2--Internet 3--Roteador/Gateway 4--Dispatcher 5--Host de ConteúdoPor padrão, o Dispatcher utiliza equilíbrio de carga em rodízio como o DNS, mas, ainda assim, cuida de várias das imperfeições do DNS. Ao contrário do DNS, ele acompanha se um host de conteúdo está indisponível ou inacessível e pára de direcionar clientes para um host de conteúdo indisponível. Além disso, ele leva em consideração a carga atual nos hosts de conteúdo rastreando conexões novas, ativas e finalizadas. Você pode otimizar ainda mais o equilíbrio de carga ativando o consultor opcional e os componentes do gerenciador do Load Balancer, que rastreiam um status do host de conteúdo com maior precisão e incorporam as informações adicionais no processo de decisão de equilíbrio de carga. O gerenciador permite que você atribua pesos diferentes aos diferentes fatores utilizados no processo de decisão, personalizando, adicionalmente, o equilíbrio de carga de seu site.
O Dispatcher do Load Balancer também pode executar o equilíbrio de carga de várias máquinas do Caching Proxy. Se o Web site de sua empresa for popular, poderá haver maior demanda para seu conteúdo do que um único Servidor Proxy possa atender de forma eficiente, diminuindo potencialmente o desempenho do Servidor Proxy.
Você pode ter vários sistemas Caching Proxy executando funções de proxy para um único host de conteúdo (semelhante à configuração descrita na Figura 1), mas se seu site for popular o suficiente para precisar de vários Servidores Proxy, provavelmente você também precise de vários hosts de conteúdo cujas cargas sejam equilibradas pelo Load Balancer. A Figura 6 descreve esta configuração. O Dispatcher marcado com o número 4 faz o equilíbrio de carga de um cluster de dois Servidores Proxy (5) e o Dispatcher marcado com o número 7 faz o equilíbrio de carga de um cluster de três hosts de conteúdo (8).
Legenda: 1--Cliente 2--Internet 3--Roteador/Gateway 4--Dispatcher 5--Servidor Proxy 6--Cache 7--Dispatcher 8--Host de ConteúdoO nome do host do cluster do Dispatcher marcado com o número 4 é o nome do host que aparece nas URLs do conteúdo da Web da empresa (ou seja, é o nome do Web site visível na Internet). O nome do host do cluster do Dispatcher marcado com o número 7 não fica visível na Internet e, portanto, pode ser qualquer valor desejado. Por exemplo, para a ABC Corporation, um nome de host apropriado para o Dispatcher marcado com o número 4 é www.abc.com, enquanto o Dispatcher marcado com o número 7 pode ser chamado de algo como http-balancer.abc.com.
Suponha que um navegador em uma das máquinas clientes marcadas com o número 1 precise acessar o arquivo X armazenado nos servidores de conteúdo marcados com o número 8. O pedido de HTTP passa pela Internet (2) e entra na rede interna da empresa no gateway (3). O roteador direciona o pedido para o Dispatcher marcado com o número 4, que o transmite ao Servidor Proxy (5), que tem, no momento, melhor capacidade para tratá-lo, de acordo com o algoritmo de equilíbrio de carga. Se o Servidor Proxy tiver o arquivo X em seu cache (6), ele o retornará diretamente ao navegador, ignorando o Dispatcher marcado com o número 4.
Se o Servidor Proxy não tiver uma cópia do arquivo X em seu cache, ele cria um novo pedido que tenha seu próprio nome de host no campo de origem do cabeçalho e o envia ao Dispatcher marcado com o número 7. O Load Balancer determina qual host de conteúdo (8) tem, no momento, melhor capacidade de atender ao pedido e direciona o pedido para lá. O host de conteúdo obtém o arquivo X do armazenamento e o retorna diretamente para o Servidor Proxy, ignorando o Dispatcher marcado com o número 7. O Servidor Proxy armazena em cache o arquivo X, se apropriado e o envia para o navegador, ignorando o Dispatcher marcado com o número 4.
Se você fornece acesso à Internet para um grande número de clientes, eles podem gerar mais demanda de acesso à Internet do que um único proxy pode oferecer com eficiência. À medida que o Caching Proxy torna-se sobrecarregado com pedidos, o tempo de resposta dos clientes pode se tornar pior do que seria com acesso direto à Internet. E, caso o Caching Proxy falhe ou fique inacessível devido a uma falha de rede, o acesso à Internet se torna impossível. A solução é instalar várias máquinas do Caching Proxy e utilizar o Load Balancer's Dispatcher para equilibrar a carga entre eles.
Sem o Dispatcher, você pode oferecer proxy transparente verdadeiro com várias máquinas do Caching Proxy apenas se seus roteadores puderem rotear o mesmo tipo de tráfego para mais de um Caching Proxy; nem todos os roteadores suportam isso. É possível oferecer serviço de proxy de redirecionamento regular em várias máquinas do Caching Proxy sem o Dispatcher, mas é necessário configurar explicitamente os navegadores do cliente para utilizar uma das máquinas do Caching Proxy como o proxy principal. Se esse Caching Proxy falhar ou se tornar sobrecarregado ou inacessível, os usuários finais podem não ser capazes de acessar a Internet. Para evitar essa situação, você pode criar um arquivo PAC (Proxy Automatic Configuration), conforme descrito em Caching Proxy de Redirecionamento Transparente (apenas Sistemas Linux), que direcione o navegador para failover em um ou mais proxies de armazenamento em cache secundários. Um arquivo PAC não atende às necessidades de equilíbrio da carga entre as máquinas do Caching Proxy, dessa forma, se um Caching Proxy receber muito mais pedidos que outro, é provável que tenha uma redução no desempenho, sujeitando seus clientes de navegador a tempos de resposta mais lentos. Para que todos os clientes tenham desempenhos semelhantes, você deve configurar um número aproximadamente igual de navegadores para utilizar cada Caching Proxy, e rastrear a distribuição manualmente para que possa manter a carga equilibrada mesmo quando incluir ou remover navegadores.
A Figura 7 descreve uma configuração de rede em que o Dispatcher equilibra a carga de um cluster de máquinas do Caching Proxy. Uma das interfaces de rede da máquina do Dispatcher é configurada para ter o nome do host e o endereço IP dedicados do cluster. Navegadores clientes são configurados para direcionar seus pedidos de Internet para o nome do host do cluster. Quando, por exemplo, um navegador em uma das máquinas cliente marcadas com 1 precisar acessar o arquivo X em um host de conteúdo (7), ele direcionará seu pedido para o nome do host ou endereço do cluster, onde o Dispatcher (2) o interceptará e o direcionará para o Caching Proxy (3) apropriado. O Caching Proxy irá criar um novo pedido, transmitir através do gateway corporativo (5) e pela Internet (6) e, se apropriado, o armazenará no arquivo retornado em sua cache (4), conforme descrito com maiores detalhes em Caching Proxy de Redirecionamento
O Dispatcher detecta quando uma das máquinas do Caching Proxy estiver indisponível e roteia automaticamente pedidos para as outras. Isso permite a você encerrar uma máquina do Caching Proxy para manutenção sem interromper o acesso à Internet. O Dispatcher possui várias opções de configuração que podem ser utilizadas para controlar os fatores que ele considera ao tomar decisões em relação ao equilíbrio de carga. Você também pode instalar programas Dispatcher auxiliares nas máquinas do Caching Proxy para monitorar seu status e retornar as informações para o Dispatcher. Para obter detalhes, consulte a publicação WebSphere Application Server Load Balancer Administration Guide. Utilizar vários Caching Proxys apresenta uma possível ineficiência, porque mais de um Caching Proxy pode armazenar em cache o mesmo arquivo se diferentes clientes solicitarem o arquivo através de diferentes máquinas do Caching Proxy. Para eliminar a redundância, você pode configurar um RCA (Remote Cache Access), que permite que todos os proxies de um grupo definido compartilhem o conteúdo de suas caches uns com os outros. Todos os proxies de um grupo de RCA utilizam o mesmo algoritmo para determinar qual Caching Proxy é responsável por uma determinada URL. Quando um Caching Proxy intercepta uma URL pela qual não é responsável, ele transmite o pedido para o Caching Proxy responsável. O Caching Proxy responsável realiza o trabalho necessário para atender ao pedido, seja recuperando-o de sua cache ou encaminhando o pedido para o host de conteúdo relevante e armazenando em cache o arquivo retornado, se apropriado. O Caching Proxy responsável, então, transmite o arquivo para o Caching Proxy original, que o entrega para o usuário final solicitante.
No grupo RCA, se o Caching Proxy responsável por uma determinada URL falhar, o Caching Proxy original, que recebeu o pedido do cliente, irá acessar diretamente o host do conteúdo (ou um servidor de backup do Caching Proxy, se houver um definido). Isso significa que os usuários podem acessar arquivos desde que pelo menos um Caching Proxy em um grupo RCA esteja funcionando corretamente.
Essa configuração satisfaz a alta demanda por acesso à Internet utilizando o Dispatcher para equilibrar a carga de pedidos entre várias máquinas do Caching Proxy. Um possível problema é o fato do Dispatcher ser um ponto único de falha. Se ele falhar ou tornar-se inacessível devido a uma falha de rede, clientes de navegador não poderão alcançar os Caching Proxies ou a Internet. A solução é configurar outro Dispatcher para agir como backup para o Dispatcher principal, conforme descrito na Figura 8.
Aqui um navegador executando em uma das máquinas marcadas com 1 normalmente direciona seu pedido de um arquivo X para o Dispatcher principal (2), que roteia o pedido para o Caching Proxy (4) selecionado com base nos critérios de equilíbrio de carga do Dispatcher. O Caching Proxy cria um novo pedido, o roteia através do gateway corporativo (6) através da Internet (7) até o host de conteúdo (8) e armazena o arquivo X retornado em sua cache (5), se apropriado (para obter uma descrição mais detalhada dessa parte do processo, consulte Caching Proxy de Redirecionamento).
Nessa configuração, o Dispatcher de backup (3) não realiza equilíbrio de carga, desde que o principal esteja operacional. Os Dispatchers principal e de backup rastreiam o status um do outro, trocando periodicamente mensagens denominadas pulsações. Se o Dispatcher de backup detectar que o principal falhou, ele automaticamente assume a responsabilidade pelo equilíbrio de carga, interceptando pedidos direcionados ao nome de host e endereço IP do principal. Também é possível configurar dois Dispatchers para alta disponibilidade mútua. Neste caso, cada um executará ativamente o equilíbrio de carga para um cluster separado de proxies de armazenamento em cache, agindo ao mesmo tempo como o backup para seu parceiro. Para obter explicações adicionais, consulte a publicação WebSphere Application Server Load Balancer Administration Guide.
O Dispatcher geralmente não consome muitos recursos de processamento ou de memória e outros aplicativos podem ser executados na máquina do Dispatcher. Caso seja importante minimizar os custos com equipamento, é também possível executar o Dispatcher de backup na mesma máquina do Caching Proxy. A Figura 9 apresenta essa configuração, na qual o Dispatcher de backup é executado na mesma máquina (3) do Caching Proxy.
O Load Balancer age como um único ponto de presença para os hosts de conteúdo de sua empresa. Isto é útil porque você informa o nome do host e o endereço do cluster no DNS, em vez do nome do host e do endereço de cada host de conteúdo, que fornece um nível de proteção contra ataques casuais e fornece uma aparência unificada para o Web site de sua empresa. Para aperfeiçoar ainda mais a disponibilidade do Web site, configure outro Load Balancer para agir como um backup para o Load Balancer principal, conforme descrito na Figura 10. Se um Load Balancer falhar ou ficar inacessível devido a uma falha na rede, os usuários finais ainda poderão acessar os hosts de conteúdo.
Legenda: 1--Cliente 2--Internet 3--Roteador/Gateway 4--Principal Dispatcher 5--Backup Dispatcher 6--Host de ConteúdoNo caso normal, um navegador em execução em uma das máquinas marcadas com o número 1 direciona seu pedido de um arquivo X para o nome de host do cluster que está mapeado para o Load Balancer principal (4). O Dispatcher roteia o pedido para o host de conteúdo (6) selecionado com base nos critérios de equilíbrio de carga do Dispatcher. O host de conteúdo envia o arquivo X diretamente para o navegador, roteando-o para o gateway da empresa (3) pela Internet (2), mas ignorando o Load Balancer.
O backup Dispatcher (5) não executa o equilíbrio de carga, desde que o principal esteja operacional. Os Dispatcher principal e de backup acompanham seus status trocando mensagens chamadas pulsações, periodicamente. Se o Dispatcher de backup detectar que o principal falhou, ele automaticamente assume a responsabilidade de fazer o equilíbrio de carga, interceptando pedidos direcionados ao nome do host e endereço IP de cluster do principal.
Há também a possibilidade de se configurar dois Dispatcher para a alta disponibilidade mútua. Neste caso, cada um executará ativamente o equilíbrio de carga para um cluster separado de hosts de conteúdo, agindo ao mesmo tempo como o backup para seu parceiro. (Em instalações do Load Balancer para IPv4 e IPv6, a alta disponibilidade simples é suportada, mas a alta disponibilidade mútua não é).
O Dispatcher geralmente não consome muitos recursos de processamento ou de memória e outros aplicativos podem ser executados na máquina do Load Balancer. Se for importante reduzir custos com o equipamento, será possível até mesmo executar o backup do Dispatcher em uma das máquinas do cluster na qual ele está fazendo o equilíbrio de carga. A Figura 11 representa essa configuração, na qual o Dispatcher de backup é executado em um dos hosts de conteúdo (5) do cluster.
Legenda: 1--Cliente 2--Internet 3--Roteador/Gateway 4--Principal Dispatcher 5--Backup Dispatcher e Host de Conteúdo 6--Host de ConteúdoIMPORTANTE: 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ê poderá utilizar o método de encaminhamento cbr do componente do Load Balancer' do Dispatcher para oferecer uma rota baseada em conteúdo de pedidos HTTP e HTTPS sem utilizar Caching Proxy. Consulte a publicação WebSphere Application Server Load Balancer Administration Guide para obter mais informações.
Load Balancer para IPv4 e IPv6 suporta apenas o método mac de encaminhamento de componentes Dispatcher. Os métodos de encaminhamento nat e cbr não são suportados.
Funcionando com o componente Caching Proxy do Application Server, o componente Load Balancer do Application Server permite distribuir pedidos para vários servidores de backend que hospedam conteúdo diferente. (Consulte o Introduzindo o Edge Components do WebSphere Application Server, para obter uma introdução a estes Edge Components).
Se o componente CBR (Content Based Routing) do Load Balancer for instalado junto com o Caching Proxy, os pedidos HTTP podem ser distribuídos com base na URL ou outras características determinadas pelo administrador, eliminando a necessidade de armazenar conteúdo idêntico em todos os servidores backend.
O uso do CBR será especialmente apropriado se os servidores da Web precisarem executar várias funções diferentes ou oferecer vários tipos de serviços. Por exemplo, o site de um varejista on-line na Web deve exibir seu catálogo, em que uma grande parte é estática e aceitar pedidos, o que significa executar um aplicativo interativo, tal como um script CGI (Commom Gateway Interface) para aceitar números de itens e informações do cliente. É sempre mais eficiente ter dois conjuntos diferentes de máquinas para executar as funções distintas e utilizar o CBR para rotear os diferentes tipos de tráfego para as diferentes máquinas. Da mesma forma, uma empresa pode utilizar o CBR para fornecer um serviço melhor para clientes pagantes do que para visitantes casuais de seu site na Web, roteando os pedidos pagos para servidores da Web mais potentes.
O CBR roteia pedidos com base em regras que você escreve. O tipo mais comum é a regra de conteúdo, que direciona pedidos com base no nome do caminho na URL. Por exemplo, a ABC Corporation pode escrever regras que direcionem pedidos da URL http://www.abc.com/catalog_index.html para um cluster de servidores e http://www.abc.com/orders.html para outro cluster. Há também regras que roteiam pedidos com base no endereço IP do cliente que os enviou ou em outras características. Para saber mais, consulte os capítulos do WebSphere Application Server Load Balancer Administration Guide sobre configuração do CBR e sobre funções avançadas do Load Balancer e do CBR. Para obter as definições de sintaxe das regras, consulte o apêndice do WebSphere Application Server Load Balancer Administration Guide sobre os tipos de regras do CBR.
A Figura 12 descreve uma configuração simples na qual o componente CBR do Load Balancer e o Caching Proxy são instalados juntos na máquina marcada com o número 4 e roteia pedidos para três hosts de conteúdo (6, 7 e 8) que hospedam conteúdo diferente. Quando um usuário final que trabalha em uma das máquinas marcadas com o número 1 solicita o arquivo X, o pedido passa pela Internet (2) e entra na rede interna da empresa através de seu gateway da Internet (3). O Servidor Proxy intercepta o pedido e transmite-o ao componente CBR na mesma máquina, que analisa a URL no pedido e determina qual host de conteúdo 6 hospeda o arquivo X. O Servidor Proxy gera um novo pedido para o arquivo X, e se seu recurso de armazenamento em cache estiver ativado, determina se o arquivo é elegível para armazenamento em cache quando o host 6 o retorna. Se o arquivo puder ser armazenado em cache, o Servidor Proxy armazenará uma cópia em seu cache (5) antes de transmiti-lo para o usuário final. O roteamento para outros arquivos funciona da mesma forma: pedidos para o arquivo Y vão para o host de conteúdo 7, e pedidos para o arquivo Z vão para o host de conteúdo 8.
Legenda: 1--Cliente 2--Internet 3--Roteador/Gateway 4--Caching Proxy e componente CBR do Load Balancer 5--Cache 6, 7, 8--Host de ConteúdoA Figura 13 representa uma configuração mais complexa que tem a possibilidade de se adequar a um varejista on-line. O componente CBR do Load Balancer e o Servidor Proxy são instalados juntos na máquina marcada com o número 4 e roteiam pedidos para duas máquinas do Load Balancer. A máquina do Load Balancer marcada com o número 6 equilibra a carga de um cluster de hosts de conteúdo (8) que hospeda o conteúdo mais estático do catálogo do varejista, enquanto o Load Balancer marcado com o número 7 equilibra a carga de um cluster de servidores Web que tratam pedidos (9).
Quando um usuário final que trabalha em uma das máquinas marcadas com o número 1 acessa a URL do catálogo do varejista, o pedido passa pela Internet (2) e entra na rede interna da empresa através de seu gateway da Internet (3). O Servidor Proxy intercepta o pedido o transmite-o ao componente CBR na mesma máquina, que analisa a URL e determina se a máquina do Load Balancer marcada com o número 6 tratará essa URL. O Servidor Proxy cria um novo pedido de acesso e envia-o ao Load Balancer, que determina qual dos hosts de conteúdo marcado com o número 8 tem, no momento, melhor capacidade de atender ao pedido (com base nos critérios definidos). Esse host de conteúdo transmite o conteúdo do catálogo diretamente para o Servidor Proxy, ignorando o Load Balancer. Como no exemplo anterior, o Servidor Proxy determina se o conteúdo pode ser armazenado em cache e o armazena em seu cache (5), se apropriado.
O usuário final faz um pedido acessando a URL do varejista para pedidos, presumivelmente por meio de um hyperlink no catálogo. O pedido faz o mesmo caminho que o pedido de acesso do catálogo, exceto que o componente CBR na máquina 4 roteia-o para a máquina do Load Balancer marcada com o número 7. O Load Balancer encaminha-o ao mais apropriado dos servidores Web marcado com o número 9, que responde diretamente ao Servidor Proxy. Como as informações do pedido são geralmente geradas de forma dinâmica, o Servidor Proxy provavelmente não as armazena em cache.
Legenda: 1--Cliente 2--Internet 3--Roteador/Gateway 4--Caching Proxy e componente CBR do Load Balancer 5--Cache 6, 7--Load Balancer 8--Host de Conteúdo 9--Servidor WebA função do CBR do Load Balancer suporta autorização de cookie. Isso significa que a identidade do servidor que atendeu ao primeiro pedido de um usuário final foi registrada em um pacote de dados especial (um cookie) incluído na resposta do servidor. Quando o usuário final acessa a mesma URL novamente dentro de um período que você define, e o pedido inclui o cookie, o CBR roteia o pedido para o servidor original em vez de reaplicar suas regras padrão. Geralmente, isso melhorará o tempo de resposta se o servidor tiver armazenado informações sobre o usuário final que não tenha que obter novamente (tal como o número do cartão de crédito).
Esta parte discute cenários de negócios que utilizam o Edge Components do IBM WebSphere Application Server. Essas são soluções de arquitetura examinadas e testadas que podem fornecer desempenho, disponibilidade, escalabilidade e confiabilidade excelentes.
Esta parte contém os seguintes capítulos:
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 cenário a seguir inclui tanto o Load Balancer quanto o Caching Proxy.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
A Figura 14 mostra um pequeno Web site de comércio projetado para fornecer uma navegação eficiente por catálogos. Todos os pedidos de clientes são passados do firewall para um Dispatcher que roteia esses pedidos para um cluster de Servidores Proxy com caches ativas, que agem como servidores substitutos para os servidores Web. Os servidores de métrica são colocados com Servidores Proxy para fornecer equilíbrio de carga de dados para o Dispatcher. Esta disposição reduz a carga da rede em servidores Web e isola-os do contato direto com a Internet.
A Figura 15 mostra a segunda fase de evolução de um Web site de comércio projetado para fornecer navegação eficiente por catálogos e carrinhos de compras rápidos e seguros para possíveis clientes. Todos os pedidos de clientes são roteados para a ramificação apropriada da rede por um Dispatcher que separa pedidos com base no protocolo Internet. Os pedidos HTTP vão para o Web site estático; os pedidos HTTPS vão para a rede de compras. O Web site principal e estático ainda é servido por um cluster de Servidores Proxy com caches ativas que agem como substitutas para servidores Web. Esta parte da rede espelha a rede na primeira fase.
A parte de e-commerce do Web site também é servida por um cluster de Servidores Proxy. No entanto, os nós do Caching Proxy são aperfeiçoados com vários módulos de plug-in. O protocolo de reconhecimento SSL é descarregado em uma placa de hardware de criptografia e a autenticação é feita por meio do plug-in do Access Manager (anteriormente denominado Policy Director). O plug-in Dynamic Caching reduz a carga de trabalho no WebSphere Application Server armazenando dados comuns. Um plug-in no servidor de aplicativo invalida objetos no Dynacache quando necessário.
Todos os aplicativos de carrinho de compras são amarrados ao banco de dados de cliente que foi utilizado para autenticar o usuário. Isso evita que o usuário tenha de inserir informações pessoais no sistema duas vezes, uma para autenticação e outra para fazer as compras.
Essa rede divide o tráfego de acordo com a utilização pelo cliente, removendo autenticação SSL intensiva de processador e carrinhos de compras de e-commerce do Web site principal. Esse Web site de trilha dupla permite ao administrador da rede ajustar os diversos servidores para fornecer excelente desempenho com base na função do servidor dentro da rede.
A Figura 16 mostra a terceira fase da evolução de uma rede business-to-consumer, com a Web estática adotando um método dinâmico de apresentação. O cluster do servidor proxy foi aperfeiçoado para suportar o armazenamento em cache de conteúdo dinâmico da Web e a montagem de fragmentos de páginas gravados para compatibilidade com o protocolo ESI (Edge Side Includes). Em vez de utilizar mecanismos de inclusão do lado do servidor para construir páginas da Web nos servidores de conteúdo e, em seguida, propagar estas páginas específicas de cliente, não armazenáveis em cache por toda a rede, os mecanismos de ESI permitem que as páginas sejam montadas a partir do conteúdo armazenado em cache na extremidade da rede, reduzindo, assim, o consumo de largura de banda e diminuindo o tempo de resposta.
Os mecanismos de ESI são importantes neste cenário da terceira fase, em que cada cliente recebe uma home page personalizada do Web site. Os blocos de construção destas páginas são recuperados de uma série de WebSphere Application Servers. Os servidores de aplicativos que contêm a lógica de negócios sensitiva e se ligam a bancos de dados seguros são isolados atrás de um firewall.
A Figura 17 mostra uma solução bancária eficiente que é semelhante à rede business-to-consumer descrita no Rede Business-to-Consumer. Todos os pedidos de clientes são passados do firewall para um Dispatcher que separa o tráfego de acordo com o protocolo Internet. Os pedidos HTTP são transmitidos para um cluster de servidores proxy com caches ativas que agem como servidores substitutos para os servidores Web. Os servidores de métrica são colocados com os servidores proxy para oferecer equilíbrio de carga de dados para o Dispatcher. Esta disposição reduz a carga da rede nos servidores Web e cria um buffer adicional entre eles e a Internet.
Os pedidos HTTPS são transmitidos para uma rede segura projetada para oferecer aos clientes informações financeiras pessoais e permitir transações bancárias on-line. Um cluster de servidores proxy avançados fornece escalabilidade para o site. Estes servidores proxy suportam o armazenamento em cache de conteúdo dinâmico da Web e a montagem de fragmentos de páginas gravados para compatibilidade com o protocolo ESI (Edge Side Includes). Uma placa de hardware criptográfica gerencia protocolos de reconhecimento SSL, o que reduz significativamente o processamento requerido do host do servidor proxy e um Access Manager (anteriormente denominado Policy Director) gerencia a autenticação do cliente.
Uma coleção de cluster de servidores de aplicativos distribui o processamento de pedidos, separando a lógica de negócios, contida em componentes EJB, desta camada de apresentação, contida em servlets e arquivos JSP. Cada um destes clusters é gerenciado por um servidor de sessão separado.
O cenário a seguir inclui tanto o Load Balancer quanto o Caching Proxy.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
A Figura 18 mostra uma rede de portal da Web projetada para suportar um grande volume de tráfego enquanto oferece a cada cliente um conteúdo personalizado. Para reduzir a carga de processamento nos diversos servidores, nenhuma parte da rede realiza o tráfego de SSL. Como o portal não entrega dados sensitivos, a segurança não é uma questão importante. É importante para os bancos de dados que contêm IDs, senhas e definições de clientes, permanecerem moderadamente seguros e íntegros, mas este requisito não afeta o desempenho do restante do Web site.
Todos os pedidos de clientes são passados do firewall para um Dispatcher que equilibra a carga da rede em um cluster de servidores proxy com caches ativas que agem como servidores substitutos para os servidores Web. Os servidores de métrica são colocados com os servidores proxy para oferecer equilíbrio de carga de dados para o Dispatcher.
O Web site real dinâmico é um cluster de servidores de aplicativos que geram fragmentos de ESI que são transmitidos aos servidores proxy para montagem. Devido a questões de segurança reduzida, cada servidor de aplicativo executa todas as funções necessárias para construir o Web site. Todos os servidores de aplicativos são idênticos. Se um servidor de aplicativo parar de funcionar, o servidor da sessão poderá rotear pedidos para os outros servidores, fornecendo grande disponibilidade para todo o site. Esta configuração também permite a rápida escalada do Web site se houver tráfego excessivo, por exemplo, a hospedagem de um evento especial pelo portal. Os servidores proxy e servidores de aplicativos adicionais podem ser rapidamente configurados no site.
Todo o conteúdo estático, como arquivos de imagens e texto padronizado é armazenado em servidores Web separados, permitindo que seja atualizado conforme necessário, sem risco de danos aos servidores de aplicativos mais complexos.
O cenário a seguir inclui tanto o Load Balancer quanto o Caching Proxy.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
Esta parte oferece os procedimentos para instalar o Edge Components.
Esta parte contém os seguintes capítulos:
Requisitos para o Edge Components
Instalando o Edge Components Utilizando o Programa de Instalação
Instalando o Caching Proxy Utilizando Ferramentas de Empacotamento de Sistema
Instalando o Load Balancer Utilizando Ferramentas de Empacotamento de Sistema
Este tópico oferece um link para requisitos de hardware e software para o Edge Components e descreve as diretrizes para utilizar navegadores da Web com formulários Caching Proxy Configuração e Administração e com a ajuda on-line de Load Balancer.
Para obter informações sobre os requisitos de hardware e software suportados para o WebSphere Application Server, Versão 6.1 Edge Components, acesse a seguinte página da Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Instalação de SDK: O Java 2 SDK é instalado automaticamente com o Load Balancer em todas as plataformas.
Requisitos mínimos do navegador
Para configurar o Caching Proxy utilizando os formulários de Configuração e Administração, seu navegador deve fazer o seguinte:
Para sistemas Linux e UNIX: Para obter as versões recomendadas dos navegadores Mozilla e Firefox, consulte o seguinte Web site e siga os links para a página da Web do software suportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Para sistemas Windows: Para obter as versões recomendadas dos navegadores Internet Explorer, Mozilla e Firefox, consulte o seguinte Web site e siga os links para a página da Web do software suportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
LIMITAÇÃO: A barra de rolagem vertical esquerda dos formulários de administração pode não ser exibida pelo navegador se o número de elementos expandidos for muito grande para ser exibido na janela do navegador. Isso faz com que os elementos expandidos no fim da lista sejam tirados da janela de visualização atual do navegador e fiquem inacessíveis. Para solucionar este problema, limite o número de elementos expandidos no menu esquerdo. Se o número de elementos expandidos for grande, reduza alguns dos elementos até que os do fim da lista sejam exibidos na janela do navegador.
Para exibir corretamente os formulários, o sistema operacional que está exibindo o formulário (aquele em que o navegador reside) deve conter os conjuntos de fontes apropriados para o idioma em que o formulário está escrito. No entanto, a interface do navegador não precisa estar no mesmo idioma que os formulários.
Por exemplo, uma versão em chinês do servidor proxy está executando em um sistema Solaris 9. Um navegador Mozilla com uma interface de idioma em inglês é carregado no host Solaris. Esse navegador pode ser utilizado localmente para editar os formulários Configuração e Administração. (Os formulários são servidos ao navegador no conjunto de caracteres utilizado pelo servidor proxy -- neste exemplo, chinês; no entanto, os formulários poderão não ser exibidos corretamente se o navegador e o seu sistema operacional subjacente não estiverem configurados devidamente para exibir o conjunto de caracteres enviado pelo servidor proxy).
Como alternativa, se uma estação de trabalho do Windows com suporte ao idioma chinês estiver disponível para conectar-se remotamente ao servidor proxy, será possível carregar uma versão em chinês de um navegador Netscape na estação de trabalho do Windows e utilizar esse navegador para inserir valores nos formulários. Esta segunda solução tem a vantagem de manter uma interface de idioma consistente para o administrador.
Os conjuntos de fontes específicos do sistema operacional afetam muito a exibição de vários idiomas, principalmente os caracteres de byte duplo, nos navegadores. Por exemplo, um conjunto específico de fontes chinesas no AIX não tem exatamente a mesma aparência que um conjunto de fontes chinesas nas plataformas Windows. Isso causa algumas irregularidades na aparência de texto HTML e applets Java dentro dos formulários de Configuração e Administração. Para obter a melhor aparência, somente os navegadores em execução nos sistemas operacionais Windows são recomendados.
Nota sobre o navegador Mozilla 1.4 no S/390 e PowerPC
O plugin Java instalado com o Mozilla 1.4 deve ser atualizado para a versão 1.4.2 ou superior para que os Formulários de Administração sejam exibidos corretamente. Use as seguintes etapas para atualizar o plugin:
Para utilizar a ajuda on-line do Load Balancer, seu navegador deve suportar:
Utilizar um navegador que não suporta estes requisitos pode resultar em páginas formatadas incorretamente e em funções que podem não funcionar corretamente.
Este tópico fornece instruções para instalar Edge Components utilizando o Programa de Instalação.
O Java 2 SDK é instalado automaticamente com o Load Balancer em todas as plataformas.
Após a instalação, scripts do pacote do Caching Proxy tentam iniciar o Servidor Proxy utilizando a configuração padrão. Se a porta 80 estiver sendo utilizada por outro servidor Web, o Servidor Proxy falhará ao iniciar.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
Utilize o Programa de Instalação para instalar o Edge Components em seu sistema Windows da seguinte maneira:
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.
Se estiver instalando a partir de um CD, você poderá utilizar o Programa de Instalação para instalar o Edge Components em seus sistemas Linux e UNIX da seguinte maneira:
# ./installA janela Bem-vindo é exibida.
O Programa de Instalaçã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.
No Red Hat Linux 3.0 Atualização 3: Ao executar o programa instalador para componentes Edge, os botões não funcionarão se o painel da GUI for maximizado e, então, restaurado. Para resolver esse problema, faça o seguinte:
Em sistemas Linux e UNIX: Se o programa de configuração for utilizado para instalar componentes Edge, o desinstalador da GUI pode ser utilizado para desinstalar componentes Edge. No entanto, o desinstalador de GUI dos componentes Edge não pode ser utilizado para desinstalar um pacote de atualização que é instalado utilizando comandos nativos. Você deve primeiro desinstalar o pacote de atualização utilizando comandos nativos (os comandos do sistema operacional) para que seja possível desinstalar componentes utilizando o desinstalador da GUI.
Para obter informações sobre a utilização de comandos nativos, consulte o Instalando o Caching Proxy Utilizando Ferramentas de Empacotamento de Sistema e o Instalando o Load Balancer Utilizando Ferramentas de Empacotamento de Sistema.
Este tópico fornece instruções para instalar o Caching Proxy utilizando ferramentas de empacotamento do sistema.
Após a instalação, scripts do pacote do Caching Proxy tentam iniciar o Servidor Proxy utilizando a configuração padrão. Se a porta 80 estiver sendo utilizada por outro servidor Web, o Servidor Proxy falhará ao iniciar.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
Utilizando o sistema de instalação do pacote do sistema operacional, instale os pacotes na ordem listada na Tabela 2. O procedimento a seguir detalha as etapas necessárias para concluir esta tarefa.
su - root Senha: senha
cd mount_point/package_directory/
Em AIX:
installp -acXd ./packagename
No HP-UX:
swinstall -s source/ packagename
No Linux:
rpm -i ./packagename
No Solaris:
pkgadd -d ./packagename
Componente | Pacotes Instalados (na Ordem Recomendada) |
---|---|
Caching Proxy |
|
Documentação do Edge Component |
doc-en_US1 |
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:
Em AIX:
installp -u packagename
Para desinstalar todos os pacotes do Caching Proxy, utilize o comando:
installp -u wses
No HP-UX:
swremove packagename
Para consultar os pacotes do Caching Proxy instalados, utilize o comando:
swlist | grep WSES
Os pacotes deveriam ser removidos na ordem inversa em que foram instalados.
No Linux:
rpm -e packagename
Para consultar os pacotes do Caching Proxy instalados, utilize o comando:
rpm -qa |grep -i wses
Os pacotes deveriam ser removidos na ordem inversa em que foram instalados.
No Solaris:
pkgrm packagename
Para consultar os pacotes do Caching Proxy instalados, utilize o comando:
pkginfo | grep WSES
Os pacotes deveriam ser removidos na ordem inversa em que foram instalados.
Este tópico documenta a instalação do Load Balancer nos sistemas AIX, HP-UX, Linux e Solaris:
Dependendo do tipo de instalação, nem todos os pacotes do componente Load Balancer listados nesta seção serão fornecidos.
A ordem recomendada para a instalação dos pacotes é um pouco diferente para instalações do Load Balancer para IPv4 e IPv6. É importante notar que o pacote de componente de administração deve ser instalado após o pacote de componente do Dispatcher. A ordem recomendada para instalação de pacotes para o Load Balancer para IPv4 e IPv6 utilizando as ferramentas do sistema é: base, licença, componente dispatcher, administração, documentação e Metric Server
Se estiver migrando de uma versão anterior do Load Balancer ou se estiver reinstalando um sistema operacional, antes da instalação, poderá salvar quaisquer um dos seus arquivos de configuração anteriores ou arquivos de script do Load Balancer.
Se efetuar logoff de uma máquina após a instalação do Load Balancer, você deverá reiniciar todos os serviços do Load Balancer quando efetuar logon novamente.
Tabela 5 lista os conjuntos de arquivo do AIX para o Load Balancer e a ordem recomendada de instalação utilizando a ferramenta de instalação do pacote do sistema.
Componentes do Load Balancer | Conjuntos de Arquivos do AIX |
---|---|
Base | ibmlb.base.rte |
Administração (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 |
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 de:
installp -u ibmlbou, para versões anteriores, digite o seguinte comando:
installp -u ibmndPara 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:
É recomendável utilizar a SMIT para instalar o Load Balancer para AIX porque a SMIT assegura que todas as mensagens sejam instaladas automaticamente.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
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.doc
ibmlb.msg.language.lb
Os caminhos de instalação do Load Balancer incluem:
Esta seção explica como instalar o Load Balancer no HP-UX utilizando 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ção para a Desinstalação de Pacotes.
A Tabela 7 lista os nomes dos pacotes de instalação do Load Balancer e a ordem recomendada para instalação dos pacotes utilizando a ferramenta de instalação do pacote do sistema.
O HP-UX não suporta o locale Português do Brasil (pt_BR). Os locales suportados no HP-UX são:
O procedimento a seguir detalha as etapas necessárias para concluir essa tarefa.
su - root Senha: senha
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 ibmlbPara desinstalar um pacote individual (por exemplo, o Cisco CSS Controller)
swremove ibmlb.cco
Os caminhos de instalação do Load Balancer incluem:
Esta seção explica como instalar o Load Balancer no Linux utilizando o CD Edge Components.
Antes de instalar o Load Balancer, certifique-se de:
rpm -e pkgnameQuando 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:
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 utilizando o CD 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:
Esta seção fornece procedimentos para construir redes de demonstração básicas utilizando o Edge Components. Essas redes não são para utilização em ambientes de produção. O processo de configurar inicialmente uma rede pode esclarecer conceitos de extremidade da rede para administradores que não estão familiarizados com o produto. Para obter uma descrição completa de todos os recursos de componentes e para obter informações detalhadas, consulte o Caching Proxy Administration Guide e o Load Balancer Administration Guide.
Os procedimentos permitem que qualquer sistema de computador suportado pelo componente seja utilizado em qualquer nó.
Esta parte contém os seguintes capítulos:
Construir uma Rede Caching Proxy.
Construir uma Rede Load Balancer.
A Figura 19 mostra uma rede básica do Servidor Proxy utilizando três sistemas de computadores localizados em três nós de rede. Esta rede liga o servidor proxy a um host de conteúdo dedicado (IBM HTTP Server), que está localizado no Servidor 2 e o servidor proxy serve o host. Isso é representado visualmente pela Internet sendo localizada entre a estação de trabalho e o Servidor 1.
IMPORTANTE: O Caching Proxy está disponível em todas as instalações do componente Edge, com as seguintes exceções:
Para construir uma rede 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 da seguinte maneira:
# 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 da seguinte maneira:
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 de Load Balancer com três estações de trabalho conectadas localmente utilizando o método de encaminhamento MAC do Dispatcher para equilibrar a carga do tráfego da Web entre dois servidores Web. A configuração é semelhante ao equilíbrio de carga de qualquer outro tráfego de TCP ou de aplicativo UDP sem estado.
Para construir uma rede 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 |
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 www.company.com 127.0.0.1 up
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 faz o equilíbrio de carga com base 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 Web com falha.
Sua configuração básica com servidores conectados localmente agora está concluída.
IMPORTANTE: Com a instalação do Load Balancer para IPv4 e IPv6, a sintaxe do comando do Dispatcher (dscontrol) é idêntica, com uma importante exceção. O delimitador para os comandos dscontrol é um símbolo de arroba (@), em vez de dois-pontos (:). Foi necessário definir um delimitador diferente de dois pontos, pois o formato do IPv6 utiliza dois pontos em seus esquemas de endereço.
Por exemplo (a partir do exemplo anterior de configuração do Dispatcher)
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
Para obter mais informações, se você estiver utilizando uma instalação do Load Balancer para IPv4 e IPv6, consulte o capítulo para implementação do Dispatcher no Load Balancer para IPv4 e IPv6, que inclui informações sobre as limitações e diferenças de configuração, na publicação WebSphere Application Server Load Balancer Administration Guide.
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 equilíbrio 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