[Gelöst] btrfs subvolume /var umziehen

[Lookbehind]

Heyho,

mein kleiner Home-Server läuft auf Stretch und nutzt btrfs als Dateisystem. Dort ist /var ein eigenes Sub-Volume. Nun macht sich doch so langsam bemerkbar, dass der drehende Rost (aka traditionelle Festplatte) in dem Server für manche Aufgaben inzwischen doch zu langsam ist. Darum möchte ich einige Teile gerne auf eine SSD (die hoffentlich bald ankommt) auslagern. Vornehmlich geht es mir dabei um /var. Wichtig wären zwar nur einige Teile daraus, aber von der Größe passt es locker auf die SSD, also, warum nicht.

Jetzt stellt sich mir nur die Frage, wie migriere ich die Daten am sinnvollsten? Mir fallen da mehrere Möglichkeiten ein:

1. Ganz stumpf.
SSD einbauen, partitionieren und formatieren, Live-System (USB) booten, HDD und SSD mounten, rsync -avP /mnt/hdd/subvols/var/ /mnt/ssd/subvols/var/, /etc/fstab anpassen, reboot, done.

2. Mal btrfs send/recive ausprobieren
SSD einbauen, partitionieren und formatieren, Live-System (USB) booten, HDD und SSD mounten, btrfs send /mnt/hdd/subvols/var/ | btrfs recive /mnt/ssd/subvols/var/, /etc/fstab anpassen, reboot, done.

3. Pooling
Hier weiß ich nicht ob das überhaupt geht. Direkt dazu gefunden hab ich nix. Allerdings bin ich bekannt dafür mit Google nicht umgehen zu können. Die Grundidee ist, dass btrfs auch über mehrere Devices hinweg arbeiten kann. Die Hoffnung ist, dass man dabei sowas wie Placement-Groups bilden kann und sagen kann: Diese Daten schreib mal auf diese Platte, jene Daten auf die andere, und bei den Daten da ist mir egal wohin du sie schreibst. Da weiß ich aber wie gesagt nicht, ob das geht. Kann da jemand was zu sagen?
Dann wäre der Ablauf:
SSD einbauen, partitionieren und in den btrfs-Pool mit aufnehmen, Placement-Groups bilden, /var der Placement-Group SSD zuweisen, /data der Placement-Group HDD zuweisen, btrfs-rebalance anstoßen, zugucken wie das System den rest regelt.

Weg 1 funktioniert mit ziemlicher Sicherheit. Aber ist es auch der beste? Fahre ich mit btrfs send/recive evtl besser? Kann jemand was zu der Pooling-Idee sagen? Geht das? Hat jemand eine andere Idee, wie ich das vielleicht im laufenden Betrieb hinbekommen könnte? (USB an die Kiste ran stecken geht noch. Bildschirm und Tastatur sind eine Herausforderung.

Danke schon mal für die Ideen die hier hoffentlich kommen.

[jph]

2. Mal btrfs send/recive ausprobieren
SSD einbauen, partitionieren und formatieren, Live-System (USB) booten, HDD und SSD mounten, btrfs send /mnt/hdd/subvols/var/ | btrfs recive /mnt/ssd/subvols/var/, /etc/fstab anpassen, reboot, done.

Variante 2 ist doch eindeutig die edlere Herausforderung, wenn man es noch nie gemacht hat

3. Pooling
Hier weiß ich nicht ob das überhaupt geht. Direkt dazu gefunden hab ich nix. Allerdings bin ich bekannt dafür mit Google nicht umgehen zu können. Die Grundidee ist, dass btrfs auch über mehrere Devices hinweg arbeiten kann. Die Hoffnung ist, dass man dabei sowas wie Placement-Groups bilden kann und sagen kann: Diese Daten schreib mal auf diese Platte, jene Daten auf die andere, und bei den Daten da ist mir egal wohin du sie schreibst. Da weiß ich aber wie gesagt nicht, ob das geht. Kann da jemand was zu sagen?

Eine Vorgabe kannst du m.W. nicht machen. Du könntest dein / als JBOD zusammenbauen und btrfs die Allokation nach eigenen Gutdünken vornehmen lassen, aber dann wird es wahrscheinlich erst die (schnelle) SSD mit x-beliebigen Daten vollschreiben und danach auf die langsameren HDD ausweichen. Ich kenne deine Anforderungen nicht, aber bei einem Heimserver würde ich das Setup schlicht halten. Bei meinem Heimserver liegt / komplett (inkl. Container, bspw. Nextcloud) auf einer SSD und die Nutzdaten (Backups, Fotos etc.) liegen auf einem RAID 1 aus zwei HDD.

Wenn es unbedingt ein CoW-Dateisystem mit Snapshots sein soll, könntest du dein Glück mit ZFS mit allen damit verbundenen Risiken (nicht Bestandteil des Kernels!) versuchen. Das kann das möglicherweise. Aber dazu müsste einer der ZFS-Junkies hier im Forum was zu sagen.

[Lookbehind]

Hallo jph, und danke für die Antwort.

2. Mal btrfs send/recive ausprobieren
SSD einbauen, partitionieren und formatieren, Live-System (USB) booten, HDD und SSD mounten, btrfs send /mnt/hdd/subvols/var/ | btrfs recive /mnt/ssd/subvols/var/, /etc/fstab anpassen, reboot, done.

Variante 2 ist doch eindeutig die edlere Herausforderung, wenn man es noch nie gemacht hat

Ja, ich sollte das wirklich mal ausprobieren. Hatte dafür aber bisher nie Bedarf. Wäre mal ne Gelegenheit.

3. Pooling
Hier weiß ich nicht ob das überhaupt geht. Direkt dazu gefunden hab ich nix. Allerdings bin ich bekannt dafür mit Google nicht umgehen zu können. Die Grundidee ist, dass btrfs auch über mehrere Devices hinweg arbeiten kann. Die Hoffnung ist, dass man dabei sowas wie Placement-Groups bilden kann und sagen kann: Diese Daten schreib mal auf diese Platte, jene Daten auf die andere, und bei den Daten da ist mir egal wohin du sie schreibst. Da weiß ich aber wie gesagt nicht, ob das geht. Kann da jemand was zu sagen?

Eine Vorgabe kannst du m.W. nicht machen. Du könntest dein / als JBOD zusammenbauen und btrfs die Allokation nach eigenen Gutdünken vornehmen lassen, aber dann wird es wahrscheinlich erst die (schnelle) SSD mit x-beliebigen Daten vollschreiben und danach auf die langsameren HDD ausweichen. Ich kenne deine Anforderungen nicht, aber bei einem Heimserver würde ich das Setup schlicht halten. Bei meinem Heimserver liegt / komplett (inkl. Container, bspw. Nextcloud) auf einer SSD und die Nutzdaten (Backups, Fotos etc.) liegen auf einem RAID 1 aus zwei HDD.

Naja, streng genommen ist das auch jetzt schon ein Pool. Ich hab da nicht nur eine Platte drin. Und da kommen auch eigentlich 2 SSDs rein, die dann eben ein RAID bilden. Aber das nur am Rande.
Das Problem ist, dass der drehende Rost für manche Dinge, wie z.B. die Datenbank von Nextcloud, einfach zu langsam ist. Ich habs erst auf RAM und CPU geschoben, aber nach eingehender Analyse kommt es immer wieder auf IO-Wait raus. Und das kommt leider von den Platten. Das Problem hoffe ich mit den SSDs zu umgehen. Natürlich darf langfristig auch noch mehr als das /var Verzeichnis auf die SSDs umziehen. Aber mit /var wollte ich anfangen, weil da das Performance-Problem am offensichtlichsten ist. Das wird quasi mein test. Danach können andere Subvolumes folgen, inklusive /.

Das meine Lösung 1 funktionieren wird, da bin ich mir ziemlich sicher. Möglichkeit 2 sollte aus meiner Sicht auch gehen, habe ich aber erwähnt um da evtl Meinungen zu zu bekommen. Aber ich behaupte nicht die Weisheit mit Schöpflöffeln gegessen zu haben. Bevor ich sowas also angehe, dachte ich, ich frag mal. Vielleicht weiß noch jemand was besseres.

Meine Traum-Lösung funktioniert aber wohl offenbar nicht so wie ich mir das erhofft habe. Hab ich mir schon fast gedacht.

Wenn es unbedingt ein CoW-Dateisystem mit Snapshots sein soll, könntest du dein Glück mit ZFS mit allen damit verbundenen Risiken (nicht Bestandteil des Kernels!) versuchen. Das kann das möglicherweise. Aber dazu müsste einer der ZFS-Junkies hier im Forum was zu sagen.

Nein, kein ZFS. Ich habe, als ich den Server aufgesetzt habe, lange überlegt, wie ich meinen Speicher einrichte. mdadm-RAID mit LVM? ZFS? btrfs? ... Ist ja nicht so, als hätte ich FreeBSD von Vornherein ausgeschlossen. ZFS kam aber letztlich aus verschiedenen Gründen nicht in Frage.

Edit: Ich muss noch was korrigieren. Die betreffende Maschine läuft mit Buster, nicht mit Stretch. ... ich hab zu viele Rechner.

[jph]

Das Problem ist, dass der drehende Rost für manche Dinge, wie z.B. die Datenbank von Nextcloud, einfach zu langsam ist.

Nur zur Sicherheit nachgefragt: du nutzt Nextcloud nicht mit Sqlite, oder? Das ist in der Tat kreuzlahm und wird allenfalls für „testing and lightweight single-user setups without client synchronization“ empfohlen, vgl. https://docs.nextcloud.com/server/18/ad ... ase-choice.

Mit PostgreSQL oder MariaDB ist ein Raspberry Pi 2 für eine Handvoll Nutzer schnell genug. Der Wechsel geht relativ einfach: https://docs.nextcloud.com/server/18/ad ... rsion.html. (Damit bin ich bspw. von MariaDB auf PostgreSQL gewechselt.)

[Lookbehind]

Nein, kein SQLite. Da läuft Postgres. Allein die Nextcloud Datenbank ist aber mittlerweile um die 300 MB groß und ist nicht die einzige Datenbank darauf. Als ich das alles anfangs eingerichtet habe, lief das auch alles mal performanter. Aber mit der Zeit wurde es halt mehr und mehr und mehr und so langsam merkt man echt, dass manche Dinge echt einen Moment brauchen.

Ich hab ein recht umfangreiches Monitoring laufen und inzwischen ist IO-Wait mit Bezug auf die Platten eindeutig als Ursache zu erkennen. Die CPU hängt teilweise mit fast 200% im IO-Wait (2-Kerne + HT), Disk-Utilization gleichzeitig auf mindesten 75%, in Spitzen auch über 90% und die Disk-Latency wächst bisweilen auf deutlich über 100 ms pro Platte. Was sicher auch daran liegt, dass Nextcloud und Postgres bei weitem nicht die einzigen Prozesse auf der Kiste und die Platten auch nicht die schnellsten sind (5400rpm).

Es ist auch nicht durchgehend so schlimm. Es gibt Phasen, da laufen einzelne Anwendungen durchaus einigermaßen performant. Aber wenn viele Anwendungen gleichzeitig die Platte brauchen, merkt man einfach, dass zuerst die Anwendungen mit vielen kleinen IO/s in die Knie gehen ... und das sind allen voran die Datenbanken.

Is ganz interessant, wenn man sich das Monitoring über die letzten 1 1/2 Jahre (solange läuft die Kiste in dieser HW-Konfiguration) so anschaut, kann man das Problem fast kommen sehen. Is son bisschen wie der Frosch und das kochende Wasser. Schmeißt man einen Frosch in einen Topf mit heißem Wasser, springt er sofort raus. Setzt man ihn in einen Topf mit kaltem Wasser und macht es langsam heiß, bleibt er drin bis es kocht. ... ich hab mich kochen lassen.

[jph]

Dann würde ich, mich auf deine einleitende Erklärung beziehend, sofort Nägel mit Köpfen machen: / (vollständig, d.h. das System und nicht nur /var) per btrfs send/receive auf eine SSD umziehen, so dass nur /data auf der HDD verbleibt.

Beachte diesen Hinweis zur Verwendung einer SSD, sofern dein Server noch mit Stretch laufen sollte: https://wiki.debianforum.de/Btrfs#Verwendung_auf_SSDs

[Lookbehind]

Wollte wenigstens noch kurz Rückmeldung da lassen.
Offline-Umzug von /var hat bestens funktioniert und den Performance-Unterschied merkt man sofort und deutlich stärker als ich das für möglich gehalten hätte. Ich hätte das schon viel früher machen sollen.

Root mit umziehen hab ich mich im ersten Schritt noch nicht getraut, wird aber noch nach geholt. Ich muss den Kasten eh nochmal auf schrauben und die SATA-Kabel tauschen. Hatte nur noch welche mit gewinkeltem Stecker, weshalb die SSDs derzeit lose im Gehäuse liegen müssen. Da gibts eh nochmal Downtime.

Und ja, die Probleme mit SSDs und BTRFS unter Stretch kannte ich schon. Is aber n Buster drauf, hatte mich im Eingangspost vertan.

Danke für die Beratung.