Zfs: Feature Request - Online Split Clone

Es klingt so, als ob zfs promote bereits das tun könnte, was Sie brauchen.

       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.

Ich habe mir zfs bewerben angesehen, aber dies scheint nur die Eltern-Kind-Beziehung umzudrehen ...

Was ich dachte, war ein Endzustand, in dem beide Dateisysteme völlig unabhängig voneinander sind ...

Einige Anwendungsfälle hierfür könnten sein
Klonen von VM-Vorlagen - mit einem Basis-Image, das geklont wird, um andere VMs zu erstellen, die wiederum von der Vorlage getrennt werden, damit die Vorlage aktualisiert / zerstört / neu erstellt werden kann
Datenbankklone - Klonen einer Prod-Datenbank für Entwickler, die viele Änderungen erfahren wird und die wiederum die Basis für einen Testklon selbst sein könnte. In dem Fall wäre es schön, den Entwickler von Prod zu trennen, da der Basis-Snapshot möglicherweise größer wird als mit einem unabhängigen Dateisystem für dev

Nachdem Sie original @ snapshot geklont haben, können Sie sowohl Dataset als auch Klon frei ändern. Sie wirken sich nicht gegenseitig aus, außer dass sie Daten gemeinsam nutzen, die beiden auf der Festplatte noch gemeinsam sind.

Wenn Sie die Vorlage (Original) zerstören / neu erstellen möchten, können Sie einfach alle Snapshots darauf zerstören (mit Ausnahme derjenigen, die als Ursprung von Klonen verwendet werden). Zfs benennt das Original um und zfs erstellt ein neues mit demselben Namen (Ursprungseigenschaft) von Klonen ist nicht an den Namen des Originaldatensatzes gebunden, sodass Sie beide frei umbenennen können.

Der einzige Nachteil dabei ist, dass alle _unique_-Daten, die im ursprünglichen @ snapshot (= Basis des Klons) enthalten sind, nur freigegeben werden können, wenn Sie bereit sind, entweder den / die Klon (e) oder (nach einer Heraufstufung des Klons) das Original zu zerstören.

@ Greg-Hydrogen Am Ende haben Sie festgestellt, ob zfs promote Ihren Anforderungen entspricht? Oder gibt es hier noch eine mögliche Feature-Anfrage.

Um dies zu kommentieren, wäre es schön, wenn es eine Funktion gäbe, mit der Ursprungs-Klon-Beziehungen in eine dedupierte Art umgewandelt werden können: Entfernen der logischen Verknüpfungen, die verhindern, dass die Datensätze nach Belieben einzeln zerstört werden - während nur eine Kopie der noch freigegebenen beibehalten wird Daten.

@behlendorf : es entspricht mit ziemlicher Sicherheit nicht dem Bedarf.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
erklärt das Problem gut.

Folgendes versuche ich konzeptionell zu tun:

user @ backup :

1. Generieren Sie einen datumsbasierten Schnappschuss
2. Senden Sie es vom Backup zum Test als Spiegel

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

user @ test :

1. Schaffen Sie einen Ort, an dem Sie den Spiegel desinfizieren können
2. Desinfizieren Sie es
3. Schnappschuss es
4. Klonen Sie die bereinigte Version zur Verwendung
5. benutze es

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

user @ backup :

1. Produktion weiter genutzt ...
2. Erstellen Sie einen aktualisierten Schnappschuss
3. Senden Sie die inkrementellen Änderungen von Produkt zu Test
4. Löschen Sie den vorherigen inkrementellen Marker (der in meinem Fall 70 GB freigibt).

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>

user @ test :

• Hier treten Probleme auf.
• Mit etwas Cajoling kann man die Desinfektionsvolumina zerstören.
• Aber ich habe noch test/mirror@20170901 was der Ursprung für die beiden verbleibenden Dinge ist: test/mirror@20170908 und test/test .
• Ich könnte den aktualisierten Spiegel ( test/mirror@20170908 ) zerstören, wenn ich wollte, aber das nützt mir nichts (da mein Ziel darin besteht, diese Daten zu verwenden).

Um Fortschritte zu erzielen, muss ich tatsächlich die Desinfektion durchlaufen, das Testobjekt stoppen, den Test (vollständig) zerstören, den Spiegel als Test klonen, das Testobjekt neu starten und dann endlich versuchen, das Original zu zerstören Schnappschuss. Oder ich kann entscheiden, ob ich einen Pass nehmen, später einen neuen Snapshot bei der Sicherung auslösen und dessen Inkrement senden möchte, den Snapshot löschen, der zum Testen nie gespiegelt wurde, und es erneut versuchen.

Fwiw, um einen Vorgeschmack darauf zu bekommen ...:

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>

(Die Zahlen sind wirklich falsch, ich habe tatsächlich 1 Volume mit 4 enthaltenen Volumes, daher die rekursiven Flags ...)

Jetzt verstehe ich, dass ich zfs send | zfs recv , um Abhängigkeiten zu lösen, und für kleine Dinge ist das in Ordnung. Aber dieser Teil meines Pools ist ungefähr doppelt so groß wie der verfügbare Platz im Pool, und eine Hälfte ist wahrscheinlich größer als diese, was bedeutet, dass die Durchführung dieser Operation problematisch ist. Es ist auch eine große Menge an Bytes zu verarbeiten. Meine Hoffnung bei der Verwendung von Snapshots war es, von COW profitieren zu können. Stattdessen wird mir COW in Rechnung gestellt, da der Verzweigungspunkt, an dem möglicherweise Daten von keiner Seite meines Verzweigungsbaums verwendet werden, noch bezahlt werden muss.

@behlendorf Hallo, irgendwelche Fortschritte in diesem Bereich? Splitting - Klon aus seinem ursprünglichen Dateisystem wird für VMs Vorlagen und / oder große Dateiebene wiederherstellen wirklich groß sein. Ein praktisches Beispiel finden Sie unter dem oben eingefügten Link

@kpande : Das Ziel ist es, (in

Wenn ich ein 10-TB-Moving-Dataset und eine Variation des Datasets hätte, die ich erstellen möchte, könnte ich die 10 TB kopieren, die Variation anwenden und für 20 TB bezahlen (wenn ich 20 TB zur Verfügung habe). Aber wenn meine Variation wirklich nur 10 MB von den ursprünglichen 10 TB abweicht, warum sollte ich dann nicht in der Lage sein, für 10 TB + 10 MB zu bezahlen? - Schnappschüsse + Klone geben mir das. Bis sich die 10 TB so weit bewegen, dass ich jetzt für 10 TB bezahle (Live + 10 TB Snapshot + 10 TB divergiert) und meine 10 MB-Variation sich so bewegt, dass es jetzt ihre eigenen 10 TB sind (sowohl von Live als auch von Snapshot abweichend). In der Zwischenzeit muss ich weitere 10 TB ausgeben (= 40 TB - über Ihr zfs send + zfs recv), um mein 30-TB-Problem zu "beheben". Das ist nicht ideal. Sicher, es wird "funktionieren", aber es ist weder "schnell" noch aus der Ferne platzsparend.

Das redigierte Senden / Empfangen klingt interessant (da es mehr oder weniger meinem Anwendungsfall entspricht) - aber obwohl ich es an einigen Stellen erwähnt finde, kann ich keine nützliche Erklärung dafür finden, was es tatsächlich redigiert.

Fwiw, für unser System habe ich so gewechselt, dass die Desinfektion auf der sendenden Seite stattfindet (was auch aus Sicht der Privatsphäre besser ist), was uns meistens aus dem Wald gebracht hat.

Dies sind Fälle, in denen die Datenvariation nicht "redigiert" und das System über die Ressourcen für zfs-Snapshot + zfs-Senden verfügt, die Ressourcen jedoch nicht wirklich dem Host einer zweiten Datenbank zuweisen möchte, um die "Mutation" durchzuführen - und Sie müssen nicht zahlen müssen, um das gesamte Volume zwischen primär und sekundär zu senden (dh es wird lieber ein inkrementeller Snapshot an ein System gesendet, das bereits über den vorherigen Snapshot verfügt).

Ja, ich bin mir bewusst, dass ich Dedup verwenden könnte. Wir zahlen für unseren CPU / RAM, daher fühlte es sich schnell wie ein schlechter Kompromiss an, konstante CPU + RAM für eine seltene Aufgabe (mutierten Klon aktualisieren) zu verwenden (ich würde lieber für etwas mehr Speicherplatz bezahlen).

@kpande Dieser Link zeigt ganz deutlich das Problem mit aktuellen Klonen. Wenn ein Klon so stark vom Basis-Snapshot abweicht, ist die permanente Eltern-Kind-Beziehung zwischen beiden eine Quelle der Verwirrung. Das Aufteilen des Klons wäre ein klarer Hinweis darauf, dass sie so weit auseinander gingen, dass sie nicht mehr als gebunden angesehen wurden.

Aber lassen Sie mich ein praktischeres Beispiel machen.

kvm/vmimages sei ein Datenspeichercontainer für mehrere Images virtueller Festplatten, wobei täglich Snapshots erstellt werden. Ich weiß, dass die Standardantwort "Verwenden Sie einen Datensatz für jede Festplatte" wäre, aber libvirt-Pools spielen damit nicht gut. Wir haben also etwas wie:

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

Irgendwann passiert etwas Schlimmes mit der VM-Festplatte (dh schwerwiegende Beschädigung des Gastdateisystems), aber in der Zwischenzeit speichern andere Benutzer aktiv neue, wichtige Daten auf den anderen Festplatten. Grundsätzlich haben Sie einige gegensätzliche Anforderungen: a) auf die alten, nicht beschädigten Daten von gestern zurückzugreifen, b) neue hochgeladene Daten beizubehalten, die in keinen Snapshots enthalten sind, und c) eine minimale Dienstunterbrechung zu verursachen.

Klone kommen als mögliche Lösung in den Sinn: Sie können kvm/vmimages@snap3 als kvm/restored klonen, um den Dienst für die betroffene VM sofort wiederherzustellen. So haben Sie jetzt:

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>
...

Die betroffene VM läuft ab kvm/restored , während alle anderen auf kvm/vmimages bleiben. Zu diesem Zeitpunkt löschen Sie alle zusätzlichen Festplatten von kvm/restored und die ursprüngliche, beschädigte Festplatte von kvm/vmimages . Alles scheint gut zu sein, bis Sie feststellen, dass das alte beschädigte Disk-Image immer noch echten Speicherplatz belegt und jedes Überschreiben in kvm/restored aufgrund des alten, nicht löschbaren kvm/vmimages@snap3 zusätzlichen Speicherplatz verbraucht. Sie können diesen alten Schnappschuss nicht entfernen, ohne auch Ihren Klon zu entfernen, und Sie können nicht einfach für kvm/restored werben und kvm/vmimages löschen, da dies nicht die einzige echte "maßgebliche" Datenquelle ist (dh echte Daten sind) in beiden Datensätzen gespeichert).

Das Aufteilen eines Klons von seiner Quelle würde das obige Problem vollständig lösen. Mir ist nicht klar, wie redigiertes Senden / Empfangen in diesem Fall helfen würde.

@kpande zuerst, danke, dass du deine Ansicht und deine Lösung geteilt hast (was interessant ist!). Ich stimme voll und ganz zu, dass eine sorgfältige und sehr spezifische Gastkonfiguration (und ein Host-Dataset-Baum) das oben beschriebene Problem vermeiden können.

Allerdings spielt libvirt (und die Implementierung von Speicherpools) mit diesem Ansatz nicht besonders gut, insbesondere wenn gemischte Umgebungen mit virtuellen Windows-Maschinen verwaltet werden. Dies war nur ein einziges Beispiel. Teilbare Klone wären beispielsweise sehr nützlich, wenn ein "Gold Master / Base Image" erstellt werden soll, das nach Belieben instanziiert werden kann, um "echte" virtuelle Maschinen zu erstellen.

Nach dem aktuellen Stand der Dinge werden Sie dadurch in dem zugewiesenen Speicherplatz stark belastet, da Sie den ursprünglichen, möglicherweise veralteten Schnappschuss niemals entfernen können. Was mich überrascht, ist, dass dies als ZFS ein CoW-Dateisystem eine relativ einfache Operation sein sollte: Wenn Sie den ursprünglichen Snapshot löschen, markieren Sie "einfach" jeden nicht referenzierten Block als frei und entfernen Sie die Eltern / Kind-Beziehung. Mit anderen Worten, sei der Klon ein echtes Dateisystem, das von jedem Quell-Snapshot entwirrt ist.

Beachten Sie, dass ich die Welt "einfach" in Anführungszeichen verwendet habe: Obwohl es sich in der Tat um eine einfache logische Operation handelt, bin ich mir nicht sicher, ob / wie gut sie dem zugrunde liegenden zfs-Dateisystem zugeordnet ist.

@kpande ok, fair genug - wenn ein echtes technisches Problem vorliegt, muss ich es akzeptieren. Dies unterscheidet sich jedoch von der Feststellung, dass ein bestimmter Anwendungsfall ungültig ist.

Wenn diese Ansicht (dh: Unmöglichkeit, einen Klon von seinem ursprünglichen übergeordneten Snapshot zu trennen, ohne den "mythischen" BPR einzubeziehen) von den zfs-Entwicklern geteilt wird, kann dieser FR meiner Meinung nach geschlossen werden.

Vielen Dank.

+1 bei Bedarf dieser Funktion. Ja, send / recv könnte verwendet werden, aber dies würde Ausfallzeiten von allem erfordern, was dieses Dataset verwendet, um vom alten (Klon) zum neuen Dataset zu wechseln.

Ich bin mit LXD auf Situationen gestoßen, in denen ein Container kopiert (geklont) wird, aber das verursacht Probleme mit meinem separat verwalteten Snapshot.

@kpande : Auch in meinem Anwendungsfall ist der gesamte Datensatz eine Datenbank und einige Variationen der Datenbank.

Nach allem, was ich gesehen habe, sieht es nicht so aus, als würde Overlayfs mit zfs als Dateisystem gut gespielt (es scheint glücklich mit zvols und ext4 / xfs gemäß Ihren Notizen). Es klingt so, als würde dieser Ansatz die meisten Fälle abdecken. In diesem Fall wäre eine Dokumentation willkommen, in der erklärt wird, wie Overlays mit ext4 / xfs eingerichtet werden.

Einige von uns verwenden zfs jedoch nicht nur für die Datenträgerverwaltung, sondern auch für das Verhalten von acl / allow / snapshot / browsen und möchten Overlays w / zfs anstelle von ext4 / xfs verwenden können ist nicht möglich, gibt es einen Fehler dafür? Wenn ja, wäre es gut, wenn dies hervorgehoben würde (von hier aus). Wenn nicht, wenn Sie den Overlayfs-Ansatz befürworten, könnten Sie ihn möglicherweise einreichen (wenn Sie darauf bestehen, könnte ich ihn wahrscheinlich schreiben, aber ich nicht.) Ich weiß nichts über Overlays, und das scheint eine Schlüsseltechnologie in der Beschreibung zu sein.

Nach allem, was ich gesehen habe, sieht es nicht so aus, als würde Overlayfs mit zfs als Dateisystem gut gespielt (es scheint glücklich mit zvols und ext4 / xfs gemäß Ihren Notizen). Es klingt so, als würde dieser Ansatz die meisten Fälle abdecken. In diesem Fall wäre eine Dokumentation willkommen, in der erklärt wird, wie Overlays mit ext4 / xfs eingerichtet werden.

Der overlayfs -Ansatz funktioniert nicht für einen äußerst wichtigen und häufigen Anwendungsfall: das Klonen eines virtuellen Bildes ausgehend von einem anderen (oder einer "Gold Master" -Vorlage). In einem solchen Fall wäre das Aufteilen des Klons der Schlüssel, um Platzverschwendung zu vermeiden, da die ursprünglichen / geklonten Bilder voneinander abweichen.

@ ptx0 Dies funktioniert nur, wenn das Gastbetriebssystem overlayfs (also keine Unterstützung für Windows-VMs) und wenn der Endbenutzer (dh unsere Kunden) bereit ist, die Bereitstellung / Installation seiner VM-Images erheblich zu ändern. Nebenbei bemerkt, obwohl ich diese auf technischer Basis geschlossene PR vollständig verstehe - und akzeptiere - (z. B. wenn es sich um BPR handelt), ist es ziemlich frustierend, einen legitimen Benutzerfall als "ungültig" stempeln zu lassen. Wenn es nicht Ihr Anwendungsfall ist, gut. Nehmen Sie jedoch bitte nicht an, dass niemand einen gültigen Anwendungsfall für diese Funktion hat.

Windows benötigt keine Overlays, sondern integrierte Ordnerumleitungs- und Roaming-Profile.

Die Ordnerumleitung ist zwar seit NT vorhanden, funktioniert jedoch nicht immer zuverlässig, da Software vorhanden ist, die (aus unklaren Gründen) umgeleitete Ordner nicht korrekt verarbeitet und bei fehlgeleiteten Desktops oder Dokumenten einfach fehlschlägt. Abgesehen davon weichen Klone von Windows-Installationen von sich aus massiv und recht schnell vom Ursprung ab, dank Windows Update - das An- und Abmelden verschiedener Benutzer beschleunigt dies nur.