Journal Btrfs et lxc

Posté par  . Licence CC By‑SA.
Étiquettes :
43
8
mai
2013

Bonsoir à tous,

Ce sera un journal court pour vous narrer le joli montage que j'ai réalisé ces dernières semaines. Je voulais réussir un triple objectif :

  • Monter un système de machines virtuelles léger me permettant de tester des logiciels sans mettre le souk dans ma Debian stable.
  • Tester Btrfs
  • Tester LXC

J'ai donc formater un disque en Btrfs (j'utilise au passage un noyau récent : 3.8) qui stocke les machines virtuelles et les templates. Pour générer un template, je crée un nouveau subvolume btrfs et y lance debootstrap. Je crée ensuite un snapshot en lecture-seule qui me servira de template pour la suite.

Crée une nouvelle machine virtuelle est alors enfantin. Un petit script crée un nouveau snapshot (clonage rw) du template, règle les paramètres de base (IP, hostname, clés ssh) et lance le containeur lxc. Comme on utilise des snapshots btrfs, le processus prend moins de 5 secondes. Je peux alors tout casser dans ce containeur (accessible en IPv6 dans mon cas). Le jour où je veux supprimer la machine virtuelle c'est encore plus court car la suppression de snapshot est quasi-instantanée avec btrfs.

Cerise sur le serveur, j'ai une tâche cron, qui prend des snapshots de tous mes containeurs toutes les heures ce qui permet de retrouver les fichiers d'origines en case de rm intempestif.

Tout ça fonctionne depuis quelques mois à merveille et Btrfs permet même d'économiser de l'espace disque car tous les containeurs provenant du même snapshot, la création d'un clone ne consomme quasiment pas d'espace disque.

Voilà c'était un journal très pertinent pour dire que Btrfs c'est rigolo et bien pratique pour déployer des containeurs LXC en quelques secondes.

  • # Intéressant mais

    Posté par  . Évalué à 8.

    Tu aurais pu rajouter les commandes, pour ceux qui ne sont pas familiers avec btrfs.

    Et y'a moyen d'utiliser plusieurs sous-volumes pour un container ? Genre /var séparé ?

    Perso j'ai tenté le support natif de lvm dans lxc, mais comme je suis sur ssd et que je n'ai pas réussi à lui faire monter le volume avec l'options discard, même en l'ajoutant avec tune2fs, je me suis quand-même retrouvé à monter les volumes dans le fstab.

    • [^] # Re: Intéressant mais

      Posté par  . Évalué à 6.

      Je crois que tu peut monter un sous volume où tu veux, donc ça doit être possible.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Intéressant mais

      Posté par  . Évalué à 6.

      Tu aurais pu rajouter les commandes, pour ceux qui ne sont pas familiers avec btrfs.

      Voilà la commande qui crée le système de fichiers du containeur :

       btrfs subvolume snapshot $template $rootfs

      avec $template et $rootfs qui sont les chemins du containeur template et du nouveau.

      Et y'a moyen d'utiliser plusieurs sous-volumes pour un container ? Genre /var séparé ?

      Oui, sans aucun problème.

      • [^] # Re: Intéressant mais

        Posté par  . Évalué à 2.

        Merci,

        Je vais rester sur du LVM pour l'instant, vu que c'est en place et que ça marche, mais la prochaine étape c'est CentOS 7 + Btrfs :)

        Juste une autre question, un sous-volumes peut avoir un quota séparé/supérieur à son parent ? Genre :
        __active = 3go
        __active/root = 512mo
        __active/root/usr = 1go
        __active/root/home = 512mo
        __active/root/var = 1go

        Ou alors il faut faire :
        __active = 3go
        __active/root = 512mo
        __active/usr = 1go
        __active/home = 512mo
        __active/var = 1go

        Et monter le tout pour reconstruire l'arborescence ?

    • [^] # Re: Intéressant mais

      Posté par  . Évalué à 9.

      Avec btrfs, la commande "btrfs" est l'outil universel pour obtenir des informations, agir sur les périphériques, créer des sous-volumes et les gérer… Avec ce système de fichiers, un "sous-volume" est simplement un répertoire d'un type particulier. Le sous-ensemble de commandes "btrfs subvolume" permet de créer, supprimer, lister des sous-volumes mais également de les cloner, en faire le point de montage par défaut ou trouver les derniers fichiers modifiés ultra-rapidement. Extrait de la syntaxe :

      usage: btrfs [--help] [--version] <group> [<group>...] <command> [<args>]

btrfs subvolume create [<dest>/]<name>
    Create a subvolume
btrfs subvolume delete <subvolume> [<subvolume>...]
    Delete subvolume(s)
btrfs subvolume list [-agopurts] [-G [+|-]value] [-C [+|-]value] [--sort=gen,ogen,rootid,path] <path>
    List subvolumes (and snapshots)
btrfs subvolume snapshot [-r] <source> [<dest>/]<name>
    Create a snapshot of the subvolume
btrfs subvolume get-default <path>
    Get the default subvolume of a filesystem
btrfs subvolume set-default <subvolid> <path>
    Set the default subvolume of a filesystem
btrfs subvolume find-new <path> <lastgen>
    List the recently modified files in a filesystem
btrfs subvolume show <subvol-path>
    Show more information of the subvolume
[...]

      Admettons que le crée un espace btrfs puis que je le monte :

      mkfs.btrfs /dev/sdb
mount /dev/sdb /mnt/mapartitionbtrfs

      Dedans, je crée 2 volumes :

      btrfs subvolume create /mnt/mapartitionbtrfs/videos
btrfs subvolume create /mnt/mapartitionbtrfs/home

      Je peux ensuite les monter où je veux :

      mount -o subvol=videos /dev/sdb /mnt/videos
mount -o subvol=home /dev/sdb /home

      À chaud, créons une copie de sauvegarde du volume home :

      btrfs subvolume snapshot /mnt/mapartitionbtrfs/home /mnt/mapartitionbtrfs/backup-home-`/bin/date '+%Y%m%d'`

      J'aurais 2 recommandations aux utilisateurs de btrfs, pour finir :
      - A minima, utilisez toujours le dernier noyau stable disponible. btrfs avance vite et des bugs constatés avec un noyau 3.6 ou 3.7 peuvent ne plus être d'actualité avec le 3.9.
      - Veillez à disposer des dernières versions des outils liés à btrfs pour pouvoir exploiter les dernières fonctionnalités en date.

      • [^] # Re: Intéressant mais

        Posté par  . Évalué à 9. Dernière modification le 08 mai 2013 à 09:32.

        Puisqu'il semble y avoir des gens qui connaissent bien par ici je réitère ma question d'il y a 2 ans : est-il préférable d'utiliser des partitions séparées ou des sous-volumes ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Intéressant mais

          Posté par  . Évalué à -1.

          Personellement je n'en ai aucune idée mais voici un message de ce matin sur la mailing list btrfs : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg24442.html

          La conclusion est :

          So I suggest: Go with partitions.

          • [^] # Re: Intéressant mais

            Posté par  . Évalué à 7.

            Le sujet n'est pas le même. Dans le mail, il s'agit de savoir si l'on peut créer le système de fichiers sur le disque (/dev/sda) plutôt que dans une partition (/dev/sda1). Le problème à ce niveau étant que certain outils n'aiment pas traiter avec un disque « nu » ce qui peu causer quelques problèmes et autres corruptions de données.

          • [^] # Re: Intéressant mais

            Posté par  (site web personnel) . Évalué à 7.

            La conclusion que tu cites n'a rien à voir avec la question de Barret Michel. Le problème auquel répond Kai Krakow (que tu cites) était de savoir si il vaut mieux utiliser btrfs directement sur le disque (sans table des partitions), ou faire une seule partition qui fait tout le disque.

        • [^] # Re: Intéressant mais

          Posté par  (site web personnel) . Évalué à 4.

          Alors, d'un point de vue performance d'écriture, j'opterais pour des sous-volumes : en effet de par son mécanisme de «Copy on Write» Btrfs va pouvoir regrouper toutes les écritures aléatoires afin d'obtenir un résultat proche des écritures séquentielles.

          Tandis que si tu utilises des partitions séparées, chacune d'elle aura son propre «curseur» pour les écritures, et tu te retrouves donc forcément avec des écritures aléatoires… en supposant que tu écrives en parallèle sur toutes ces partitions.

          Maintenant autres aspects à prendre en compte :
          - en cas de problème, de FS endommagé par exemple, un partition cloisonnera le problème à une zone précise, contrairement aux sous-volumes
          - certaines options de Btrfs sont / étaient communes à tout les sous-volumes, c'est le cas de la compression je crois, ce qui ne correspond pas forcément à ton besoin

          Pour résumer : par précaution j'opterais pour des partitions, tandis que pour les perfs j'opterais pour les sous-volumes. Mais selon les options de montage nécessaires, je n'aurais peut-être pas le choix, et devrais utiliser des partitions.

          alf.life

          • [^] # Re: Intéressant mais

            Posté par  . Évalué à 3.

            • en cas de problème, de FS endommagé par exemple, un partition cloisonnera le problème à une zone précise, contrairement aux sous-volumes

            De mémoire, btrfs stocke les subvolumes dans des B-tree séparés ; ça permet de limiter un peu la casse si un seul est corrompu. Ça sépare un peu les structures des subvolumes. Après, les chunks de données sont — il me semble — entremêlés entre subvolumes (enfin, ils n'ont pas de zone particulière réservée, quoi), ce qui protège donc mal contre la récupération en cas d'effacement bourrin d'un bout du FS (à coup de dd ou autre sur une zone contiguë).

      • [^] # Re: Intéressant mais

        Posté par  . Évalué à 5.

        À chaud, créons une copie de sauvegarde du volume home :

        btrfs subvolume snapshot /mnt/mapartitionbtrfs/home /mnt/mapartitionbtrfs/backup-home-/bin/date '+%Y%m%d'

        Une option bien pratique: rajouter le flag -r pour créer une sauvegarde en lecture-seule histoire de ne pas faire de bêtises avec le volume de backup.

  • # Les temps changent

    Posté par  . Évalué à 1.

    me permettant de tester des logiciels sans mettre le souk dans ma Debian stable

    Moi à mon époque pour ce genre de trucs, on utilisait un gestionnaire de paquets.

    • [^] # Re: Les temps changent

      Posté par  . Évalué à 2.

      Sauf que tous les logiciels ne sont pas empaquetés pour Debian et dans l'archive officielle. Par exemple, au hasard, RStudio

      Merci pour le joli troll.

      • [^] # Re: Les temps changent

        Posté par  . Évalué à 4.

        Ce n'est pas un troll, tu remarqueras que je n'ai pas dit que c'était mieux avant. Si tu fais l'effort de chercher dans les archives de linuxfr tu verras que c'était l'un des principaux arguments en faveur de l'adoption des gestionnaires de paquets.

  • # OpenVZ ; BtrFS

    Posté par  . Évalué à -4.

    1/ OpenVZ:
    Si quelqu'un veut passer d'OpenVZ à LXC est-ce simple à mettre en oeuvre?

    2/ BtrFS
    A un moment donné BtrFS ne défragmentait pas de manière automatisé, comme ext3/4.
    Est-ce le cas maintenant ?

    Merci d'avance pour les réponses

    PS: j'accepte même les réponses en anglais.

    • [^] # Re: OpenVZ ; BtrFS

      Posté par  (site web personnel) . Évalué à 1.

      Pour Btrfs il y a maintenant une option de montage autodefrag ; le problème étant que ça ne fait pas forcément mon ménage avec les snapshots : si tu as deux version du fichiers, similaire à 80% par exemple, tu ne pourras en avoir qu'une seule de non fragmentée…. à moins de dupliquer complètement les données.

      alf.life

      • [^] # Re: OpenVZ ; BtrFS

        Posté par  . Évalué à -7.

        tu ne pourras en avoir qu'une seule de non fragmentée

        Au moins c'est partiellement possible si je vous comprends…

        1/ Mais dans le futur, un résultat à 100% c'est possible vous croyez (deux snapshots défragmentés pour reprendre votre exemple)?
        [Oui la défragmentation totale c'est rare notamment lorsque le disque est presque plein…]

        2/ Admettons que ce ne sera jamais possible, est-ce qu'on peut choisir le snapshot soi-même ou dois-t'on se contenter du choix arbitraire du défragmenteur ?

        Et encore merci.

        • [^] # Re: OpenVZ ; BtrFS

          Posté par  (site web personnel) . Évalué à 4.

          Avoir les deux versions défragmentées est complètement impossible. Prenons un exemple :

          tu as ton fichier d'origine, la version 1 constituée de 5 blocs de données : ABCDE
          ensuite tu fais des modifications, la version 2, en modifiant 2 blocs dedans : AfCgE

          Tu as donc deux cas de défragmentation :
          a) la v1 est défragmentée : ABCDE sont contigus, tandis que f et g sont "plus loin"
          b) la v2 est défragmentée : AfCgE sont contigus, tandis que B et D sont "plus loin"

          La seule solution pour complètement défragmenter le truc serait de dupliquer toutes les données, ce qui entraînerait un gros gaspillage d'espace disque, du genre : ABCDEAfCgE

          L'option de défragmentation automatique détecte les écritures aléatoires dans un fichier, et en déclenche la défragmentation (je ne connais pas du tout le "seuil" de détection). Dans notre exemple, j'imagine que le système optimiserait pour la v2.

          alf.life

          • [^] # Re: OpenVZ ; BtrFS

            Posté par  . Évalué à -5.

            Merci beaucoup

            Oui logiquement ce devrait être la v2
            Mais il serait bon de permettre la v1 en option.
            [Genre je teste une nouvelle snapshot et si elle ne me plaît pas je la vire]

            Ce que vous dites est encore plus simple que je ne l'avais imaginé.

            • [^] # Re: OpenVZ ; BtrFS

              Posté par  (site web personnel) . Évalué à 1.

              C'est le cas, tu as un outil en ligne de commande te permettant de défragmenter ce que tu veux.

              Quelque chose du genre : « btrfs filesystem defrag /chemin/du/fichier »

              alf.life

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.