Tiered Storage mit BTRFS - wie geht das?
NETGEAR verwendet BTRFS in seinem ReadyNAS-Betriebssystem und implementiert Tiered Storage in seinen neuesten Versionen. Sie begannen nur in ReadyNAS v6.9 mit der Ebene "Metadaten" und fügten dann in Version 6.10 "Datenebene" hinzu. Das System verwendet SSDs als Tier-0, um den Zugriff auf die langsameren Festplatten im System zu beschleunigen. Die Beschreibung des Systems besagt, dass sich Metadaten in beiden Fällen auf den SSDs befinden und dass im Fall "Datenebene" auch neu geschriebene Daten zuerst auf die SSDs übertragen werden und später regelmäßig auf die Festplatte migriert werden oder wenn die Die SSD-Schicht füllt sich bis zu einer bestimmten Ebene.
ReadyNAS verwendet BTRFS bei normalen Installationen zusätzlich zu RAID-fähigen Festplatten - z. B. verfügt mein System über ein RAID5 aus 4 Festplatten, das BTRFS als einzelnes Gerät sieht / verwendet.
Wenn man sich ansieht, wie das Tiering implementiert ist, sieht es so aus, als würden sowohl "Metadaten" - als auch "Datenebenen" eingerichtet, indem dem Haupt-HDD-RAID-Array ein zweites RAID-Array hinzugefügt wird, das nur aus SSDs besteht, und das ursprüngliche Einzelgerät transformiert wird BTRFS in ein Gerät mit mehreren Geräten.
Was ich nicht herausfinden kann, ist, wie die Migration durchgeführt wird und wie der Fall "Metadaten" es schafft, Metadaten von Daten zu trennen, sodass nur Metadaten an SSD gesendet werden? Wie leitet der Modus "Datenschicht" die Schreibvorgänge vollständig auf die SSD-Schicht?
Irgendwelche Ideen?
Antworten
OK, hier ist, was ich während der periodischen Salden festgestellt habe:
Der folgende Prozess wird auf dem Host gestartet:
btrfs balance start -dsweep lt:/dev/md127:7 /data LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DBUS_SESSION_BUS_ADDRESS=unix:path=/var/netatalk/spotlight.ipc TRACKER_USE_CONFIG_FILES=1 TRACKER_USE_LOG_FILES=1 XDG_DATA_HOME=/apps/.xdg/local/share XDG_CONFIG_HOME=/apps/.xdg/config XDG_CACHE_HOME=/apps/.xdg/cache
Dabei ist / data mein gestuftes Datenvolumen, / dev / md127 das SSD-Array, das als Puffer / Cache verwendet wird.
Dieser Prozess wird ausgeführt, bis die Daten von der SSD-Schicht fast vollständig auf die HDD-Schicht verschoben wurden - z. B. irgendwo auf dem Weg, den ich sehe:
btrfs fi sh /data
Label: '0a44c6bc:data' uuid: ed150b8f-c986-46d0-ada8-45ee219acbac
Total devices 2 FS bytes used 393.14GiB
devid 1 size 7.12TiB used 359.00GiB path /dev/md126
devid 2 size 114.68GiB used 42.06GiB path /dev/md127
und dann geht es runter, bis die Nutzung der SSD-Schicht fast auf Null geht. Das Seltsame ist, dass ich diesen Befehl bisher nicht manuell ausführen konnte.
Ich kann den 'Sweep'-Balance-Filter immer noch nicht herausfinden.
Dies zeigt die -Hilfe:
# btrfs balance start --help
usage: btrfs balance start [options] <path>
Balance chunks across the devices
Balance and/or convert (change allocation profile of) chunks that
passed all filters in a comma-separated list of filters for a
particular chunk type. If filter list is not given balance all
chunks of that type. In case none of the -d, -m or -s options is
given balance all chunks in a filesystem. This is potentially
long operation and the user is warned before this start, with
a delay to stop it.
-d[filters] act on data chunks
-m[filters] act on metadata chunks
-s[filters] act on system chunks (only under -f)
-v be verbose
-f force reducing of metadata integrity
--full-balance do not print warning and do not delay start
--background|--bg
run the balance as a background process
Dies erklärt jedoch nicht, wie es dem " lt:/dev/md127:7
" Teil des Befehls zugeordnet wird, der regelmäßig ausgeführt wird:
btrfs balance start -dsweep lt:/dev/md127:7 /data
Was bedeutet das hier: Ausführen, bis die Datennutzung / dev / md127 unter 7% fällt?!?
Es muss ein Cronjob sein, der regelmäßig ausgeführt wird und die Migration durchführt.
Überprüfen Sie /etc/cron.d auf Einträge, die dies möglicherweise tun.
Sie sagen, Netgear hat einen Weg gefunden, das zu tun, was MergerFS Tiered Caching Ihnen bereits in einer benutzerfreundlichen und äußerst einfachen Konfiguration ermöglicht: https://github.com/trapexit/mergerfs#tiered-caching
Erstellen Sie zwei MergerFS-Pools. A) einen mit allen Festplattenlaufwerken einschließlich der SSD ("POOL", Tier0), und stellen Sie ein, dass auf das Gerät mit dem geringsten freien Speicherplatz geschrieben wird (es sei denn, es ist noch X freier Speicherplatz vorhanden). B) zweiter Pool ("POOL-ARCHIVE", Tier1), der nur die Festplatten enthält.
Ihre Benutzer und alle Anwendungen verwenden nur den Pfad des ersten Pools.
Ein nächtliches Skript, das alles kopiert, was in den letzten X Tagen nicht berührt wurde, vom ersten Pool in den zweiten (einfach, da die Laufwerke identisch sind, werden nur Daten auf der SSD kopiert). Dies ist das einzige Element, das den Pfad des zweiten Pools verwendet.
Genau so habe ich meinen Homeserver eingerichtet. Alle Laufwerke sind BtrFS-formatiert. Ich benutze Raid nicht (kann mit dieser Lösung nicht).
Die Profis:
- Wenn ein Laufwerk ausfällt, verlieren Sie nur Daten auf diesem Laufwerk (und ich mildere dies, indem ich SnapRAID als erstes Sicherungssystem verwende). Sie verlieren nicht den gesamten Pool wie bei BtrFS-RAID0.
- Dies ist extrem einfach einzurichten. 2 Reittiere in Ihrer / etc / fstab. BAM, Tiered Caching!
- Sie verwenden die SSD immer zuerst (es sei denn, sie hat nur noch X freien Speicherplatz). Wir geben Ihnen maximale Geschwindigkeit.
Die Nachteile:
- Sie können keine BtrFS-Subvolumes (die sich über mehrere Festplatten erstrecken) in Ihrem MergerFS-Pool verwenden, da MergerFS auf Dateisystemen im Benutzerbereich ausgeführt wird.
- Dies bedeutet auch, dass Sie keine Snapshots von Subvolumes in Ihrem Pool erstellen können. Ich würde gerne Zeitmaschinen wie Schnappschüsse pro Benutzerdatenordner in meinem Pool haben.
Ich liebe MergerFS wegen seiner Einfachheit, aber Con # 2 interessiert mich sehr, wie Netgear eine ähnliche Lösung mit BTRFS gehackt hat.