Equilíbrio de Carga

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

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

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

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

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

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

Balanceamento de Carga de Vários Servidores Proxy Reversos

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

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

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

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

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

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

Load Balancer com Vários Servidores Proxy de Redirecionamento

Se você fornece acesso à Internet para um grande número de clientes, eles podem gerar mais demanda de acesso à Internet do que um único proxy pode oferecer com eficiência. À medida que o Caching Proxy torna-se sobrecarregado com pedidos, o tempo de resposta dos clientes pode se tornar pior do que seria com acesso direto à Internet. E, caso o Caching Proxy falhe ou fique inacessível devido a uma falha de rede, o acesso à Internet se torna impossível. A solução é instalar várias máquinas do Caching Proxy e usar o Dispatcher do Load Balancer para 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 de configuração automática de proxy (PAC) (conforme descrito em Caching Proxy de Redirecionamento Transparente (apenas Sistemas Linux)) que direciona o failover do navegador para um ou mais proxies de armazenamento em cache secundários. Um arquivo PAC não atende às necessidades de balanceamento da carga entre as máquinas do Caching Proxy, dessa forma, se um Caching Proxy receber muito mais pedidos que outro, é provável que tenha uma redução no desempenho, sujeitando seus clientes de navegador a tempos de resposta mais lentos. Para que todos os clientes tenham desempenhos semelhantes, você deve configurar um número aproximadamente igual de navegadores para utilizar cada Caching Proxy, e rastrear a distribuição manualmente para que possa manter a carga equilibrada mesmo quando incluir ou remover navegadores.

O Figura 7 descreve uma configuração de rede na qual o Dispatcher faz o balanceamento de carga de um cluster de máquinas do Caching Proxy. Uma das interfaces de rede da máquina do Dispatcher é configurada para ter o nome do host e o endereço IP dedicado 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 cria um novo pedido, passa-o pelo gateway da empresa (5) e pela Internet (6) e, se adequado, armazena o arquivo retornado em seu cache (4) conforme descrito em mais detalhes em Caching ProxyEncaminhamento

Nota:
O recurso de proxy transparente está disponível apenas em sistemas Linux.
Figura 7. Usando o Dispatcher para Balanceamento de Carga em Vários Proxies de Armazenamento em Cache.
Esse gráfico descreve o balanceamento de carga em vários proxies

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

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

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

Figura 8. Usando um Dispatcher Principal e de Backup para Fornecer Acesso de Alta Disponibilidade à Internet.
Esse gráfico descreve um Dispatcher principal e de backup para balanceamento de carga em vários proxies

Aqui, um navegador executando em uma das máquinas marcadas como 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 balanceamento de carga do Dispatcher. O Caching Proxy cria um novo pedido, roteia-o através do gateway da empresa (6) pela Internet (7) para o host de conteúdo (8) e armazena o arquivo X retornado em seu cache (5), se adequado (para obter uma descrição mais detalhada dessa parte do processo, consulte Caching ProxyEncaminhamento).

Nessa configuração, o Dispatcher de backup (3) não realiza balanceamento de carga, desde que o principal esteja operacional. Os Dispatchers principal e de backup acompanham o status de cada um trocando periodicamente mensagens chamadas pulsações. Se o Dispatcher de backup detectar que o principal falhou, ele automaticamente assume a responsabilidade pelo balanceamento de carga, interceptando pedidos direcionados ao nome do 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 balanceamento de carga para um cluster separado de proxies de armazenamento em cache, agindo ao mesmo tempo como o backup para seu parceiro. Para uma discussão adicional, consulte o WebSphere Application Server Load Balancer Administration Guide.

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

Figura 9. Localizando o Dispatcher de Backup em uma Máquina de Caching Proxy
Esse gráfico descreve um Dispatcher principal e de backup para balanceamento de carga em vários proxies