Stockage hiérarchisé avec BTRFS - comment est-ce fait?
NETGEAR utilise BTRFS dans son système d'exploitation ReadyNAS et implémente le stockage hiérarchisé dans ses dernières versions. Ils ont commencé avec le niveau «Métadonnées» uniquement dans ReadyNAS v6.9, puis ont ajouté «Data Tier» dans la v6.10. Le système utilise des disques SSD comme niveau 0 pour accélérer l'accès aux disques durs plus lents du système. La description du système indique que les métadonnées résideront sur les disques SSD dans les deux cas, et que dans le cas du «niveau de données», les données nouvellement écrites iront d'abord aux disques SSD, puis seront migrées périodiquement vers le disque dur, ou lorsque le Le niveau SSD se remplit jusqu'à un niveau spécifié.
ReadyNAS utilise BTRFS au-dessus des disques durs RAID-ed dans ses installations normales - par exemple mon système a un RAID5 composé de 4 disques, que BTRFS voit / utilise comme un seul périphérique.
En regardant comment la hiérarchisation est mise en œuvre, il semble que les configurations «Métadonnées» et «Niveau de données» soient effectuées en ajoutant une deuxième matrice RAID, composée uniquement de SSD, à la matrice RAID HDD principale et en transformant le périphérique unique initial. BTRFS dans un appareil à plusieurs appareils.
Ce que je ne peux pas comprendre, c'est comment la migration est effectuée, et aussi comment le cas «Métadonnées» parvient à séparer les métadonnées des données, de sorte que seules les métadonnées sont transmises au SSD? De plus, comment le mode "Data Tier" dirige-t-il les écritures entièrement vers le niveau SSD?
Des idées?
Réponses
OK, voici ce que j'ai trouvé pendant les soldes périodiques:
Le processus suivant est lancé sur l'hôte:
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
où / data est mon volume de données hiérarchisé, / dev / md127 est le tableau SSD utilisé comme tampon / cache.
Ce processus s'exécute jusqu'à ce que les données du niveau SSD soient déplacées presque complètement vers le niveau HDD - par exemple, quelque part le long du chemin que je vois:
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
puis il diminue jusqu'à ce que l'utilisation du niveau SSD tombe presque à zéro. La chose étrange est que jusqu'à présent, je n'ai pas pu exécuter cette commande manuellement.
Je n'arrive toujours pas à comprendre le filtre de balance «balayage».
Voici ce que montre le -help:
# 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
mais cela n'explique pas comment il correspond à la lt:/dev/md127:7
partie " " de la commande qui s'exécute périodiquement:
btrfs balance start -dsweep lt:/dev/md127:7 /data
Quelle est la signification ici: Exécuter jusqu'à ce que l'utilisation des données / dev / md127 tombe en dessous de 7%?!?
Il doit s'agir d'un cronjob qui s'exécute régulièrement et effectue la migration.
Vérifiez /etc/cron.d pour les entrées qui pourraient faire cela.
Vous dites que Netgear a trouvé un moyen de faire ce que MergerFS Tiered Caching vous permet déjà de faire, dans une configuration conviviale et extrêmement simple: https://github.com/trapexit/mergerfs#tiered-caching
créez 2 pools MergerFS A) un avec tous les disques durs, y compris le SSD ("POOL", tier0) et configuré pour écrire sur le périphérique avec le moins d'espace libre (à moins qu'il ne dispose de X quantité d'espace libre). B) deuxième pool ("POOL-ARCHIVE", tier1) contenant uniquement les disques durs.
Vos utilisateurs et toutes les applications utilisent uniquement le chemin du premier pool.
Un script de nuit qui copie tout ce qui n'a pas été touché au cours des X derniers jours du premier pool au second (facile, puisque les disques sont les mêmes, cela ne fera que copier les données sur le SSD). C'est le seul élément qui utilise le chemin du deuxième pool.
C'est exactement comment j'ai configuré mon serveur domestique. Tous les lecteurs sont au format BtrFS. Je n'utilise pas (je ne peux pas, avec cette solution) Raid.
Les avantages:
- Lorsqu'un disque tombe en panne, vous ne perdez que des données sur ce disque (et j'atténue cela en utilisant SnapRAID comme premier système de sauvegarde). Vous ne perdez pas tout le pool comme avec BtrFS-RAID0.
- C'est extrêmement facile à installer. 2 montages dans votre / etc / fstab. BAM, mise en cache à plusieurs niveaux!
- Vous utilisez toujours le SSD en premier (à moins qu'il ne reste que X espace libre). Vous donnant une vitesse maximale.
Les inconvénients:
- Vous ne pouvez pas utiliser les sous-volumes BtrFS (s'étendant sur les disques) dans votre pool MergerFS car MergerFS s'exécute au-dessus des systèmes de fichiers dans l'espace utilisateur.
- Cela signifie également que vous ne pouvez pas créer d'instantanés de sous-volumes dans votre pool. J'aimerais avoir une machine à remonter le temps comme des instantanés par dossiers de données utilisateur dans ma piscine.
J'adore MergerFS pour sa simplicité, mais la con # 2 me rend très intéressé par la façon dont Netgear a piraté une solution similaire en utilisant BTRFS.