Balanceamento de carga do Apache em um orçamento?

Question

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 para oferecer uma velocidade espantosa para milhões de usuários.

Estamos em um orçamento e tentando manter as coisas onde há muito conhecimento disponível, então rodar o Apache no Ubuntu VPS parece ser a estratégia até que algum motor de busca famoso nos adquira ( ironia de sábado incluída, por favor note ).

Pelo menos para mim, é uma selva completa de diferentes soluções disponíveis. Apaches possui mod_proxy & HAproxy são dois que encontramos por meio de uma rápida pesquisa no google, mas tendo zero experiência de balanceamento de carga, não tenho idéia do que seria apropriado para a nossa situação ou do que cuidaríamos enquanto escolhemos uma solução para resolver nossas preocupações de disponibilidade. / p>

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

    

Answer 1

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

• O DNS é arredondado (sp?) para 6 endereços IP válidos diferentes.
• Eu tenho 3 balanceadores de carga com configuração idêntica e usando o corosync / pacemaker para distribuir uniformemente os 6 endereços IP (para que cada máquina receba 2 endereços).
• Cada um dos balanceadores de carga tem um nginx + verniz configuração. O Nginx lida com o recebimento das conexões e reescreve e alguma veiculação estática, e passa de volta para o Varnish que faz o balanceamento de carga e o armazenamento em cache.

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

O
1. corosync / pacemaker redistribuirá os endereços IP caso um dos LB falhe.
2. nginx pode ser usado para servir SSL, certos tipos de arquivos diretamente do sistema de arquivos ou NFS sem usar o cache (grandes vídeos, arquivos de áudio ou grandes).
3. O verniz é 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 LB ser necessário 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 até mesmo fazer isso automaticamente (adicionando e removendo balanceadores de carga). É por isso que uso 6 ips para 3 máquinas, para deixar algum espaço para crescimento.

No seu caso, ter VPSs fisicamente separados é uma boa ideia, mas torna o compartilhamento de ip mais difícil. O objetivo é ter um sistema redundante e resistente a falhas, e algumas configurações para balanceamento de carga / HA acabam adicionando um único ponto de falha (como um único balanceador de carga para receber todo o tráfego).

Eu também sei que você perguntou sobre o apache, mas atualmente temos ferramentas específicas mais adequadas ao trabalho (como nginx e verniz). Deixe o apache rodar os aplicativos no backend e sirva-o usando outras ferramentas (não que o apache não possa fazer 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 é share).

    

Answer 2

O haproxi é uma boa solução. A configuração é bastante direta.

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

Algumas coisas para pensar também são:

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

2. Armazenamento de arquivos. Se um usuário envia uma imagem para onde ela vai? Isso apenas fica em uma máquina? Você precisa de algum modo compartilhar arquivos instantaneamente entre máquinas - você poderia usar o serviço S3 da Amazon para armazenar todos os seus arquivos estáticos, ou você poderia ter outro VPS que atuaria como um servidor de arquivos, mas eu recomendaria o S3 porque é redundante e insanamente barato.

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

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

Então, eu estive no seu lugar, esse é o problema de um site que faz algumas centenas de acessos por dia para uma operação real. Fica complexo rápido. Espero que tenha lhe dado alguma coisa para pensar:)

    

Answer 3

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

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

O custo pode ser reduzido fazendo o primeiro diretor estar na mesma máquina que o primeiro nó LVS e o segundo diretor na mesma máquina que o segundo nó LVS. Terceiros e nós subseqüentes 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, já que o redirecionamento ocorre abaixo da camada do aplicativo.

    

Answer 4

Que tal esta cadeia?

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

Possivelmente também use o ucarp ou o heartbeat para garantir que o haproxy sempre responda. Stunnel se sentaria na frente do haproxy se você precisar de SSL também

    

Answer 5

Você pode querer considerar o uso de software de cluster apropriado. O Cluster Suite da RedHat (ou do CentOS), ou o ClusterWare . Eles podem ser usados para configurar clusters ativo-passivo e podem ser usados para reiniciar serviços e falhar entre nós quando houver problemas sérios. Isso é basicamente o que você está procurando.

Todas essas soluções de cluster estão incluídas nas respectivas licenças de SO, então você provavelmente tem um bom custo. Eles exigem algum tipo de armazenamento compartilhado - seja uma montagem NFS ou um disco físico acessado por ambos os nós com um sistema de arquivos em cluster. Um exemplo deste último seria discos SAN, com múltiplos acessos de host permitidos, formatados com OCFS2 ou < href="http://www.redhat.com/gfs/"> GFS . Eu acredito que você pode usar VMWare discos compartilhados para este .

O software de cluster é usado para definir 'serviços' que são executados em nós o tempo todo, ou somente quando esse nó está 'ativo'. Os nós se comunicam por meio de heartbeats e também monitoram esses serviços. Eles podem reiniciá-los se perceberem falhas e reinicializarem 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 executados somente no servidor ativo. O disco compartilhado seria usado para todo o seu conteúdo da web, quaisquer arquivos enviados e seus diretórios de configuração do apache. (com httpd.conf, etc)

Na minha experiência, isso funciona incrivelmente bem.

• Não há necessidade de round robin de DNS ou qualquer outro balanceador de carga de ponto único de falha - tudo atinge um IP / FQDN.
• Os arquivos enviados pelo usuário vão para o armazenamento compartilhado e, portanto, não se importam se a sua máquina apresentar failover.
• Os desenvolvedores enviam conteúdo para esse único IP / FQDN com nenhum treinamento adicional e está sempre atualizado se houver falha.
• O administrador pode pegar a máquina off-line, consertá-la, reinicializá-la etc. Em seguida, falha o nó ativo. Fazer uma atualização leva um mínimo de tempo de inatividade.
• Esse nó agora desatualizado pode ser mantido sem correção por um tempo, tornando o failback um processo igualmente fácil. (Mais rápido que os instantâneos 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 off-line.

- Christopher Karel

    

Answer 6

O balanceamento otimizado de carga pode ser muito caro e complicado. O balanceamento de carga básico deve apenas garantir que cada servidor esteja atendendo aproximadamente o mesmo número de acessos 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 resultará na distribuição relativamente uniforme dos usuários pelos 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 informações de estado, você pode usar redirecionamentos. Dê a cada servidor 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 com problemas de favoritos dessa maneira, mas eles devem ser uniformemente dispersos pelos servidores.

Como alternativa, usar um caminho diferente para indicar qual servidor está manipulando a sessão com preservação de estado permitiria sessões de proxy que mudaram de 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 servidor com falha. No entanto, bloqueando o software de cluster, 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 pela configuração do 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 armazenamento em cluster, as sessões com informações de estado serão perdidas se um servidor falhar.

Sem usuários de failover, haverá um atraso até que o navegador passe para o próximo endereço IP.

O uso de serviços Repousários, em vez de sessões com informações de estado, deve eliminar os problemas de cluster no front-end. Os problemas de cluster no lado do armazenamento ainda se aplicam.

Mesmo com balanceadores de carga na frente dos servidores, você provavelmente terá um DNS round-robin na frente deles. Isso garantirá que todos os seus balanceadores de carga sejam utilizados. Eles adicionarão outra camada ao projeto, 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 outros conteúdos estáticos pode facilitar a carga nos servidores de aplicativos.

    

Answer 7

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

• Use o RelayD para o balanceamento de carga, o monitoramento do servidor da Web e o tratamento 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.

• link - Site principal
• link - documentação da carpa
• link - Um conjunto decente de informações sobre o Howto no RelayD

Para começar, recomendo uma configuração de layer3. Evita a configuração do firewall (PF) de complicações. Aqui está um arquivo /etc/relayd.conf de exemplo que mostra a configuração de um balanceador de carga de retransmissão simples com o monitoramento dos servidores da 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

}

    

Answer 8

Já deu ec2 com cloudfoundry ou talvez Pé de feijão elástico ou apenas um escalonamento automático AWS simples e um pensamento. Eu tenho usado isso e ele escala muito bem e ser elástico pode aumentar / diminuir sem qualquer intervenção humana.

Se você disser que não tem experiência com balanceamento de carga, sugiro essas opções, pois elas exigem uma "fritura" mínima do cérebro para funcionar.

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