Zfs: Demande de fonctionnalité - clone fractionné en ligne

Il semble que zfs promote déjà ce dont vous avez besoin.

       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.

Je cherchais à promouvoir zfs, mais cela semble simplement inverser la relation parent-enfant ...

ce que je pensais était un état final où les deux systèmes de fichiers sont complètement indépendants l'un de l'autre ...

certains cas d'utilisation pourraient être
cloner des modèles de VM - avoir une image de base qui est clonée pour créer d'autres VM, qui sont à leur tour séparées du modèle afin que le modèle puisse être mis à jour / détruit / recréé
clones de base de données - clonage d'une base de données prod pour dev qui subira de nombreux changements et qui à son tour pourrait être la base d'un clone de test lui-même, dans le cas où il serait bien de séparer le développement de prod car l'instantané de base pourrait devenir plus grand que d'avoir un système de fichiers indépendant pour le développement

Après avoir cloné l' original @ snapshot, vous pouvez modifier à la fois l'ensemble de données et le cloner librement, ils ne s'affecteront pas, sauf qu'ils partagent des données toujours communes aux deux sur le disque.

Si vous souhaitez détruire / recréer le modèle (original), vous pouvez simplement détruire tous les instantanés qu'il contient (sauf celui (s) utilisé (s) comme origine des clones), zfs renommer l'original et zfs en créer un nouveau avec le même nom (propriété d'origine of clones n'est pas lié au nom de l'ensemble de données d'origine, vous pouvez donc renommer les deux librement).

Le seul inconvénient est que toutes les données _uniques_ contenues dans l'instantané @ original (= base du clone) ne peuvent pas être libérées à moins que vous ne souhaitiez détruire le ou les clones ou (après une promotion du clone) l'original.

@ greg-hydrogène à la fin avez-vous déterminé si zfs promote répondait à vos besoins? Ou y a-t-il encore une demande de fonctionnalité possible ici.

Pour commenter cela, ce serait bien s'il y avait une fonctionnalité pour transformer les relations origine-clone en un type dédoublé: en supprimant les liens logiques qui empêchent les ensembles de données d'être détruits individuellement à volonté - tout en ne conservant qu'une seule copie du reste partagé Les données.

@behlendorf : cela ne répond presque certainement pas au besoin.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
fait un bon travail pour expliquer le problème.

Voici ce que j'essaye de faire conceptuellement:

utilisateur @ sauvegarde :

1. générer un instantané basé sur la date
2. envoyez-le de la sauvegarde au test en tant que miroir

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

utilisateur @ test :

1. créer un endroit pour désinfecter le miroir
2. désinfectez-le
3. instantané
4. cloner la version désinfectée pour utilisation
5. utilise le

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

utilisateur @ sauvegarde :

1. ayant utilisé davantage la production ...
2. créer un instantané mis à jour
3. envoyer les modifications incrémentielles de la production au test
4. supprimer le marqueur incrémentiel précédent (qui dans mon cas libère 70 Go)

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>

utilisateur @ test :

• c'est là que les problèmes apparaissent.
• avec un peu de cajolage, on peut détruire les volumes désinfectants.
• Mais, il me reste test/mirror@20170901 qui est l'origine des deux choses restantes: test/mirror@20170908 et test/test .
• Je pourrais détruire le miroir mis à jour ( test/mirror@20170908 ) si je le voulais, mais cela ne me fait aucun bien (puisque mon objectif est d'utiliser ces données).

Pour que je progresse, je dois en fait passer par sanitize, arrêter la chose qui utilise test, détruire le test (complètement), cloner le miroir comme test, redémarrer la chose en utilisant test, puis je peux enfin essayer de détruire l'original instantané. Ou, je peux décider que je vais prendre une passe, déclencher un nouvel instantané lors de la sauvegarde plus tard, et envoyer son incrément, supprimer l'instantané qui n'a jamais été mis en miroir pour le tester, et réessayer.

Fwiw, pour avoir un avant-goût de ceci ...:

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>

(les chiffres sont vraiment faux, j'ai en fait 1 volume avec 4 volumes contenus, d'où les drapeaux récursifs ...)

Maintenant, je comprends que je peux utiliser zfs send | zfs recv pour briser les dépendances, et pour de petites choses c'est bien. Mais cette partie de ma piscine représente environ le double de l'espace disponible dans la piscine, et la moitié est probablement plus grande que cela, ce qui signifie que l'exécution de cette opération est problématique. C'est aussi une énorme quantité d'octets à retraiter. Mon espoir d'utiliser des instantanés était de pouvoir bénéficier de COW, mais à la place, je suis facturé pour COW car le point de branchement qui aura finalement des données utilisées par aucun côté de mon arbre de ramification doit toujours être payé.

@behlendorf Salut, des progrès à ce sujet? Séparer le clone de son système de fichiers d'origine sera vraiment idéal pour les modèles de VM et / ou la restauration de gros fichiers. Voir le lien @jsoref collé ci-dessus pour un exemple pratique.

@kpande : l'objectif est de payer (en espace et en transfert de données) ce qui a changé (COW), pas pour l'ensemble des données (à chaque fois que cette opération se produit).

Si j'avais un ensemble de données mobiles de 10 To et une variante de l'ensemble de données que je veux établir, bien sûr, je pourrais copier les 10 To, appliquer la variation et payer 20 To (si j'ai 20 To disponibles). Mais, si ma variante n'est vraiment différente que de 10 Mo par rapport aux 10 To d'origine, pourquoi ne serais-je pas en mesure de payer pour 10 To + 10 Mo? - instantanés + clones me donnent ça. Jusqu'à ce que les 10 To bougent suffisamment pour que je paie maintenant pour 10 To (instantané en direct + 10 To + 10 To divergé) et ma variation de 10 Mo se déplace de sorte qu'il s'agit maintenant de son propre 10 To (divergeant à la fois du direct et de l'instantané). En attendant, pour "résoudre" mon problème de 30 To, je dois dépenser 10 To supplémentaires (= 40 To - via votre envoi zfs + recv zfs). Ce n'est pas idéal. Bien sûr, cela «fonctionnera», mais ce n'est ni «rapide» ni efficace à distance.

L'envoi / recv expurgé semble intéressant (car il correspond plus ou moins à mon cas d'utilisation) - mais bien que je puisse le trouver mentionné à plusieurs endroits, je ne trouve aucune explication utile de ce qu'il est en fait en train de rédiger.

Fwiw, pour notre système, j'ai changé pour que la désinfection se produise du côté de l'envoi (ce qui est également mieux du point de vue de la confidentialité), ce qui nous a surtout fait sortir du bois.

Il y a des instances où la variation de données n'est pas "réductrice" et où le système a les ressources pour le snapshot zfs + zfs envoyer mais ne veut pas vraiment allouer les ressources pour héberger une deuxième base de données pour faire la "mutation" - et ne veut pas avoir à payer pour envoyer le volume entier entre le primaire et le secondaire (c'est-à-dire qu'il préfère envoyer un instantané incrémentiel à un système qui possède déjà l'instantané précédent).

Oui, je suis conscient que je pourrais utiliser la dédup. Nous payons pour nos cpus / ram, donc dédier constamment cpu + ram pour faire une tâche rare (rafraîchir le clone muté) rapidement ressenti comme un mauvais compromis (je préfère payer un peu plus d'espace disque).

@kpande ce lien montre assez clairement le problème avec les clones actuels. Après tout, si un clone diverge tellement de l'instantané de base, la relation permanente parent-> enfant entre les deux est une source de confusion. Le fractionnement du clone indiquerait clairement qu'ils ont tellement divergé qu'ils ne sont plus considérés comme liés.

Mais laissez-moi faire un exemple plus pratique.

Soit kvm/vmimages un conteneur de banque de données pour plusieurs images de disque virtuel, avec des instantanés pris quotidiennement. Je sais que la réponse par défaut serait "utiliser un ensemble de données pour chaque disque", mais les pools libvirt ne fonctionnent pas bien avec cela. Nous avons donc quelque chose comme:

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

À un moment donné, quelque chose de mauvais arrive au disque vm (c'est-à-dire: une grave corruption du système de fichiers invité), mais entre-temps, d'autres utilisateurs stockent activement de nouvelles données importantes sur les autres disques. Vous avez fondamentalement des exigences différentes: a) revenir aux anciennes données non corrompues d'hier, b) conserver toutes les nouvelles données téléchargées, qui ne se trouvent dans aucun instantané et c) provoquer une interruption de service minimale.

Les clones viennent à l'esprit comme solution possible: vous pouvez cloner kvm/vmimages@snap3 tant que kvm/restored pour restaurer immédiatement le service pour la machine virtuelle affectée. Vous avez donc maintenant:

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 affectée fonctionne à partir de kvm/restored , tandis que toutes les autres restent sur kvm/vmimages . À ce stade, vous supprimez tous les disques supplémentaires de kvm/restored et le disque d'origine corrompu de kvm/vmimages . Tout semble bien, jusqu'à ce que vous vous rendiez compte que l'ancienne image disque corrompue utilise toujours de l'espace disque réel et que tout écrasement dans kvm/restored consomme de l'espace supplémentaire en raison de l'ancien kvm/vmimages@snap3 . Vous ne pouvez pas supprimer cet ancien instantané sans supprimer également votre clone, et vous ne pouvez pas simplement promouvoir kvm/restored et supprimer kvm/vmimages car ce n'est pas la seule véritable source de données "faisant autorité" (c'est-à-dire: les données réelles sont stocké dans les deux ensembles de données).

Séparer un clone de sa source résoudrait complètement le problème ci-dessus. Il n'est pas clair pour moi comment l'envoi / recv expurgé aiderait dans ce cas.

@kpande d' abord, merci de partager votre avis et votre solution (ce qui est intéressant!). Je suis tout à fait d'accord qu'une configuration d'invité (et un arbre de jeu de données hôte) soigneuse et très spécifique peut éviter le problème exposé ci-dessus.

Cela dit, libvirt (et son implémentation de pools de stockage) ne joue pas très bien avec cette approche, en particulier lors de la gestion d'environnements mixtes avec des machines virtuelles Windows. Encore plus, ce n’était qu’un seul exemple. Les clones fractionnables seraient très utiles, par exemple, lorsqu'ils sont utilisés pour créer une "image de base / maître d'or", qui peut être instanciée à volonté pour créer de "vraies" machines virtuelles.

Avec l'état actuel des choses, cela vous imposera beaucoup d'espace alloué, car vous ne pourrez jamais supprimer l'instantané original, potentiellement obsolète. Ce qui me surprend, c'est que, étant ZFS un système de fichiers CoW, cela devrait être une opération relativement simple: lors de la suppression de l'instantané d'origine, marquez "simplement" comme libre tout bloc non référencé et supprimez la relation parent / enfant. En d'autres termes, laissez être le clone d'un véritable système de fichiers, démêlé de tout instantané source.

Notez que j'ai utilisé le monde "simplement" entre guillemets: bien qu'il s'agisse en effet d'une simple opération logique, je ne suis pas sûr si / dans quelle mesure il correspond au système de fichiers zfs sous-jacent.

@kpande ok, c'est juste - s'il y a un vrai problème technique, je dois l'accepter. Mais c'est différent de déclarer qu'un cas d'utilisation spécifique est invalide.

Si ce point de vue (ie: impossibilité de séparer un clone de son instantané parent d'origine sans impliquer le BPR "mythique") est partagé par les développeurs zfs, je pense que ce FR peut être fermé.

Merci.

+1 pour avoir besoin de cette fonctionnalité. Oui, send / recv pourrait être utilisé, mais cela nécessiterait un temps d'arrêt de tout ce qui utilise cet ensemble de données pour passer de l'ancien (clone) au nouvel ensemble de données.

J'ai rencontré des situations avec LXD où un conteneur est copié (cloné), mais cela pose des problèmes avec mon instantané géré séparément.

@kpande : encore une fois, mon cas d'utilisation a tout le jeu de données étant une base de données, et quelques variantes de la base de données.

D'après ce que j'ai vu, il ne semble pas que overlayfs joue bien avec / zfs en tant que système de fichiers (il semble heureux avec / zvols et ext4 / xfs selon vos notes). Cela ressemble à cette approche pour couvrir la plupart des cas, auquel cas une documentation expliquant comment configurer overlayfs w / ext4 / xfs serait la bienvenue.

Cela dit, certains d'entre nous utilisent zfs non seulement pour la gestion des volumes, mais également pour le comportement / la navigation acl / allow / snapshot, et aimeraient pouvoir utiliser overlayfs w / zfs au lieu de ext4 / xfs, donc si cela n'est pas c'est pas possible, y a-t-il un bug pour ça? S'il y en a, ce serait bien si cela était mis en évidence (à partir d'ici), sinon, si vous approuvez l'approche overlayfs, peut-être que vous pourriez le déposer (si vous insistez, je pourrais probablement l'écrire, mais je ne le fais pas) Je ne sais rien des overlayfs, et cela semble être une technologie clé dans la rédaction).

D'après ce que j'ai vu, il ne semble pas que overlayfs joue bien avec / zfs en tant que système de fichiers (il semble heureux avec / zvols et ext4 / xfs selon vos notes). Cela ressemble à cette approche pour couvrir la plupart des cas, auquel cas une documentation expliquant comment configurer overlayfs w / ext4 / xfs serait la bienvenue.

L'approche overlayfs ne fonctionnera

@ ptx0 cela ne fonctionne que si le système d'exploitation invité prend en charge overlayfs (donc pas de prise en charge des VM Windows) et si l'utilisateur final (c'est-à-dire: nos clients) est prêt à modifier de manière significative le provisionnement / l'installation de leurs images de VM. En passant, même si je comprends parfaitement - et accepte - ce PR fermé sur une base technique (par exemple: s'il s'agit de BPR), il est assez frustrant d'avoir un cas d'utilisateur légitime marqué comme "invalide". Si ce n'est pas votre cas d'utilisation, très bien. Mais veuillez ne pas supposer que personne n'a de cas d'utilisation valide pour cette fonctionnalité.

Windows n'a pas besoin de overlayfs, il a intégré la redirection de dossier et les profils itinérants.

La redirection de dossiers, bien qu'elle existe depuis NT, ne fonctionne pas toujours de manière fiable car il existe des logiciels qui (pour des raisons obscures) ne gèrent pas correctement les dossiers redirigés et échouent simplement lorsqu'ils sont confrontés à un bureau ou des documents redirigés. En dehors de cela, les clones des installations Windows divergent, tous seuls, massivement et assez rapidement de l'origine, grâce à Windows Update - le fait que différents utilisateurs se connectent et se déconnectent ne fait qu'accélérer cela.