Prevenire il blocco della connessione NFS dal sistema client

Abbiamo una condivisione NFS 4, che condivide un volume tra un numero di server (server NFS e client tutti Debian 8). Di recente abbiamo riscontrato alcuni problemi in cui le interruzioni di rete congelerebbero i sistemi client.

Il nostro opzioni NFS sono state minime, solo rw(e quindi le impostazioni predefinite hard, fgecc).

Ora sto sperimentando queste opzioni, ma non ottengo il comportamento che mi aspetto: rw,soft,bg,retrans=6,timeo=150

(Ho aumentato i ritocchi per compensare parte del rischio soft)

La procedura che sto seguendo per testare è:

Macchina di avvio
cd a /mnt/mountpoint
Verifica connessione NFS ok
cd /
uccidi la rete ifdown eth0
cd a /mnt/mountpoint
ls

A questo punto la riga di comando si blocca e non posso interromperla. Dopo qualche tempo il messaggio 'nfs: server [servername] non risponde, è scaduto`, che sembra ripetersi una volta al minuto (indefinitamente).

Cosa vorrei / mi aspetto che accada perché l'operazione non riesca e restituisca il controllo.

Per favore qualcuno potrebbe dirmi dove sto sbagliando con queste impostazioni?

(PS: ho anche provato a montare con autofs, ma ho visto un comportamento simile)

Grazie

nfs

— UpTheCreek
fonte

Non lo consiglierei softin nessun caso. Consente di eliminare i dati in caso di errore . Invece suggerirei hard,intr.

— roaima,

@roaima - Grazie. Questa opinione sembra essere molto diffusa sul web :) Il problema è che l'attuale situazione che abbiamo hardè altrettanto grave per noi (i sistemi che muoiono e rimangono morti fino al riavvio). intrnon è supportato in NFS4 secondo man.

— UpTheCreek

(Correzione, sembra intrche sia supportato da NFS4, ma non da kernel> 2.6.25)

— UpTheCreek

Penso che la cosa che differisce dalle risposte "standard" sia che stai cambiando l'attuale directory di lavoro con il punto di montaggio. Ottieni lo stesso comportamento senza cd, ma invece lo fai ls /mnt/mountpoint? È possibile che dopo il lsfallimento la shell stia tentando operazioni sul filesystem dipendenti da PWD. (Ancora peggio, se fossi abbastanza sciocco da mettere il .tuo $PATH)

— Toby Speight

Risposte:

intrdovrebbe permetterti di riprendere il controllo quando colpisci ^C, ma di solito non immediatamente.

   intr           If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the
                  file  operation  and cause it to return EINTR to the calling program.  The default is to not allow file
                  operations to be interrupted.

Come dici tu, le aspettative sono il problema qui. I problemi di rete possono essere temporanei, ma il fallimento di un'operazione è permanente. Quindi la maggior parte delle operazioni si limita a bloccare semplicemente fino al completamento dell'operazione.

Questa è la risposta standard, ma guardando una pagina man attuale vedo questo:

                  The  intr / nointr mount option is deprecated after ker-
                  nel 2.6.25.  Only SIGKILL can interrupt  a  pending  NFS
                  operation on these kernels, and if specified, this mount
                  option is ignored  to  provide  backwards  compatibility
                  with older kernels.

Quindi non mi sembra un problema NFS3 / NFS4, ma una decisione su come intrfunziona. Quindi dovresti essere in grado di eseguire KILLil processo, ma ciò potrebbe non darti molta utilità.

Non sono riuscito a trovare la discussione sul perché l'opzione è stata rimossa. Puoi uccidere -KILL il tuo processo?

— BowlOfRed
fonte

Grazie, ma secondo l'uomo intrè supportato da nfs 2/3 ma non da 4.

— UpTheCreek

@UpTheCreek, non capisco perché sarebbe. Non ho un sistema debian qui ma è esplicitamente menzionato come disponibile. L'hai provato? "intr Questo consentirà di interrompere le operazioni NFS4 (su hard mount) in attesa di una risposta dal server."

— BowlOfRed

Sì, l'ho provato e non sembrava avere alcun effetto. L'uomo dice che è ignorato nelle recenti versioni del kernel.

— UpTheCreek

Non è possibile KILL un processo perché l'intero sistema si blocca. Nessun comando può essere emesso nella mia esperienza. (Anche se in alcuni casi potrebbe essere possibile SSH in una macchina così congelata.)

— MountainX per Monica Cellio,

Alcune delle mie risposte sono opinioni, basate sull'esperienza. Laddove ho dei fatti (cercherò di ricordare di) collegarmi a loro.

NFS 4 è considerato un miglioramento rispetto alle versioni 2 e 3. Tuttavia, non ho ancora visto un caso d'uso forte per aver bisogno dei miglioramenti. Forse è perché intendo esportare filesystem su client Windows con Samba e su client Unix / Linux con NFS.
Non consiglierei softin quasi nessuna circostanza. Consente di scartare i dati in caso di errore . Invece suggerirei hard,intr.
Come hai sottolineato, intrnon è valido per NFS 4, ma sembra che si tratti di una modifica del kernel piuttosto che di una NFS.
NFS Automounter ( autofs) funziona bene per i miei casi d'uso con le versioni 2 e 3 di NFS e riesce a proteggere i miei sistemi client dai guasti del server montando i filesystem NFS solo quando sono necessari.

Il mio suggerimento per te sarebbe di prendere in considerazione il passaggio da NFS 4 a NFS 3 e vedere se questo aiuta il tuo caso d'uso particolare. Non pensarlo come un downgrade.

— roaima
fonte

Grazie, ma non sono in grado di passare a NFS3 e anche se, come dici tu, intrnon sono supportato nelle recenti versioni del kernel.

— UpTheCreek

Ah sì, sembra che intr sia supportato in NFS4 (è elencato sia nelle opzioni solo 2/3 che nelle 4 opzioni solo in man, il che è un po 'confuso), ma non è supportato nelle recenti versioni del kernel.

— UpTheCreek

"Non consiglierei il soft in nessun caso" - davvero? Nel mio caso, ho un web server occupato che monta una directory di immagini. Se l'host di immagini si arresta e utilizziamo hard, l'intero sito Web si arresta. Se usiamo soft, potremmo eventualmente ottenere alcune immagini rotte (anche se il nostro sistema di memorizzazione nella cache lo mitiga quasi completamente). Il rischio di softconsentire la corruzione dei file non è davvero un grosso problema. Preferirei avere un file immagine corrotto piuttosto che un sito inattivo!

— Doug McLean l'

@DougMcLean è stato anche in una situazione simile (web farm occupata, server di immagini, NFS ...) Direi che è un caso un po 'specializzato. Se i miei server di immagini fossero stati inaffidabili, sospetto che avrei potuto optare per softuna soluzione accettabile. Risposta modificata da "mai" a "quasi mai". Grazie!

— roaima,

Se la mia memoria è corretta, questo problema di blocco del sistema era presente anche in NFS v3.

— MountainX per Monica Cellio,