“distribuindo” servidor ftp?

Question

Existe um servidor ftp que se comporta como um 'front-end de distribuição' para vários outros servidores? Então, quando eu carrego um arquivo, ele aceita o conteúdo, coloca-o em uma lista de outros servidores ftp e (o que é importante) não confirma o sucesso do upload até que ele esteja em todos os outros servidores?

Como alternativa, se ele pudesse esperar até que o rsync replicasse o arquivo enviado para todos os outros servidores antes de retornar com sucesso (ou, mais genericamente, espere que algum comando externo seja concluído antes de retornar o sucesso).

Antecedentes:

Temos um aplicativo que envia arquivos para um repositório (usando ftp ou sftp) e instrui imediatamente um dispositivo a fazer o download do arquivo (via http).

Precisamos que o repositório seja balanceado em carga / altamente disponível / resiliente. Nossos padrões de hospedagem corporativa não permitem armazenamento compartilhado.

O que fazemos com outros aplicativos relacionados é ter vários servidores ftp / http e fazer o upload manual de arquivos para todos eles antes de informar o aplicativo (e, em seguida, o dispositivo) para usá-los. Um balanceador de carga distribui solicitações de download. Isso funciona porque esses aplicativos não fazem o upload, em vez disso, nós os configuramos para usar o URL dos arquivos enviados anteriormente. O aplicativo problema não faz isso, ele faz o upload em si.

Poderíamos usar o rsync ou similar para replicar os arquivos carregados pelo aplicativo problemático para os vários servidores, mas o uso desses arquivos é imediato, portanto eles podem não ter sido replicados para os outros servidores quando uma solicitação para eles é recebida. O aplicativo não pode ser configurado para ter um atraso aqui.

Mas se o servidor ftp não retornasse até que o arquivo fosse replicado (pelo próprio servidor fazendo toda a replicação / upload para outros servidores, ou aguardando que um comando externo fosse concluído), então o aplicativo seria diga ao dispositivo para usar os arquivos até sabermos que eles estavam em todo lugar. E tudo funcionaria.

Algum apontador para servidores adequados? Outras idéias para resolver o problema? (alterar o aplicativo não é possível nos prazos, infelizmente)

    

Answer 1

Se você precisar usar o FTP, você pode escrever um script (talvez um programa em Python, ou em qualquer idioma que ofereça uma biblioteca FTP conveniente) que seu programa de upload execute imediatamente após completar o upload para o servidor 'master'. Esse script examinaria os sites FTP que deveriam ser replicados e não sairia até ver esses arquivos. No servidor mestre, você teria outro script que monitore o sistema de arquivos (como o inotify do Linux) e quando ele vir novos ou arquivos modificados, ele os envia para os servidores escravos.

Como alternativa, você pode usar um sistema de arquivos replicado. Isso move o problema de um conjunto de scripts homebrewed na camada de aplicativo para uma camada projetada para lidar com arquivos de replicação. Confira Tahoe-LAFS . Cito a frase relevante:

Users do rely on storage servers for availability. The ciphertext is erasure-coded into N shares distributed across at least H distinct storage servers (the default value for N is 10 and for H is 7) so that it can be recovered from any K of these servers (the default value of K is 3). Therefore only the failure of H-K+1 (with the defaults, 5) servers can make the data unavailable.

    

Answer 2

Eu acho que a resposta verdadeira é "não". Você está pedindo mais do que o protocolo FTP fornece. Se o cliente enviar um segmento TCP e o servidor informar "Recebi", o cliente enviará o próximo. Quando todos eles são recebidos, a transferência é feita. Não há nenhum gancho no protocolo existente para o servidor dizer "Por favor, espere enquanto eu brinco por aí".

Se você modificasse o servidor FTP para que ele diminuísse as TCP ACKs até que tivesse escrito os bytes em qualquer outro lugar, você poderia obter o que queria, mas eu me preocupo que você também poderia transformar suas transferências em um rastreamento ainda maior do que necessário, devido à janela deslizante do TCP.

Você está essencialmente pedindo um commit de duas fases para uma operação de transferência de arquivos dentro do FTP, e isso não existe.

Talvez você possa analisar um sistema de armazenamento virtualizado / replicado, como sugerido acima.