Temos um cluster GlusterFS que usamos para nossa função de processamento. Queremos integrar o Windows a ele, mas estamos tendo problemas para descobrir como evitar o ponto único de falha que é um servidor Samba que atende a um volume GlusterFS.
Nosso fluxo de arquivos funciona assim:
- Os arquivos são lidos por um nó de processamento do Linux.
- Os arquivos são processados.
- Os resultados (podem ser pequenos, podem ser bastante grandes) são gravados de volta no volume GlusterFS à medida que são feitos.
- Os resultados podem ser gravados em um banco de dados ou podem incluir vários arquivos de vários tamanhos.
- O nó de processamento seleciona outro trabalho da fila e GOTO 1.
O Gluster é ótimo, pois fornece um volume distribuído e replicação instantânea. A resiliência a desastres é agradável! Nós gostamos.
No entanto, como o Windows não possui um cliente GlusterFS nativo, precisamos de alguma maneira de nossos nós de processamento baseados no Windows interagirem com o armazenamento de arquivos de maneira semelhante resiliente. A documentação do GlusterFS afirma que a maneira de fornecer acesso ao Windows é configurar um servidor Samba em cima de um volume GlusterFS montado. Isso levaria a um fluxo de arquivos como este:
Isso me parece um único ponto de falha.
Uma opção é agrupar o Samba , mas isso parece estar baseado no código instável agora e, portanto, fora de execução.
Então, eu estou procurando outro método.
Alguns detalhes importantes sobre os tipos de dados que lançamos:
- Os tamanhos de arquivo originais podem variar de alguns KB a dezenas de GB.
- O tamanho dos arquivos processados pode variar de alguns KB a um GB ou dois.
- Certos processos, como cavar em um arquivo morto como .zip ou .tar, podem causar muitas gravações adicionais à medida que os arquivos contidos são importados para o armazenamento de arquivos.
- A contagem de arquivos pode chegar aos 10 milhões.
Essa carga de trabalho não funciona com uma configuração do Hadoop "tamanho estático da unidade de trabalho". Da mesma forma, avaliamos os armazenamentos de objetos no estilo S3, mas os encontramos em falta.
Nosso aplicativo é escrito em Ruby e temos um ambiente Cygwin nos nós do Windows. Isso pode nos ajudar.
Uma opção que estou considerando é um serviço HTTP simples em um cluster de servidores com o volume GlusterFS montado. Como tudo o que estamos fazendo com o Gluster são essencialmente operações GET / PUT, isso parece facilmente transferível para um método de transferência de arquivos baseado em HTTP. Coloque-os atrás de um par de balanceador de carga e os nós do Windows podem colocar HTTP no conteúdo do seu pequeno coração azul.
O que não sei é como a coerência do GlusterFS seria mantida . A camada de proxy HTTP introduz latência suficiente entre quando o nó de processamento relata que é feito com a gravação e quando é realmente visível no volume GlusterFS, que estou preocupado com os estágios de processamento posteriores que tentam pegar o arquivo. encontre. Tenho certeza de que usar a direct-io-mode=enableopção de montagem ajudará, mas não tenho certeza se isso é suficiente . O que mais devo fazer para melhorar a coerência?
Ou devo seguir outro método inteiramente?
Como Tom apontou abaixo, o NFS é outra opção. Então eu fiz um teste. Como os arquivos mencionados acima têm nomes fornecidos pelo cliente que precisamos manter e podem vir em qualquer idioma, precisamos preservar os nomes dos arquivos. Então, eu criei um diretório com esses arquivos:
Quando o monto a partir de um sistema Server 2008 R2 com o NFS Client instalado, recebo uma lista de diretórios como esta:
Claramente, o Unicode não está sendo preservado. Então o NFS não vai funcionar para mim.
ctdbestável e pronta para uso em produção e a primeira frase no link que você deu inviabiliza a segunda porque se nunca foi atualizada. Eu estava planejando estabelecer isso, mas antes de chegar a esse ponto, mudei de emprego para um ambiente quase sem janelas.