Atualmente, tenho uma configuração de sistema em que um cliente envia arquivos por FTP para mim, o que aciona o inotify (por meio de notificações do kernel do Linux) para acionar uma análise para executar ações sobre esses arquivos. O problema que estou enfrentando é que o analisador está atingindo a capacidade de E/S em uma instância do EC2 e gostaria de adicionar nós adicionais para trabalhar na divisão da carga do arquivo. Infelizmente, o cliente só pode fazer upload via FTP. Isso me deixa pensando como posso ter outra instância, que não compartilhe o volume EBS no qual os arquivos estão sendo descartados, trabalhando nesse arquivo.
Existe atualmente uma solução AWS que manterá meu cliente que usa FTP intacto (além de talvez uma alteração de IP, o que é bom) e permitirá que várias instâncias do EC2 acessem o sistema de arquivos?
Responder1
Claro...
Você pode anexar e distribuir vários volumes de qualquer tipo para aumentar o desempenho de E/S disponível para seus aplicativos do Amazon EC2.
Isso é uma coisa que usei, RAID-10 de volumes EBS, mas... mas presumo que você tenha pensado nisso.
Pensei em sugerir dimensionar seu servidor FTP usando algo comoHAProxye/ou o redirutilitário que acompanha o Ubuntu (que pode reescrever pacotes FTP para corrigir alguns dos absurdos inerentes a esse protocolo), mas a estranha natureza de múltiplas conexões do FTP pode tornar isso uma proposta complicada, e pode não ser realmente o que você querer.
Então, e quanto ao s3fs?
Antes de sugerir isso, pesquisei no Google e encontrei coisas comoesta postagem, o que sugeria que poderia não funcionar, mas então percebi que o OP nesse caso parecia ter uma falta significativa de compreensão de como o S3 e os sistemas de arquivos realmente funcionam, e esperava que o inotify percebesse que as coisas haviam mudado remotamente no S3 por meio de causas externas (não tendo atravessado o sistema de arquivos local), o que obviamente não faz sentido.
Mas escrevi um código para testá-lo e o s3fs realmente parece interagir corretamente com o inotify. Você poderia montar um bucket, em vez de um volume EBS, a partir do seu servidor FTP, para que quando seu cliente fizer upload dos arquivos via FTP, eles caiam diretamente no bucket - e o inotify captura esse evento como faria com um sistema de arquivos tradicional, em ponto em que você poderia usar o SQS ou qualquer outro mecanismo para alertar as máquinas dos trabalhadores de que havia tarefas a serem realizadas. Eles poderiam então buscar e processar os arquivos de forma independente, com a E/S sendo limitada apenas pela largura de banda disponível entre cada uma dessas máquinas e a infraestrutura S3.
Há uma série de coisas para as quais o s3fs é totalmente inapropriado, como um servidor que fornece o mesmo conteúdo estático repetidamente - o s3fs não é uma boa solução para isso, devido ao grande número de solicitações redundantes que seriam prováveis. ocorrer e/ou a necessidade de s3fs armazenar coisas em cache localmente (o que pode, mas não faz sentido - se você precisar disso, basta armazenar os arquivos localmente) e a latência envolvida em buscá-los individualmente sob demanda ao tentar fornecer um site responsivo pode ser problemático... mas quando cada arquivo énãosendo acessado repetidamente, tive resultados positivos com ele.
Recentemente, fiz um pequeno projeto para um cliente em que eles queriam armazenar ativos para download público no S3, mas talvez tivessem uma restrição semelhante à sua: elesrealmentequeria poder fazer upload dos arquivos usando FTP. Combinar o proftpd com um bucket montado em uma instância EC2 via s3fs forneceu a eles um "gateway" fácil para o S3 que era compatível com seus sistemas existentes ... então eu sei que funciona, e tendo testado a mesma configuração com inotify apenas agora posso dizer que os dois parecem ter a interação esperada.
Usando o S3 de dentro do EC2 assim, o preço de armazenamento é essencialmente equivalente ao EBS e você não pagaria pela largura de banda se o bucket estivesse na mesma região do seu endpoint - você pagaria apenas por cada PUT(US$ 5 por milhão de solicitações) e GET(US$ 4 por milhão de solicitações) (minha interpretação das tabelas de preços; tenho milhões de objetos armazenados no S3 e nunca tive uma surpresa de faturamento, mas não acredite apenas na minha palavra). Possivelmente não haverá exatamente uma correlação 1:1 de arquivos e solicitações, uma vez que o s3fs precisa fazer algumas tarefas em segundo plano para armazenar o modo e a propriedade do arquivo no S3 como parte de sua emulação de pseudo-sistema de arquivos, e precisa iterar objetos para gerar listagens de diretórios, então YMMV nas solicitações... mas parece uma solução viável.
Contanto que você entenda isso com o entendimento adequado da incompatibilidade de impedância entre o que o S3 faz e o que um sistema de arquivos tradicional faz, não vejo por que isso não o dimensionaria tão infinitamente quanto necessário.
Claro que minha parte favorita do s3fs é que você nunca fica sem espaço. :)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
Responder2
Se o seu cliente conseguir acessar seu FTP por DNS, em vez de IP, parece que a solução mais fácil seria colocar um ELB na frente de várias instâncias de FTP, para que você possa escalar horizontalmente.
Então, se você precisar que todos os arquivos FTP acabem em um só lugar quando terminar o processamento, você pode usar o S3 ou qualquer outra solução para armazenar persistentemente os arquivos processados em um único local.
Responder3
Você não pode ter um script para transferir esses arquivos para o outro nó quando o inotify descobrir que há novos arquivos sendo enviados por FTP para o seu nó principal?