Balanceamento de carga Cenário - Estou certo?

Question

Atualmente, tenho um servidor da Web que executa meus sites, todos os pedidos vão direto para lá. O servidor da Web executa o Ruby on Rails e tudo está indo bem, mas conforme meus sites crescerem, eu precisarei obter um servidor maior ou escalar com mais servidores lidando com a carga extra.

Eu gostaria de ir com o segundo cenário. Em vez de ter um servidor enorme, gostaria de dois ou três servidores menores e mais baratos. É assim que eu acho que isso deve ser feito:

Todos os domínios apontam para x.x.x.30 (HAProxy.) Quando o HAProxy recebe uma solicitação GET, ele envia esta solicitação para o servidor web menos ocupado disponível. O servidor responde diretamente ao cliente. Com essa configuração, eu poderia facilmente aumentar adicionando servidores da Web a qualquer momento e rapidamente corrigir qualquer problema, removendo servidores problemáticos da Web do cluster.

x.x.x.30 <-- HAProxy
x.x.x.31 <-- webserver1: Rails/Passenger3
x.x.x.32 <-- webserver2: Rails/Passenger3

Estou correto em meu entendimento dessa configuração?

    

Answer 1

Sim - eu acho que você tem o básico para baixo pat:

O que é o HAProxy:

É o proxy - e apenas um proxy que funciona com qualquer coisa baseado em TCP - não apenas HTTP. Não serve arquivos - simplesmente apenas proxies.

Por que o HAProxy:

O HAProxy vem com muitos algoritmos de balanceamento de carga, incluindo uma estratégia de “menos conexões” que seleciona o back-end com o menor número de conexões pendentes.

Os back-ends podem ser verificados com sanidade e integridade por URL para evitar solicitações de roteamento para back-ends danificados por computador. (Pode até escalonar essas verificações para evitar picos).

Uma página de status dedicada oferece status de back-end, tempo de atividade e muitas métricas muito interessantes. As solicitações podem ser roteadas com base em todos os tipos de coisas: cookies, substrings de URL, IP do cliente, etc.

Como configurar o HAProxy:

    listen app_a_proxy 127.0.0.1:8100
  # - equal weights on all servers
  # - queue requests on HAPRoxy queue once maxconn limit on the appserver is reached
  # - minconn dynamically scales the connection concurrency (bound my maxconn) depending on size of HAProxy queue
  # - check health of app. server every 20 seconds

  server a1 127.0.0.1:8010 weight 1 minconn 3 maxconn 6 check inter 20000
  server a1 127.0.0.1:8010 weight 1 minconn 3 maxconn 6 check inter 20000

listen app_b_proxy 127.0.0.1:8200
  # - second cluster of servers, for another app or a long running tasks

  server b1 127.0.0.1:8050 weight 1 minconn 1 maxconn 3 check inter 40000
  server b2 127.0.0.1:8051 weight 1 minconn 1 maxconn 3 check inter 40000
  server b3 127.0.0.1:8052 weight 1 minconn 1 maxconn 3 check inter 40000

Confira aqui alguns exemplos e detalhes adicionais

    

Answer 2

Você geralmente tem razão, mas um detalhe que você encobriu é a parte da resposta. A configuração que você descreve é chamada de "Roteamento Direto", o que significa que os pacotes chegam ao balanceador de carga, são encaminhados para um servidor de backend e esse servidor responde diretamente ao cliente sem passar o tráfego de volta pelo balanceador de carga .

Para que o DR funcione, o endereço IP do balanceador de carga precisa ALSO existir em todos os servidores da web. No entanto, você precisa desabilitar as respostas ARP para esses endereços nos outros servidores. Aqui está uma referência a uma discussão sobre isso no CentOS .

A outra coisa a lembrar é que esse proxy pode agora se tornar um gargalo ou um único ponto de falha. Geralmente, quando esses proxies de balanceamento de carga são configurados, eles são configurados como um cluster de alta disponibilidade de máquinas para que a manutenção possa ser feita em um ou um deles pode falhar sem derrubar todo o site.

Além do DR, você também pode fazer NAT, em que os servidores da Web usam o balanceador de carga como o gateway, e os servidores da Web têm um IP privado, ao qual o balanceador de carga traduz e dos IPs públicos. Isso geralmente é mais fácil de configurar, porque você não precisa se preocupar com os problemas de ARP ou roteamento assimétrico, etc ...

Finalmente, um método não muito usado é o do módulo iptables CLUSTERIP. Este módulo bloqueia o tráfego com base no endereço IP remoto ou no endereço IP e no número da porta e uma ideia de qual nó no cluster em que está sendo executado. Então, você configuraria o endereço IP em todas as máquinas como um alias e configuraria o CLUSTERIP. Ele usa um hash das informações de conexão para que todas as máquinas no cluster concordem com qual nó o manipulará. Os pacotes são bloqueados nos nós que não manipulam e são aceitos pelo nó que o faz. Isso é feito usando um endereço MAC multicast no nível baixo.

Isso funciona muito bem porque você não tem um balanceador de carga dedicado para falhar. No entanto, é um pouco primitivo e obviamente não pode fazer balanceamento de carga com base em URLs ou outras informações de "camada 7", apenas com base no endereço IP.

Aqui está um artigo que escrevi sobre como configurar o CLUSTERIP no ano passado .

Existem muitas opções e usamos todas elas, dependendo da situação. Todos eles têm seus pontos strongs e fracos, dependendo exatamente de sua situação e objetivos e nível de experiência.