A maneira mais rápida de replicar arquivos pequenos em 4 máquinas?

Question

Eu tenho 4 servidores, todos em uma rede local segura.

Cada servidor executa script.php (a cada minuto).

script.php lê de um diretório local chamado / arc, faz um teste de arquivo e grava um novo arquivo de volta em / arc.

(Estes são pequenos arquivos de texto de 2kb, sendo criados a uma taxa de aproximadamente 20 por segundo em cada servidor).

Gostaria que todos os 4 / dir dirs fossem mesclados em um.

Por exemplo, quando o script.php é executado no server1, eu gostaria que ele soubesse sobre todos os arquivos em TODOS os diretórios / arc, não apenas aquele na máquina local. E quando server1 grava o arquivo em seu diretório local / arc, os servidores2-4 devem agora vê-lo em seus diretórios / arc.

Além disso, esses arquivos são perecíveis e todos limpos a cada 10 minutos.

ATUALIZAÇÃO: Atualmente, vou tentar o NFS montando todos os diretórios. Os dirs de arco também são tmpfs, então deve ser bem rápido. A menos que alguém pense que há um caminho mais rápido, vou tentar isso:

1) em cada máquina, eu vou montar o NFS / arc dirs para todas as outras máquinas. Então 1 local e 3 NFS.

2) Quando script.php é executado em qualquer uma das máquinas, haverá vários comandos "cp" para cada um dos diretórios de arco. Isso garantirá que cada máquina tenha sempre a última saída armazenada em cache. (É 20 cópias por segundo X 4 locais sobre NFS um gargalo? Espero que não.)

3) já que a saída em cache é copiada para todas as máquinas locais, isso significa que o script.php nunca precisa ler um arquivo sobre a montagem NFS. Uma leitura local do cache de arco leva 0,37 segundos. Quanto tempo levaria para ler o arquivo pelo NFS? mais do que isso? Isso é o que aconteceria se eu copiasse para um único local central.

Então, estou negociando vários comandos de cópia para leituras. Mas eu acho que é um bom negócio, já que o ponto é que as requisições script.php sejam executadas o mais rápido possível, o que significa minimizar o tempo que leva para ler um arquivo em cache.

    

Answer 1

O rsync foi projetado para sincronização unidirecional entre 1 origem e 1 destino. Não é adequado para sincronização bidireccional fiável entre 4 anfitriões.

Uma ferramenta de sincronização como SyncThing ou BitTorrent Sync pode funcionar, embora a taxa de alteração de seus arquivos (20 / segundo) possa ser muito rápida para esse tipo de ferramenta.

Minha sugestão seria designar um dos servidores como o "mestre" (alternativamente, configurar uma 5ª máquina ou NAS) e a montagem de rede (por exemplo, NFS) /arc de todas as outras máquinas para esse mestre. em cada máquina está realmente trabalhando no mesmo diretório.

Outra opção, se você não puder aceitar a confiança na única máquina que hospeda o diretório, é usar algo como o DRBD para criar um dispositivo de bloco distribuído que possa replicar no nível de bloco pela rede.

    

Answer 2

Vinte 2k arquivos por segundo ... em 4 máquinas. Isso soa como o que você realmente quer é um servidor de banco de dados.

MySQL, Postgres, SQLServer podem lidar com essa taxa de atualização facilmente.

Se cada máquina precisar copiar para os outros 3, você precisará de n-1 cópias para cada arquivo. Então, 4 máquinas gerando 20 arquivos por segundo são 120 cópias por segundo. Se você precisar de uma quinta máquina, o número dobra. A sexta máquina dobraria novamente. Você não pode pensar que você vai crescer no futuro, mas você vai.

Se você estivesse indo para scp cada arquivo depois que ele fosse criado, seriam 3 scp de comandos toda vez que script.php fosse executado. Considerando quanto tempo o scp leva para autenticar a sessão, isso pode levar de 1 a 2 segundos por execução. Isso é 60 scp s por segundo.

Em vez disso, você pode simplesmente criar os arquivos e ter outro processo que execute rsync em um loop. Cada vez que é executado, o rsync seleciona novos arquivos. O tempo entre a criação do arquivo e quando ele chega aos outros servidores seria de segundos ou minutos. Tudo bem se você quiser fazer backups dos dados e resistir a alguma perda de dados no caso de uma indisponibilidade não planejada. Não é suficiente se você deseja que os outros servidores tenham as informações instantaneamente.

Por outro lado, se você usar um banco de dados, todas as três máquinas teriam conexões em cache para o banco de dados e as atualizações seriam muito rápidas. Os dados estariam disponíveis instantaneamente.

    

Answer 3

Se você tem um bom controle sobre seus servidores, acho que construir um servidor de mensagens como o RabbitMQ pode ser o caminho a percorrer. Em vez de criar arquivos, você coloca as mensagens em uma fila e seu script assina esses eventos de fila, processa e, em seguida, coloca os resultados de volta na fila para serem capturados pelos outros servidores.

Eu não acho que o rsync é o caminho a percorrer. O modelo de lsync pode ser interessante, pois ele observa os eventos do kernel em busca de mudanças, mas é um arranjo mestre / escravo, e não tenho certeza de que funcionaria para sua situação.

Você pode fazer melhor com um sistema de arquivos de rede compartilhada de algum tipo, como sugere o @Andy. (NFS, GFS, Gluster) vêm à mente, e há muitos mais. Tenha cuidado com os problemas de bloqueio e com o que acontece se a conexão com um servidor de arquivos for interrompida.

@ A resposta do TomOnTime provavelmente está correta, pois ele diz que um sistema baseado em arquivos é provavelmente a escolha errada. O principal mérito de uma solução baseada em SQL é que você provavelmente já tem o servidor de banco de dados configurado. Existem mais armadilhas do que você imagina para tornar esse tipo de coisa eficiente em SQL.

EDITAR:

Se, como você diz, este é um sistema de cache, você também pode querer olhar para memcached, redis ou mesmo verniz.

Seus aplicativos sabem antecipadamente o que esperam estar no cache sem precisar pedir uma lista?