estratégia para distribuir os nós do erlang otp por trás do haproxy

Question

Eu tenho um aplicativo erlang padrão baseado em princípios otp. Eu pretendo colocar meus nós erlang em produção, conforme explicado abaixo:

1. recebe todo o tráfego em um ip público (haproxy)
2. haproxy-los para um dos nós de backlandlang disponíveis

Tudo isso funciona muito bem, no entanto, no caso de transações http baseadas em sessões, é provável que um dos nós do erlang receba uma solicitação, cujos processos relacionados à sessão residem em outro nó do erlang.

Minhas perguntas estão relacionadas à melhor estratégia para lidar com esses casos:

1. primeira opção é configurar o haproxy para equilibrar com base na fonte (ou seja, endereço IP), isso sempre garantirá que todas as solicitações de uma sessão de um único ip vão para o mesmo backend erlang node
2. a segunda opção é configurar o haproxy para balancear com base em algum parâmetro de cookie relacionado à sessão (que basicamente me dá o mesmo que o caso 1))
3. finalmente, como os nós do erlang podem se comunicar uns com os outros, também é possível configurar o haproxy para balancear na forma roundrobin e, quando um nó erlang recebe uma solicitação, cujos processos de sessão residem em outro nó erlang, pode se comunicar internamente com o nó erlang usando rpc: call () e atender a solicitação.

1), 2) são muito fáceis de usar e configurar, no entanto eu li e testei que o balanceamento baseado em source / cookie / url_param não garante balanceamento igual entre backends.

3) é possível usando o poder de replicação de mnésia dentro de erlang. Com 3) provavelmente terminarei com um caso em que um nó erlang se comunica internamente com outro nó erlang antes de finalmente atender a uma solicitação.

Eu gostaria de saber o que é preferível e por quê? 3) será uma escolha melhor a longo prazo, considerando que minha aplicação otp lida com muitos dados em tempo real (protocolo xmpp).

    

Answer 1

Acho que isso depende muito da carga que um de seus nós pode suportar em termos de sessões. O hash de IP e cookie, pelo menos em termos de HTTP, faz um bom trabalho em manter o equilíbrio com um grande número de sessões breves .

Assim, por exemplo, pode haver muitos clientes por trás de um único IP (o hashing baseado em cookie deve ajudar nisso). Se um único nó puder manipular apenas uma quantidade relativamente pequena de sessões simultâneas, um nó poderá ficar sobrecarregado. Além disso, se as sessões durarem muito, o desequilíbrio do hashing pode ser pronunciado. Se, por outro lado, o número de sessões for grande e curto, a importância relativa de um nó ter mais algumas conexões provavelmente não importará muito.

Em teoria, eu também esperaria que, com alguma forma de balanceamento baseado em fonte ou em cookie, você obteria melhores índices de acertos do cache. Uma outra coisa a considerar é que, se você disser 3 nós, se um nó desce, cada um dos outros nós teria ~ 16% mais carga em cada um deles, mesmo com um balanceamento de carga perfeito. Então você deve fatorar o provisionamento também.

Se você consegue lidar com muitas solicitações em um único nó, a terceira opção para mim parece que você está resolvendo um problema que não tem e provavelmente não terá quando uma opção muito mais simples for viável.