Balanceamento de carga
A necessidade de balanceamento de carga na computação decorre de dois requisitos básicos: primeiro, a alta disponibilidade pode ser melhorada pela replicação. Em segundo lugar, o desempenho pode ser melhorado através do processamento paralelo. A elevada disponibilidade é a propriedade de um serviço que está disponível durante quase todo o tempo quando um cliente tenta aceder ao serviço. A qualidade do serviço (QoS) de um determinado serviço geralmente inclui várias considerações, tais como os requisitos de débito e latência.
O que é o balanceamento de carga?
A forma mais bem conhecida de balanceamento de carga é o "DNS round robin" que muitos serviços Web grandes utilizam para balancear a carga de pedidos entre vários servidores. Especificamente, múltiplos servidores Web de front-end, cada um com um endereço IP exclusivo, partilham um nome DNS. Para balancear o número de pedidos em cada um destes servidores Web, as grandes empresas como a Google mantêm e organizam um conjunto de endereços IP associados a uma única entrada DNS. Quando um cliente faz uma solicitação (por exemplo, para o domínio www.google.com), o DNS do Google seleciona um dos endereços disponíveis do pool e o envia para o cliente. A estratégia mais simples empregada para distribuir endereços IP consiste em utilizar uma simples fila round robin em que, depois de cada resposta DNS, a lista de endereços é permutada.
Antes do aparecimento da cloud, o balanceamento de carga DNS era uma forma simples de colmatar a latência das ligações de longa distância. O distribuidor no servidor DNS era programado para responder com o endereço IP do servidor que estava geograficamente mais próximo do cliente. Os esquemas mais simples para o fazer tentavam responder com o endereço IP do conjunto numericamente mais próximo do endereço IP do cliente. É claro que este método não era fiável, uma vez que os endereços IP não são distribuídos numa hierarquia global. As técnicas atuais são mais sofisticadas e dependem de um mapeamento de software de endereços IP a localizações com base em mapas físicos de fornecedores de serviços Internet (ISPs). Como isto é implementado como uma pesquisa de software cara, este método produz resultados mais precisos, mas a computação é dispendiosa. No entanto, o custo de uma pesquisa lenta é amortizado, uma vez que a pesquisa de DNS ocorre apenas quando é feita a primeira ligação a um servidor pelo cliente. Todas as comunicações subsequentes ocorrem diretamente entre o cliente e o servidor que possui o endereço IP distribuído. Pode ver um exemplo de esquema de balanceamento de carga DNS na figura que se segue.
Figura 4: Balanceamento de carga em um ambiente de hospedagem em nuvem
A desvantagem deste método é que, em caso de falha de servidor, a comutação para um endereço IP diferente depende da configuração TTL (Time-To-Live) da cache DNS. As entradas DNS são conhecidas como sendo de longa duração e as atualizações demoram mais de uma semana a propagar-se pela Internet. Como tal, é difícil "ocultar" rapidamente uma falha do servidor do cliente. É possível melhorar-se isto através da redução da validade (TTL) de um endereço IP na cache, mas isto ocorre à custa do desempenho e do aumento do número de pesquisas.
O balanceamento de carga moderno refere-se frequentemente à utilização de uma instância dedicada (ou de um par de instâncias) que direciona o tráfego de entrada para os servidores de back-end. Para cada pedido recebido numa porta especificada, o balanceador de carga redireciona o tráfego para um dos servidores de back-end com base numa estratégia de distribuição. Ao fazê-lo, o balanceador de carga mantém os metadados do pedido, incluindo informações como os cabeçalhos de protocolo das aplicações (tais como, os cabeçalhos HTTP). Nesta situação, não existe o problema das informações obsoletas, uma vez que cada pedido passa pelo balanceador de carga.
Embora todos os tipos de balanceadores de carga da rede reencaminhem simplesmente as informações do utilizador juntamente com qualquer contexto para os servidores de back-end, quando se trata de servir a resposta de volta ao cliente, eles podem utilizar uma de duas estratégias básicas:1
- Proxy: Nessa abordagem, o balanceador de carga recebe a resposta do back-end e a retransmite de volta ao cliente. O balanceador de carga comporta-se como um proxy Web padrão e está envolvido em ambas as metades de uma transação de rede, nomeadamente ao encaminhar o pedido para o cliente e ao enviar a resposta de volta.
- Entrega TCP: nesta abordagem, a ligação TCP com o cliente é entregue ao servidor de back-end. Como tal, o servidor envia a resposta diretamente para o cliente sem passar pelo balanceador de carga.
Figura 5: Mecanismo de transferência TCP do dispatcher para o servidor back-end
Impacto na disponibilidade e no desempenho
O balanceamento de carga é uma estratégia importante para mascarar falhas num sistema. Desde que o cliente do sistema esteja exposto a um único ponto final que esteja a balancear carga em vários recursos, é possível ocultar do cliente as falhas nos recursos individuais, sendo que, para tal, basta servir o pedido num recurso diferente. No entanto, é importante ter em atenção que o balanceador de carga é agora um ponto único de falha para o serviço. Se falhar por qualquer motivo, mesmo que todos os servidores de back-end ainda estejam a funcionar, não será possível servir os pedidos do cliente. Desta forma, para alcançar uma elevada disponibilidade, os balanceadores de carga são geralmente implementados aos pares.
O balanceamento de carga permite que um serviço distribua cargas de trabalho por vários recursos de computação na cloud. Ter uma única instância de computação na cloud tem várias limitações. Anteriormente, abordámos a limitação física em termos de desempenho, em que são necessários mais recursos para aumentar as cargas de trabalho. Com o balanceamento de carga, é possível distribuir volumes maiores de cargas de trabalho por múltiplos recursos de forma que cada um possa satisfazer os respetivos pedidos de forma independente e em paralelo, o que melhora o débito da aplicação. Isto também melhora os tempos médios de serviço, uma vez que existem mais servidores para servir a carga de trabalho.
Os serviços de verificação e monitorização são fundamentais para possibilitar o sucesso das estratégias de balanceamento de carga. Um balanceador de carga precisa de garantir que todos os pedidos são satisfeitos ao assegurar a disponibilidade de cada nó de recursos. Caso contrário, o tráfego não é direcionado para esse nó específico. A monitorização ping-echo é uma das táticas mais populares para verificar o estado de funcionamento de um nó de recursos específico. Para além do estado de funcionamento de um nó, algumas estratégias de balanceamento de carga requerem informações adicionais, tais como o débito, a latência e a utilização da CPU, para avaliar o recurso mais adequado para direcionar tráfego.
Os balanceadores de carga geralmente devem garantir uma elevada disponibilidade. A forma mais simples de fazer isto consiste em criar múltiplas instâncias de balanceamento de carga (cada uma com um endereço IP exclusivo) e associar cada instância a um único endereço DNS. Sempre que uma instância do balanceador de carga falhar por algum motivo, é substituída por uma nova e todo o tráfego é passado para a instância de ativação pós-falha com um impacto pequeno no desempenho. Simultaneamente, é possível configurar uma nova instância do balanceador de carga para substituir a que falhou e os registos DNS devem ser imediatamente atualizados.
Estratégias de balanceamento de carga
Existem várias estratégias de balanceamento de carga na cloud.
Distribuição equitativa
Esta é uma abordagem estática ao balanceamento de carga, na qual um simples algoritmo round robin é utilizado para dividir o tráfego uniformemente por todos os nós e não tem em consideração a utilização de qualquer nó de recursos individual no sistema nem o tempo de execução de qualquer pedido. Esta abordagem tenta manter cada nó no sistema ocupado e é uma das abordagens mais simples de implementar. Uma desvantagem importante desta abordagem é o facto de os pedidos pesados de clientes poderem agregar-se e acabar nos mesmos datacenters, o que faz com que alguns nós fiquem sobrecarregados enquanto outros permanecem subutilizados. No entanto, isto requer um padrão de carga muito específico e, na prática, há uma baixa probabilidade de ocorrer num grande número de clientes e servidores com capacidade e distribuição de ligação relativamente uniformes. Contudo, esta estratégia dificulta a implementação de estratégias de colocação em cache no datacenter que têm em conta considerações como a localidade espacial (onde se pré-obtêm e colocam em cache dados próximos dos dados que foram atualmente obtidos), uma vez que o próximo pedido feito pelo mesmo cliente poderá acabar num servidor diferente.
O AWS utiliza esta abordagem na oferta ELB (Elastic Load Balancer). O ELB do AWS aprovisiona balanceadores de carga que balanceiam o tráfego entre as instâncias EC2 anexadas. Os balanceadores de carga são essencialmente instâncias EC2 com um serviço para encaminhar o tráfego especificamente. Como os recursos por trás do balanceador de carga são aumentados horizontalmente, os endereços IP dos novos recursos são atualizados no registo DNS do balanceador de carga. Este processo demora vários minutos a ser concluído, uma vez que exige tempo de monitorização e de aprovisionamento. Este período de dimensionamento (o tempo decorrido até o balanceador de carga poder processar a carga mais alta) é conhecido como "aquecimento" do balanceador de carga.
Os balanceadores de carga do ELB do AWS também monitorizam todos os recursos anexados para distribuição da carga de trabalho de forma a manter uma verificação do estado de funcionamento. É utilizado um mecanismo ping-echo para garantir que todos os recursos estão em bom estado de funcionamento. Os utilizadores do ELB podem configurar os parâmetros da verificação de estado de funcionamento ao especificar os atrasos e o número de tentativas.
Distribuição baseada em hashes
Esta abordagem tenta garantir que os pedidos feitos por um cliente através da mesma ligação acabam sempre no mesmo servidor. Além disso, para balancear a distribuição do tráfego de pedidos, isto é feito por ordem aleatória. Isto apresenta diversas vantagens em relação à abordagem round robin, uma vez que ajuda no contexto de aplicações com reconhecimento de sessão, onde a persistência do estado e as estratégias de colocação em cache podem ser muito mais simples. Também é menos suscetível a padrões de tráfego que resultariam em entupimentos num único servidor, uma vez que a distribuição é aleatória, mas ainda há risco. No entanto, como todos os pedidos têm de ser avaliados para metadados de ligação de forma a encaminhá-los para um servidor relevante, isto introduz uma pequena quantidade de latência em cada pedido.
O Balanceador de Carga do Azure utiliza um mecanismo de distribuição baseada em hashes deste género para distribuir a carga. Este mecanismo cria um hash para cada pedido com base no IP de origem, na porta de origem, no IP de destino, na porta de destino e no tipo de protocolo para garantir que todos os pacotes da mesma ligação acabam sempre no mesmo servidor. A função de hash é escolhida para que a distribuição de ligações a servidores seja relativamente aleatória.
O Azure fornece verificações de integridade por meio de três tipos de testes: testes de agente convidado (em VMs PaaS), testes personalizados HTTP e testes personalizados TCP. Estas três sondas procedem à verificação de estado de funcionamento dos nós de recursos através de um mecanismo ping-eco.
Outras estratégias populares
Há outras estratégias utilizadas para balancear carga em múltiplos recursos. Cada uma delas utiliza métricas diferentes para medir o nó de recursos mais adequado para um pedido específico:
- Estratégias baseadas no tempo de execução da solicitação: Essas estratégias usam um algoritmo de agendamento de prioridade, no qual os tempos de execução da solicitação são usados para julgar a ordem mais apropriada de distribuição de carga. O principal desafio desta abordagem é prever com precisão o tempo de execução de um pedido específico.
- Estratégias baseadas na utilização de recursos: essas estratégias usam a utilização da CPU em cada nó de recurso para equilibrar a utilização em cada nó. Os balanceadores de carga mantêm uma lista ordenada de recursos com base na sua utilização e, em seguida, direcionam pedidos para o nó menos carregado.
Outros benefícios
Um balanceador de carga centralizado promove várias estratégias que podem melhorar o desempenho do serviço. No entanto, é importante denotar que essas estratégias só funcionam se o balanceador de carga não estiver sujeito a uma carga excessiva. Caso contrário, o próprio balanceador de carga torna-se um estrangulamento. Algumas destas estratégias estão apresentadas abaixo:
- Descarregamento de SSL: As transações de rede via SSL têm um custo extra associado a elas, uma vez que precisam ter processamento para criptografia e autenticação. Em vez de processar todos os pedidos através do SSL, a ligação do cliente ao balanceador de carga pode ser feita através do SSL. Já os pedidos de redirecionamento para cada servidor individual podem ser feitos por HTTP. Isto reduz consideravelmente a carga nos servidores. Além disso, a segurança é mantida desde que os pedidos de redirecionamento não sejam feitos numa rede aberta.
- Buffer TCP: Esta é uma estratégia para descarregar clientes com conexões lentas no balanceador de carga, a fim de aliviar os servidores que estão servindo respostas a esses clientes.
- Cache: em determinados cenários, o balanceador de carga pode manter um cache para as solicitações mais populares (ou solicitações que podem ser tratadas sem ir aos servidores, como conteúdo estático) para reduzir a carga nos servidores.
- Modelagem de tráfego: Para alguns aplicativos, um balanceador de carga pode ser usado para atrasar/repriorizar o fluxo de pacotes, de modo que o tráfego possa ser moldado para se adequar à configuração do servidor. Isto afeta o QoS de alguns pedidos, mas garante que a carga de entrada pode ser processada.
Referências
- Aron, Mohit e Sanders, Darren e Druschel, Peter e Zwaenepoel, Willy (2000). Distribuição escalável de solicitações com reconhecimento de conteúdo em servidores de rede baseados em cluster das Atas da Conferência Técnica Anual USENIX de 2000