Voltar ao blog

HAProxy e Conceitos de Balanceamento de Carga: o Básico

HAProxy e Conceitos de Balanceamento de Carga: o Básico

Introdução

High Availability Proxy (HAProxy), é uma solução popular de proxy de código aberto e TCP/HTTP balanceador de carga capaz de rodar em Solaris, FreeBSD, e Linux. Ele é mais comumente usado para melhorar a confiabilidade e o desempenho de um ambiente de servidor, fornecendo uma distribuição equilibrada de carga de trabalho entre vários servidores. Esse tipo de ferramenta é usado em muitos ambientes de alto perfil, como Instagram, GitHub, Twitter e Imgur.

Este guia irá apresentar-lhe o HAProxy, familiarizá-lo com a terminologia de balanceamento de carga e fornecer exemplos de como ele pode ser aproveitado para reforçar tanto o desempenho quanto a confiabilidade dos ambientes de servidor.

Termos Essenciais do HAProxy

Antes de entrar nos detalhes de balanceamento de carga e proxying, existem alguns termos e conceitos importantes com os quais você deve se familiarizar. Começaremos revisando esses conceitos nas seções a seguir.

ACL (Lista de Controle de Acesso)

Quando se trata de balanceamento de carga, as ACLs são utilizadas para testar uma condição específica e realizar uma ação com base no resultado. Isso proporciona a capacidade de encaminhar o tráfego de forma ideal com base em fatores como conexões de backend e correspondência de padrões, além de muitos outros. Aqui está um exemplo de ACL em uso:

Neste caso, a ACL é correspondida se o caminho solicitado pelo usuário começar com /blog. For exemplo, esta solicitação de correspondência apontaria para http://yourdomain.com/blog/blog-entry-1. O Manual de Configuração do HAProxy contém um guia detalhado sobre o uso de ACL.

O Backend

As solicitações encaminhadas são recebidas por um conjunto de servidores conhecido como backend. As solicitações são definidas na seção backend da configuração do HAProxy. Nos termos mais básicos, um backend pode ser definido por quais algoritmos de balanceamento de carga usar e uma lista de portas e servidores. Um backend pode consistir em um único servidor ou em vários servidores. À medida que mais servidores são adicionados ao backend, a capacidade de carga potencial aumenta, com o processamento distribuído por vários servidores. Se alguns dos servidores de backend ficarem offline, os outros servirão como backup para lidar com o processamento das solicitações.

Vejamos um exemplo de configuração de dois backends. Neste caso, eles são um blog-backend e um web-backend. Cada um possui dois servidores web, escutando na porta 80:

A linha balance roundrobin destina-se a especificar o algoritmo de balanceamento de carga. Os detalhes podem ser encontrados na próxima seção de Algoritmos para Balanceamento de Carga, enquanto o mode http configura o uso de proxy de camada 7. Explicaremos isso na seção de Tipos de Balanceamento de Carga. Além disso, a opção check após a diretiva dos servidores indica que as verificações de integridade serão acionadas nesses servidores de backend específicos.

O Frontend

A definição de como as solicitações são encaminhadas para o backend é chamada de frontend. As solicitações são definidas na seção frontend da configuração do HAProxy. Elas são compostas por ACLs, uma porta, um conjunto de endereços IP e uma regra que define quais backends usar dependendo de quais condições de ACL foram atendidas, chamada de regra use_backend. Além disso, também existe uma regra default_backend para tratar qualquer outro caso. A próxima seção explicará como um frontend pode ser configurado para vários tipos de tráfego de rede.

Tipos de Balanceamento de Carga

Com os componentes básicos usados para o balanceamento de carga estabelecidos, podemos agora passar para os tipos básicos de balanceamento de carga.

Sem Balanceamento de Carga

Em sua forma mais rudimentar, a falta de balanceamento de carga pode ser ilustrada da seguinte forma:

HAProxy 1

Neste cenário, um usuário se conecta diretamente ao servidor web, em yourdomain.com. Não há balanceamento de carga presente. Como há apenas um servidor de banco de dados, se ele ficar offline, o acesso às informações nele contidas será completamente cortado. Se muitos usuários tentarem se conectar a um único servidor web simultaneamente, e este não for capaz de lidar com a carga exercida, todas as conexões ficarão lentas ou falharão completamente.

Balanceamento de Carga (camada 4)

Uma das maneiras mais simples e pragmáticas de balancear o tráfego de rede para múltiplos servidores é usando métodos de balanceamento de camada de transporte ou camada 4. Essa forma de balanceamento de carga direciona qualquer usuário que se conecta com base na faixa de IP em que seu endereço IP se enquadra e na porta. Em outras palavras, se http://yourdomain.com/anything é de onde vem a requisição, o backend definido para lidar com essas requisições será o que, em última análise, as tratará. Ele encaminhará essas requisições para yourdomain.com na porta 80.

A formação básica do balanceamento de carga de camada 4 se parece com isto:

HAProxy 2

À medida que o usuário obtém acesso ao balanceador de carga, suas requisições são encaminhadas para o grupo de servidores web-backend. O servidor backend configurado responderá diretamente à requisição do usuário. Para evitar que o usuário encontre dados inconsistentes, todos os servidores web-backend devem servir conteúdo idêntico. Conforme o diagrama acima, ambos os servidores web se conectam, em última análise, ao mesmo servidor de banco de dados.

Balanceamento de Carga (Camada 7)

Existe outro método mais complexo para balancear o tráfego de rede. Trata-se do uso de balanceamento de carga de nível 7, ou camada de aplicação. Essa abordagem permite que as requisições dos usuários sejam encaminhadas para diferentes servidores backend dependendo do conteúdo das requisições. Esse método permite que o balanceamento de carga ocorra em múltiplos servidores de aplicação web através da mesma porta e domínio. Para mais detalhes sobre esta camada, dê uma olhada na subseção HTTP do nosso The Nitty Gritty of Networking: Learn about Terminology, Interfaces, and Protocols tutorial.

O diagrama a seguir ilustra o balanceamento de carga de camada 7:

layer 7

Neste caso, um usuário requisita yourdomain.com/blog, e sua requisição é encaminhada para o backend do blog. Este é um conjunto de servidores backend alocado especificamente para executar a aplicação do blog. Enquanto isso, outras requisições serão encaminhadas para o web-backend. No entanto, ambos os backends resultam no acesso ao mesmo servidor de banco de dados.

Um exemplo de uma pequena parte de configuração de frontend para balanceamento de carga de camada 7 seria parecido com os seguintes comandos. Eles configuram o frontend http para lidar com o tráfego de entrada através da porta 80:

Se o caminho da requisição do usuário começar com /blog, o acl url_blog path_beg /blog corresponderá à requisição.

use_backend blog backend if url_blog faz o proxy do tráfego para o blog-backend utilizando ACL.

defaut_backen web_backend direciona todos os outros encaminhamentos de tráfego para o web-backend.

Algoritmos para Balanceamento de Carga

Quando o balanceamento de carga está sendo executado, é o algoritmo de balanceamento de carga que define qual servidor backend será selecionado para essa finalidade. Existem várias opções de algoritmos oferecidas pelo HAProxy. Adicionalmente, é possível atribuir um parâmetro de peso (weight) aos servidores para manipular a frequência com que um servidor é selecionado em contraste com os outros. Existem simplesmente algoritmos demais disponíveis para descrever todos eles. Portanto, este guia focará apenas nos mais comuns. Você pode consultar o HAProxy Documentation Converter para ver a lista completa. Os mais comumente usados incluem:

  • roundrobin: O algoritmo padrão que seleciona os servidores por vez.
  • leastconn: O servidor com menos conexões é selecionado automaticamente. No entanto, esses servidores dentro do mesmo backend devem ser alternados em um esquema round-robin.
  • source: O algoritmo escolhe o servidor com base no endereço IP de origem da requisição do usuário. É um método para garantir que o usuário sempre se conectará ao mesmo servidor.

Sticky Sessions

Para algumas aplicações, é um requisito que os usuários que se conectam o façam vinculando-se sempre ao mesmo servidor. Por meio de 'sticky sessions' e usando o appsession no backend que o exige, essa persistência pode ser alcançada.

Processamento de Health Checks

O HAProxy precisa de um método pelo qual possa determinar a capacidade de um servidor backend de processar requisições. Isso serve para remover um servidor do backend se ele ficar offline. Há uma execução padrão de 'health check' que tenta estabelecer uma conexão TCP. Ela faz isso escutando no endereço IP e porta configurados.

Se o health check do servidor não passar, o servidor ficará incapaz de processar as requisições enviadas. Nesse ponto, o servidor é desativado automaticamente no backend, e o tráfego deixa de ser encaminhado para ele até que ele esteja ativo e funcionando novamente (saudável). No entanto, em certos casos, determinar a integridade do servidor por meio do health check padrão se mostra insuficiente.

Soluções Alternativas

O HAProxy pode se mostrar sofisticado demais para as suas necessidades específicas. Nesse caso, existem algumas boas alternativas que podem se mostrar mais eficientes:

  • Nginx: Este é um servidor web rápido e confiável que pode ser aproveitado para fins de balanceamento de carga e proxy. Na verdade, o Nginx é comumente usado em conjunto com o HAProxy, que utiliza seus recursos de compressão e cache.
  • Linux Virtual Servers (LVS): Este é um balanceador de carga simples de camada 4 que está incluído em muitos sistemas Linux.

Alta Disponibilidade

Até agora, falamos sobre balanceamento de carga de camada 4 e camada 7. Ambos utilizam um balanceador de carga para determinar qual dos muitos servidores backend será encarregado de responder à requisição do usuário. Mas é importante ter em mente as limitações de um balanceador de carga. Ou seja, que ele é um ponto único de falha. Isso significa que, se ele cair ou ficar sobrecarregado com as requisições dos usuários, resultará em inatividade ou latência no processamento das requisições, respectivamente. No entanto, uma configuração de HA (alta disponibilidade) apresenta uma infraestrutura sem nenhum ponto único de falha. Isso evita que ocorram eventos de inatividade devido a falhas no servidor, introduzindo redundância em todos os níveis da arquitetura do sistema. Embora o balanceador de carga ajude a facilitar a redundância do backend, os próprios balanceadores de carga também precisam exercer redundância.

O diagrama a seguir exibe uma forma básica de uma configuração de alta disponibilidade:

basic form of a high availability setup

 

Esta infraestrutura possui vários balanceadores de carga (um ativo, os demais passivos) vinculados a um endereço IP estático. Este endereço IP pode ser remapeado para um servidor diferente se a situação exigir. A requisição do usuário viaja através do endereço IP externo para o balanceador de carga atualmente ativo. Se o balanceador de carga estiver offline no momento, o mecanismo de segurança (failsafe) detectará seu estado, reatribuindo o endereço IP para o(s) servidor(es) passivo(s).

Conclusão

A compreensão fundamental do balanceamento de carga e o conhecimento de algumas das maneiras pelas quais o HAProxy pode atender às necessidades de balanceamento de carga do seu sistema devem fornecer uma base sólida para começar a otimizar a confiabilidade e o desempenho dos seus ambientes de servidor atuais. Você também pode conferir o nosso tutorial Proxying HTTP, Balanceamento de Carga, Buffering e Caching do Nginx: Uma Visão Geral para saber mais sobre as propriedades de balanceamento de carga do Nginx.

Feliz computação!

author

Hark Labs

Autor · CloudSigma

Preslav Dobrev é um designer criativo na CloudSigma, focado na construção de uma identidade empresarial consistente por meio de canais de marketing tradicionais e inovadores. Ele é hábil em combinar a visão artística com o marketing estratégico para criar narrativas de marca impactantes.

Comentários

Nenhum comentário ainda. Seja o primeiro.