É possível ter uma pasta pessoal hospedada com o NFS?

Estou planejando implantar alguns computadores quiosques e gostaria de deixá-los com um pequeno pendrive como disco de inicialização, mantendo o restante em um servidor fácil de fazer backup, como o LTSP .

No momento, estou pensando em duas opções. Um NFSed / home / ou uma cópia local de ~ / copiada no login, sincronizada no logout.

Meu medo é que o trabalho com arquivos possa ficar muito lento ou minha rede fique entupida .

Eu uso o NFS para meus diretórios pessoais em nosso ambiente de produção. Existem alguns truques.

1. Não monte o NFS para /home- dessa forma, você pode ter um usuário local que permita a entrada no caso de o servidor NFS ficar inativo. Montamos para/mnt/nfs/home

2. Use montagens suaves e um tempo limite muito curto - isso impedirá que os processos sejam bloqueados para sempre.

3. Use o montador automático . Isso manterá o uso de recursos baixo e também significa que você não precisa se preocupar em reiniciar os serviços quando o servidor NFS for ativado, se for desativado por algum motivo.

   auto.master:
     +auto.master
     /mnt/nfs /etc/auto.home --timeout=300
   
   auto.home
      home -rw,soft,timeo=5,intr      home.bzzprod.lan:/home
   

4. Use um sistema de logon único para não ter problemas relacionados à permissão. Eu tenho um servidor OpenLDAP.

http://www.howtoforge.com recentemente publicou um artigo sobre o uso do GlusterFS como uma substituição / alternativa ao NFS, você pode conferir.

http://www.howtoforge.com/creating-an-nfs-like-standalone-storage-server-with-glusterfs-on-debian-lenny

Aqui está uma breve descrição de por que é uma boa alternativa 'viável' ao NFS, na página do projeto GlusterFS http://www.gluster.org/ :

"O GlusterFS se auto-recupera rapidamente. Não há fsck. O back-end de armazenamento é acessível diretamente como arquivos e pastas regulares (estilo NFS). Com a replicação ativada, o GlusterFS pode suportar falhas de hardware."

Mais informações podem ser encontradas na documentação do projeto.

Além disso, outra coisa interessante sobre o uso do GlusterFS é que, se você precisar de mais espaço na sua SAN, basta adicionar outro bloco de armazenamento (nó do servidor) e poderá escalar / aumentar seu armazenamento em paralelo quando houver necessidade.

Espero que isso ajude ou pelo menos ajude a apontar na direção certa!

Tenha cuidado com as montagens suaves! A montagem suave de um sistema de arquivos NFS significa que o IO falhará após ocorrer um tempo limite. Tenha certeza de que é isso que você deseja nos diretórios pessoais dos usuários! Meu palpite é que você não. Usar uma montagem rígida em diretórios pessoais em combinação com a opção intr parece muito mais seguro aqui.

O tempo limite do disco rígido não excederá o tempo limite: as operações de E / S serão repetidas indefinidamente. A opção intr permite interromper o processo de montagem. Portanto, se você montar a exportação e ocorrer uma falha, a montagem rígida bloqueará sua sessão. A opção intr tornará possível interromper a montagem, portanto a combinação é bastante segura e garante que você não perderá facilmente os dados de um usuário.

De qualquer forma, o autofs torna tudo isso ainda mais fácil.

A única coisa a notar é que, quando o servidor NFS estiver fora do ar - suas montagens congelarão - a montagem suave não bloqueará, portanto, o "congelamento" poderá ser evitado, mas isso não resolverá o problema dos diretórios pessoais sem uma casa. diretório, o usuário está ferrado de qualquer maneira.

Mesmo quando o servidor NFS se recuperar, a menos que você faça algo a respeito, o problema de congelamento permanecerá - você terá que interromper o processo na máquina de montagem e remontar. A razão para isso é que, quando o servidor NFS retorna, ele atribui um diferente fsid- para que você possa pelo menos corrigir esse problema codificando os fsids no servidor NFS, por exemplo ...

#. Home Directories
/usr/users \
  192.168.16.0/22(rw,sync,no_root_squash,fsid=1) \
  192.168.80.0/22(rw,sync,no_root_squash,fsid=1)

#. Scratch Space
/var/ftp/scratch \
  192.168.16.0/22(rw,async,no_root_squash,fsid=3) \
  192.168.80.0/22(rw,async,no_root_squash,fsid=3) \
  172.28.24.151(rw,async,root_squash,fsid=3)

A exports(5)página de manual declara ...

fsid=num
          This option forces the filesystem identification portion of the file handle
          and  file attributes used on the wire to be num instead of a number derived
          from the major and minor number of the block device on which the filesystem
          is  mounted.   Any 32 bit number can be used, but it must be unique amongst
          all the exported filesystems.

          This can be useful for NFS failover, to ensure that  both  servers  of  the
          failover  pair use the same NFS file handles for the shared filesystem thus
          avoiding stale file handles after failover.

... Embora isso indique que, desde que os números principais / secundários não sejam alterados (o que geralmente não ocorre, exceto quando você exporta volumes SAN / caminhos múltiplos, onde os dados podem mudar), descobri que removi completamente o problema - ou seja, se o servidor NFS voltar - a conexão foi restaurada rapidamente - ainda não sei por que isso fez diferença em dispositivos como, /dev/sdaXpor exemplo.

Agora, devo salientar que meu argumento é amplamente anedótico - na verdade não faz sentido o porquê de ter corrigido o problema, mas "parece" corrigi-lo - de alguma forma - provavelmente existem outras variáveis ​​em jogo aqui. ainda não descoberto. =)

Alguns conselhos gerais que serão aplicados, independentemente do sistema de arquivos da rede que você adotar: muitos programas armazenam em cache os dados no diretório inicial do usuário, o que geralmente causa mais danos do que benefícios quando o diretório inicial é acessado por uma rede.

Atualmente, você pode dizer a muitos programas para armazenar seus caches em outro local (por exemplo, em um disco local), definindo a XDG_CACHE_HOMEvariável de ambiente em um script de login. Muitos programas (por exemplo, Firefox) ainda requerem configuração manual; portanto, você provavelmente precisará fazer um trabalho extra para identificá-los e configurá-los de maneira uniforme para todos os seus usuários.

Em muitos lugares em que trabalhei, usei diretórios pessoais montados em NFS. Geralmente, não há uma grande diferença no desempenho (e os usuários do quiosque são provavelmente um pouco menos exigentes do que os desenvolvedores que sabem como se apossar do pessoal de TI local). Um problema que eu vi é o que acontece quando estou conectado a uma área de trabalho do Gnome e o servidor NFS desaparece por qualquer motivo. As coisas ficam realmente sem resposta.

Eu uso uma casa NFSed e funciona bem. mas você deve garantir que a rede seja rápida o suficiente e que nunca caia.

Na prática, o NFS tem bom desempenho no diretório pessoal se houver uma rede comutada de 100mbit ou melhor. Por mais de 10 a 20 quiosques, o servidor deve ter conectividade de gigabit. Você não ganhará concursos de desempenho, mas coisas como Firefox e Open Office funcionarão bem.

Copiar no diretório inicial será um grande problema em termos de atrasos no login (em uma rede de 100 bits com um máximo de 12MB / s. Um diretório inicial de 100 MB fica perto de 10 segundos). minutos e 500 arquivos doem.

Dê uma olhada no cachefilesd . Eu não o usei, mas parece promissor.

O daemon cachefilesd gerencia os arquivos e o diretório de armazenamento em cache usados ​​pelos sistemas de arquivos da rede, como um AFS e NFS, para fazer cache persistente no disco local.

Além disso, não esqueça de ajustar os parâmetros rsize e wsize e use quadros Jumbo, se possível.