È possibile avere la cartella home ospitata con NFS?

Sto progettando di distribuire alcuni computer kiosk e vorrei lasciarli con un piccolo pendrive come disco di avvio, mantenendo il resto su un server di facile backup, come LTSP .

In questo momento sto riflettendo su due opzioni. Un NFSed / home /, o una copia locale di ~ / copiato all'accesso, sincronizzato al logout.

Le mie paure sono che lavorare con i file potrebbe diventare troppo lento o la mia rete potrebbe essere intasata .

Uso NFS per le mie home directory nel nostro ambiente di produzione. Ci sono un paio di trucchi.

1. Non montare NFS su /home: in questo modo puoi avere un utente locale che ti consenta nel caso in cui il server NFS non funzioni. Montiamo su/mnt/nfs/home

2. Utilizza supporti morbidi e un timeout molto breve: questo impedirà ai processi di bloccarsi per sempre.

3. Usa l' automounter . Ciò consentirà di ridurre l'utilizzo delle risorse e significa anche che non è necessario preoccuparsi di riavviare i servizi quando il server NFS si presenta se si interrompe per qualche 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. Utilizzare un unico sistema di accesso in modo da non incorrere in problemi relativi alle autorizzazioni. Ho un server OpenLDAP.

http://www.howtoforge.com ha recentemente pubblicato un articolo sull'uso di GlusterFS come sostituto / alternativa a NFS, si consiglia di verificarlo.

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

Ecco una breve descrizione del perché è una buona alternativa 'fattibile' a NFS, dalla pagina del progetto GlusterFS http://www.gluster.org/ :

"GlusterFS si auto-guarisce al volo. Non c'è fsck. Il back-end di archiviazione è accessibile direttamente come normali file e cartelle (stile NFS). Con la replica abilitata, GlusterFS può sopportare guasti hardware."

Ulteriori informazioni sono disponibili nella documentazione del progetto.

Inoltre, un'altra cosa bella dell'uso di GlusterFS è che se hai bisogno di più spazio sulla tua SAN, aggiungi semplicemente un altro mattone di memoria (nodo del server) e sei in grado di ridimensionare / espandere la tua memoria in parrallel quando ce n'è bisogno.

Spero che questo aiuti o almeno ti aiuti nella giusta direzione!

Fai attenzione ai supporti morbidi! Il montaggio soft di un filesystem NFS significa che IO non funzionerà dopo un timeout. Assicurati che sia quello che vuoi nelle home directory degli utenti! Suppongo che non lo sia. L'uso di un hard mount su home directory in combinazione con l'opzione intr è molto più sicuro qui.

Hard non scadrà: le operazioni IO verranno ritentate indefinitamente. L'opzione intr consente di interrompere il processo di montaggio. Pertanto, se si monta l'esportazione e si verifica un errore, il disco rigido bloccherà la sessione. L'opzione intr consentirà di interrompere il mount, quindi la combinazione è abbastanza sicura e ti assicura di non perdere facilmente i dati di un utente.

Ad ogni modo, autofs rende tutto ancora più semplice.

L'unica cosa da notare è che quando il server NFS è fuori uso - i tuoi mount si bloccheranno - fare un soft mount non si bloccherà quindi il "freeze" stesso può essere evitato, tuttavia ciò non risolverà il problema delle home directory come senza home directory, l'utente viene comunque fregato.

Anche quando il server NFS viene ripristinato, a meno che tu non faccia qualcosa al riguardo, il problema di blocco rimarrà: dovrai interrompere il processo sulla macchina di montaggio e rimontarlo. La ragione di ciò è che quando viene ripristinato il server NFS, ne viene assegnato uno diverso fsid, in modo da poter almeno risolvere questo problema codificando i messaggi di posta fsidelettronica sul server NFS, ad esempio ...

#. 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)

La exports(5)pagina man afferma ...

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.

... Mentre ciò indica che fintanto che i numeri maggiori / minori non cambiano (cosa che di solito non cambia, tranne quando si esportano volumi SAN / multipath, dove possono cambiare), ho scoperto che noi ho rimosso completamente il problema - vale a dire, se il server NFS ritorna - la connessione è stata ripristinata rapidamente - ancora non so davvero perché questo abbia fatto la differenza per dispositivi come /dev/sdaXad esempio.

Ora dovrei sottolineare che il mio argomento è in gran parte aneddotico - in realtà non ha senso il motivo per cui ha risolto il problema, ma "sembra" averlo risolto - in qualche modo - probabilmente ci sono altre variabili in gioco qui che ho non ancora scoperto. =)

Alcuni consigli generali che verranno applicati indipendentemente dal file system di rete adottato: molti programmi memorizzano nella cache i dati nella home directory dell'utente, che di solito fa più male che bene quando si accede alla home directory su una rete.

In questi giorni, puoi dire a molti programmi di memorizzare le loro cache altrove (ad esempio, su un disco locale) impostando la XDG_CACHE_HOMEvariabile di ambiente in uno script di accesso. Molti programmi (ad esempio, Firefox) richiedono comunque la configurazione manuale, quindi probabilmente dovrai fare un lavoro extra per identificarli e configurarli in modo uniforme per tutti i tuoi utenti.

In molti posti in cui ho lavorato usano le home directory montate su NFS. Di solito non c'è un'enorme differenza nelle prestazioni (e gli utenti dei chioschi sono probabilmente un po 'meno esigenti rispetto agli sviluppatori che sanno come ottenere il loro ragazzo IT locale). Un problema che ho visto è quello che succede quando accedo a un desktop Gnome e il server NFS scompare per qualsiasi motivo. Le cose diventano davvero insensibili.

Uso una casa NFSed e funziona benissimo. ma devi assicurarti che la rete sia abbastanza veloce e che non sarà mai inattiva.

Su base pratica, NFS funziona bene per la home directory se esiste una rete commutata a 100 mbit o superiore. Per più di 10-20 chioschi, il server dovrebbe avere connettività gigabit. Non vincerai concorsi sulle prestazioni, ma cose come Firefox e Open Office funzioneranno bene.

Copiare nella home directory sarà un grosso problema in termini di ritardi all'accesso (su una rete da 100 mbit con un massimo di 12 MB / s. Una home directory da 100 MB è vicina ai 10 secondi.) Rsync ti bloccherà sincronizzando la cache del browser web ... 10 minuti e 500 file feriti.

Dai un'occhiata a cachefilesd . Non l'ho usato da solo, ma sembra promettente.

Il daemon cachefilesd gestisce i file di cache e la directory utilizzati dai file system di rete come AFS e NFS per eseguire la memorizzazione nella cache persistente sul disco locale.

Inoltre, non dimenticare di ottimizzare i parametri rsize e wsize e, se possibile, utilizzare i frame Jumbo.