NFSv4 ben configurat per entorns Linux

Configurar NFSv4 en un entorn Linux sembla una tasca senzilla sobre el paper, però a la pràctica, és fàcil cometre errors que només es fan evidents amb el temps, sota càrrega o quan alguna cosa falla de forma subtil.

NFSv4: alguns supòsits que continuen causant problemes

NFSv4 porta millores reals sobre v3 —gestió d’identitats, delegacions, single-root mount point, millor semàntica de locking— però també imposa canvis de comportament que no sempre s’entenen bé.

Un dels errors més comuns és assumir que n’hi ha prou amb migrar a NFSv4 simplement canviant la versió en les opcions de muntatge. La realitat és que NFSv4 espera que el servidor estigui exportant des d’un únic punt d’export i que els clients muntin subdirectoris relatius a aquest punt, com /export/home o /export/data.

Si s’intenta muntar /home directament des del servidor, com es feia amb v3, i el servidor està configurat només amb /export com root export, el client veurà errors com “permission denied” o fins i tot muntarà alguna cosa inesperada. Això s’arregla configurant fsid=0 a l’exportació (per exemple, /export), i assegurant-se que les rutes muntades pels clients estiguin sempre sota aquest punt.

# /etc/exports en el servidor
/export    192.168.0.0/24(rw,fsid=0,no_subtree_check,sync)
/export/home 192.168.0.0/24(rw,no_subtree_check,sync)

Molts ho sabem, però encara es veu gent fent servir fsid=0 en múltiples exportacions per separat. Això no només trenca el muntatge, sinó que pot causar errors difícils de depurar si els clients tenen configuracions antigues o inconsistents.

Muntatge persistent: systemd i els errors silenciosos

Una de les fonts més freqüents de frustració en entorns amb NFS és l’ arrencada de sistemes que depenen de muntatges remots. Aquí és on entra, i tot i que ha millorat força quant a gestió de dependències i retries, hi ha formes de fer-lo servir que continuen generant fallades subtils.

Una recepta que dona pocs problemes amb el temps és aquesta:

# /etc/systemd/system/home.mount
[Unit]
Description=Mount NFS Home
After=network-online.target remote-fs-pre.target
Wants=network-online.target
 
[Mount]
What=192.168.0.10:/export/home
Where=/home
Type=nfs
Options=vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noatime
 
[Install]
WantedBy=multi-user.target

Alguns detalls:

• network-online.target en comptes de només network.target. És comú que el sistema arribi a network.target sense haver portat encara la IP via DHCP.
• remote-fs-pre.target assegura que qualsevol preparació de muntatges es faci abans de la resta de remot-fs.
• L’ús explícit de home.mount en comptes de confiar a /etc/fstab ajuda a tenir més control i logs més clars al journalctl.

Evitar elauto a fstab i dependre de noauto,x-systemd.automount també pot fer que els muntatges siguin més resilients si el servidor NFS no està disponible en l’arrencada. Però això s’ha d’avaluar segons el tipus de servei que s’ofereix. Per a estacions de treball pot ser bona idea; en servidors amb aplicacions que esperen rutes muntades, no tant.

Rendiment: més enllà de rsize/wsize

Tothom ajusta rsize i wsize, i hi ha recomanacions de pujar-los a 1 MB (1048576) per a NFSv4.2. Però a la pràctica, això no és garantia de rendiment consistent. Depèn de la MTU, de si hi ha Jumbo Frames, del rendiment de l’emmagatzematge subjacent i de com es comporta l’aplicació.

A NFSv4.2, delegacions i caching local poden ajudar molt… o ser un problema si no s’entenen. Per exemple:

• Si tens múltiples clients escrivint al mateix arxiu freqüentment, les delegacions poden causar conflictes i retries, augmentant la latència.
• Algunes càrregues de treball es beneficien de fer servir noac (no attribute caching), per exemple en aplicacions que fan stat() constantment i necessiten coherència absoluta. Però això penalitza el rendiment en lectures.

Aquestes opcions donen bons resultats en càrregues de treball mixtes (lectura i escriptura):

192.168.0.10:/export/data /mnt/data nfs4 vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noatime

I en casos on es prioritza coherència sobre rendiment (certes tasques de compilació distribuïda o apps legacy):

192.168.0.10:/export/build /mnt/build nfs4 vers=4.2,hard,noac,timeo=600,retrans=5

També podem veure millores amb tcp_nodelay=on en xarxes amb latència variable, tot i que aquesta opció no sempre és reconeguda per tots els clients NFS.

No t’oblidis del costat servidor: el nombre de threads de nfsd (/proc/fs/nfsd/threads o en /etc/nfs.conf) ha de correspondre a la càrrega real. En servidors multi-core amb trànsit alt, deixar els 8 fils per defecte és un coll d’ampolla.

# /etc/nfs.conf
[nfsd]
threads=32

Identitats i mapatge: els problemes invisibles d’idmapd

Amb NFSv4 desapareix la transferència d’UID/GID com a v3. Es fan servir i es comparen els noms d’usuari/grup. Això causa problemes subtils quan el domini no coincideix o quan el servei nfs-idmapd no està corrent.

Detalls que solen passar-se per alt:

• A /etc/idmapd.conf, el Domain ha de coincidir exactament entre servidor i client. No ha de ser un FQDN real, però sí que ha de ser idèntic.
• A sistemes que fan servir systemd, de vegades nfs-idmapd no s’ inicia automàticament. Cal habilitar-lo o assegurar-se que rpc.idmapd s’ executi quan es munta NFSv4.
• Si els noms d’usuari no estan sincronitzats entre client i servidor (per exemple, si un fa servir LDAP i un altre arxius locals), l’accés falla sense missatges clars.

En ambients controlats, una opció vàlida és deshabilitar el mapatge i fer servir sec=sys amb sincronització manual d’UID/GID. Una altra opció és integrar ambdós extrems amb LDAP/SSSD i assegurar-se que els noms estiguin alineats.

Errors comuns

1. fstab amb defaults en muntatges NFSv4.
Això activa coses com soft, intr o proto=udp (a sistemes antics). A NFS, pot provocar corrupció de dades en certs casos. Sempre definir explícitament: hard, timeo, retrans, etc.

2. Muntatges des de múltiples subdirectoris sense fsid = 0 definit correctament.
El client veu directoris buits o errors de permisos, encara que l’export estigui bé.

3. Clients amb clocks desincronitzats.
Amb NFSv4, el locking i alguns comportaments depenen de timestamps. Sempre córrer chronyd o ntpd.

4. Muntatges penjant-se en arrencar perquè network.target arriba abans de tenir IP.
Es resol apuntant a network-online.target i, si cal, assegurant que systemd-networkd-wait-online.service o equivalent estigui actiu.

5. Logs buits o poc útils.
Fer servir rpcdebug ajuda quan els muntatges fallen sense motiu clar:

rpcdebug -m nfs -s all
rpcdebug -m nfsd -s all

I després observar amb dmesg o journalctl -k.

Un apunt sobre seguretat

En entorns multiusuari, fer servir NFSv4 sense sec = krb5 és un risc. sec=sys es basa en UID/GID que poden falsificar-se. No sempre és possible desplegar Kerberos bé, però si els clients són confiables (per exemple, estacions controlades pel mateix equip), es pot assumir aquest risc.

Quan sí que es necessita seguretat real entre clients (per exemple, accés a dades sensibles des de diferents zones de xarxa), Kerberos amb sec=krb5p és l’opció correcta, però té un cost operatiu que no convé subestimar.

NFSv4 en entorns multiclient: coherència, escalabilitat i vigilància

Quan es passa de 2 o 3 clients a una desena o més accedint als mateixos exports, comencen a aparèixer problemes que abans no es veien: bloquejos intermitents, errors de permisos, lentitud aleatòria.

Exportacions compartides: compte amb les escriptures concurrents

Si múltiples clients escriuen simultàniament als mateixos directoris o arxius (per exemple, un clúster de renderitzat o compilació), els locks de NFSv4 entren en joc. No és estrany veure processos penjats perquè estan esperant un fcntl() que mai acaba.

Per defecte, el servidor permet locks, però en alguns casos es recomana desactivar el 20% si els clients no el fan servir correctament. Per exemple, amb nfsdcltrack (el sistema de tracking de clients de NFSv4), si el servidor perd l’estat després d’un reboot i els clients no renegocien bé, els locks poden quedar-se penjats.

A servidors amb moltes connexions concurrents:

echo 128 > /proc/fs/nfsd/max_connections

Això limita la quantitat de connexions NFS simultànies. No sempre és necessari, però en servidors amb clients mal comportats, pot evitar que se saturin els recursos.

I sobretot: mai el mateix export en dues rutes diferents dins del mateix client. He vist problemes de locking intern en fer això.

Integració amb autofs: útil, però amb trampes

autofs té l’avantatge de muntar sota demanda, cosa que evita molts dels problemes durant l’arrencada del sistema. És especialment útil en entorns on els clients no necessiten tenir tots els NFS disponibles tot el temps (per exemple, estacions de treball que accedeixen a /net/share/ ocasionalment).

Un exemple bàsic de configuració:

/etc/auto.master:

/mnt/nfs    /etc/auto.nfs    --timeout=300

/etc/auto.nfs:

data   -fstype=nfs4,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=3,noatime    192.168.0.10:/export/data

Avantatges:

• Redueix el nombre de muntatges actius.
• Evita dependre de l’ ordre d’ arrencada de xarxa.
• Permet desmuntar automàticament rutes inactives.

Però té limitacions:

• Si el primer accés a un directori autofs el fa un servei que corre com a root abans que la xarxa estigui aixecada, pot fallar sense fer soroll.
• Alguns dimonis (com cron o certs agents de backup) no gestionen bé rutes que es munten/desmunten dinàmicament.

En general, és excel·lent en escriptoris o servidors amb accés esporàdic. En servidors d’aplicacions, és més segur mantenir muntatges persistents ben controlats via systemd.

Monitorització i anàlisi

Un dels errors més comuns és assumir que NFS està lent per “la xarxa” o “el disc”, sense mesurar res. Les eines més útils en aquest context:

nfsstat

Serveix per a analitzar tant client com servidor:

nfsstat -c  # estadístiques del client
nfsstat -s  # estadístiques del servidor

Fixeu-vos en camps com retrans (retransmissions), timeout, badxids. Una taxa de retransmissions >5% indica problemes de xarxa o de saturació del servidor.

iostat

Fet servir al servidor per veure el backend d’ emmagatzematge:

iostat -dx 2

Si el dispositiu que recolza l’export (ex. /dev/sdb) té un await molt alt, llavors el coll està en disc.

netstat / ss

Per revisar connexions actives NFS:

ss -t | grep :nfs

o si el port està ben definit:

ss -tna | grep 2049

En entorns amb molts clients, revisar ss -s també dona pistes sobre connexions en espera o slots saturats.

Diagnòstic avançat: tcpdump i wireshark

Quan els errors no s’expliquen amb logs, una traça pot revelar el que passa realment. Per exemple:

tcpdump -i eth0 port 2049 -w nfs-trace.pcap

Després es pot obrir amb Wireshark i filtrar per nfs o nfs.name == “filename” per veure qui accedeix què, quan i com.

Podem trobar problemes com:

• Clients que repeteixen el mateix GETATTR cada segon.
• Escriptures que mai reben COMMIT del servidor.
• Respostes amb NFS4ERR_DELAY quan el servidor està saturat.

Això és més feina, però en ambients crítics estalvia hores.

Kernel i compatibilitat

Una cosa que continua passant: muntar NFSv4 entre clients i servidors amb versions de kernel desalineades (per exemple, un client amb 5.4 i servidor amb 6.1), especialment quan un dels dos té backports. Els símptomes: comportament erràtic, muntatges que fallen sense logs clars, o fallades intermitents sota càrrega.

Algunes distribucions backporten funcions de NFSv4.2 sense etiquetar-les bé, cosa que genera confusió. Recomanació: almenys sincronitzar famílies de kernel (5.10 amb 5.10, 6.1 amb 6.1) en entorns on NFSv4 és crític. Si no es pot, forçar opcions conservadores:

vers=4.1,nconnect=4,noac,hard,timeo=600

Evita sorpreses com delegacions o pnfs activant-se automàticament.

I què passa amb nconnect?

A partir del kernel 5.3, NFS suporta nconnect=N, que permet múltiples connexions TCP entre el client i el servidor, balancejant la càrrega d’I/O sense requerir múltiples muntatges. Això redueix la latència percebuda en càrregues concurrents.

Exemple:

192.168.0.10:/export/share /mnt/share nfs4 vers=4.2,nconnect=4,hard,timeo=600

En proves internes, en entorns amb SSD i xarxa 10GbE, nconnect=4 ha millorat el rendiment de certes càrregues (còpies paral·leles grans, operacions tar+rsync) entre un 10% i 30%. Però no té efecte si el coll d’ampolla està al disc o la CPU del servidor.

També ajuda a evitar que una connexió única bloquegi tots els accessos si es congestiona.

Conclusió

L’ús de NFSv4 a Linux és estable i viable, però cal tractar-lo com a part de la infraestructura, no com una cosa que simplement “munta un directori remot”. L’experiència ensenya que els errors més molestos no són els que tomben un servidor, sinó els que l’alenteixen durant setmanes sense explicació clara.

Documentar configuracions, mesurar, i tractar NFS com un servei crític ajuda més que qualsevol truc de configuració puntual. I quan l’entorn escala o canvia, revisar el que funcionava “fins ara” pot evitar sorpreses.