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 está servindo um volume GlusterFS.
Nosso fluxo de arquivos funciona assim:
- OsarquivossãolidosporumnódeprocessamentodoLinux.
- Osarquivossãoprocessados.
- Osresultados(podemserpequenos,podemserbemgrandes)sãogravadosdevoltanovolumedoGlusterFSassimquesãofeitos.
- Osresultadospodemsergravadosemumbancodedadosoupodemincluirváriosarquivosdeváriostamanhos.
- OnódeprocessamentoselecionaoutrotrabalhoforadafilaeGOTO1.
OGlusteréótimo,poisofereceumvolumedistribuídoereplicaçãoinstantânea.Aresiliênciadedesastreséboa!Nósgostamosdisso.
Noentanto,comooWindowsnãotemumclientenativodoGlusterFS,precisamosdealgumamaneiraparaqueosnósdeprocessamentobaseadosnoWindowsinterajamcomoarmazenamentodearquivosdemaneirasimilarmenteresiliente.A documentação do GlusterFS declara que o Uma maneira de fornecer acesso ao Windows é configurar um servidor Samba sobre um volume GlusterFS montado. Isso levaria a um fluxo de arquivos como este:
Pareceumpontoúnicodefalhaparamim.
Umaopçãoé agrupar o Samba , mas isso parece ser baseado no código instável agora e, portanto, da corrida.
Estou procurando outro método.
Alguns detalhes importantes sobre os tipos de dados que utilizamos:
- Os tamanhos de arquivo originais podem variar de alguns KB a dezenas de GB.
- Os tamanhos de arquivo processados podem variar de alguns KB a GB ou dois.
- Certos processos, como cavar em um arquivo como .zip ou .tar, podem causar muitas gravações adicionais, pois os arquivos contidos são importados para o armazenamento de arquivos.
- As contagens de arquivos podem chegar aos 10 milhões.
Esta carga de trabalho não funciona com a configuração do Hadoop "tamanho da unidade de trabalho estática". Da mesma forma, avaliamos os armazenamentos de objeto no estilo S3, mas descobrimos que eles estão faltando.
Nosso aplicativo é personalizado escrito em Ruby, e nós 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 que possuem o volume do GlusterFS montado. Já que tudo o que estamos fazendo com o Gluster é essencialmente operações GET / PUT, que parecem facilmente transferíveis para um método de transferência de arquivos baseado em HTTP. Coloque-os atrás de um par de balanceamento de carga e os nós do Windows podem enviar HTTP para o conteúdo do seu pequeno coração azul.
O que eu não sei é como a coerência do GlusterFS seria mantida . A camada HTTP-proxy introduz latência suficiente entre quando o nó de processamento relata que é feito com a gravação e quando é realmente visível no volume do GlusterFS, que eu estou preocupado com o fato de os estágios de processamento posteriores tentarem pegar o arquivo não encontre. Tenho certeza de que usar a opção direct-io-mode=enable mount-will ajudará, mas não tenho certeza se isso é suficiente . O que mais devo fazer para melhorar a coerência?
Ou eu deveria buscar outro método completamente?
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:
QuandoeuomontodeumsistemaServer2008R2comoClienteNFSinstalado,receboumalistagemdediretórioscomoesta:
Claramente, o Unicode não está sendo preservado. Então o NFS não vai funcionar para mim.