Hallo zusammen,
seit einigen Jahren ist overlayfs offiziell im Kernel integriert und wird inzwischen nahezu fuer alle Live-Medien genutzt. Damit koennte man die sync-Zeit bei Linuxclients auf 0 reduzieren. Habt ihr darueber schon einmal nachgedacht? (@thomas)
LG Yannik
Hallo Yannik.
Darüber wurde hier schon mehrfach diskutiert, z.B. hier:
(ab Beitrag #7 geht es so allmählich damit los)
Schöne Grüße,
Michael
Ah, dein Post geht ein wenig in die Richtung. Tatsaechlich waere bei LVM snapshots eine merge (der Zeit kostet, allerdings dennoch schneller als rsync sein wird) notwendig, da per COW die alten Daten in ein separates LV weggeschrieben werden. Ich vermute recht stark, dass das bei ZFS ebenfalls so ist?
Daher finde ich die Idee vom overlayfs interessanter, da dort per COW die neuen Dateien separat geschrieben werden.
Ja, ZFS/btrfs machen auch Copy on Write.
Die Idee ist also nicht neu aber ich glaube nicht, dass das sehr weit oben auf der to-do-Liste der Entwickler steht. Es funktioniert ja im Moment noch alles – auch wenn die LINBO- Images in letzter Zeit tatsächlich riesig geworden sind…
Ok - ich wollte das hier nur mal einbringen 
Moin!
ein Overlay-Dateisystem fürs Imaging zu nutzen, steht meiner Todo für Linbo. Aber die Lösung die Yannik vorschwebt, muss ja auf dem Client eingerichtet werden. Beim Booten wird ein transparentes Dateisystem übergemountet, das alle Schreibzugriffe abfängt, sodass das ursprüngliche Dateisystem unverändert bleibt. Das erspart das lokale Syncen. So ein Vorgehen wurde vor einiger Zeit z.B. in der c’t dokumentiert. Aber wie gesagt, das ist eine Geschichte, die im Betriebssystem des Clients abläuft und hat mit Linbo erstmal nix zu tun. Sicher könnte man ein so präpariertes Client-BS auch in ein Linbo-Image packen und ausrollen.
VG, Thomas
Moin Thomas,
was meinst Du denn mit „ein Overlay-Dateisystem fürs Imaging zu nutzen“?
Ich denke, dass das overlayfs letztlich im Client-Image genutzt werden muss, ist klar. Allerdings könnte man dies fuer weniger bedarfte Administratoren durchaus Linbo-Seitig als automatisierten Patch des Clientsystems anbieten. Wenn ich mich recht erinnere, gibt es in Linbo ja sogar die Möglichkeit, MS-Produkte zu aktivieren… 
LG
Wäre eine effiziente Methode differentielle Images anzuwenden. Man schreibt in ein neues Image nur die Differenz zum Original. Ist klein und lässt sich schnell verteilen. Auf dem Zielsystem wird das Differenzimage per Overlay über das ursprüngliche Image gemountet und dann gesynct.
Das Client-BS per Linbo so zu präprieren, dass es Overlayfs verwendet, sollte doch per postsync schon möglich sein.
Ansonsten sehe ich in der direkten Apassung des Client-Betriebssystems die effizientere Methode. Linbo mit immer mehr Funktionen zu überfrachten, die mit der eigentlichen Aufgabe des Imagings nichts zu tun haben, halte ich für keine gute Idee.
VG, Thomas
Ja, ich gebe dir recht. Eine gute Dokumentation dieser Möglichkeit wuerde sicherlich bereits einiges bewirken. Wer dann nicht will - selber Schuld.
LG Yannik
Hi.
Der Einwand von Andreas (@Till) war ja, dass man das für alle Client-Betriebssysteme realisieren müsste. Wenn man es zunächst „nur“ auf der LINBO-Ebene angeht, wäre es daher imho weniger komplex, da man dort nur das overlayfs (oder eben o.g. btrfs/ZFS mit Snapshots) laden müsste.
Ich sehe auch noch nicht ganz ein, warum es ein Problem ist, wenn man pro .cloop für die Clients serverseitig ein ZVOL oder Dataset aufmacht?! Natürlich müsste im v7-Server dann die Partition, auf der die cloops liegen, ZFS-formatiert sein. Aber wenn das gemacht ist (ist hier schon lange der Fall), sehe ich noch nicht das Problem, warum es dann nicht gehen sollte? (@Maurice: Kannst du evtl nochmal kurz erklären, wo du ein Problem gesehen hattest?)
Bis später,
Michael
Hi Michael,
wenn das alles so einfach ist, dann mach doch einfach ein PR. @thomas betreut das Linbo-Paket und wird es sicher dann anschauen.
VG, Maurice
Hallo Maurice (@Maurice)
Na ja – ob es wirklich so einfach ist hat halt noch nie einer ausprobiert. Du hattest „damals“ am Telefon ein Argument genannt, weshalb es evtl doch nicht so einfach ist. Und genau dieses Argument habe ich leider vergessen … hatte aber mit den zvol-Containern oder deren Größe (?) zu tun … vielleicht kannst du’s ja nochmal auf den Punkt bringen?
Schöne Grüße,
Michael
Hallo Thomas (@thomas).
Ich hatte in dem anderen Beitrag ja schon mal gefragt:
Wäre es ausreichend, dass man diesen Eintrag scharf stellt, um z.B. btrfs unter LINBO zu aktivieren?
https://github.com/linuxmuster/linuxmuster-linbo/blob/master/conf/kernel64.conf#L3407
Oder ist es damit nicht getan? Wenn man auf diesem Weg dem LINBO-Kernel ein snapshotfähiges Filesystem beibringen könnte, wäre das die erste Hürde … und ich sehe noch nicht, warum Du es lieber auf Client-Seite machen würdest?
Ich meine, dass man auf diese Weise das Aktualisieren der Caches aller Clients dramatisch reduzieren könnte, da nur noch die Änderungen aktualisiert werden müssen … korrigiere mich, wenn ich falsch liege…!?
Schöne Grüße,
Michael
Hallo Michael,
Nein, reicht nicht. Es müssen noch die entsprechenden Dienstprogramme für btrfs ins linbofs und in linbo_cmd muss code für btfrs ergänzt werden.
BTW, warum nicht zfs? Wer verwendet noch btrfs?
Mir ist nicht ganz klar, wie das nur durch das Verwenden von btrfs statt ext4 erreicht werden kann.
VG, Thomas
Hallo Thomas (@thomas)
Ok, wenn du so fragst: ZFS – ich dachte nur, weil btrfs schon „halb“ dabei ist und direkt vom Kernel unterstützt wird, während es bei ZFS ja diese ganzen Klimmzüge mit den Lizenzen gibt …
Das Zauberwort ist: „Storage Replication“. Man kann halt mit ZFS/btrfs sehr gut folgendes machen: Zwei Storages sind beide ZFS-formatiert. Man erzeugt auf Maschine A einen Snapshot (hier: LINBO-Cache-Partition) und schiebt ihn auf Maschine B (hier: Server-Partition auf v7-Server). Dabei wird aber nunmal nicht immer alles neu von A nach B kopiert, sondern (und das ist nur eine der exzellenten Eigenschaften des ZFS-Filesystems) immer nur die Änderungen vom letzten Mal. Damit sind inkrementelle Upgrades gleich mit erschlagen, weil ZFS das sowieso so macht. Zudem geht es dann extrem schnell. Auch ein Rollback auf einen alten Zustand ist in wenigen Sekunden erledigt – dabei ist es egal, ob in der Zwischenzeit 3 kB oder 4 TB neu dazu gekommen sind.
Ich habe in Sachen ZFS ja schon öfter die Videos von
Christian Zengel „zfs rocks“ empfohlen. Er zeigt die Möglichkeiten von ZFS sehr gut. Als ich das gesehen habe, bin ich jedenfalls weg von normalen RAID-Controllern und hin zu ZFS gegangen. Unser Proxmox läuft jetzt nur noch auf ZFS-Dateisystemen…
Der Kanal befindet sich hier:
https://www.youtube.com/channel/UCC0WuyODhqPuROasZV878Yw/videos
und das entscheidende Video zur „Storage Replication“ dürfte das hier (#008) sein?
Vielleicht es damit klarer, warum ich denke, dass LINBO so ein Feature extrem gut stehen würde? Aber wie gesagt: Korrigiert mich, wenn es aus irgendwelchen Gründen so nicht funktionieren sollte…
Schöne Grüße,
Michael
Im Falle eines komprimierten cloop-Images von z.b. 10G umfasst die Änderung vom letzen Mal halt das gesamte Image mit 10G. So what?
VG, Thomas
Isso. In einer geänderten Datei, die komprimiert wird, sind halt alle
Bytes geändert.
VG, Thomas
Hallo @thomas
Schade, dann funktioniert es so natürlich nicht, solange es auf Basis einer Datei läuft. Einen Plan, Linbo direkt auf ZVOLs umzustellen, so dass es auf dieser Ebene dann doch funktionieren würde, gibt es wahrscheinlich nicht, nehme ich an? Ich bin auch nicht sicher, wie groß so ein ZVOL werden würde.
Na ja, war einen Versuch wert…
Schöne Grüße
Michael
Hallo Michael,
Schade, dann funktioniert es /so/ natürlich nicht, solange es auf Basis
einer Datei läuft. Einen Plan, Linbo /direkt/ auf ZVOLs umzustellen, so
dass es auf dieser Ebene dann doch funktionieren würde, gibt es
wahrscheinlich nicht, nehme ich an? Ich bin auch nicht sicher, wie groß
so ein ZVOL werden würde.
wie sollte das gehen?
Kann man Windows auf ZFS installieren?
Es ist ein altes Dilema, das wir schon mit rsync hatten: da war es auch
so, dass man ja eigentlich nur die Differenzen transferiert beim image
download: das hat aber kaum was an der übertragenen Datenmenge geändert:
nur an der Serverlast, die immens ist, weil jedes Image neu komprimiert
wird: also verschiebt es alles: rsync erkennt die Ähnlichkeiten nicht mehr.
Alternative wäre: unkomprimiert: dann ist das Image halt ca. 3mal so groß.
Und das muss beim initialen Aufspielen dann auch erstmal durchs Netz …
bisher hat sich meiner Meinung nach starke Komprimierung und torrent zum
Verteilen bewährt.
Viele Grüße
Holger
