Export e mount NFS che falliscono in sicurezza

NFS è uno degli strumenti più vecchi nella cassetta di un operatore Linux, e uno dei più facili da fare quasi bene. Una condivisione che si monta non è la stessa cosa di una condivisione che si comporta bene quando la rete ha un singhiozzo, quando un client si comporta male o quando il filer si riavvia. Ecco le impostazioni e i controlli che fanno la differenza, su entrambi i lati del mount.

Perché i file condivisi vanno storti

Il motivo tipico per usare NFS è un gruppo di server web o applicativi che devono vedere gli stessi file: media caricati, asset generati, un albero di documenti condiviso. Viene impostato in fretta, spesso copiando un esempio, e funziona al primo tentativo. I problemi compaiono dopo. Un export aperto a un'intera rete permette a una macchina di test dimenticata di scrivere su contenuti di produzione. Un client montato con opzioni che rinunciano sugli errori perde scritture in silenzio. Un server che al boot non riesce a raggiungere il suo filer resta bloccato per minuti invece di partire senza la condivisione. Nulla di tutto questo è visibile il giorno in cui viene configurato.

Sul filer: esportate verso nomi, fate squash di root

Esportate ogni condivisione verso gli host che ne hanno bisogno, per nome, con i diritti più stretti che funzionano:

# /etc/exports
/export/web   web1.example.internal(rw,sync,root_squash,no_subtree_check) \
              web2.example.internal(rw,sync,root_squash,no_subtree_check)
/export/media media-reader.example.internal(ro,sync,root_squash,no_subtree_check)

Host con nome, non reti. Un wildcard o un'intera subnet significa che ogni macchina che prima o poi finisce su quella rete può montare la condivisione. Elencare gli host rende ogni client una decisione deliberata.

root_squash. Root su un client diventa un utente senza privilegi sul filer. Senza, chiunque abbia root su un qualunque client possiede ogni file della condivisione.

sync. Il server conferma una scrittura solo dopo che è stata scritta su storage stabile. L'alternativa più veloce conferma scritture che una perdita di alimentazione potrebbe ancora cancellare.

Applicate e controllate cosa è effettivamente esportato, che non sempre è ciò che pensate di aver scritto:

exportfs -ra
exportfs -v

Poi limitate il servizio sul firewall dell'host agli stessi client. Con firewalld, una zona dedicata lo mantiene leggibile:

firewall-cmd --permanent --new-zone=nfsclients
firewall-cmd --permanent --zone=nfsclients --add-source=<client address>
firewall-cmd --permanent --zone=nfsclients --add-service=nfs
firewall-cmd --reload

Export e regole firewall sono due serrature indipendenti. Usatele entrambe.

Sul client: hard mount che non bloccano il boot

Il lato client decide cosa succede quando il filer è lento o brevemente irraggiungibile:

# /etc/fstab
filer.example.internal:/export/web  /srv/web  nfs  hard,proto=tcp,timeo=600,retrans=2,_netdev,nofail,x-systemd.mount-timeout=30  0 0

hard, non soft. Un hard mount riprova finché il server non risponde. Un soft mount restituisce un errore dopo un certo numero di tentativi, e molte applicazioni non controllano quell'errore in scrittura, quindi si possono perdere dati senza che nessuno venga avvisato. Se una condivisione contiene qualcosa che vi sta a cuore, montatela hard. Il prezzo è che un processo che tocca la condivisione aspetta mentre il filer è assente, che è il comportamento onesto.

_netdev e nofail. Il mount aspetta la rete, e un filer mancante non impedisce al server di avviarsi. Insieme a un timeout di mount, la macchina viene su, l'applicazione può segnalare chiaramente la condivisione mancante, e il mount si completa quando il filer torna.

Fissate il protocollo che avete testato. Client e server negoziano una versione di protocollo. Impostate esplicitamente quella che avete testato (nfsvers= o vers=) così un aggiornamento su uno dei due lati non può cambiarvi in silenzio il comportamento di locking e caching sotto i piedi.

Controllate cosa è stato effettivamente negoziato, non cosa avete chiesto:

nfsstat -m
findmnt -t nfs,nfs4
mountstats /srv/web

mountstats mostra conteggi per operazione, ritrasmissioni e tempi di round trip. Un conteggio di ritrasmissioni in crescita è l'avviso precoce che il percorso di rete o il filer hanno bisogno di attenzione.

Ridondanza sul filo, snapshot sul disco

Un filer è disponibile quanto i suoi link di rete. Collegatelo con link in bond verso una coppia di switch, fate l'hash del bond su indirizzi e porte così entrambi i link portano traffico, e tenete filer e client sullo stesso segmento Layer 2 dove potete. Un percorso switchato ha meno parti mobili di uno instradato e tiene il traffico dei file dentro la rete privata.

Sul lato storage, un filesystem con checksum e snapshot cambia il modo in cui gestite gli errori. Con ZFS, per esempio:

zfs snapshot tank/web@before-deploy
zfs list -t snapshot
ls /export/web/.zfs/snapshot/before-deploy/

Uno snapshot prima di ogni deploy o modifica massiva rende una cattiva modifica reversibile in secondi, e una directory nascosta degli snapshot permette a un amministratore di ricopiare un singolo file senza un job di restore.

Quando una condivisione di file è la risposta sbagliata

NFS è eccellente per contenuti scritti occasionalmente e letti da molti. È una pessima casa per i file dati di un database, per carichi che fanno locking pesante tra client, o per milioni di file minuscoli riscritti di continuo. Quelli appartengono allo storage a blocchi. Quando una libreria supera il file serving, spostatela, contate e verificate con checksum ogni file su entrambi i lati prima del cutover, e tenete l'originale come rollback finché la nuova copia non è stata provata nell'uso.

Una breve checklist per le vostre condivisioni

• exportfs -v elenca solo host con nome, con root_squash e sync.
• Il firewall permette NFS solo da quegli host.
• Ogni mount lato client è hard, con _netdev, nofail e una versione di protocollo fissata.
• nfsstat -m su ogni client mostra le opzioni che intendevate.
• Le ritrasmissioni in mountstats sono vicine a zero e non crescono.
• Il filer ha link ridondati, e avete testato la perdita di uno.
• Gli snapshot esistono, e i backup vengono prelevati separatamente.

Come lo facciamo noi

I nostri servizi file girano su ZFS sopra volumi della nostra SAN all-flash, si collegano con link in bond a una coppia di switch sullo stesso segmento privato dei loro client, e vengono aggiornati in un nuovo boot environment così che il precedente resti avviabile finché l'aggiornamento non è provato.

Se il vostro storage condiviso è stato impostato in fretta e da allora nessuno l'ha più guardato, siamo lieti di rivederlo con voi.

cta: Parla con un ingegnere

Related

• /what-we-do/storage-compute/network-attached-storage/
• /what-we-do/storage-compute/enterprise-san-storage/
• /what-we-do/storage-compute/disaster-recovery/