Como dice la pregunta.
Supongamos que quiero tener el equivalente a un "botón de emergencia" con secuencias de comandos para mi grupo de FreeNAS, algo en lo que puedo hacer clic para ejecutar desde una GUI o ejecutar en consola/SSH, que cierra muy rápidamente todo lo que pueda estar leyendo o escribiendo en él. desmonta el sistema de archivos e, idealmente, pone en modo inactivo los discos o particiones que está usando.
No me importan los errores que surjan en otro software o conexiones remotas al hacer esto, o la cancelación prematura de cualquier transferencia de archivos largos, solo quiero que desconecte el grupo de la manera más rápida que sea consistente para mantener su consistencia y posiblemente darle algunos segundos para que se completen las escrituras pendientes y el grupo esté en un estado consistente para propósitos de datos.
Las opciones sugeridas por los comandos ZFS no parecen prometedoras:zpool offline solo funciona en dispositivos individuales, por lo que uno podría tener una condición de carrera si la escritura ocurre mientras se extraen los discos uno a la vez; zpool export requiere la opción -f si está en uso y lleva una advertencia de que -f también puede perder datos. Uno podría verificar todos los file descriptors abiertos usar el grupo o sus dispositivos (¿miles o cientos de miles de ellos?) y forzar el cierre manual de cada uno, pero eso podría afectar las condiciones de carrera, ya que no impide que se creen nuevos fd al mismo tiempo. Tampoco debo suponer que toda la actividad de ZFS está mediada por una lista de demonios de servicio de archivos remotos a los que se enviarán señales de salida, porque es probable que parte de la actividad de los archivos sea local (cron/CLI/sesiones separadas).
Entonces, al ver la mejor manera de desconectar un grupo completo de manera segura y rápida, parece que umount podría ser mi mejor opción:funciona a nivel de sistema de archivos y puede desconectar un sistema de archivos completo rápidamente y como una unidad monolítica, después de lo cual zpool export parece que luego podría finalizar y detener cualquier actividad interna de manera segura sin el -f opción, manteniendo los datos en sí mismos en un estado consistente garantizado. Si hay actividad de disco sin procesar (resilver o depuración), supongo que se reanudará o reiniciará cuando el grupo vuelva a estar en línea más tarde.
Pero incluso umount no parece hacerlo completamente, porque podría haber iSCSI zvol objetivos en uso también. Los datos dentro de esos inherentemente no se pueden mantener consistentes ya que el servidor no conoce su estructura, por lo que los iniciadores remotos tendrán que reparar los datos lo mejor que puedan cuando se vuelvan a conectar. Estoy de acuerdo con eso, pero no estoy seguro de si se necesita algún tipo de comando para forzar la terminación o desconectar los objetivos o si es una buena práctica. (Nota:terminación forzada de conexiones tiene los mismos problemas que cerrar los fd individuales.)
Soy consciente de que es probable que haya algún tipo de pérdida de datos o problema si el grupo se saca abruptamente del estado RW cuando se están realizando escrituras. Pero siempre y cuando no pierda consistencia (a nivel de grupo ZFS y sistema de archivos), está bien:cualquier archivo en uso/objetivo iSCSI que se actualice tendrá que arriesgarse a que los archivos/bloques estén en un ZFS-consistente. pero el estado de datos no es válido debido a que se desconectó a la mitad de la escritura de los datos. Eso es inevitable y no es un problema para la pregunta.
Entonces, ¿qué pasos debo hacer realmente para desconectar un grupo en uso lo más rápido posible de acuerdo con la seguridad y consistencia garantizadas del grupo, y umount manualmente? ¿Será seguro usar un sistema de archivos ZFS en uso (como parte de una solución) o correrá el riesgo de dañar los datos?
Actualización: Mencionando aquí en caso de que alguien más lo encuentre útil. La respuesta aceptada establece que export -f puede tener problemas con zvols (iSCSI, etc.). Basándome en esta sugerencia, descubrí que el controlador iSCSI utilizado por FreeNAS puede forzar el cierre de sesión/terminar sesiones, y tiene otros subcomandos útiles que podrían ejecutarse de antemano; consulte man ctladm . Cualquiera que sea el uso de sus zvols, es probable que haya algún comando para finalizar sesiones en ellos).
Respuesta aceptada:
Descargo de responsabilidad:en este momento no tengo muchos enlaces y referencias para respaldar todo lo que se muestra a continuación, y no lo probé exhaustivamente. Este es solo un resumen de las cosas que he leído durante los últimos cinco a siete años sobre ZFS y cómo funciona, y algunas pruebas propias limitadas (no coordinadas, pero en su mayoría reinicios aleatorios).
Además, todo lo siguiente se dice sin tener en cuenta eventos catastróficos (el servidor se quema por completo), errores de software (errores en ZFS y en el sistema operativo principal, así como en los controladores de hardware) y malicia activa (administrador deshonesto, errores de administración). ¡Para todos esos casos, aún necesita tener copias de seguridad regulares y restaurables!
Datos en reposo/coherencia en disco
No me importan los errores que surjan en otro software o conexiones remotas al hacer esto, o la cancelación prematura de cualquier transferencia de archivos largos, solo quiero que desconecte el grupo de la manera más rápida que sea consistente para mantener su consistencia y posiblemente darle algunos segundos para que se completen las escrituras pendientes y el grupo esté en un estado consistente para propósitos de datos.
Primero, las buenas noticias:dado que ZFS utiliza CoW y transacciones atómicas, sus datos ya existentes estarán seguros incluso en caso de una pérdida repentina de energía. Esto incluye el diseño del grupo y los metadatos. Como los datos antiguos nunca se mueven antes de que los datos nuevos se hayan escrito por completo (de hecho, nunca se mueven, solo se reasignan), estos datos no pueden estar en peligro de ninguna manera si la escritura se interrumpe repentinamente.
Relacionado:Grep:¿por qué los corchetes en el patrón grep eliminan el proceso grep de los resultados de ps?Además, las sumas de verificación (árboles hash de Merkle) ayudan a certificar que no ha ocurrido nada malo durante el reinicio, lo que puede verificar limpiando el grupo. Si tiene vdevs redundantes, ZFS corregirá automáticamente cualquier error que encuentre de una buena copia conocida. Si algunos bloques se hubieran dañado de alguna manera (por ejemplo, por un controlador de disco falso que no escribe pero dice que sí), sus sumas de verificación no coincidirían con las de otros vdevs y se mostrarían errores.
Datos en modo vuelo/escritura y pérdida de los últimos n segundos
Escrituras sincronizadas y asincrónicas
Normalmente, ZFS recopila múltiples transacciones para acelerar las costosas operaciones de escritura en las unidades giratorias:posicionar el cabezal de escritura de la unidad de disco duro lleva mucho más tiempo que escribir realmente, por lo que querrá poner en cola tanto como sea posible y luego escribirlo en orden secuencial (más rápido). !) orden (recuerde, tenemos CoW, esto funciona de forma bastante natural aquí).
La desventaja de esto es que cuanto más recopile, más tiempo tendrán que esperar sus aplicaciones para recibir un mensaje de "escritura exitosa", lo que significa que su sistema se bloqueará durante varios segundos, lo cual es inaceptable. Peor aún:perderá todos los datos que se escribirán en el disco pero que aún no se han escrito en caso de un corte de energía. Si sus aplicaciones no pueden hacer frente a esto, se pueden producir daños en la capa de la aplicación.
Para combatir esto, se agregó el ZIL (registro de intentos de ZFS). Todas las transacciones de sincronización se recopilan en este registro (que se almacena de manera predeterminada en el disco de grupo lento, pero se puede almacenar en SSD duplicados más rápidos, que se denominan dispositivos SLOG) y, una vez que se almacenan, se devuelve "escritura exitosa" al aplicación que puede continuar con sus tareas (ya no hay bloqueos largos). Además, todas las transacciones asincrónicas se realizan sin ZIL, por lo que pueden ser más rápidas, siempre que la aplicación realice las operaciones de escritura correctas para sus datos (sincronización frente a asincrónica).
Propiedades ZFS
Ahora, la parte más interesante:¿qué sucede con tus escritos? Allí tenemos que discernir el modo de operación para el sistema de archivos (es una propiedad de ZFS y se puede configurar individualmente para cada sistema de archivos). Los tres modos posibles son (de las páginas de manual):
sync=standard
This is the default option. Synchronous file system transactions
(fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
and then secondly all devices written are flushed to ensure
the data is stable (not cached by device controllers).
sync=always
For the ultra-cautious, every file system transaction is
written and flushed to stable storage by a system call return.
This obviously has a big performance penalty.
sync=disabled
Synchronous requests are disabled. File system transactions
only commit to stable storage on the next DMU transaction group
commit which can be many seconds. This option gives the
highest performance. However, it is very dangerous as ZFS
is ignoring the synchronous transaction demands of
applications such as databases or NFS.
Setting sync=disabled on the currently active root or /var
file system may result in out-of-spec behavior, application data
loss and increased vulnerability to replay attacks.
This option does *NOT* affect ZFS on-disk consistency.
Administrators should only use this when these risks are understood.
Notarás que incluso si disabled se elige, el diseño de su grupo/la coherencia interna no se ven afectados:solo perderá los últimos 5 segundos de datos y esto puede poner sus archivos en un estado incorrecto (por ejemplo, porque tiene una VM en la parte superior que espera escrituras sincronizadas pero solo proporcionó un zvol asíncrono como almacén de datos de respaldo).
Por otro lado, si no quieres perder nada , establezca todos sus sistemas de archivos en always y cambie a SSD de alto rendimiento, al menos para el dispositivo SLOG (o sufra los tiempos de espera).
standard es un compromiso y el más flexible:la aplicación misma decide qué modo de escritura necesita. Si sus aplicaciones son malas, puede experimentar pérdida de datos. Si se comportan bien, tendrá el mejor rendimiento posible con una línea de base dada de seguridad.
Exportación/importación de grupo:
De la documentación sobre zpool export :
El comando intenta desmontar cualquier sistema de archivos montado dentro del grupo antes de continuar. Si alguno de los sistemas de archivos no se puede desmontar, puede desmontarlo a la fuerza usando la opción -f.
Si los dispositivos no están disponibles en el momento de la exportación, los dispositivos no se pueden identificar como exportados limpiamente. Si uno de estos dispositivos se conecta posteriormente a un sistema sin ninguno de los dispositivos en funcionamiento, aparece como "potencialmente activo".
Si los volúmenes ZFS están en uso en el grupo, el grupo no se puede exportar, incluso con la opción -f. Para exportar un grupo con un volumen ZFS, primero asegúrese de que todos los consumidores del volumen ya no estén activos.
Esto significa aproximadamente tres cosas:
-fobliga a que el grupo se exporte forzando el desmontaje de todos los sistemas de archivos, incluso si están activos (sin tener en cuenta los bloqueos o las aplicaciones que escriben allí)- Esto no funciona con
zvols - No debe dividir los grupos y usarlos en diferentes sistemas (tenga cuidado con las situaciones de conmutación por error)
Resumen:
- Si todo lo que le importa es la consistencia en el disco, está listo para usar
export -fo un apagado completo - Si te importan todos los datos, usa
sync=alwaysy SSD rápidos - Con respecto a iSCSI/NFS como almacenes de datos para máquinas virtuales, esta descripción general también puede ser útil (extracto:use NFS o deshabilite la caché de reescritura de iSCSI en el host invitado/VM; desactive la máquina virtual antes de tomar una instantánea de ZFS, ZFS estará bien de todos modos, pero la máquina virtual invitada solo será compatible con fallas)
En respuesta a las preguntas de seguimiento de los comentarios (preguntas omitidas para las que no tengo respuestas útiles):
(1) “buenas noticias/COW”:¿qué pasaría si los bloques de nivel superior estuvieran a punto de actualizarse? ¿Siempre encontrará un bloque de nivel superior utilizable (incluso si apunta a versiones ligeramente antiguas del árbol de metadatos)? ¿Qué tan malo puede ser eso?
En el peor de los casos, el uberblock (el que está en la parte superior de todos los demás) está dañado en todos los dispositivos redundantes. Debido a que no hay un bloque encima, no puede reconstruirlo desde arriba, por lo que existen varias copias de cada uberblock (IIRC eran alrededor de 3 o 4), por lo que uno puede perderse y todavía hay una copia de reemplazo.
(2) Estoy familiarizado con TXG y uso ESXi. Usando APC UPS + buena PSU/hw + P3700 NVMe ZIL por lo que es una potencia decente + ZIL rápido. Pero es poco probable que todas las escrituras actuales se sincronicen y, como usted dice, sync=always es lento. Pero su respuesta plantea un pensamiento, podría hacer algunas pruebas de rendimiento. Estoy usando dedup (ahorro 4x, vale la pena), así que escribe =lento de todos modos (tiene que buscar DDT). El motivo es que sync=always solo afecta a la escritura, que de todos modos es lenta debido a DDT. Pero configurar sync=always fuerza ZIL, ZIL es muy rápido y eso hace que los TXG largos sean seguros, lo que podría significar que el acceso al disco es más eficiente. O podría matar la latencia. ¡Ni idea de cuál! ¡Tendría que intentarlo!
No tengo experiencia real con deduplicación, por lo que no puedo decir nada útil aquí, excepto que ya ha tomado buenas decisiones en hardware (baja latencia, alta IOPS de escritura aleatoria de 64k, interfaz NVMe). Solo podría ser más rápido si invierte en una unidad RAM permanente realmente costosa (ZeusRAM et al.).
(6) ¿Por "coherencia en el disco" quiere decir que ZFS es feliz y que el grupo es autoconsistente? No me preocupa si algunos archivos/directorios. termina con contenido no válido o no se mueve/elimina si el grupo desaparece repentinamente, o el sistema de archivos como NTFWS/VMFS en un zvol se corrompe internamente (es decir, como ZFS zvol está bien, pero desde la perspectiva del cliente necesita fsck/chkdsk), siempre que el grupo es seguro/coherente como lo ve ZFS
Sí. Esencialmente, "mi piscina no está jodida, ¡sí!" en una configuración multiusuario, incluso si un usuario tiene problemas con sus archivos, los demás no sufren.
(7) Por "coherencia con fallas" quiere decir lo que quiero decir (creo que sí):que ZFS estará bien, el grupo en la medida en que ZFS lo vea estará bien, pero los datos del cliente remoto pueden estar alterados desde ese cliente perspectiva similar a como si el cliente hubiera golpeado una falla repentina de E / S del disco y se hubieran perdido las escrituras? ==el grupo estará bien, el cliente puede haber perdido datos o ser inconsistentes y puede necesitar ayuda para recuperarse, como con cualquier otra falla de E/S de disco o bloqueo del sistema.
Sí, esencialmente un apagado completo de la VM en lugar de un apagado limpio y LUEGO tomar una instantánea; si la enciende después, fsck o similar, según el sistema de archivos, se ejecutará y es posible que se queje de un apagado incorrecto. Esto contrasta con las instantáneas de ESXi, que se reanudan en el momento exacto como si nada hubiera pasado, pero necesitan interacción con el sistema invitado (adiciones de invitados instaladas) e incluyen la memoria virtual de la VM.
Puede combinar ambos para su beneficio:primero tome una instantánea de ESXi, luego una instantánea de ZFS del almacén de datos (ESXi almacena sus instantáneas junto con la VM). Luego, elimine su instantánea de ESXi, pero conserve la de ZFS (ocupa mucho menos espacio debido a las copias a nivel de bloque). Al restaurar, primero restaure su instantánea de ZFS y luego vuelva a su instantánea de ESXi (guardada) y continuará donde lo dejó. napp-it (excelente sistema de administración ZFS con interfaz web) tiene este concepto incorporado (al menos para almacenes de datos NFS, no verifiqué iSCSI pero asumo que es similar).