Zfs: Solicitud de función: clon dividido en línea

Parece que zfs promote ya puede hacer lo que necesita.

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

Estaba viendo la promoción de zfs, pero esto parece solo cambiar la relación entre padres e hijos ...

lo que estaba pensando era un estado final en el que ambos sistemas de archivos son completamente independientes entre sí ...

algunos casos de uso para esto podrían ser
clonación de plantillas de VM: tener una imagen base que se clona para crear otras VM, que a su vez se separan de la plantilla para que la plantilla se pueda actualizar / destruir / volver a crear
Clones de base de datos: clonación de una base de datos prod para dev que sufrirá muchos cambios y que a su vez podría ser la base para un clon de prueba en sí mismo, en el caso de que sería bueno dividir el dev de prod ya que la instantánea base podría crecer que tener un sistema de archivos independiente para desarrolladores

Después de clonar la instantánea @ original , puede modificar el conjunto de datos y clonar libremente, no se afectarán entre sí, excepto que comparten datos que aún son comunes a ambos en el disco.

Si desea destruir / recrear la plantilla (original), simplemente puede destruir todas las instantáneas en ella (excepto las que se usan como orígenes de los clones), zfs renombra original y zfs crea una nueva con el mismo nombre (propiedad de origen of clones no está vinculado al nombre del conjunto de datos original, por lo que puede cambiar el nombre de ambos libremente).

El único inconveniente es que todos los datos _únicos_ contenidos en la instantánea @ original (= base del clon) no se pueden publicar a menos que esté dispuesto a destruir los clones o (después de una promoción del clon) el original.

@ greg -rogen al final, ¿determinaste si zfs promote satisface tus necesidades? ¿O todavía hay una posible solicitud de función aquí?

Para comentar sobre esto, sería bueno si hubiera una funcionalidad para transformar las relaciones origen-clon en un tipo deduplicado: eliminar los enlaces lógicos que evitan que los conjuntos de datos se destruyan individualmente a voluntad, mientras se mantiene solo una copia de la aún compartida datos.

@behlendorf : es casi seguro que no satisface la necesidad.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
hace un buen trabajo al explicar el problema.

Esto es lo que intento hacer conceptualmente:

usuario @ copia de seguridad :

1. generar una instantánea basada en la fecha
2. enviarlo desde la copia de seguridad para probarlo como espejo

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

usuario @ prueba :

1. crear un lugar para desinfectar el espejo
2. desinfectarlo
3. instantánea
4. clonar la versión desinfectada para su uso
5. usarlo

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

usuario @ copia de seguridad :

1. habiendo utilizado la producción más ...
2. crear una instantánea actualizada
3. enviar los cambios incrementales de prod a prueba
4. eliminar el marcador incremental anterior (que en mi caso libera 70GB)

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

usuario @ prueba :

• aquí es donde aparecen los problemas.
• con cierta cantidad de halagos, se pueden destruir los volúmenes de desinfección.
• Pero, me quedo con test/mirror@20170901 que es el origen de las dos cosas restantes: test/mirror@20170908 y test/test .
• Podría destruir el espejo actualizado ( test/mirror@20170908 ) si quisiera, pero eso no me sirve de nada (ya que mi objetivo es usar esos datos).

Para poder progresar, en realidad tengo que ejecutar desinfectar, detener lo que está usando la prueba, destruir la prueba (completamente), clonar el espejo como prueba, reiniciar la cosa usando la prueba, y luego finalmente puedo intentar destruir el original. instantánea. O puedo decidir que voy a aprobar, activar una nueva instantánea en la copia de seguridad más tarde y enviar su incremento, eliminar la instantánea que nunca se reflejó para probar e intentar nuevamente.

Fwiw, para probar esto ...:

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

(los números son realmente incorrectos, en realidad tengo 1 volumen con 4 volúmenes contenidos, de ahí las banderas recursivas ...)

Ahora, entiendo que puedo usar zfs send | zfs recv para romper dependencias, y para cosas pequeñas está bien. Pero esta parte de mi grupo es aproximadamente el doble del espacio disponible en el grupo, y la mitad es probablemente más grande que eso, lo que significa que realizar esa operación es problemático. También es una gran cantidad de bytes para reprocesar. Mi esperanza al usar instantáneas era poder beneficiarme de COW, pero en cambio, me cobran por COW porque el punto de ramificación que eventualmente tendrá datos utilizados por ninguno de los lados de mi árbol de ramificación aún debe pagarse.

@behlendorf Hola, ¿algún progreso en esto? Dividir el clon de su sistema de archivos original será realmente bueno para las plantillas de VM y / o la restauración a nivel de archivo grande. Vea el enlace @jsoref pegado arriba para ver un ejemplo práctico.

@kpande : el objetivo es pagar (en espacio y transferencia de datos) por lo que ha cambiado (COW), no por todo el conjunto de datos (cada vez que ocurre esta operación).

Si tuviera un conjunto de datos móviles de 10 TB y una variación del conjunto de datos que quiero establecer, claro, podría copiar los 10 TB, aplicar la variación y pagar 20 TB (si tengo 20 TB disponibles). Pero, si mi variación es en realidad solo 10 MB diferente de los 10 TB originales, ¿por qué no debería poder pagar 10 TB + 10 MB? - Las instantáneas + los clones me dan eso. Hasta que los 10TB se muevan lo suficiente, ahora estoy pagando por 10TB (en vivo + 10TB instantánea + 10TB divergieron) y mi variación de 10MB se mueve para que ahora sea su propia 10TB (divergente tanto de en vivo como de instantánea). Mientras tanto, para "arreglar" mi problema de 30TB, tengo que gastar otros 10TB (= 40TB - a través de su zfs send + zfs recv). Eso no es ideal. Seguro, "funcionará", pero no es ni "rápido" ni remotamente eficiente en el espacio.

El envío / recepción redactado suena interesante (ya que coincide más o menos con mi caso de uso), pero aunque puedo encontrarlo mencionado en muchos lugares, no puedo encontrar ninguna explicación útil de lo que realmente está redactando.

Fwiw, para nuestro sistema, cambié para que la desinfección ocurra en el lado de envío (que también es mejor desde una perspectiva de privacidad), lo que en su mayoría nos sacó de peligro.

Hay instancias en las que la variación de datos no se está "redactando" y donde el sistema tiene los recursos para zfs snapshot + zfs send pero realmente no quiere asignar los recursos para alojar una segunda base de datos para hacer la "mutación" - no quiere tener que pagar para enviar todo el volumen entre el primario y el secundario (es decir, preferiría enviar una instantánea incremental a un sistema que ya tiene la instantánea anterior).

Sí, sé que podría usar la deduplicación. Estamos pagando por nuestro cpus / ram, por lo que dedicar cpu + ram constante para hacer una tarea rara (actualizar clon mutado) se sintió rápidamente como una compensación pobre (prefiero pagar por un poco más de espacio en disco).

@kpande este enlace muestra claramente el problema con los clones actuales. Después de todo, si un clon diverge tanto de la instantánea base, la relación padre-> hijo permanente entre los dos es una fuente de confusión. Dividir el clon sería una clara indicación de que divergieron tanto como para que ya no se los considere atados.

Pero déjeme hacer un ejemplo más práctico.

Deje que kvm/vmimages sea ​​un contenedor de almacén de datos para varias imágenes de disco virtual, con instantáneas tomadas a diario. Sé que la respuesta predeterminada sería "usar un conjunto de datos para cada disco", pero los grupos libvirt no funcionan bien con eso. Entonces tenemos algo como:

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

En algún momento, algo malo le sucede al disco vm (es decir: daños graves en el sistema de archivos del invitado), pero mientras tanto, otros usuarios almacenan activamente datos nuevos e importantes en los otros discos. Básicamente, tiene algunos requisitos contrastantes: a) volver a los datos antiguos, no corruptos, de ayer, b) preservar los datos nuevos cargados, que no se encuentran en ninguna instantánea yc) causar una interrupción mínima del servicio.

Los clones vienen a la mente como una posible solución: puede clonar kvm/vmimages@snap3 como kvm/restored para restaurar inmediatamente el servicio para la máquina virtual afectada. Entonces ahora tienes:

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

La VM afectada se ejecuta desde kvm/restored , mientras que todas las demás permanecen en kvm/vmimages . En este punto, borra todos los discos adicionales de kvm/restored y el disco original dañado de kvm/vmimages . Todo parece estar bien, hasta que te das cuenta de que la vieja imagen de disco dañada todavía está usando espacio de disco real, y cualquier sobrescritura en kvm/restored consume espacio adicional debido al antiguo e imborrable kvm/vmimages@snap3 . No puede eliminar esta instantánea anterior sin eliminar también su clon, y no puede simplemente promover kvm/restored y eliminar kvm/vmimages porque no es la única fuente de datos "autorizada" verdadera (es decir, los datos reales son almacenados dentro de ambos conjuntos de datos).

Dividir un clon de su fuente resolvería completamente el problema anterior. No me queda claro cómo ayudaría el envío / recepción redactado en este caso.

@kpande primero, gracias por compartir su vista y su solución (¡lo cual es interesante!). Estoy totalmente de acuerdo en que una configuración de invitado cuidadosa y muy específica (y un árbol de conjunto de datos de host) puede evitar el problema expuesto anteriormente.

Dicho esto, libvirt (y su implementación de grupos de almacenamiento) no funciona muy bien con este enfoque, especialmente cuando se administran entornos mixtos con máquinas virtuales de Windows. Aún más, este fue solo un ejemplo. Los clones dividibles serían muy útiles, por ejemplo, cuando se usan para crear una "imagen maestra / base de oro", que se puede instanciar a voluntad para crear máquinas virtuales "reales".

Con el estado actual del asunto, haciendo que será impuesto que en gran medida en el espacio asignado, ya que no será capaz de eliminar alguna vez el original, potencialmente obsoleta, instantánea. Lo que me sorprende es que, al ser ZFS un sistema de archivos CoW, debería ser una operación relativamente simple: al eliminar la instantánea original, "simplemente" marque como libre cualquier bloque no referenciado y elimine la relación padre / hijo. En otras palabras, dejemos que el clon sea un sistema de archivos real, desenredado de cualquier instantánea de origen.

Tenga en cuenta que utilicé el mundo "simplemente" entre comillas: si bien es una operación lógica simple, no estoy seguro de si se corresponde con el sistema de archivos zfs subyacente o qué tan bien se asigna.

@kpande ok, bastante justo, si existe un problema técnico real, debo aceptarlo. Pero esto es diferente a afirmar que un caso de uso específico no es válido.

Si esta vista (es decir, la imposibilidad de dividir un clon de su instantánea principal original sin involucrar al "mítico" BPR) es compartida por los desarrolladores de zfs, creo que este FR puede cerrarse.

Gracias.

+1 al necesitar esta función. Sí, se podría usar send / recv, pero eso requeriría un tiempo de inactividad de lo que esté usando ese conjunto de datos para cambiar del antiguo (clon) al nuevo conjunto de datos.

Me he encontrado con situaciones con LXD en las que se copia (clona) un contenedor, pero eso causa problemas con mis instantáneas administradas por separado.

@kpande : de nuevo, mi caso de uso tiene todo el conjunto de datos como una base de datos y un par de variaciones de la base de datos.

Por lo que he visto, no parece que overlayfs se reproduzca bien con / zfs como sistema de archivos (parece feliz con / zvols y ext4 / xfs según sus notas). Suena como que este enfoque cubriría la mayoría de los casos, en cuyo caso la documentación que explique cómo configurar overlayfs con ext4 / xfs sería bienvenida.

Dicho esto, algunos de nosotros estamos usando zfs no solo para la administración del volumen sino también para el comportamiento / navegación acl / allow / snapshot, y nos gustaría poder usar overlayfs w / zfs en lugar de ext4 / xfs, así que si eso no es No es posible, ¿hay algún error para eso? Si lo hay, sería bueno si eso estuviera resaltado (desde aquí), si no, si respalda el enfoque de overlayfs, tal vez pueda archivarlo (si insiste, probablemente podría escribirlo, pero no lo hago) No sé nada sobre overlayfs, y eso parece una tecnología clave en la redacción).

Por lo que he visto, no parece que overlayfs se reproduzca bien con / zfs como sistema de archivos (parece feliz con / zvols y ext4 / xfs según sus notas). Suena como que este enfoque cubriría la mayoría de los casos, en cuyo caso la documentación que explique cómo configurar overlayfs con ext4 / xfs sería bienvenida.

El enfoque overlayfs no funcionará para un caso de uso común y extremadamente importante: clonar una imagen virtual a partir de otra (o una plantilla "maestra de oro"). En tal caso, dividir el clon sería clave para evitar el desperdicio de espacio ya que las imágenes originales / clonadas divergen.

@ ptx0, esto solo funciona si el sistema operativo invitado admite overlayfs (por lo que no hay soporte para VM de Windows) y si el usuario final (es decir, nuestros clientes) está dispuesto a cambiar significativamente el aprovisionamiento / instalación de las imágenes de su VM. Como nota al margen, aunque entiendo completamente - y acepto - este PR cerrado sobre una base técnica (por ejemplo: si involucra BPR), es bastante frustrante tener un caso de usuario legítimo marcado como "inválido". Si no es su caso de uso, está bien. Pero no suponga que nadie tiene un caso de uso válido para esta función.

Windows no necesita overlayfs, tiene un redireccionamiento de carpetas integrado y perfiles móviles.

La redirección de carpetas, aunque existe desde NT, no siempre funciona de manera confiable, ya que existe un software que (por razones desconocidas) no maneja las carpetas redirigidas correctamente y simplemente falla cuando se enfrenta a un escritorio o documentos redirigidos. Aparte de eso, los clones de las instalaciones de Windows divergen, por sí mismos, de forma masiva y bastante rápida desde el origen, cortesía de Windows Update: tener diferentes usuarios iniciando y desconectando solo acelera esto.