Melhores práticas de balanceamento de carga para persistência

Question

Executamos um aplicativo da Web que atende APIs da web para um número crescente de clientes. Para começar, os clientes geralmente viam redes domésticas, de escritório ou outras redes sem fio enviando uploads HTTP em partes para nossa API. Agora, nos ramificamos para lidar com mais clientes móveis. Os arquivos variam de alguns k a vários shows, divididos em partes menores e remontados em nossa API.

Nosso balanceamento de carga atual é executado em duas camadas, primeiro usamos o round robin DNS para anunciar vários registros A para o nosso endereço api.company.com. Em cada IP, hospedamos um Linux LVS: link , balanceador de carga que examina o endereço IP de origem de uma solicitação para determinar qual API servidor para entregar a conexão para. Essas caixas LVS são configuradas com heartbeatd para assumir VIPs externos e IPs de gateway internos uns dos outros.

Ultimamente, vimos duas novas condições de erro.

O primeiro erro é onde os clientes estão oscilando ou migrando de um LVS para outro, no meio do upload. Isso, por sua vez, faz com que nossos balanceadores de carga percam o rastro da conexão persistente e enviem o tráfego para um novo servidor de API, quebrando, assim, o upload em partes em dois ou mais servidores. Nossa intenção era que o valor TTL do Round Robin DNS para nosso api.company.com (que definimos em 1 hora) fosse respeitado pelos servidores de nome de armazenamento em cache downstream, camadas de armazenamento em cache do sistema operacional e camadas de aplicativo do cliente. Este erro ocorre por aproximadamente 15% dos nossos uploads.

O segundo erro que vimos muito menos comumente. Um cliente irá iniciar o tráfego para uma caixa LVS e será roteado para o servidor real A por trás dele. Posteriormente, o cliente entrará por meio de um novo endereço IP de origem, que a caixa LVS não reconhece, roteando assim o tráfego em andamento para o servidor real B também por trás desse LVS.

Dada a nossa arquitetura descrita na parte acima, gostaria de saber quais são as experiências das pessoas com uma abordagem melhor que nos permitirá lidar com cada um dos casos de erro acima de forma mais elegante?

Editar 5/3/2010:

Isso parece com o que precisamos. Swing ponderado do GSLB no endereço IP de origem.

link

    

Answer 1

A solução canônica para isso é não confiar no endereço IP do usuário final, mas usar um balanceador de carga da Camada 7 (HTTP / HTTPS) com "Sticky Sessions" por meio de um cookie.

Sessões aderentes significa que o balanceador de carga sempre direcionará um determinado cliente para o mesmo servidor de back-end. Via cookie significa que o balanceador de carga (que é um dispositivo HTTP totalmente capaz) insere um cookie (que o balanceador de carga cria e gerencia automaticamente) para lembrar qual servidor de backend deve usar uma determinada conexão HTTP.

A principal desvantagem das sessões é que a carga do servidor beckend pode se tornar um pouco desigual. O balanceador de carga só pode distribuir a carga de maneira justa quando novas conexões são feitas, mas, considerando que as conexões existentes podem durar muito em seu cenário, então, em alguns períodos de tempo, a carga não será distribuída totalmente de maneira justa.

Quase todos os balanceadores de carga da Camada 7 devem ser capazes de fazer isso. No Unix / Linux, alguns exemplos comuns são nginx, HAProxy, Apsis Pound, Apache 2.2 com mod_proxy e muitos mais. No Windows 2008+, há o Microsoft Application Request Routing. Como aparelhos, Coyote Point, loadbalancer.org, Kemp e Barracuda são comuns no espaço low-end; e F5, Citrix NetScaler e outros em high-end.

Willy Tarreau, autor de HAProxy, tem uma bela visão geral das técnicas de balanceamento de carga aqui .

Sobre o round robin do DNS:

Our intent was for the Round Robin DNS TTL value for our api.company.com (which we've set at 1 hour) to be honored by the downstream caching nameservers, OS caching layers, and client application layers.

Não será . E O DNS Round Robin não é um bom ajuste para balanceamento de carga . E se nada mais te convence, tenha em mente que clientes modernos podem preferir um host sobre todos os outros devido à maior correspondência de prefixo , então se o cliente móvel alterar o endereço IP, ele pode optar por mudar para outro host RR.

Basicamente, não há problema em usar o round robin de DNS como uma distribuição de carga grosseira, apontando 2 ou mais registros RR para endereços IP altamente disponíveis, manipulados por balanceadores de carga reais em HA ativo / passivo ou ativo / ativo. E se isso é o que você está fazendo, então você também deve servir esses registros RR de DNS com valores de Time To Live longos, já que os endereços IP associados já estão altamente disponíveis.

    

Answer 2

Para responder à sua pergunta sobre alternativas: Você pode obter um sólido balanceamento de carga da camada 7 por meio de HAProxy .

No que diz respeito à correção dos problemas de afinidade com o LVS, estou um pouco seco em ideias sólidas. Pode ser tão simples quanto um tempo limite ou estouro. Alguns clientes móveis alternarão os endereços IP enquanto estiverem conectados à rede. talvez isso possa ser a fonte de suas desgraças? Eu sugiro, no mínimo, que você espalhe a granularidade de afinidade para pelo menos uma classe C.