Load Balancing e Protegendo o Servidor para o Protocolo TCP Customizado no EC2

Question

Desenvolvemos um protocolo TCP personalizado para fazer a interface com os clientes do iPhone por meio de soquetes e estou procurando o layout do nosso servidor de produção. Nós estaremos rodando nosso servidor escrito em erlang em uma única instância debian EC2, bem como provavelmente rodando o mysql em uma instância separada (eu estou supondo que isso seria recomendado?).

Estou procurando proteger e carregar as conexões de balanceamento com o nosso servidor TCP e estava analisando o ELB, o HAProxy, o LVM e o nginx da EC2. O nginx parece ser apenas http, e desde que estamos usando um protocolo personalizado, eu estava procurando por alguma entrada no design de tal sistema. Também estou me perguntando quais serão as implicações do bloqueio de roteador / firewall nos ISPs das redes de celular.

Minha idéia atual de design seria colocar tudo na porta 80 para o ELB e rotear isso para o servidor TCP. Eu não estou completamente vendido no ELB, então eu estava pensando:

1. Quais outras opções estão disponíveis para o proxy reverso não http,
2. O SSL pode ser executado no proxy reverso ou isso também precisa ser executado no servidor TCP
3. Quaisquer recomendações para soluções alternativas de firewall / roteador para redes de celular que não sejam a porta 80.

Answer 1

Bem, nem haproxy nem ELB são somente HTTP; ambos farão proxy de conexão TCP arbitrário. Mas por que você possivelmente quer um proxy? Basta executar um balanceador de carga L3; é muito mais limpo. Pode não funcionar na AWS, mas eu chamaria isso de limitação da AWS.

    

Answer 2

1. O HAProxy e o ELB parecem atender bem às suas necessidades.
2. A adição de stunnel à sua solução HAProxy faria isso, assim como o ELB (embora não esteja completamente claro se o descarregamento de SSL funciona em conexões TCP brutas).
3. Depende das redes de celular com as quais você precisa trabalhar, mas eu diria evitar porta 80 - algumas delas tentam fazer proxy dessas solicitações. Se houver alguma coisa, execute o 443 com seu fluxo SSL - que deve funcionar para operadoras com interferência de tráfego decentemente limitada.