Cómo reorganizar conjuntos de datos NFS sin cambiar las rutas de exportación visibles para los clientes
Los conjuntos de datos NFS se pueden reorganizar sin dejar identificadores de cliente obsoletos cuando el espacio de nombres de exportación visible para el cliente permanece estable mientras el almacenamiento se mueve detrás de ese límite.
El diseño preventivo consiste en separar la ruta que montan los clientes del nombre físico del conjunto de datos que podrías cambiar más adelante. Crea un árbol de exportación estable, asigna los conjuntos de datos de forma deliberada, conserva la identidad del sistema de archivos siempre que sea posible, desconecta a los clientes antes de realizar reemplazos destructivos y verifica la misma ruta de exportación después del cambio. Si el servidor debe destruir y volver a crear el sistema de archivos subyacente, considéralo un cambio de identidad y planifica un nuevo montaje coordinado de los clientes, en lugar de prometer una continuidad invisible.
Crea un espacio de nombres de exportación estable por encima de los conjuntos de datos
Usa una raíz de exportación NFS dedicada cuyos nombres visibles para los clientes no reflejen cada nombre interno de conjunto de datos de ZFS o Btrfs. Así, los administradores de almacenamiento pueden reorganizar los conjuntos de datos del backend sin tener que enseñar a cada cliente una nueva ruta de montaje.
Una explicación sobre el diseño de NFSv4 muestra cómo los montajes bind crean exportaciones estables dentro de un pseudo-sistema de archivos gestionado deliberadamente.
Documenta la ruta del cliente como el contrato de compatibilidad. Los nombres internos de los conjuntos de datos pueden cambiar más adelante, pero solo después de reasignar la capa de exportación y probarla con la misma ruta.
Fija la identidad de la exportación en lugar de depender del orden de detección
Registra el UUID del sistema de archivos, la ruta de exportación, la versión de NFS y la configuración explícita de fsid que usa el servidor actual. El mismo nombre de directorio visible no es suficiente cuando el servidor NFS identifica de otra manera el sistema de archivos subyacente después de un traslado.
SUSE señala que NFS identifica cada sistema de archivos exportado en lugar de tratar una exportación como un simple alias de ruta.
Usa identificadores explícitos solo cuando tu implementación de NFS los admita y mantén cada valor único. No copies un fsid en dos sistemas de archivos exportados simultáneamente solo para hacer que parezcan idénticos.
Prepara el nuevo conjunto de datos detrás de la misma ruta de exportación
Crea o recibe el conjunto de datos de reemplazo en una ruta temporal del servidor, copia o replica su contenido, verifica los permisos y, después, asígnalo al árbol de exportación estable durante una ventana de mantenimiento. Mantén disponible el conjunto de datos antiguo para poder revertir el cambio, pero no lo actives con la misma identidad de exportación.
Un ejemplo de exportación NFS muestra cómo los subárboles montados requieren exportaciones deliberadas cuando varios sistemas de archivos aparecen dentro de un mismo espacio de nombres NFS.
El cambio debe modificar una sola asignación en el servidor, no simultáneamente la definición de montaje del cliente y la identidad del conjunto de datos. Así se conserva la evidencia necesaria para solucionar problemas si el nuevo árbol es incorrecto.
Detén las escrituras antes de reemplazar el sistema de archivos subyacente
Detén o pausa los servicios que escriben activamente a través del montaje NFS y confirma que ningún cliente importante mantenga una operación de archivo de larga duración durante el cambio. Completa la sincronización final solo después de detener las escrituras.
IBM explica que el estado de NFSv4 necesita almacenamiento estable, porque el estado del cliente forma parte de la continuidad, no solo el contenido de los archivos del servidor.
En un servidor doméstico, el objetivo es más sencillo que en una conmutación por error en clúster: evita cambiar la identidad de los archivos mientras las aplicaciones están activas. Una breve pausa controlada es más segura que obligar a las aplicaciones de bases de datos, multimedia o copias de seguridad a sobrevivir a un reemplazo del sistema de archivos en vivo.
Reconoce cuándo es inevitable volver a montar el recurso en el cliente
Si la reorganización destruye y vuelve a crear el sistema de archivos, restaura una instantánea como un sistema de archivos nuevo o cambia la identidad del identificador de archivo en el servidor, planifica desmontar y volver a montar el recurso de forma coordinada después de estabilizar la ruta del servidor.
Una guía actual de solución de problemas de NFS afirma que los cambios de identidad del servidor dejan obsoletos los identificadores y recomienda comprobar la identidad estable del servidor cuando el problema vuelva a producirse.
No anuncies un mantenimiento “sin necesidad de volver a montar” cuando la identidad subyacente realmente cambia. Una ventana de montaje documentada es mejor que permitir que las aplicaciones descubran un error ESTALE durante las escrituras normales.
Prueba la ruta del cliente antes de retirar el conjunto de datos antiguo
Monta la exportación desde un cliente nuevo y desde un cliente existente no crítico; después, compara la identidad del directorio, los permisos, varias lecturas representativas, una escritura reversible y la ruta esperada por la aplicación. Reinicia un cliente para demostrar que la configuración persistente del montaje no ha cambiado.
Un caso de Arch Linux descubrió que una raíz NFS estable evita ESTALE después de cambios en los sistemas de archivos del backend.
La reorganización está completa cuando los clientes siguen usando la ruta exportada original y el conjunto de datos antiguo puede retirarse sin referencias ocultas. El artículo relacionado de ZimaSpace sobre identificadores obsoletos después de cambiar el nombre de un conjunto de datos es la vía de recuperación si ESTALE ya ha aparecido.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
