ZFS pour débutants

 (ikrima.dev)
2 points par GN⁺ 2023-09-06 | 1 commentaires | Partager sur WhatsApp
  • Un guide d’introduction né d’une panne ZFS sur FreeNAS, qui couvre le dépannage, la création de nouveaux volumes et la stratégie de sauvegarde, en présentant dans un même fil les structures et commandes nécessaires lors des premiers pas avec ZFS
  • ZFS fournit à la fois un système de fichiers et un gestionnaire de volumes logiques ; lancé chez Sun Microsystems, il s’appuie aujourd’hui principalement sur le code OpenZFS sous Linux, FreeBSD, etc.
  • Sa structure de base se divise en vdev, qui regroupe des disques physiques, en pool, qui agrège ces vdev, en dataset, qui joue le rôle de système de fichiers, et en volume, exposé sous forme de périphérique bloc ; RAIDZ-1/2/3 tolèrent respectivement la panne de 1, 2 ou 3 disques
  • Les commandes utilisées en pratique tournent autour de zpool create/status/list/import/export/destroy/scrub et zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy ; pour éviter les problèmes liés aux changements de nom de périphérique, l’usage des UUID de périphérique est préférable
  • Les snapshots protègent de manière légère l’état à un instant donné et peuvent être répliqués vers un autre pool ou système avec zfs send/recv, mais à eux seuls ils remplacent difficilement une sauvegarde ou un PRA

Concepts de base de ZFS

  • ZFS est un système de fichiers local, comme ext4, NTFS ou exFAT, tout en jouant aussi le rôle de gestionnaire de volumes logiques, comme LVM sous Linux
  • Il a été créé par Sun Microsystems, et le code source de ZFS était publié sous licence open source jusqu’au rachat de Sun par Oracle
  • Comme le code déjà publié avait été porté sur plusieurs OS, le projet OpenZFS a ensuite été créé ; ce code est utilisé sur la plupart des systèmes de type Unix, notamment Linux et FreeBSD
  • Le contenu est organisé du point de vue d’un débutant, afin d’aider les personnes qui découvrent ZFS à comprendre sa structure et ses commandes d’exploitation

Composants de ZFS

  • Un vdev est constitué d’un ou plusieurs disques physiques, et peut aussi inclure des fichiers en plus des disques durs
    • Il peut être combiné sous forme de mirror ou de RAIDZ
    • Il existe 7 types de vdev, dont des types importants comme hot spare, L2ARC et ZIL
  • Un pool est constitué d’un ou plusieurs vdev ; on y crée généralement des volumes ou des datasets
    • Lors de la création d’un pool avec la commande zpool, les vdev sont définis en même temps
    • On peut mélanger plusieurs types de vdev pour configurer un niveau RAIDZ
  • Un dataset est le composant qui correspond à un système de fichiers dans ZFS
    • On peut y configurer l’accès utilisateur, les quotas, la compression, les snapshots, etc.
  • Un volume ressemble à un dataset, mais fournit une représentation sous forme de périphérique bloc
    • Il ne propose qu’une partie des fonctionnalités d’un dataset
    • Il est utile pour exécuter un autre système de fichiers au-dessus de ZFS ou exporter un extent iSCSI

Types de RAIDZ

  • Le Dynamic/Simple Stripe, c’est-à-dire RAID0, répartit les données sans parité ; si un périphérique est perdu, toutes les données sont perdues
  • Le MIRROR, c’est-à-dire RAID1, met les disques en miroir et s’utilise avec 2 à 4 disques, voire davantage
  • RAIDZ-1, c’est-à-dire RAID5, répartit la parité avec les données et peut tolérer la perte d’un disque physique avant une défaillance RAID
    • RAIDZ nécessite au minimum 3 disques
  • RAIDZ-2, c’est-à-dire RAID6, peut tolérer la perte de jusqu’à 2 disques physiques
    • RAIDZ-2 nécessite au minimum 4 disques
  • RAIDZ-3 peut tolérer la perte de jusqu’à 3 disques physiques
    • Il nécessite au minimum 4 disques, mais il vaut mieux éviter de l’utiliser avec moins de 5 disques

Création d’un pool et vérification de son état

  • Un pool ZFS se crée sous la forme zpool create [pool] [devices]
    • Exemple de pool sur disque unique : zpool create tank /dev/sdb
    • Exemple de stripe sur 3 disques : zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • Exemple de mirror sur 2 disques : zpool create tank mirror sdb sdc
    • Exemple de pool RAIDZ : zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3 peuvent être créés sous la forme zpool create [pool name] raidz[1,2,3] [devices]
  • Lors de la création du pool, l’option -m permet de définir le point de montage par défaut
    • Exemple : zpool create tank -m /mnt/tank mirror sdb sdc
  • Les exemples utilisent des noms de périphériques de la forme /dev/sdx, mais pour éviter les problèmes de démarrage causés par un changement de nom de périphérique, il est préférable d’utiliser les UUID de périphérique
  • zpool status est la commande de base pour vérifier l’état d’un pool
    • state indique si le pool est en ligne
    • status affiche des informations supplémentaires sur le pool
    • action indique les actions de suivi nécessaires
    • scan affiche la progression d’un scrub ou l’état du dernier scrub
    • errors indique s’il existe des problèmes sur le pool
  • zpool list affiche des informations détaillées comme la taille du pool, l’espace alloué, l’espace libre, la fragmentation, la capacité, la déduplication et l’état de santé
  • zpool history affiche l’historique des commandes utilisées pour modifier la configuration depuis la création du pool

Import, export, suppression et scrub d’un pool

  • Après sa création, un pool est généralement importé et monté automatiquement, mais un import manuel peut être nécessaire après un dépannage ou une réinstallation de l’image système
  • Exécuter zpool import sans nom de pool affiche la liste des pools importables
    • Si aucun pool n’est importable, le message no pools available to import s’affiche
    • En indiquant un nom de pool, le pool correspondant est importé ; la commande d’import effectue aussi le montage du pool
    • zpool import -a importe tous les pools importables
  • Avec -R, comme dans zpool import -R /mnt/tank2 tank, le pool est monté à un emplacement alternate root
    • Il ne s’agit pas du chemin de montage du pool lui-même, mais d’un dossier racine alternatif
  • zpool export [pool name] effectue l’opération inverse de l’import : il tente d’exporter le pool après avoir démonté les systèmes de fichiers montés qu’il contient
    • Si le démontage d’un système de fichiers échoue, -f permet de forcer le démontage
    • Si un volume ZFS est en cours d’utilisation, l’export échouera même avec -f
  • zpool destroy supprime un pool ainsi que ses datasets ou volumes enfants
    • Il faut l’utiliser avec prudence, car toutes les données et tous les snapshots sont supprimés
  • Un scrub ZFS vérifie la validité des données en comparant tous les blocs du pool avec leurs checksums connus
    • Dans les vdev avec parité, il répare les données corrompues en utilisant les données des disques sains
    • Pour préserver l’état du système, il faut exécuter des scrubs selon un planning
    • Démarrer : zpool scrub [pool]
    • Vérifier l’état : consulter la zone scan de zpool status
    • Arrêter : zpool scrub -s [pool]

Création et montage de datasets

  • zfs create est la commande qui crée un nouveau système de fichiers ou volume ; ici, l’accent est mis sur les datasets plutôt que sur les volumes
  • zfs create tank/dataset1 crée dataset1 sous tank
    • Le dataset tank est créé automatiquement lors de zpool create
  • zfs create -p crée aussi les datasets parents manquants, comme mkdir -p
    • Si le dataset parent n’existe pas, un zfs create classique échoue
  • Exécuter zfs mount sans argument affiche les systèmes de fichiers ZFS actuellement montés et leurs points de montage
    • Cette sortie n’inclut pas les datasets enfants
  • zfs mount [pool|dataset] monte le système de fichiers indiqué
    • zfs mount -a monte tous les systèmes de fichiers
  • Un dataset enfant peut être monté même sans son dataset parent
    • Dans ce cas, le chemin nécessaire est créé dans le système de fichiers de l’OS
    • Si l’on tente ensuite de monter le dataset parent, une erreur directory is not empty peut se produire à cause du répertoire créé
  • zfs unmount [dataset] démonte le dataset indiqué

Consultation des datasets et configuration des propriétés

  • zfs list [dataset name] affiche les informations du dataset indiqué
    • On peut aussi passer un point de montage en argument à la place du nom du dataset
  • Exécuter zfs list sans nom de dataset affiche récursivement tous les datasets du système
  • Lorsqu’un nom de dataset est indiqué, l’option -r permet d’afficher récursivement ce qui se trouve sous ce dataset
  • Les propriétés ZFS contrôlent le comportement des systèmes de fichiers, volumes, snapshots et clones
    • Elles peuvent ressembler à des options de montage
  • zfs get all [dataset] affiche toutes les propriétés d’un dataset
  • Une propriété précise se consulte par exemple avec zfs get compression tank
  • La configuration d’une propriété se fait avec zfs set
    • Exemple : zfs set compression=lz4 tank
    • Après la configuration, zfs get compression tank permet de vérifier que la valeur de compression est passée à lz4

Fonctionnement et usages des snapshots

  • Un snapshot enregistre l’état d’un système de fichiers à un instant donné, mais ne copie pas les fichiers
  • Un snapshot marque les données existantes en lecture seule ; même si de nouvelles données sont ensuite ajoutées au système de fichiers, les blocs de données existants protégés par le snapshot ne sont pas affectés
  • Le déroulé d’exemple est le suivant
    • Créer snapshot 1 sur un système de fichiers contenant les données existantes Data A
    • Ajouter ensuite Data B et créer snapshot 2
    • Ajouter ensuite Data C
    • Snapshot 1 protège Data A, et snapshot 2 protège Data A et Data B
    • Même si snapshot 1 est supprimé, Data A reste protégée par snapshot 2
  • La quantité de données utilisée par un snapshot est très faible
    • En effet, au lieu de copier les fichiers, il enregistre le bloc de métadonnées de plus haut niveau du système de fichiers indiquant l’appartenance au snapshot
  • Les snapshots sont utiles pour les tests de développement logiciel ou pour créer un filet de sécurité avant une mise à jour
  • Un snapshot seul ne doit pas être considéré comme une solution de sauvegarde ou de PRA

Commandes de snapshot

  • La création d’un snapshot utilise la forme zfs snapshot [pool/dataset@snapshot_name]
    • Exemple : zfs snapshot tank/dataset1@snapshot1
  • La liste des snapshots se consulte avec zfs list -t snapshot
  • S’il existe plusieurs datasets enfants, on peut créer un snapshot du dataset de niveau supérieur ou un snapshot récursif avec l’option -r
    • Exemple de snapshot classique : zfs snapshot tank@snapshot-master
    • Exemple de snapshot récursif : zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot] compare les différences entre snapshots
    • La sortie permet de vérifier les fichiers ajoutés et les chemins modifiés
  • La restauration d’un snapshot s’effectue avec zfs rollback [pool/dataset@snapshot_name]
    • Un rollback supprime les fichiers créés après le snapshot
    • Les snapshots plus récents sont également supprimés ; dans ce cas, l’utilisation de l’option -r peut être demandée

ZFS send/recv et réplication

  • ZFS send est une fonctionnalité qui permet d’envoyer un snapshot sous forme de flux de données
  • On peut répliquer un snapshot et un dataset vers un fichier, un autre pool ou un autre système via SSH
  • Les exemples utilisent deux pools nommés tank et backup
    • Le dataset tank/Movies contient 1,50 G de données
    • Avant le transfert, un snapshot est créé avec zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M')
    • zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies envoie le snapshot vers le pool backup
  • Après le transfert, backup/Movies et tank/Movies sont tous deux visibles dans zfs list, et les snapshots des deux côtés sont également visibles avec zfs list -t snapshot
  • zfs send mérite d’être exploré pour ses nombreuses options et cas d’usage ; combiné à RAIDZ et aux snapshots, il peut rendre le système de fichiers plus robuste

Suppression de datasets et de snapshots

  • La suppression d’un dataset utilise la forme zfs destroy [pool/dataset]
    • L’option -r peut aussi être utilisée
  • La suppression d’un snapshot utilise également zfs destroy [pool/dataset@snapshot_name]
    • L’option -r peut aussi être utilisée pour supprimer des snapshots
  • ZFS offre bien plus de fonctionnalités, mais ce document constitue surtout un point de départ pour apprendre les concepts et commandes de base

Références

À lire aussi

1 commentaires

 
GN⁺ 2023-09-06
Avis de Hacker News
  • Je viens tout juste de me mettre à ZFS, et la courbe d’apprentissage est plus raide que je ne le pensais. J’aimerais qu’il existe un wrapper simple qui rende les cas d’usage courants très faciles
    Par exemple, pour créer un pool, il utiliserait simplement des valeurs par défaut raisonnables comme ashift=12, la compression lz4, xattr=sa, acltype=posixacl, atime=off, et le chiffrement se limiterait à activé/désactivé plutôt qu’à de multiples options
    Il devrait générer la clé de chiffrement, configurer un service systemd qui déchiffre le pool au démarrage, et guider l’utilisateur pour sauvegarder la clé. zfs list devrait indiquer si les datasets sont montés, s’ils sont chiffrés et si la clé est chargée
    J’aimerais supprimer les datasets récursifs et distinguer clairement pool et dataset avec {pool}:{dataset} au lieu de {pool}/{dataset}. Il serait aussi préférable de ne pas avoir à nommer soi-même les pools ou snapshots, mais d’appliquer automatiquement des conventions comme {hostname}-[A-Z], {pool name}_{datetime created} et des noms courts numériques
    Lors de la création d’un pool, il ne faudrait pas avoir à saisir directement les identifiants de disque ; on créerait le pool avec /dev/sda, /dev/sdb, puis des métadonnées seraient stockées sur les disques pour éviter toute confusion si l’ordre des lecteurs change
    La progression devrait toujours être affichée avec pv, et il faudrait configurer automatiquement un scrub hebdomadaire ainsi que des snapshots horaires/journaliers/hebdomadaires/mensuels et leur nettoyage
    Si l’on envoie vers un disque sans pool, il devrait, après confirmation, créer un pool à disque unique avec les mêmes paramètres que le pool émetteur, et zpool et zfs devraient être fusionnés en une seule commande
    Lors de l’envoi de datasets chiffrés, --raw devrait être utilisé automatiquement, la valeur par défaut pour les envois devrait être --replicate, et -I devrait être utilisé si possible. Il faudrait aussi ne pas cacher le système de fichiers des snapshots dans un répertoire masqué, et fournir un moyen simple de monter et parcourir les datasets de snapshots
    • Il y a là un mélange de propositions raisonnables et de préférences très marquées. Je comprends le choix par défaut ashift=12 ou la syntaxe {pool}:{dataset}, mais il semble déjà trop tard pour changer cela, et certaines propositions pourraient casser des cas d’usage que l’on ne connaît pas
      Nommer les pools avec le nom d’hôte ne convient pas aux pools SAN qui peuvent être importés depuis plusieurs hôtes
      À mon avis, le scrub hebdomadaire, les snapshots périodiques et le nettoyage périodique relèvent du planificateur du système d’exploitation. Fusionner zpool et zfs serait sans doute possible, mais on finirait avec des choses comme zfs -pool XXXX, zfs -volume XXXX, et je ne vois pas bien l’intérêt
      Les datasets récursifs sont réellement utiles dans certains cas. En revanche, je suis totalement d’accord pour dire que zfs list devrait indiquer si un dataset est monté, s’il est chiffré et si la clé est chargée
      La partie sur le fait de ne pas saisir d’identifiant de disque est ambiguë. On peut désigner les disques de plusieurs façons — ID, WWN, label, sdX, etc. — mais il faut bien indiquer, d’une manière ou d’une autre, quels disques utiliser
      La fonctionnalité qui consiste à stocker des métadonnées sur les disques pour les retrouver même si l’ordre change existe déjà. Si l’on rebranche quelques lecteurs autrement et que l’on importe le pool, il les retrouve
      Certaines propositions seraient de bonnes valeurs par défaut, mais plusieurs semblent ne pas assez tenir compte des usages et besoins autres que les siens. ZFS vise un public beaucoup plus large
    • Dire que créer un pool avec /dev/sda, /dev/sdb embrouille ZFS, franchement, ce n’est pas un problème de ZFS, mais plutôt un problème d’utilisateur qui ne l’utilise pas de manière adaptée à l’époque actuelle
      Sous Linux, il existe depuis assez longtemps des références complètes comme /dev/disk/by-id/ata-$manufactuer-$serial-$whatever. C’est ce genre de chemin qu’il faut utiliser pour créer un pool
    • Beaucoup de propositions relèvent fortement de la préférence personnelle ; ce n’est pas mauvais en soi, mais on dirait qu’elles bousculent inutilement les conventions existantes. Par exemple, je ne vois pas pourquoi il faudrait {pool}:{dataset}
      Si vous ne voulez pas nommer vous-même les snapshots, mon petit outil https://github.com/rollcat/zfs-autosnap peut convenir
      Mettez zfs-autosnap snap dans cron toutes les heures et zfs-autosnap gc une fois par jour, et il fera tourner l’historique des snapshots selon la politique de conservation
      Il n’est pas difficile d’utiliser un simple wrapper de commandes ZFS ; vous pouvez donc reprendre mon code et créer votre propre outil
    • J’ai lu un jour que l’une des dernières épreuves d’un apprenti forgeron consistait à fabriquer lui-même tous les outils qu’un vrai forgeron utiliserait : l’enclume, le marteau, les pinces, etc.
      Au travail aussi, nous avons écrit plusieurs scripts pour créer des ensembles ZFS adaptés au type de déploiement prévu ce jour-là. Ils incluaient la création de volumes chiffrés LUKS sur lesquels placer des zvol, la standardisation des conventions de nommage et la définition de valeurs par défaut comme ashift=12 et la compression lz4
      C’était bien avant l’arrivée du chiffrement natif de ZFS, et comme cette approche fonctionne encore sans problème, nous n’avons pas mis à jour les scripts pour prendre en charge le chiffrement ZFS
      Aujourd’hui, je ne me souviens plus de nombreux flags, mais les scripts font office de documentation, et les autres membres de l’équipe n’ont qu’à exécuter make-zfs-big-mirror ou make-big-zfs-undundant-raid0
      Si un jour il faut provisionner des systèmes plus de 20 fois par an, même cela pourra être automatisé par le provisioning
    • Comme d’autres l’ont déjà dit, ce sont des propositions très marquées par des préférences personnelles. C’est très bien d’avoir un avis, mais beaucoup d’éléments vont de « ce n’est pas la façon dont j’ai l’habitude de faire sous Linux » jusqu’à des propositions réellement problématiques
      Dire qu’il ne faudrait pas nommer les pools n’a pas de sens. On ne crée pas des pools si souvent que cela, donc il suffit de leur donner un nom
      Si vous ne voulez pas nommer les snapshots, vous pouvez utiliser httm et zfs allow. Par exemple, httm -S . crée un snapshot comme rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount
      zfs et zpool sont chacun de très bonnes commandes Unix avec plusieurs sous-commandes. Je pense que les concepteurs de ZFS ont pris une décision très intelligente en ne créant pas une commande d’administration unique plus complexe
      Monter et parcourir explicitement un dataset de snapshots se fait aussi facilement avec zfs mount. Cela dit, j’aimerais que l’on reconnaisse aussi qu’une interface virtuelle stable facilite la recherche dans toutes les versions d’un fichier, et que c’est beaucoup plus difficile avec btrfs, entre autres. httm mérite aussi d’être consulté
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...

  • Il y a d’autres choses utiles dans ZFS. Il est bon de connaître la différence entre zpool-attach(8) et zpool-replace(8), et zfs list -t all -o space montre où l’espace est utilisé.
    Pour protéger le système d’exploitation avant de gros changements ou mises à niveau, les ZFS Boot Environments sont la meilleure fonctionnalité. Pour commencer, https://is.gd/BECTL peut être utile.
    zpool history poolname affiche toute la configuration du pool et l’historique des modifications. Par exemple, des changements comme zpool create, autotrim=on, atime=off, compression=zstd, recordsize=1m y sont enregistrés.
    Il manque aussi des informations importantes dans le guide. Un miroir 3-way conserve les données même si 2 disques sur 3 tombent en panne ; un miroir 4-way les conserve même si 3 disques sur 4 tombent en panne ; et un miroir N-way préserve les données même si N-1 disques sur N tombent en panne.
    C’est utile quand les données sont primordiales, mais qu’on n’a pas beaucoup d’emplacements ou de disques.

    • Un miroir N-way a aussi la particularité de permettre à ZFS de répartir les lectures sur plusieurs disques. C’était assez important avec les disques rotatifs, où le nombre d’opérations d’E/S était limité.

  • J’exploite depuis plusieurs années de grosses bases de données PostgreSQL de plusieurs To sur ZFS. Grâce à ZFS, les sauvegardes, la création d’environnements de test à partir d’anciens instantanés et les économies de disque via la compression intégrée sont devenues très simples.
    Si cela vous intéresse, vous pouvez lire ce retour d’expérience sur https://lackofimagination.org/2022/04/our-experience-with-po....

  • Ce qui m’a le plus aidé pour débuter avec ZFS, ce sont le ZFS Handbook de FreeBSD et les articles d’Aaron Toponce.
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    1 https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • J’aime la documentation FreeBSD.
      J’ai installé FreeBSD sur un vieux HP Microserver avec 1 Go de RAM ECC qui traînait, et comme j’avais aussi cinq vieux disques durs de 500 Go, je les ai configurés en miroir 5x en suivant le FreeBSD Handbook. C’était ma première fois avec FreeBSD, et ça s’est fait très facilement.

  • Récemment, en reconstruisant une bonne partie d’une infrastructure principalement composée de serveurs LAMP, j’ai décidé de tout baser sur ZFS sous Linux pour bénéficier d’une réplication de sauvegarde efficace et du chiffrement.
    J’utilisais depuis longtemps ZFS avec rsync pour les sauvegardes, donc j’étais assez à l’aise et, au final, cela a bien fonctionné, mais faire les choses correctement m’a pris beaucoup plus de temps que prévu. En particulier, il y avait beaucoup de mauvais conseils sur le Web concernant les bases de données et la réplication.
    Pour les bases de données, il faut au minimum effectuer les réglages de base, comme l’alignement de la taille des blocs. Pour mariadb/InnoDB, la ressource de Let’s Encrypt https://github.com/letsencrypt/openzfs-nvme-databases était de très loin la meilleure. Elle justifie chaque point et cite plusieurs sources, ce qui lui donne beaucoup de valeur.
    Si l’on cherche davantage sur le Web, on tombe sans fin sur des conseils contradictoires, des anecdotes et des mythes, accompagnés de théories incomplètes et infondées. Au bout du compte, il faut tester soi-même, comprendre ce que l’on ajuste, et il est aussi tout à fait acceptable de décider de ne pas ajuster certains paramètres.
    Pour la réplication, je recommande vraiment les pages de manuel. ZFS fournit des outils de réplication solides, mais ils sont tellement génériques qu’ils donnent l’impression de commandes de bas niveau à la Git. Comme ils ne supposent pas qu’on utilisera SSH, il faut assembler soi-même les morceaux, et si l’on veut automatiser, il faut aussi penser aux conditions limites, ce qui peut paraître intimidant au début.
    C’est pourquoi tout le monde se tourne vers des outils comme syncoid, mais les scripts de réplication du genre syncoid avaient quelque chose d’horrible : ils n’utilisent pas le mode send --replication de ZFS et le réimplémentent imparfaitement en Perl au motif que ce serait plus flexible.
    Lors des premiers tests, quand on restaure à neuf et qu’on voit que toutes les racines de chiffrement sont cassées et que toutes les propriétés des datasets ne sont pas synchronisées automatiquement, il y a de quoi devenir fou. Avec les seules options de réplication récursives intégrées, ZFS gère cela.
    Si l’on se décide à écrire son propre script, ce n’est pas difficile. Il suffit de rester simple et de ne pas empiler des tas de choses inutiles dans le pipeline comme syncoid. Lors de vrais tests, ces éléments peuvent même ralentir le processus. On affiche la progression avec pv et on envoie simplement les données, et ça fonctionne rapidement.
    Je publierai peut-être un jour mon script de réplication. J’ai l’impression qu’il existe très peu de bons scripts de référence qui couvrent les bases sans réimplémenter la réplication de travers.

    • Cette ressource mentionne le réglage de io_capacity et io_capacity_max, mais quand on ouvre la documentation MySQL pour voir le rôle réel de ces paramètres, ils ne sont malheureusement pas très utiles.
      Ces valeurs contrôlent les E/S en arrière-plan, comme la fusion du change buffer, et peuvent détourner des E/S des processus principaux qui en ont réellement besoin.
      D’après mon expérience avec une base MySQL assez chargée à 120K QPS, je n’ai eu besoin de toucher à aucun des deux. Si vous pensez en avoir besoin, il faut d’abord surveiller le temps de remplissage du redo log et la proportion de pages sales dans le buffer pool. Il vaudra probablement mieux ajuster d’autres paramètres.
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • Lorsqu’on fait les réglages de base pour une base de données, comme l’alignement de la taille des blocs, il y a un point à vérifier auquel on ne pense pas forcément. En général, on conseille d’aligner la taille des enregistrements, ce qui conduit en pratique à réduire la taille d’enregistrement du système de fichiers ZFS qui contient les données.
      À un certain niveau, cela peut être plus efficace, mais d’après mon expérience, cela réduit fortement le taux de compression.
      Effet secondaire intéressant : selon la charge de travail, si la bande passante disque est le goulot d’étranglement, le débit peut même se dégrader. Grâce à la compression, on peut lire et écrire plus vite que ce que le disque physique supporterait normalement ; si l’on casse la compression, cela peut nuire à la bande passante en lecture/écriture.

  • J’ai commencé à utiliser ZFS sous Linux il y a quelques années, et dans l’ensemble tout s’est bien passé.
    La seule chose qui m’a surpris, c’est que la valeur par défaut de volblocksize est assez mauvaise pour la plupart des configurations RAIDZ. Il faut l’augmenter si l’on ne veut pas perdre 50 % de l’espace disque brut.
    Les articles liés sont les suivants :
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    J’ai fini par consulter l’une des feuilles de calcul consacrées à ZFS.
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • Personnellement, je considère que l’efficacité de 50 % des vdev en miroir est un prix raisonnable à payer, vu la simplicité et les performances nettement meilleures. Aujourd’hui, on peut aussi étendre des pools RAIDZ, mais cela reste beaucoup plus complexe et les performances ne sont pas aussi bonnes.

  • Quand j’étais plus jeune et plus idiot, j’ai lu beaucoup de textes de passionnés expliquant à quel point les OS de NAS open source — probablement FreeNAS — et ZFS étaient formidables. J’ai acheté sur eBay un microserveur HP d’occasion aux caractéristiques très modestes, et je me suis lancé sans vraiment savoir ce que je faisais.
    J’ai posé quelques questions sur les forums de la communauté, mais la plupart des réponses étaient : « Avez-vous lu la documentation ? » ou « Avez-vous assez de RAM ? »
    Cette fameuse documentation était une présentation PowerPoint au style difficile à lire, au ton un peu évangélisateur, avec beaucoup de prérequis implicites, et elle n’était pas mise à jour régulièrement. La quantité de RAM nécessaire était aussi floue, l’idée étant surtout d’en mettre autant que possible.
    Au final, j’ai ignoré tous les signaux d’alerte concernant la technologie, l’ambiance exagérément enthousiaste et mon propre niveau de connaissances, et j’ai perdu beaucoup de données. J’ai beaucoup appris.

    • Je me demande si vous vous souvenez à peu près de quand cela date. ZFS existe depuis le début des années 2000, et il me semble que FreeNAS a démarré en 2005.
      Le système de fichiers est devenu bien plus stable, et la documentation me semble aussi plus claire.
      Cela dit, comme il est plus puissant et plus avancé qu’un système de fichiers journalisé traditionnel comme ext3, il offre aussi davantage de moyens de se tirer une balle dans le pied.

  • Pour en laisser quelques éléments pour plus tard : dans ZFS, toute la redondance se situe au niveau des vdev. Un zpool est constitué d’un ou plusieurs vdev, et dans tous les cas, si vous perdez ne serait-ce qu’un vdev dans un zpool, le zpool est définitivement détruit.
    Historiquement, RAIDZ, c’est-à-dire le RAID à parité, ne pouvait pas être étendu en ajoutant des disques. La seule façon d’agrandir un RAIDZ était de remplacer chaque disque de la grappe, un par un, par un disque plus grand, en espérant qu’aucun disque ne tombe en panne pendant la reconstruction.
    À vue de nez, et de manière très amateur, je n’envisagerais RAIDZ que dans les cas avec beaucoup de disques, comme RAIDZ2 ou RAIDZ3. Si n<=6 et que le budget le permet, j’utiliserais plusieurs vdev en miroir. En production, il faudrait examiner plus en détail les métriques de performances en lecture/écriture des différents RAID.

    • Un pool en miroir est généralement l’approche la plus sûre, oui.
      Cela dit, je ne recommanderais RAIDZ1 que si vous avez une sauvegarde complète sur site et une assez grande confiance dans vos compétences et votre supervision.
      Dans mon cas, j’ai un pool de 3x3 disques, et j’envoie les snapshots vers une cible de sauvegarde située quelques U plus bas dans le rack. Cette cible de sauvegarde se réveille chaque jour, possède un pool de 3x4 disques, et utilise elle aussi RAIDZ1.
      Si un disque tombe en panne dans le NAS, mon plan est de lancer immédiatement la sauvegarde pour qu’elle reçoive les snapshots, puis de remplacer le disque. Cela minimise la probabilité de perdre des données à cause d’une deuxième panne de disque pendant le resilvering.
      Les données vraiment importantes sont bien sûr aussi stockées hors site.

  • Je rencontre un problème ZFS que je ne comprends pas. Sur un certain zpool, zpool status affiche une liste d’erreurs détectées, mais elles ne se trouvent pas dans des fichiers : elles apparaissent toujours uniquement dans des snapshots, et probablement dans des entrées hexadécimales qui semblent correspondre à des snapshots supprimés.
    Si je supprime le snapshot signalé comme erroné et que je lance deux fois zpool scrub, les erreurs disparaissent et le scrub ne trouve rien. zpool status n’a jamais indiqué d’erreur sur le moindre périphérique.
    Il n’y a pas d’erreurs dans les fichiers, pas d’erreurs sur les périphériques, et aucune erreur détectée par le scrub, mais en fonctionnement, une douzaine de nouvelles « erreurs » apparaissent chaque jour dans zpool status. Je ne comprends pas comment cela peut arriver.

    • Très bonne question. Je n’ai pas le temps de chercher moi-même un ticket en double maintenant, mais vous pouvez consulter ou poser la question sur la liste de diffusion https://zfsonlinux.topicbox.com/groups/zfs-discuss et dans les issues GitHub https://github.com/openzfs/zfs/issues.
      Le premier lien peut sembler étrange, mais c’est bien l’interface web normale de la liste de diffusion.
    • Je rencontre le même problème. Parfois, un fichier semble corrompu non seulement dans les snapshots, mais aussi dans sa version actuelle.
      Impossible de le déplacer ou de le modifier ; on peut seulement le supprimer. Je n’ai aucune idée de la raison pour laquelle ces fichiers se corrompent. Heureusement, il ne s’agissait que de grosses ISO Linux, donc ce n’était pas catastrophique.