Exports y mounts NFS que fallan con seguridad

NFS es una de las herramientas más antiguas del kit de un operador Linux, y una de las más fáciles de dejar casi bien. Un recurso compartido que monta no es lo mismo que un recurso compartido que se comporta bien cuando la red parpadea, cuando un cliente se porta mal o cuando el filer se reinicia. Estos son los ajustes y las comprobaciones que marcan la diferencia, a ambos lados del mount.

Por qué los ficheros compartidos salen mal

La razón habitual para usar NFS es un grupo de servidores web o de aplicación que deben ver los mismos ficheros: medios subidos, recursos generados, un árbol de documentos compartido. Se configura deprisa, muchas veces copiando un ejemplo, y funciona a la primera. Los problemas aparecen después. Un export abierto a toda una red permite que una máquina de pruebas olvidada escriba en contenido de producción. Un cliente montado con opciones que se rinden ante los errores pierde escrituras en silencio. Un servidor que no puede alcanzar su filer al arrancar se queda colgado minutos en lugar de arrancar sin el recurso compartido. Nada de esto es visible el día en que se configura.

En el filer: exporte a nombres, aplaste root

Exporte cada recurso compartido a los hosts que lo necesitan, por nombre, con los derechos más estrechos que funcionen:

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

Hosts con nombre, no redes. Un wildcard o una subred entera significa que cualquier máquina que alguna vez aterrice en esa red puede montar el recurso compartido. Enumerar los hosts convierte a cada cliente en una decisión deliberada.

root_squash. Root en un cliente se convierte en un usuario sin privilegios en el filer. Sin esto, cualquiera con root en cualquier cliente es dueño de todos los ficheros del recurso compartido.

sync. El servidor confirma una escritura solo después de que esté comprometida en storage estable. La alternativa más rápida confirma escrituras que un corte de corriente todavía podría borrar.

Aplique y compruebe lo que realmente está exportado, que no siempre es lo que cree haber escrito:

exportfs -ra
exportfs -v

Después restrinja el servicio en el firewall del host a los mismos clientes. Con firewalld, una zona dedicada lo mantiene legible:

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

Los exports y las reglas del firewall son dos cerraduras independientes. Use ambas.

En el cliente: hard mounts que no cuelgan el arranque

El lado del cliente decide qué ocurre cuando el filer va lento o es inalcanzable por un momento:

# /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, no soft. Un hard mount reintenta hasta que el servidor responde. Un soft mount devuelve un error tras un número de reintentos, y muchas aplicaciones no comprueban ese error al escribir, así que se pueden perder datos sin que nadie se entere. Si un recurso compartido contiene algo que le importa, móntelo hard. El precio es que un proceso que toca el recurso compartido espera mientras el filer está ausente, que es el comportamiento honesto.

_netdev y nofail. El mount espera a la red, y un filer ausente no impide que el servidor arranque. Combinado con un tiempo límite de mount, la máquina arranca, la aplicación puede informar con claridad del recurso compartido ausente, y el mount se completa cuando el filer vuelve.

Fije el protocolo que probó. Clientes y servidores negocian una versión de protocolo. Fije explícitamente la que probó (nfsvers= o vers=) para que una actualización en cualquiera de los dos lados no pueda cambiar en silencio el comportamiento de bloqueo y de caché debajo de usted.

Compruebe lo que realmente se negoció, no lo que pidió:

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

mountstats muestra recuentos por operación, retransmisiones y tiempos de ida y vuelta. Un recuento de retransmisiones que crece es el aviso temprano de que la ruta de red o el filer necesitan atención.

Redundancia en el cable, snapshots en el disco

Un filer está tan disponible como sus enlaces de red. Conéctelo con enlaces agregados a un par de switches, haga el hash del bond sobre direcciones y puertos para que ambos enlaces lleven tráfico, y mantenga el filer y los clientes en el mismo segmento de capa 2 siempre que pueda. Una ruta conmutada tiene menos piezas móviles que una enrutada y mantiene el tráfico de ficheros dentro de la red privada.

En el lado del storage, un sistema de ficheros con sumas de comprobación y snapshots cambia la forma de tratar los errores. Con ZFS, por ejemplo:

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

Un snapshot antes de cada despliegue o cambio masivo hace que un mal cambio sea reversible en segundos, y un directorio oculto de snapshots permite a un administrador copiar de vuelta un único fichero sin un trabajo de restauración.

Cuando un recurso compartido de ficheros es la respuesta equivocada

NFS es excelente para contenido que se escribe ocasionalmente y se lee mucho. Es un mal hogar para los ficheros de datos de una base de datos, para cargas de trabajo que bloquean intensamente entre clientes, o para millones de ficheros diminutos reescritos constantemente. Esos pertenecen al storage de bloques. Cuando una biblioteca se queda grande para el servicio de ficheros, muévala, cuente y calcule la suma de comprobación de cada fichero a ambos lados antes del cutover, y conserve el original como rollback hasta que la nueva copia se haya probado en uso.

Una lista corta para sus propios recursos compartidos

• exportfs -v enumera solo hosts con nombre, con root_squash y sync.
• El firewall permite NFS solo desde esos hosts.
• Cada mount de cliente es hard, con _netdev, nofail y una versión de protocolo fijada.
• nfsstat -m en cada cliente muestra las opciones que pretendía.
• Las retransmisiones en mountstats están cerca de cero y no crecen.
• El filer tiene enlaces redundantes, y ha probado perder uno.
• Existen snapshots, y los backups se extraen por separado.

Cómo lo hacemos nosotros

Nuestros servicios de ficheros funcionan sobre ZFS en volúmenes de nuestra SAN all-flash, se conectan por enlaces agregados a un par de switches en el mismo segmento privado que sus clientes, y se actualizan en un nuevo entorno de arranque para que el anterior siga siendo arrancable hasta que la actualización esté probada.

Si su storage compartido se configuró deprisa y nadie lo ha vuelto a mirar desde entonces, con gusto lo revisamos con usted.

CTA

Hable con un ingeniero

Related

Relacionado: Servicios de ficheros NAS, NFS y SMB · Storage SAN enterprise en HPE 3PAR, all-flash · Disaster recovery y réplicas entre sedes