Balanceamento de carga do Apache com orçamento limitado?

Estou tentando entender o conceito de balanceamento de carga para garantir disponibilidade e redundância para manter os usuários felizes quando as coisas dão errado, em vez de balancear a carga com o objetivo de oferecer velocidade empolgante a milhões de usuários.

Estamos com um orçamento apertado e tentando nos ater às coisas em que há muito conhecimento disponível, portanto, rodar o Apache no Ubuntu VPS parece ser a estratégia até que algum mecanismo de pesquisa famoso nos adquira ( incluindo a ironia de sábado, observe ).

Pelo menos para mim, é uma selva completa de diferentes soluções disponíveis. Os apaches próprios mod_proxy e HAproxy são dois que encontramos em uma rápida pesquisa no google, mas com uma experiência nula de balanceamento de carga, não tenho idéia do que seria apropriado para a nossa situação ou do que cuidaríamos ao escolher uma solução para resolver nosso problema. preocupações de disponibilidade.

Qual é a melhor opção para nós? O que devemos fazer para obter alta disponibilidade enquanto permanecemos dentro de nossos orçamentos?

A solução que eu uso e pode ser facilmente implementada com o VPS é a seguinte:

• O DNS é alternado (sp?) Para 6 endereços IP válidos diferentes.
• Eu tenho 3 balanceadores de carga com configuração idêntica e usando corosync / pacemaker para distribuir os 6 endereços IP de maneira uniforme (para que cada máquina obtenha 2 endereços).
• Cada um dos balanceadores de carga possui uma configuração de nginx + verniz . O Nginx lida com o recebimento de conexões, com reescritas e com algumas veiculações estáticas, e devolvendo-o ao Varnish que faz o balanceamento de carga e o cache.

Este arco tem as seguintes vantagens, na minha opinião tendenciosa:

1. o corosync / pacemaker redistribuirá os endereços IP caso um dos LB falhe.
2. O nginx pode ser usado para servir SSL, certos tipos de arquivos diretamente do sistema de arquivos ou NFS sem usar o cache (vídeos grandes, arquivos de áudio ou grandes).
3. O Varnish é um balanceador de carga muito bom que suporta peso, verificação de integridade de back-end e faz um excelente trabalho como proxy reverso.
4. No caso de mais LBs serem necessários para lidar com o tráfego, basta adicionar mais máquinas ao cluster e os endereços IP serão reequilibrados entre todas as máquinas. Você pode fazer isso automaticamente (adicionando e removendo balanceadores de carga). É por isso que eu uso 6 ips para 3 máquinas, para deixar algum espaço para crescimento.

No seu caso, ter VPSs separados fisicamente é uma boa idéia, mas dificulta o compartilhamento de ip. O objetivo é ter um sistema redundante e resistente a falhas, e algumas configurações para o balanceamento de carga / HA acabam prejudicando a adição de um único ponto de falha (como um único balanceador de carga para receber todo o tráfego).

Também sei que você perguntou sobre o apache, mas naqueles dias temos ferramentas específicas mais adequadas ao trabalho (como nginx e verniz). Deixe o apache para executar os aplicativos no back-end e atenda-o usando outras ferramentas (não que o apache não possa executar um bom balanceamento de carga ou proxy reverso, é apenas uma questão de transferir diferentes partes do trabalho para mais serviços, para que cada parte possa se sair bem é compartilhar).

HAproxy é uma boa solução. A configuração é bastante simples.

Você precisará de outra instância do VPS para se sentar na frente de pelo menos outros 2 VPS. Portanto, para balanceamento de carga / failover, você precisa de no mínimo 3 VPS

Algumas coisas em que pensar também é:

1. Terminação SSL. Se você usar HTTPS: // essa conexão deve terminar no balanceador de carga, por trás do balanceador de carga, ele passará todo o tráfego por uma conexão não criptografada.

2. Armazenamento de arquivo. Se um usuário enviar uma imagem para onde ela vai? Apenas fica em uma máquina? Você precisa, de alguma maneira, compartilhar arquivos instantaneamente entre máquinas - você pode usar o serviço S3 da Amazon para armazenar todos os seus arquivos estáticos ou pode ter outro VPS que funcione como servidor de arquivos, mas eu recomendaria o S3 por ser redundante e incrivelmente barato.

3. informações da sessão. cada máquina em sua configuração do balanceador de carga precisa acessar as informações da sessão do usuário, porque você nunca sabe em qual máquina ele será atingido.

4. db - você tem um servidor db separado? se você tiver apenas uma máquina agora, como garantirá que sua nova máquina tenha acesso ao servidor db - e se for um servidor VPS db separado, quão redundante é isso. Não necessariamente faz sentido ter front-ends da Web de alta disponibilidade e um único ponto de falha com um servidor db, agora você precisa considerar a replicação db e a promoção de escravos também.

Então, eu estou no seu lugar, esse é o problema de um site que faz algumas centenas de acessos por dia para uma operação real. Fica complexo rapidamente. Espero que isso lhe dê um pouco de pensamento :)

Meu voto é para o Linux Virtual Server como o balanceador de carga. Isso torna o diretor do LVS um ponto único de falha e também um gargalo, mas

1. O gargalo não é, na minha experiência, um problema; a etapa de redirecionamento do LVS é da camada 3 e extremamente (computacionalmente) barata.
2. O ponto único de falha deve ser tratado com um segundo diretor, com os dois controlados pelo HA do Linux .

O custo pode ser reduzido mantendo o primeiro diretor na mesma máquina que o primeiro nó LVS e o segundo diretor na mesma máquina que o segundo nó LVS. O terceiro e os nós subsequentes são nós puros, sem implicações de LVS ou HA.

Isso também deixa você livre para executar qualquer software de servidor da web que desejar, pois o redirecionamento ocorre abaixo da camada do aplicativo.

E essa cadeia?

round robin dns> haproxy em ambas as máquinas> nginx para separar arquivos estáticos> apache

Possivelmente também use ucarp ou batimentos cardíacos para garantir que a haproxia sempre responda. O Stunnel ficaria na frente do haproxy se você também precisar de SSL

Você pode considerar o uso de um software de cluster adequado. RedHat's (ou CentOS) Cluster Suite ou Oracle's ClusterWare . Eles podem ser usados ​​para configurar clusters ativo-passivos e para reiniciar serviços e falhar entre nós quando houver problemas sérios. Isto é essencialmente o que você está procurando.

Todas essas soluções de cluster estão incluídas nas respectivas licenças do sistema operacional, portanto, você provavelmente terá um custo baixo. Eles exigem algum tipo de armazenamento compartilhado - uma montagem NFS ou disco físico acessado pelos dois nós com um sistema de arquivos em cluster. Um exemplo deste último seria discos SAN com acesso a vários hosts permitido, formatados com OCFS2 ou GFS . Eu acredito que você pode usar discos compartilhados do VMWare para isso.

O software de cluster é usado para definir 'serviços' que são executados em nós o tempo todo ou apenas quando esse nó está 'ativo'. Os nós se comunicam por meio de pulsações e também monitoram esses serviços. Eles podem reiniciá-los se perceberem falhas e reiniciar se não puderem ser corrigidos.

Você basicamente configuraria um único endereço IP 'compartilhado' para o qual o tráfego seria direcionado. Em seguida, o apache e quaisquer outros serviços necessários também podem ser definidos e apenas executados no servidor ativo. O disco compartilhado seria usado para todo o seu conteúdo da web, arquivos carregados e diretórios de configuração do apache. (com httpd.conf, etc)

Na minha experiência, isso funciona incrivelmente bem.

• Não há necessidade de rodízio de DNS ou qualquer outro balanceador de carga de ponto único de falha - tudo atinge um IP / FQDN.
• Os arquivos enviados pelo usuário são enviados para esse armazenamento compartilhado e, portanto, não se importam se a máquina falhar.
• Os desenvolvedores enviam conteúdo para esse único IP / FQDN com zero treinamento adicional e sempre está atualizado se houver falha.
• O administrador pode pegar a máquina offline, corrigir o problema, reinicializar etc. etc. Em seguida, faça o failover do nó ativo. Fazer uma atualização exige um tempo de inatividade mínimo.
• Esse nó agora desatualizado pode ser mantido sem patch por um tempo, tornando o failback um processo igualmente fácil. (Mais rápido que os instantâneos do VMWare)
• As alterações na configuração do Apache são compartilhadas, para que nada de estranho aconteça durante um failover, porque um administrador esqueceu de fazer alterações na caixa offline.

--Christopher Karel

O balanceamento ideal de carga pode ser muito caro e complicado. O balanceamento de carga básico deve garantir apenas que cada servidor esteja atendendo aproximadamente o mesmo número de ocorrências a qualquer momento.

O método mais simples de balanceamento de carga é fornecer vários registros A no DNS. Por padrão, o endereço IP será configurado em um método round robin. Isso fará com que os usuários sejam distribuídos de maneira relativamente uniforme entre os servidores. Isso funciona bem para sites sem estado. Um método um pouco mais complexo é necessário quando você tem um site com estado.

Para lidar com requisitos com estado, você pode usar redirecionamentos. Atribua a cada servidor da Web um endereço alternativo, como www1, www2, www3, etc. Redirecione a conexão www inicial para o endereço alternativo do host. Você pode acabar tendo problemas com os favoritos dessa maneira, mas eles devem estar uniformemente dispersos pelos servidores.

Como alternativa, o uso de um caminho diferente para indicar qual servidor está lidando com a sessão com estado permitiria as sessões de proxy que trocaram o host para o servidor original. Isso pode ser um problema quando a sessão de um servidor com falha chega ao servidor que assumiu o controle do servidor com falha. No entanto, exceto o software de clustering, o estado estará ausente de qualquer maneira. Devido ao cache do navegador, você pode não ter muitas sessões alterando os servidores.

O failover pode ser tratado configurando o servidor para assumir o endereço IP de um servidor com falha. Isso minimizará o tempo de inatividade se um servidor falhar. Sem o software de cluster, as sessões com estado serão perdidas se um servidor falhar.

Sem failover, os usuários sofrerão um atraso até que o navegador faça o failover para o próximo endereço IP.

O uso de serviços Restful em vez de sessões com estado deve eliminar os problemas de cluster no front-end. Problemas de cluster no lado do armazenamento ainda se aplicam.

Mesmo com os balanceadores de carga na frente dos servidores, você provavelmente terá DNS de rodízio na frente deles. Isso garantirá que todos os seus balanceadores de carga sejam utilizados. Eles adicionarão outra camada ao seu design, com complexidade adicional e outro ponto de falha. No entanto, eles podem fornecer alguns recursos de segurança.

A melhor solução dependerá dos requisitos relevantes.

A implementação de servidores de imagem para exibir conteúdo como imagens, arquivos CSS e outro conteúdo estático pode facilitar a carga nos servidores de aplicativos.

Eu geralmente uso um par de máquinas OpenBSD idênticas:

• Use o RelayD para o balanceamento de carga, monitoramento de servidor da web e manipulação de um servidor da web com falha
• Use o CARP para alta disponibilidade dos próprios balanceadores de carga.

O OpenBSD é leve, estável e bastante seguro - Perfeito para serviços de rede.

• http://www.openbsd.org - Site principal
• http://www.openbsd.org/faq/pf/carp.html - Documentação de Carp
• https://calomel.org/relayd.html - Um conjunto decente de informações sobre como usar o RelayD

Para começar, recomendo uma configuração de layer3. Evita a instalação do firewall de complicações (PF). Aqui está um exemplo de arquivo /etc/relayd.conf que mostra a configuração de um balanceador de carga de retransmissão simples com monitoramento dos servidores web de back-end:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Você deu ec2 com cloudfoundry ou talvez Elastic beanstalk ou apenas um simples e antigo escalonamento automático da AWS um pensamento. Eu tenho usado isso e ele escala muito bem e ser elástico pode aumentar / diminuir sem qualquer intervenção humana.

Dado que você diz que não tem experiência com o balanceamento de carga, eu sugeriria essas opções, pois elas exigem um mínimo de "fritura" do cérebro para começar a funcionar.

Pode ser uma melhor utilização do seu tempo.