Práticas recomendadas para persistência de balanceamento de carga

Executamos um aplicativo da web que atende APIs da web para um número crescente de clientes. Para começar, os clientes geralmente estavam em casa, no escritório ou em outras redes sem fio enviando carregamentos http em pedaços para a nossa API. Agora, começamos a lidar com mais clientes móveis. Os arquivos variam de alguns k a vários shows, divididos em pedaços menores e remontados em nossa API.

Nosso balanceamento de carga atual é realizado em duas camadas; primeiro, usamos o DNS de rodízio para anunciar vários registros A para o nosso endereço api.company.com. Em cada IP, hospedamos um Linux LVS: http://www.linuxvirtualserver.org/ , balanceador de carga que analisa o endereço IP de origem de uma solicitação para determinar em qual servidor API entregar a conexão. Essas caixas LVS são configuradas com pulsação para assumir VIPs externos e IPs de gateway interno um do outro.

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 controle da conexão persistente e enviem o tráfego para um novo servidor de API, interrompendo o upload em pedaços em dois ou mais servidores. Nossa intenção era que o valor TTL Round Robin DNS da nossa api.company.com (que definimos em 1 hora) fosse respeitado pelos servidores de nomes de cache downstream, camadas de cache do SO e camadas de aplicativos clientes. Este erro ocorre em aproximadamente 15% dos nossos envios.

O segundo erro que vimos com muito menos frequência. Um cliente iniciará o tráfego para uma caixa LVS e será roteado para o servidor real A atrás dela. Posteriormente, o cliente entrará através de um novo endereço IP de origem, que a caixa LVS não reconhece, direcionando o tráfego em andamento para o servidor real B também atrás desse LVS.

Dada a nossa arquitetura, conforme descrito na parte acima, eu 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 mais graciosamente?

Editar 03/05/2010:

Parece o que precisamos. Hash GSLB ponderado no endereço IP de origem.

http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674

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 "Sessões permanentes" por meio de um cookie.

Sessões permanentes 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 back-end uma determinada conexão HTTP deve usar.

A principal desvantagem das sessões complicadas é 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, como as conexões existentes podem durar muito tempo no seu cenário, em alguns períodos, a carga não será distribuída de maneira totalmente 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 ou superior, existe o Microsoft Application Request Routing. Como eletrodomésticos, Coyote Point, loadbalancer.org, Kemp e Barracuda são comuns no espaço low-end; e F5, Citrix NetScaler e outros de alto nível.

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

Sobre o DNS Round Robin:

Nossa intenção era que o valor TTL Round Robin DNS da nossa api.company.com (que definimos em 1 hora) fosse respeitado pelos servidores de nomes de cache downstream, camadas de cache do SO e camadas de aplicativos clientes.

Não será . E o DNS Round Robin não é um bom ajuste para o balanceamento de carga . E se nada mais o convencer, lembre-se de que os clientes modernos podem preferir um host a todos os outros devido à fixação de correspondência de prefixo mais longa ; portanto, se o cliente móvel alterar o endereço IP, poderá optar por mudar para outro host RR.

Basicamente, não há problema em usar o round robin do DNS como uma distribuição de carga de granulação grossa, apontando 2 ou mais registros RR para endereços IP altamente disponíveis, manipulados por balanceadores de carga reais em HA ativa / passiva ou ativa / ativa. E se é isso que você está fazendo, é melhor servir esses registros RR de DNS com valores longos de tempo de vida, pois os endereços IP associados já estão altamente disponíveis.

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

Quanto a corrigir os problemas de afinidade do LVS, estou um pouco seco com idéias sólidas. Pode ser tão simples quanto um tempo limite ou estouro. Alguns clientes móveis trocam de endereço IP enquanto estão conectados à rede; talvez essa seja a fonte de seus problemas? Sugiro, no mínimo, que você espalhe a granularidade de afinidade para pelo menos uma classe C.