Temos uma configuração com alguns servidores da Web com balanceamento de carga. Queremos ter algum tipo de armazenamento compartilhado na rede que todos os servidores da web possam acessar. Ele será usado como um local para armazenar arquivos enviados por usuários. Tudo está rodando o Linux.
Devemos usar NFS, CIFS, SMB, fusível + sftp, fusível + ftp? Há tantas opções por aí para protocolos de compartilhamento de arquivos de rede, é muito difícil escolher um. 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 pela rede de nenhum outro lugar além dos servidores que o montam. Nós apenas queremos que funcione de forma confiável e rápida.
Qual deles devemos usar?
A resposta curta é usar o NFS. De acordo com esse 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 de uma só vez. Basicamente, você compartilha um dispositivo de bloco via iSCSI, que é um sistema de arquivos GFS. Todos os clientes (iniciadores no jargão do iSCSI) podem ler e gravar nele. Redhat tem um whitepaper . Você também pode usar o cluster do oracle FS OCFS para gerenciar a mesma coisa.
O redhat paper faz um bom trabalho listando os prós e contras de um cluster FS vs NFS. Basicamente, se você quer muito espaço para escalar, o GFS provavelmente vale o esforço. Além disso, o exemplo de GFS usa uma SAN de Fibre Channel como um exemplo, mas isso pode facilmente ser um RAID, DAS ou iSCSI SAN.
Por fim, certifique-se de examinar 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 dois clusters de carga do servidor. Tentamos os seguintes métodos para sincronizar o conteúdo entre os servidores:
A solução RSYNC foi a mais simples, mas demorou 10 minutos para as alterações serem exibidas e o RSYNC colocou tanta carga nos servidores que precisávamos reduzi-lo com o script personalizado para pausá-lo a cada segundo. Também nos limitávamos a gravar apenas na unidade de origem.
A unidade compartilhada de desempenho mais rápido foi a unidade em cluster OCFS2 até enlouquecer e travar o cluster. Não conseguimos manter a estabilidade com o OCFS2. Assim que mais de um servidor acessa os mesmos arquivos, o carregamento sobe pelo telhado e os servidores iniciam a reinicialização. Isso pode ser uma falha de treinamento da nossa parte.
O segundo 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 da web. SMB também tendeu a travar ao falhar no servidor SMB
Nossa conclusão foi que o OCFS2 tem o maior potencial, mas requer MUITAS análises 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 - é 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 qualquer outra máquina na rede ;-)
Nenhum insulto ao material do FUSE, mas ainda parece ... novo, se você sabe o que quero dizer. Eu não sei se confio ainda, mas isso poderia ser apenas eu sendo um velho fogy, mas o velho fogeyism é algumas vezes garantido quando se trata de dados empresariais valiosos.
Se você quiser montar permanentemente um compartilhamento em várias máquinas, e você pode jogar junto com algumas das estranhezas (principalmente problemas de UID / GID), então use o NFS. Eu uso isto e tenho por muitos anos.
NFS. É tentado e verdadeiro, e você pode ter uma configuração sólida. O desempenho do GFS é geralmente horrível, especialmente em sistemas de arquivos com grande número de arquivos pequenos. Eu não usei o OCFS, mas eu geralmente desaprovo o conceito de sistema de arquivos do cluster. Então há o Lustre, mas essa é outra lata de minhocas ...
Eu aconselharia contra o NFS. Simplificando - nós tínhamos um farm de servidores web, com JBoss, Apache, Tomcat e Oracle, todos usando compartilhamentos NFS para arquivos de configuração comuns e registro.
Quando o compartilhamento NFS desapareceu (reconhecidamente uma ocorrência rara) a coisa toda acabou de cair (previsível na verdade, e eu avisei 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 cairia em um loop de espera sem fim, aguardando o retorno do destino do NFS. Mesmo se a caixa NFS for reconectada - o loop ainda não terminou.
Nós 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 balanceado de carga, verificando o armazenamento único - isso não afetaria o sistema?
Você já considerou uma conexão iSCSI somente leitura para 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, ele é bem escalável
Mas você precisaria instalar alguns serviços de cluster e o GFS não é exatamente conhecido por sua agilidade. Otoh, sempre foi rápido o suficiente para mim, mas ymmv.
Eu posso estar um pouco atrasado. Usamos um MD3220 Dell Storage que tem porta dupla de cluster. Nossa unidade tem 2 controladores, caso um desça em segundo, ele continuará funcionando até corrigirmos esse problema. Como o HDD, o FAN, a fonte de alimentação e o controlador são todos Hotswap, substituímos as peças por dentro e por fora. A partir de Format usamos o NFS.
Se você já tem servidores da web em todos os lugares e é bom em executá-los, por que não considerar o WebDAV?
Resposta simples +1 para NFS. Eu tenho compartilhamentos NFS que foram montados por anos a fio sem problemas.
Se você está procurando por super confiabilidade, considere lançar o DRBD na mistura, bem como em um sistema de arquivos NFS distribuído e com failover automático.
A única outra opção (que eu conheço) é o iSCSI, mas pode ser uma dor na parte traseira para configurar ...
Você ficaria louco para considerar um FS distribuído como o GFS, e o iSCSI é um exagero.
Se você quer simples, use o NFS. É simples e rápido, e com montagens suaves bastante robustas. Também considere desabilitar todo o lixo bloqueado que o acompanha. Eu tenho desktops Linux que pegam todos os seus diretórios home e aplicativos do NFS, funciona bem.
Se você quer velocidade ultrajante, use o Lustre, que é significativamente mais fácil do que o GFS para configurar e é muito parecido com o RAID NFS. Usamos o Lustre para nossos clusters.
Você tem várias opções, com vários custos. SAN compartilhada com FC, iSCSI ou uma das adições mais recentes. Em qualquer caso, eles podem ser caros para definir e você ainda precisa executar um sistema de arquivos com reconhecimento de cluster. Sistemas de arquivos em cluster é um mundo de dor. Para qualquer esperança de sucesso você precisa de uma velocidade oi separada, baixa redes de latência para comunicação e dados de cluster. Mesmo com isso você é probabilidade de obter falhas que resultam em um nó sendo cercado e morto.
O único sistema de arquivos de cluster que encontrei que funciona sem problemas é VMFS. Mas isso é tão especializado que não seria útil, mesmo que estivesse disponível para uso geral.
O NFS é provavelmente o melhor caminho para a sua configuração. Se você está preocupado com a resiliência você precisa obter uma caixa NFS em cluster adequada. Você pode fazer uma configuração homebrew, mas iria bater o problema acima. Melhor aposta (se você tiver o dinheiro), é agrupada Os arquivadores da NetApp. É uma opção cara, mas o cluster realmente funciona sem qualquer aborrecimento. Não só isso, eles são muito rápidos.
Eu faria eco do aviso que alguns deram contra o NFS - embora o NFS seja provavelmente sua melhor aposta (por mais estranho que isso soe).
Eu tive um cliente NFS que tive que desconectar do AC para desligar porque o servidor NFS tinha desaparecido e o cliente recusou (no kernel) para desbloquear ou desligar porque o servidor NFS estava ausente.
Para fazer isso direito, eu insistiria no NFSv4 por toda parte, ficasse com conexões TCP, usasse quadros jumbo e usasse um cluster NFS. Você não pode permitir que seu servidor NFS desapareça.
GFS é um vodu seriamente negro. A quantidade de trabalho necessária para obter um funcionamento simples de dois clusters de clientes é impressionante em comparação com as alternativas. O OCFS2 é muito mais simples de implementar, mas é muito exigente quando se trata das versões do módulo do kernel envolvidas em todos os servidores conectados - e isso é só o começo.
A menos que você realmente precise do tipo de acesso de baixo nível que um sistema de arquivos de cluster oferece, o 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 comparada a percorrer uma árvore de diretórios era praticamente a mesma.
Eu usei o SFTP e ele funcionou bem para os meus propósitos - o NFS foi meu primeiro recurso, mas a falta de estilo dos IDs de usuário / grupo me fez desistir rapidamente.
Basta configurar a autenticação de chave pública e você será 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 a corrupção de dados.
O FTP pode se adequar aos seus propósitos, já que é mais leve. Provavelmente você quer que seus servidores estejam fazendo a web, não o trabalho ssh.