Qual protocolo de compartilhamento de arquivos de rede tem o melhor desempenho e confiabilidade? [fechadas]

Temos uma configuração com alguns servidores Web com balanceamento de carga. Queremos ter algum tipo de armazenamento compartilhado em rede que todos os servidores da web possam acessar. Será usado como um local para armazenar arquivos enviados pelos usuários. Tudo está executando o Linux.

Devemos usar NFS, CIFS, SMB, fusível + sftp, fusível + ftp? Existem tantas opções para protocolos de compartilhamento de arquivos em rede, que é muito difícil escolher uma. Basicamente, queremos apenas montar permanentemente esse compartilhamento em várias máquinas. Os recursos de segurança são menos preocupantes, porque não serão acessíveis à rede a partir de qualquer outro lugar que não os servidores que o montam. Só queremos que ele funcione de forma confiável e rápida.

Qual devemos usar?

Eu voto no NFS.

O NFSv4.1 adicionou o recurso Parallel NFS pNFS, que possibilita o acesso a dados paralelos. Gostaria de saber que tipo de clientes estão usando o armazenamento, se apenas como o Unix, então eu iria para o NFS com base nos números de desempenho.

A resposta curta é usar o NFS. De acordo com este tiroteio e minha própria experiência, é mais rápido.

Mas você tem mais opções! Você deve considerar um cluster FS como o GFS, que é um sistema de arquivos que vários computadores podem acessar ao mesmo tempo. Basicamente, você compartilha um dispositivo de bloco via iSCSI, que é um sistema de arquivos GFS. Todos os clientes (iniciantes na linguagem iSCSI) podem ler e gravar nele. Redhat tem um whitepaper . Você também pode usar o FS OCFS do cluster da Oracle para gerenciar a mesma coisa.

O artigo redhat faz um bom trabalho listando os prós e contras de um cluster FS vs NFS. Basicamente, se você deseja muito espaço para escalar, o GFS provavelmente vale o esforço. Além disso, o exemplo GFS usa uma SAN Fibre Channel como exemplo, mas isso poderia ser facilmente uma RAID, DAS ou iSCSI SAN.

Por fim, verifique os Jumbo Frames e, se a integridade dos dados for crítica, use a soma de verificação CRC32 se você usar o iSCSI com Jumbo Frames.

Temos um cluster da Web de 2 servidores para carregamento de cargas. Tentamos os seguintes métodos para sincronizar o conteúdo entre os servidores:

• Unidades locais em cada servidor sincronizadas com o RSYNC a cada 10 minutos
• Um compartilhamento CIFS central (SAMBA) para ambos os servidores
• Um compartilhamento central do NFS para os dois servidores
• Uma unidade SAN compartilhada executando o OCFS2 montou os dois servidores

A solução RSYNC foi a mais simples, mas demorou 10 minutos para que as alterações aparecessem, e o RSYNC colocou tanta carga nos servidores que tivemos que limitá-la com script personalizado para pausar a cada segundo. Também estávamos limitados a gravar apenas na unidade de origem.

A unidade compartilhada de desempenho mais rápido foi a unidade em cluster do OCFS2 até ficar louca e travar o cluster. Não conseguimos manter a estabilidade com o OCFS2. Assim que mais de um servidor acessa os mesmos arquivos, a carga sobe pelo telhado e os servidores começam a reiniciar. Isso pode ser uma falha de treinamento da nossa parte.

O próximo melhor foi o NFS . Tem sido extremamente estável e tolerante a falhas. Esta é a nossa configuração atual.

O SMB (CIFS) teve alguns problemas de bloqueio. Em particular, as alterações nos arquivos no servidor SMB não estavam sendo vistas pelos servidores web. O SMB também tendia a travar ao fazer failover no servidor SMB

Nossa conclusão foi que o OCFS2 tem o maior potencial, mas requer MUITA análise antes de usá-lo na produção. Se você quiser algo direto e confiável, eu recomendaria um cluster de servidor NFS com Heartbeat para failover.

Eu sugiro que você POHMELFS - foi criado pelo programador russo Evgeniy Polyakov e é muito, muito rápido.

Em termos de confiabilidade e segurança, provavelmente o CIFS (também conhecido como Samba), mas o NFS "parece" muito mais leve e com uma configuração cuidadosa, é possível não expor completamente seus valiosos dados a todas as outras máquinas da rede ;-)

Nenhum insulto ao material do FUSE, mas ainda parece ... novo, se você entende o que quero dizer. Ainda não sei se confio nisto, mas isso pode ser apenas um fato antigo, mas às vezes é necessário justificar quando o assunto é dados corporativos valiosos.

Se você deseja montar permanentemente um compartilhamento em várias máquinas e pode brincar com algumas das estranhezas (principalmente problemas de UID / GID), use o NFS. Eu uso, e tenho por muitos anos.

NFS. É experimentado e verdadeiro, e você pode ter uma configuração sólida. O desempenho do GFS geralmente é péssimo, especialmente em sistemas de arquivos com um grande número de arquivos pequenos. Eu não usei o OCFS, mas geralmente desaprovo o conceito de sistema de arquivos em cluster. Depois, há o Luster, mas essa é outra lata de vermes ...

Eu recomendaria contra o NFS. Simplificando - tínhamos um farm de servidores da Web, com JBoss, Apache, Tomcat e Oracle, todos usando compartilhamentos NFS para arquivos de configuração comuns e registro.

Quando o compartilhamento do NFS desapareceu (admita-se uma ocorrência rara), tudo acabou em colapso (previsível, na verdade, e eu aconselhei os 'devlopers' contra esse atalho de tempo de configuração).

Parece haver um problema com a versão do NFS que estávamos usando, se o destino desaparecesse durante uma gravação, o cliente passaria para um loop de espera sem fim, aguardando o retorno do destino do NFS. Mesmo se a caixa NFS se reconectou - o loop ainda não terminou.

Estávamos usando uma mistura de RHEL 3,4,5. O armazenamento estava no RHEL4, os servidores estavam no RHEL5, a rede de armazenamento era uma LAN separada e não estava sendo executada em vlans.

Se houver um front end com carga equilibrada, verificar o armazenamento único - isso não prejudicaria o sistema?

Você considerou uma conexão iSCSI somente leitura ao seu armazenamento, com um script orientado a eventos para mover o arquivo carregado para o armazenamento via ftp / scp quando um arquivo é carregado?

A única vez que implementei um armazenamento centralizado bem-sucedido para várias cabeças de leitura foi em um storage array da EMC ... Todas as outras tentativas econômicas tiveram suas desvantagens.

Considerado GFS? O GFS é um sistema de arquivos em cluster e, na minha experiência, é bastante confiável. Pode ter mais de um diário, é muito bem dimensionado

Mas você precisaria instalar alguns serviços de cluster e o GFS não é exatamente conhecido por sua rapidez. Otoh, sempre foi rápido o suficiente para mim, mas sim.

Você não conseguiria considerar um FS distribuído como o GFS, e o iSCSI é um exagero.

Se você quiser simples, vá com o NFS. É simples e rápido, e com montagens suaves bastante robustas. Considere também desativar todo o lixo indesejado que o acompanha. Eu tenho desktops Linux que pegam todo o diretório pessoal e aplicativos do NFS, ele funciona bem.

Se você deseja uma velocidade ultrajante, vá com o Luster, que é significativamente mais fácil do que o GFS configurar e é muito parecido com o RAID NFS. Usamos o Luster para nossos clusters.

Talvez eu esteja um pouco atrasado. Usamos um armazenamento Dell MD3220 com porta dupla de cluster. Nossa unidade possui 2 controladores, caso um seja desativado, o segundo continuará funcionando até resolvermos esse problema. Como HDD, FAN, fonte de alimentação e controlador são todos Hotswap, substituímos as peças por dentro e por fora. No formato, usamos o NFS.

Se você já possui servidores da Web em todos os lugares e é bom em executá-los, por que não considerar o WebDAV?

Resposta simples +1 para NFS. Tenho compartilhamentos NFS que foram montados por anos seguidos sem problemas.

Se você está procurando uma super confiabilidade, considere lançar o DRBD no mix também para um sistema de arquivos NFS de failover automático distribuído.

A única outra opção (com a qual estou familiarizado) é o iSCSI, mas pode ser um problema na parte traseira configurar ...

Você tem várias opções, com diversos custos. SAN compartilhada com FC, iSCSI ou uma das adições mais recentes. Em qualquer caso, eles podem ser caros de configurar e você ainda precisa executar um sistema de arquivos com reconhecimento de cluster. Sistemas de arquivos em cluster são um mundo de dor. Para qualquer esperança de sucesso, você precisa de redes separadas de alta velocidade e baixa latência para comunicação e dados de cluster. Mesmo com isso, é provável que você tenha falhas que resultam em um nó sendo cercado e morto.

O único sistema de arquivos de cluster que me deparei que funciona sem problemas é o VMFS. Mas isso é tão especializado que seria inútil mesmo que estivesse disponível para uso geral.

NFS é provavelmente o caminho a percorrer para a sua configuração. Se você estiver preocupado com a resiliência, precisará obter uma caixa NFS em cluster adequada. Você pode fazer uma configuração de homebrew, mas atingirá o problema acima. A melhor aposta (se você tiver o dinheiro), são os arquivadores da NetApp em cluster. É uma opção cara, mas o cluster realmente funciona sem qualquer aborrecimento. Não é só isso, eles são muito rápidos.

Eu ecoaria o aviso que alguns deram contra o NFS - embora o NFS seja provavelmente a sua melhor aposta (por mais estranho que pareça).

Eu tinha um cliente NFS que precisei desconectar do AC para desligar porque o servidor NFS havia desaparecido e o cliente se recusou (no kernel) a desbloquear ou desligar porque o servidor NFS se fora.

Para fazer isso da maneira certa, eu insistiria no NFSv4, ficaria com as conexões TCP, usaria jumbo-frames e um cluster NFS. Você não pode permitir que seu servidor NFS desapareça.

GFS é um vodu seriamente preto. A quantidade de trabalho necessária para que um cluster simples de dois clientes funcione é impressionante em comparação com as alternativas. O OCFS2 é muito mais simples de implantar, mas é muito exigente quando se trata das versões do módulo do kernel envolvidas em todos os servidores conectados - e isso é apenas o começo.

A menos que você realmente precise do tipo de acesso de baixo nível oferecido por um sistema de arquivos em cluster, NFS ou CIFS é provavelmente tudo o que você precisa.

Em um grande farm de servidores, tivemos vários milhões de páginas html criadas pelo usuário. O NFS não funcionou tão bem, então acabamos colocando-os em uma tabela mysql. A sobrecarga em comparação com a travessia de uma árvore de diretórios era praticamente a mesma.

Eu usei o SFTP e funcionou bem para meus propósitos - o NFS foi meu primeiro recurso, mas o humor dos IDs de usuário / grupo me fez descartá-lo rapidamente.

Basta configurar a autenticação de chave pública e você estará definido em grande parte. Pode haver uma sobrecarga de CPU um pouco mais pesada para a criptografia SSH, mas no lado positivo, nunca tive problemas com corrupção de dados.

No entanto, o FTP pode se adequar aos seus objetivos, uma vez que é mais leve. Presumivelmente, você deseja que seus servidores da Web prestem serviços da Web, não o trabalho ssh.