Verificação do estado do servidor
A verificação do estado ou saúde do servidor (server health checking ) é a capacidade do balanceador de carga para executar testes aos servidores para determinar se eles estão ou não a fornecer os serviços:
- Ping: Este é o método mais simples, porém não é muito fiável porque o servidor pode responder enquanto, por exemplo, o serviço web está em baixo;
- TCP connect: Este é um método mais sofisticado que pode verificar se um serviço está instalado e a funcionar, como um serviço web na porta 80 ou seja, tentar abrir uma ligação para a porta no servidor real;
- HTTP GET HEADER: Isso irá fazer uma solicitação HTTP GET para o servidor web e, normalmente, verificar se há um cabeçalho resposta, como 200 OK;
- HTTP GET CONTENTS: Isto fará um HTTP GET seguido de uma verificação do conteúdo real em busca de uma resposta correcta. Pode ser útil para verificar uma página dinâmica que retorna 'OK' somente se alguns testes de verificação de aplicação funcionam, por exemplo, validação de consultas a bases de dados. Este recurso só está disponível nalguns dos produtos mais avançados, mas é o método mais fiável para aplicações web porque verifica se a aplicação está de facto disponível.
Balanceamento de carga na camada 2
Balanceamento de carga na camada 2 (também conhecido como agregação de ligações ou agregação de portas) é unir duas ou mais ligações numa única ligação lógica com maior largura de banda. As ligações agregadas também fornecem redundância e tolerância a falhas, se cada uma das ligações seguir um caminho físico diferente.
Balanceamento de carga na camada 4
Balanceamento de carga na camada 4 é distribuir os pedidos para os servidores no nível ou camada de transporte, ou seja, nos protocolos como o TCP e o UDP. Um router típico limita-se a enviar os pacotes recebidos para o endereço IP apropriado na sua rede, mas um router de camada 4 está na camada de transporte e toma decisões sobre para onde enviar os pacotes distribuindo ligações de rede de clientes que conhecem um único endereço IP para um serviço, a um conjunto de servidores que realmente executam o trabalho.
Um router de camada 4, mais correctamente um NAT com conhecimento das portas e da transacção, usa uns artifícios e envia pacotes de entrada para uma ou mais máquinas que estão escondidos atrás de um único endereço IP. Uma vez que a ligação deve ser estabelecida entre o cliente e o servidor antes de ser enviado o conteúdo pedido, o balanceador de carga normalmente selecciona um servidor sem olhar ao conteúdo do pedido. Este é também um método de redundância, por isso, se uma máquina não está a funcionar, o router não lhe irá enviar tráfego.
Balanceamento de carga na camada 7
Balanceamento de carga na camada 7, também conhecido como balanceamento de carga de aplicações, é analisar os pedidos na camada de aplicação e distribui-los pelos servidores com base nos diferentes tipos de conteúdos de cada pedido, de modo a fornecer requisitos de qualidade de serviço para diferentes tipos de conteúdos e melhorar o desempenho global do cluster. A sobrecarga de analisar pedidos na camada de aplicação é alta, portanto, a sua escalabilidade é limitada, em comparação com balanceamento de carga de camada 4.
As appliances capazes de efectuar balanceamento de carga na camada 7 são conhecidas como Application Delivery Controllers (ADC) e combinam as tradicionais funcionalidades de balanceamento de carga com comutação avançada de camada 7 para sustentar a implementação de redes de aplicações altamente escaláveis e optimizadas. Vamos em seguida ver a diferença entre estas duas tecnologias, e os benefícios de combiná-las numa única appliance.
Como vimos anteriormente, o Balanceamento de Carga é o processo de balanceamento de pedidos em que o balanceador de carga apresenta ao mundo exterior um "servidor virtual", que aceita pedidos em nome de um grupo (também chamado cluster ou farm) de servidores que disponibilizam o mesmo conteúdo e distribui os pedidos para todos os servidores com base num algoritmo de balanceamento de carga.
Comutação na camada 7
A comutação na camada 7, também conhecida como "comutação de pedidos", "comutação de aplicações" ou "encaminhamento de conteúdos”, é assim chamada com base no modelo OSI, indicando que o dispositivo comuta pedidos com base em dados da camada 7 (aplicação). Um switch de camada 7 apresenta ao mundo exterior um "servidor virtual", que aceita pedidos em nome de um número de servidores e distribui esses pedidos com base em políticas que utilizam dados de aplicação para determinar qual o servidor deve atender o pedido.
Isso permite que a infra-estrutura de aplicações possa ser ajustada especificamente para atender a tipos específicos de conteúdo. Por exemplo, um servidor pode ser ajustado para servir apenas imagens, outro para a execução de scripting no servidor como PHP e ASP e outro para conteúdo estático, como HTML, CSS e JavaScript.
Ao contrário do balanceamento de carga, a comutação da camada 7 não exige que todos os servidores no grupo (farm / cluster) tenham o mesmo conteúdo. Na verdade, a comutação da camada 7 espera que os servidores tenham um conteúdo diferente, daí a necessidade de inspeccionar os pedidos mais profundamente antes de determinar para onde devem ser direccionados.
Conceitos de balanceamento de carga na camada 7
Ao combinar o balanceamento de carga com a comutação da camada 7, chegamos ao balanceamento de carga da camada 7, um recurso básico de todos os modernos ADCs.
O balanceamento de carga da camada 7 permite que os recursos adicionais oferecidos pelos ADCs sejam aplicados com base no tipo de conteúdo, o que melhora ainda mais a performance, executando apenas as políticas que são aplicáveis ao conteúdo. É também improvável que todos os servidores tenham as mesmas especificações e isso pode até ser adequado para os diferentes tipos de conteúdo a ser servido; alguns utilizadores podem ser direccionados para maiores servidores, se forem clientes premium, ou se estão no site para fazer uma encomenda ao invés de estar apenas a ver.
O balanceamento de carga da camada 7 permite também uma maior eficiência da infra-estrutura das aplicações porque tipos diferentes de conteúdo têm diferentes requisitos em termos de uso da CPU, ou de entradas e saídas, etc. É então é possível obter uma melhor eficiência dos servidores agrupando-os de modo que alguns possam lidar com transacções, enquanto outros só agem como sistemas de armazenamento em massa para servir páginas estáticas ou são optimizados para fazer o download de streaming de vídeo, por exemplo.
Para realizar o balanceamento de carga mais preciso, o ADC tem que ser capaz de olhar para a carga útil do pacote. Os principais parâmetros de decisão estão descritos abaixo:
Análise do URL
Trata-se de olhar para o URL que surge logo após o cabeçalho HTTP GET, e enviar o pedido para um grupo de servidores com base nesse endereço. O ADC pode procurar por uma determinada sequência, de modo a que os pedidos para www.meusite.com/welcome.html vão para um grupo de servidores de alta potência enquanto aqueles dirigidos www.meusite.com/exit.html vão para outro, ou pode usar a extensão (.asp, .gif, etc) para apontar o tráfego para servidores que foram optimizados para que servir esse tipo de tráfego.
Análise do cabeçalho HTTP
O ADC pode recolher muita informação a partir do cabeçalho. O cabeçalho Host: é realmente a parte www.meusite.com do endereço HTTP global, e é separada do resto (a partir do HTTP 1.1) para o seu próprio campo no cabeçalho. No caso de alojamento de vários sites empresariais não é necessário anunciar vários endereços IP virtuais para cada um, mas apenas deixar que o ADC direccione o tráfego usando as informações de cabeçalho.
Persistência / Afinidade
Quando as pessoas eram direccionadas para servidores com base apenas no seu endereço de origem, era muito fácil conseguir que fossem sempre para o mesmo servidor mas direccionar as pessoas de acordo com os endereços de páginas web e tipo de conteúdo torna mais difícil manter o controlo. Há ocasiões em que é vital que apenas um servidor processe todas as transacções de um utilizador durante toda a duração dessa sessão e a mais óbvia é fazer compras online. Independentemente da forma como o utilizador salta sobre as páginas de produtos, as suas entradas do carrinho de compras têm que ir sempre para o mesmo lugar. Isto é conhecido como persistência.
A persistência é uma característica requerida por muitas aplicações web e é normalmente necessária quando o estado da sessão é armazenado localmente no servidor web ao invés de numa base de dados. Depois de um utilizador ter interagido com um servidor em particular, todas as solicitações subsequentes serão enviadas ao mesmo servidor, portanto, persistindo nesse determinado servidor. Balanceamento de carga persistente pode ser conseguido usando o hashing do endereço IP ou através do uso de cookies - sendo este último o mais flexível.
- Persistência por IP: Este é um método simples e rápido, e hoje em dia é muito improvável que um cliente mude o IP durante uma sessão de modo que é perfeitamente seguro para ser usado, mas não é muito eficaz devido aos proxies ou seja, um utilizador pode ligar-se ao site através de uma faixa de IPs externos quebrando assim a persistência;
- Persistência por cookie: Os dispositivos da camada 7 podem tirar proveito da utilização de um cookie balanceador de carga com as informações de persistência. Este é um método mais fiável, que não sofre do problema dos proxies e funciona bem desde que os clientes aceitem cookies mas, obviamente, só pode funcionar com o tráfego HTTP. Sendo um caso especial de informações de cabeçalho, os cookies enviados dos servidores para os clientes, seja temporariamente para a duração dessa sessão, ou permanente para ser armazenada nos discos de rígidos dos utilizadores, fornecem informação adicional para tomar decisões sobre encaminhamento. Um valor do cookie (que pode ser mais ou menos uma string qualquer) pode indicar que essa pessoa usou o site anteriormente para que possa ser recebida pelo nome da próxima vez que visitar ou, se é um serviço que já tenha pago, ser enviada para os servidores que prestam os serviços que pagou.
O problema aqui é que se os servidores estão a usar HTTP seguro - o que é mais que provável num site de comércio electrónico onde há troca de informações financeiras e pessoais - o "cookie" está dentro do conteúdo SSL cifrado e portanto, os servidoesr não podem vê-lo nem agir em função dele.
Aceleração SSL
Aceleração SSL ou terminação SSL é a capacidade de um balanceador de carga para estabelecer um túnel seguro com o cliente e assim, na maioria dos casos, substituir a necessidade do servidor web executar SSL. Para que o balanceador de carga possa desempenhar esta função ele deve ser configurado com um certificado SSL ou auto gerado ou assinado por uma autoridade certificadora. A terminação SSL é muitas vezes necessária para outras funções da camada 7, como inserção de cookies; caso contrário, o balanceador de carga não pode ler o conteúdo dos pacotes cifrados. O balanceamento de carga de camada de 4 não tem a necessidade de ler o conteúdo dos pacotes e, portanto, não requer terminação SSL.
Vantagens do balanceamento de carga da camada 7
Em suma o balanceamento de carga da camada 7 permite:
- Balanceamento inteligente de carga das aplicação entre servidores de aplicação, firewalls, e muitos outros dispositivos baseados em algoritmos de balanceamento de carga, conteúdo e políticas, verificação contínua do estado dos servidores, suporte para dispositivos de backup e de escuta e configurações de comutação redundante activo-activo para assegurar que os pedidos são eficientemente enviados e servidos para o dispositivo de rede mais apropriado;
- Redireccionamento inteligente de aplicações, com base na inspecção de URLs, cookies e cabeçalhos de host em várias solicitações e respostas, aplicada com poderosas regras de filtragem;
- Serviços diferenciados 'Cookie-aware', tais como o tratamento especial para clientes frequentes versus visitantes ocasionais e características diferenciadas de largura de banda para diferentes tipos de aplicações baseadas na sensibilidade ao URL solicitado e não apenas ao IP ou a porta da aplicação;
- Hospedagem virtual, permitindo que um único endereço IP público represente vários domínios e redireccionando automaticamente os pedidos para o servidor apropriado ou cluster de servidores.
- Ligações persistentes para melhorar o desempenho da sessão para as operações de eBusiness (carrinhos de compras e formulários de várias páginas, por exemplo), as aplicações multimédia (VoIP, SIP, etc) e aplicações wireless.
- Segurança sensível a aplicações que protege os servidores e as aplicações contra ataques (vírus, worms, DoS, etc) e intrusos indesejáveis, proporcionando simultaneamente serviços de forma contínua para o tráfego legítimo;
- Capacidades de gestão inteligente de largura de banda que podem medir, controlar e reportar a utilização de recursos por atributo, incluindo o tipo de aplicação, o cliente, cluster de servidores, filtros, serviços, classe de utilizador, URL, cookies e tipo de conteúdo.