Como manter os servidores com balanceamento de carga sincronizados, mesmo com arquivos excluídos?

Question

Recentemente, configurei uma solução de balanceamento de carga para nossos sites. Nós hospedamos cerca de 200 sites, a maioria executado de nosso aplicativo personalizado, mas alguns estão executando blogs wordpress (em que os arquivos podem ser enviados / excluídos). A configuração é básica:

          |-------------------> Apache1
          |
 HAProxy -|
          |
          |-------------------> Apache2

Eu configurei Apache1 como 'mestre', para que a maioria das alterações feitas nele sejam rsyncdas para Apache2 a cada minuto usando o seguinte comando:

rsync -av --delete apache1:/var/www/html/ /var/www/html/

O problema é que, como mencionado anteriormente, em alguns casos, os arquivos são adicionados / removidos em Apache2 . A única solução que eu obtive até agora é ter Apache1 rsync todos os arquivos em certos diretórios (wp-content, por exemplo) para si mesmo (não deletar), então empurre tudo de volta para Apache2 .

Isso tem suas falhas, sendo as principais:

• Os dois servidores eventualmente obterão arquivos extras que foram excluídos em Apache2
• Ao adicionar mais servidores, o script rsync levará mais tempo para ser concluído.

Existe alguma maneira de manter 2 ou mais servidores web sincronizados, levando em conta que ambos os servidores podem ter arquivos adicionados, atualizados e excluídos?

    

Answer 1

Estou usando OCFS2 com DRBD .

Um recurso do DRBD /etc/drbd.d/r0.res :

resource r0 {
    syncer { rate 1000M; }
    net {
        allow-two-primaries;
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    startup { become-primary-on both; }

    on s1 {
        device      /dev/drbd1;
        disk        /dev/sdc;
        address     ip1:7789;
        meta-disk   internal;
    }
    on s2 {
        device      /dev/drbd1;
        disk        /dev/xvdb2;
        address     ip2:7789;
        meta-disk   internal;
    }
}

/dev/drbd1 está formatado como sistema de arquivos ocfs2:

/dev/drbd1   ocfs2   100660180   7427076  93233104   8% /data/webroot

Configuração para o OCFS2 sem marcapasso /etc/ocfs2/cluster.conf :

node:
    ip_port = 7777
    ip_address = ip1
    number = 0
    name = s1
    cluster = ocfs2

node:
    ip_port = 7777
    ip_address = ip2
    number = 1
    name = s2
    cluster = ocfs2

cluster:
    node_count = 2
    name = ocfs2

O status do DRBD pode ser visto com o utilitário drbd-overview :

# drbd-overview 
  1:r0  Connected Primary/Primary UpToDate/UpToDate C r---- /data/webroot ocfs2 96G 9.8G 87G 11% 

ou de /proc/drbd :

cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by [email protected], 2010-06-04 08:04:09

 1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
    ns:953133955 nr:42207234 dw:1185526354 dr:62396241 al:230084 bm:5853 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

    

Answer 2

Atualmente, estamos usando o rsync, mas não sou louco por isso.

Temos feito experiências com o fileconveyor , que não só sincroniza entre dois servidores, mas também podemos sincronizar com o S3, Cloudfiles ou outro armazenamento em nuvem. Isso obviamente nos fornecerá muito mais flexibilidade.

Não tenho configurações de configuração para compartilhar neste momento, mas estamos gostando do que vemos.

    

Answer 3

Eu não o usei em uma configuração de servidor, mas você pode tentar Unison . Ele lida com as alterações em ambos os lados e sincronizará automaticamente as coisas que não estão em conflito. Acredito que seja limitado a dois hosts, por isso não passaria da sua solução atual.

A única maneira de saber como escalar dois hosts anteriores seria configurar o NFS ou algum outro sistema de arquivos compartilhado / distribuído.

    

Answer 4

Outra opção seria criar uma réplica "autoritativa" do conteúdo, além dos servidores da Web, e garantir que todas as atualizações e alterações sejam feitas nessa réplica.

Em seguida, você implanta a partir desse servidor para qualquer número de servidores frontais em um cronograma definido.

Sim, é uma cópia extra do conteúdo, mas oferece alguns benefícios em potencial:

1) Controle de quando as atualizações são ativadas

2) Menos complexidade no manuseio da sincronização de várias direções entre qualquer número de servidores

3) A capacidade de fazer alterações e visualizá-las sem afetar sua produção de frente.

Outras opções são alguns tipos de armazenamento compartilhado espalhados em todo o hardware necessário para confiabilidade, desempenho e escalabilidade.

    

Answer 5

Eu tenho tido esse mesmo enigma e me deparei com algumas soluções, dependendo das especificidades do aplicativo em questão.

NFS: Embora o NFS, ou algum tipo de drive compartilhado, certamente funcionasse, no meu caso, eu queria evitá-lo porque cria um gargalo de um computador que pode derrubar todo o sistema. Uma parte strong do meu motivo para balanceamento de carga é a redundância, e o NFS tira isso da equação. Embora, se todas as outras opções falharem, essa pode ser a única que resta.

Arquivos do banco de dados: A maior parte do que tento fazer é criar o aplicativo para armazenar seus arquivos em um banco de dados. Dessa forma, não preciso me preocupar com nenhum dos servidores da Web em cluster que precisam gravar dados. Essa parece ser, de longe, a melhor solução, mas muitas vezes não é uma opção se você não estiver desenvolvendo o software.

Controle de DNS: Para alguns sites ou aplicativos que têm uma seção "admin" que apenas alguns usuários usam (como um blog wordpress), às vezes eu uso um dns separado apontando para o servidor mestre Certifique-se de que o administrador apenas crie gravações no servidor correto. Com algumas modificações, você pode redirecionar o wp-admin para usar o admin dns. A desvantagem aqui é que, enquanto a face frontal do blog permanece com carga balanceada e redundante, a seção administrativa depende de um sistema. Para a maioria dos blogueiros, isso provavelmente é ok.

Rsync de duas vias: A última opção, que tento evitar, é rsyncing de várias direções. A exclusão se torna o maior problema aqui, onde é difícil para o rsync saber se um arquivo é um novo arquivo (e, portanto, só aparece em um servidor), ou um arquivo excluído (e, portanto, só aparece em um servidor). Geralmente, se eu tiver que fazer rsyncing de multi-direção, eu direciono uma pasta específica onde os dados são armazenados e removê-lo do resto da estrutura usando um link simbólico, em seguida, rsync nos dois sentidos sem excluir. A maioria dos aplicativos nunca precisa excluir um arquivo, a menos que esteja criando arquivos temporários, que provavelmente devem ser armazenados fora da estrutura do seu site, de qualquer forma. Isso ainda pode funcionar com a exclusão de arquivos, mas eu ainda tentaria segmentar seus diretórios específicos que você armazena arquivos.

    

Answer 6

veja o LSYNCD present delete support

1. configure a autorização ssh sem senha link

2. configure o lsyncd (também presente nos repositórios do debian / ubuntu por padrão) link