Conversion de LVM / EXT4 en ZFS sans perte de données

3

J'ai un serveur multimédia domestique avec 2 lecteurs de 3 To. Il est actuellement configuré avec mdraid (1), LVM et EXT4. L'installation a été effectuée à l'aide du programme d'installation ncurses Ubuntu Server.

Objectif

Convertissez la configuration pour utiliser ZFS (RAIDZ) et ajoutez un troisième disque de 3 To. Je souhaite activer la compression et la déduplication à la volée. La conversion ne devrait pas nécessiter une réinstallation d'Ubuntu et de tous les packages. Il ne devrait y avoir aucune perte de données (sauf si un disque tombe en panne au cours du processus).

Comment puis-je faire cela?

Question bonus, est-il préférable de faire cela en utilisant btrfs, car si je comprends bien, je peux initialiser le tableau avec un disque, copier les données, puis ajouter le deuxième disque avec btrfs mais pas avec zfs?

mon / proc / mdstat: 

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md4 : active raid1 sdb2[1] sda2[0]
      2930070069 blocks super 1.2 [2/2] [UU]

unused devices: <none>

mes pvs -v 

    Scanning for physical volume names
  PV         VG   Fmt  Attr PSize PFree DevSize PV UUID
  /dev/md4   Data lvm2 a-   2,73t    0    2,73t MlZlTJ-UWGx-lNes-FJap-eEJh-MNIP-XekvvS

mes périphériques lvs -a -o + 

  LV     VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert Devices
  Data   Data -wi-ao  2,68t                                       /dev/md4(13850)
  Swap   Data -wi-ao  7,54g                                       /dev/md4(11920)
  Ubuntu Data -wi-ao 46,56g                                       /dev/md4(0)
raid lvm mdadm zfs Maciej Swic
la source
Si vous vous souciez des données, n'essayez pas de convertir un système de fichiers sans sauvegarde! Obtenez le troisième disque, essayez d’y adapter les données (qui vous intéressent). Créez un raidz1 en mode dégradé (ne savez pas si vous pouvez en démarrer à partir de Linux, il y a eu des problèmes de démarrage dans BSD), copiez-le et résiluez-le après avoir ajouté le troisième disque.
jpe
Je me fiche de tout cette beaucoup, je veux surtout gagner du temps à réinstaller. Puis-je créer un RAIDZ dégradé avec un lecteur, puis continuer à y ajouter des lecteurs? Ou est-ce là que btrfs excelle? (RAID-5)
Maciej Swic
1
Btrfs peut faire ce que vous voulez directement, zfs requiert des étapes intermédiaires soigneusement choisies, comme par exemple décrit ici: pcaddicts.ca/rc/2010/05/20/…
jpe
Je commence à penser que btrfs est la voie à suivre ici. wiki.kernerl.org le liste comme stable maintenant. Est-ce que btrfs-convert peut faire tout le travail pour moi peut-être? Ai-je raison si je pense que je ne peux convertir que ma partition de données, même si je suis en utilisant LVM et que je démarre à partir d'une partition de démarrage sur le même LVM que la partition de données?
Maciej Swic
Btrfs-convert peut aller d'ext4 à btrfs si vous avez de la chance, mais le LVM restera en dessous. Vous gagnerez du temps en réinstallant ou en exécutant le système avec un petit disque SSD ou une carte SD. La conversion de systèmes de fichiers est une loterie: bbs.archlinux.org/viewtopic.php?id=175866
jpe

Réponses:

0

Court:

  • Je pense qu'il n'y a pas de conversion sur place d'ext4 en ZFS.

  • Pour les serveurs de médias, je recommande SnapRAID au lieu

Plus long:

ZFS utilise une structure interne très unique et très spéciale, qui ne correspond pas bien à la structure de ext4. (Lire: peut-être que quelqu'un pourrait créer une structure ZFS artificielle au-dessus de certains ext4, mais je doute que cette conversion soit rapide, fiable et facile à utiliser.)

SnapRAID, cependant, n’a pas besoin de convertir quoi que ce soit. Utilisez-le simplement avec (presque) tous les systèmes de fichiers existants pour créer une redondance des fichiers présents, de sorte que vous puissiez vérifier et récupérer les fichiers en cas de panne de lecteur ou de corruption (silencieuse).

Avantages / inconvénients:

  • SnapRAID est inefficace s'il doit créer une redondance pour de nombreux petits fichiers, chaque fichier crée un certain surcoût (Padding) dans la parité.

  • SnapRAID n'offre pas la compression elle-même.
    Sur un serveur de supports, vous n’avez généralement pas besoin de compression, le support étant généralement déjà compressé (MP4, JPG, PDF).
    Si vous utilisez un système de fichiers autorisant la compression, vous pouvez l’utiliser. Mais uniquement au niveau du périphérique, pas sur le pool complet (comme le fait ZFS).

  • SnapRAID n'offre pas de déduplication au niveau des blocs.
    Sur un serveur multimédia, le snapraid dup fonctionnalité est généralement suffisant, comme les fichiers multimédias ne partagent généralement pas beaucoup de blocs en double. (Exception: youtube-dl. Si vous téléchargez une vidéo deux fois avec la même qualité, il ne diffère que par quelques octets. Pas toujours. Mais assez souvent. Il suffit de garder l’ID vidéo Youtube dans le nom du fichier pour identifier deux fichiers similaires.)

  • La déduplication ZFS nécessite beaucoup de mémoire. Prévoyez 1 Go de RAM pour 1 Go de données, mieux encore!
    S'il n'y a pas assez de RAM, vous devez ajouter un périphérique de cache hyper rapide SSD. ZFS doit rechercher 1 secteur aléatoire par bloc de déduction écrit, donc avec "seulement" 40 kIOP / s sur le SSD, vous limitez la vitesse d’écriture effective à environ 100 Mo / s. (En général, ZFS est capable d’utiliser la bande passante parallèle de tous les périphériques, afin que vous puissiez facilement atteindre 1 Go / s et plus de vitesse d'écriture sur le matériel grand public ces jours, mais pas si vous activez la déduplication et que vous n’avez pas d’énormes quantités de RAM.)

  • Notez que je n’ai jamais eu de difficulté à utiliser SnapRAID pour récupérer des données.
    Je ne peux donc pas jurer que SnapRAID est vraiment capable de récupérer des données. Cependant, j’ai déjà eu assez de problèmes pour lesquels SnapRAID était utile, que les données étaient correctes et que j'ai eu l'impression, SnapRAID fonctionne vraiment.

  • Sur ZFS, vous devez planifier à l'avance. Vous devez connaître et planifier chaque aspect de la Tout le cycle de vie de votre lecteur ZFS à l’avance, avant de commencer avec ZFS.
    Si vous pouvez le faire, il n'y a pas de meilleure solution que ZFS, faites-moi confiance!
    Mais si vous oubliez quelque chose qui se produit alors dans le futur de manière imprévue vous êtes condamné. Ensuite, vous devez redémarrer à partir de zéro avec ZFS:
    Créez un nouveau deuxième pool ZFS frais et indépendant et transférez toutes les données.
    ZFS vous aide à le faire. Mais vous ne pouvez pas éviter de dupliquer les données temporairement. Comme vous en avez besoin lorsque vous introduisez ZFS.

  • L'administration de ZFS est un jeu d'enfant. La seule chose que vous devez faire régulièrement est:
    zpool scrub
    C'est tout. ensuite zpool status vous dit comment résoudre votre problème.
    (Cela fait maintenant plus de 10 ans que ZFS est installé. Sous Linux. Simplement dit: ZFS est une bouée de sauvetage.)

  • OTOH sur SnapRAID, vous n’avez besoin d’aucune planification. Allez-y. Et changez votre structure au fur et à mesure, au besoin.
    Vous n’avez donc pas besoin de copier vos données pour commencer avec SnapRAID. Ajoutez simplement un lecteur de parité, configurez et voilà.

  • Mais SnapRAID est beaucoup plus difficile à administrer en cas de problème.
    Vous devez apprendre à utiliser snapraid sync, snapraid scrub, snapraid check et snapraid fix. snapraid status est une aide la plupart du temps, mais vous êtes souvent perplexe, quelle pourrait être la bonne façon de réparer quelque chose, car il n'y a pas évident meilleur moyen (SnapRAID est comme un couteau suisse, mais vous devez savoir vous-même, comment le gérer correctement).

  • Notez que, sous Linux, vous avez deux choix différents sur ZFS:

    • ZFSonLinux, qui est une extension du noyau.
      Les nouveaux noyaux que vous verrez sur Ubuntu 20.04 seront probablement incompatibles.
    • ZFS-FUSE, qui est généralement un peu plus lent, est indépendant du noyau.
    • Les deux ont des avantages et des inconvénients, cela dépasse le cadre de cette réponse.
    • Si ZFS n’est pas disponible (vous voulez peut-être avoir besoin de réparer quelque chose), toutes vos données sont inaccessibles.
    • Si un périphérique échoue, en fonction de votre redondance utilisée, soit toutes les données sont entièrement accessibles, soit toutes les données sont complètement perdues.

  • SnapRAID est GPLv3 et entièrement un addon sur l’espace utilisateur.

    • Si SnapRAID n'est pas disponible, toutes vos données restent intactes et accessibles.
    • Si un périphérique échoue, toutes les données des autres périphériques sont toujours intactes et accessibles.

Généralement, un serveur multimédia a la propriété de conserver longtemps les anciennes données et est en croissance constante. C’est exactement ce pour quoi SnapRAID a été conçu.

  • Snapraid permet d'ajouter de nouveaux lecteurs ou même de nouvelles parités ultérieurement.

  • Vous pouvez mélanger différents systèmes de fichiers sur tous les lecteurs. SnapRAID ajoute simplement la redondance.

  • SnapRAID n'est pas conçu comme une sauvegarde.
    Sur les archives de supports, vous n'avez souvent pas besoin d'une sauvegarde.

  • ZFS RAIDZ n'est pas conçu comme une sauvegarde non plus.
    toutefois zfs send en combinaison avec zfs snapshot offre quelques très facile à utiliser, 24 heures sur 24, 7 jours sur 7, fonction de sauvegarde et de restauration

  • ZFS est destiné aux systèmes de fichiers, où il est crucial qu'ils ne disposent jamais d'une temps d'arrêt. Presque tout peut être réparé à la volée sans temps d'arrêt.
    Les temps morts ne se produisent que dans le cas où la redondance / l'auto-guérison de ZFS n'est plus capable de réparer les dégâts. Mais même dans ce cas, ZFS est plus qu’utile, et vous répertorie toutes vos données perdues. Habituellement.

  • OTOH SnapRAID peut récupérer des données, mais cela se fait hors connexion.
    Donc, jusqu'à ce que récupéré, les données ne sont pas disponibles.
    Il est également utile de savoir quelles données sont perdues. Mais c'est plus difficile, qu'avec ZFS.

Recommandation de meilleure pratique avec SnapRAID (ZFS va au-delà de cette réponse):

  • Restez avec LVM!
    • Faites de chaque lecteur un PV complet. Pas de table de partition.
      Si vous souhaitez chiffrer le lecteur, placez le PV dans le conteneur LUKS.
    • Mettez chaque PV dans son propre VG. De cette façon, un disque défaillant ne nuit pas aux autres VG.
      Vous pouvez regrouper plusieurs disques plus petits dans une taille similaire
    • Créez un groupe de LV de taille similaire sur tous ces VG.
    • Créez un ensemble de lecteurs de parité plus grands que les lecteurs de données.
    • Laissez suffisamment d'espace libre (100 Go) sur les VG pour créer des instantanés et petits ajustements des systèmes de fichiers.
    • À la fin de chaque PV, il doit rester de la place (voir suffisamment de place ci-dessus).
      Ceci concerne les systèmes de fichiers modernes qui créent des copies de superbloc à la fin. Si vous remplissez complètement le PV, ces FS (ZFS) peuvent détecter l’ensemble du lecteur. ou le PV au lieu du LV.
  • Créez le système de stockage de votre choix pour vos lecteurs de données sur ces volumes logiques.
  • Utilisez ZFS pour les lecteurs de parité sur les LV. Pas de compression / déduplication nécessaire ici.
    Notez que ceci n’est pas parfait, car ZFS crée généralement son système de fichiers dans /.

Comment configurer et administrer SnapRAID dépasse le cadre de cette réponse.

Pourquoi ZFS pour la parité:

Eh bien, quand un lecteur de données va mal (secteurs illisibles), vous pouvez copier les fichiers lisibles. Les fichiers illisibles se trouvent facilement de cette façon. Vous pouvez alors le récupérer.

Cependant, la parité SnapRAID n'est qu'un gros fichier. Si vous copiez ce fichier, vous voulez pour être sûr, il n'a pas de corruption silencieuse. ZFS assure cela indépendamment de SnapRAID. En cas de corruption, ZFS vous le dit, de sorte que vous sachiez vous devez vérifier le fichier de parité.

Vérifier le fichier complet en cas de secteurs défectueux prend beaucoup de temps, car toutes les données de tous les lecteurs doivent être lues complètement.

Pourquoi pas BTRFS?

  • ZFS est complètement stable, silencieux et sans faille depuis des années.
  • OTOH, nous sommes en 2019 et BTRFS est toujours aux prises avec de graves problèmes.
  • Par exemple, BTRFS réagit de manière imprévisible et instable si vous le remplissez complètement, si vous pouvez le remplir complètement. En revanche, aucun problème de ce type n’est connu avec ZFS.
  • Il est probable que vous atteignez parfois une parité complète si vous ne faites pas attention (SnapRAID est un peu inefficace s'il doit mettre beaucoup de petits fichiers en parité.)
Tino
la source