ZFS vous connaissez?

Justement, j’essaye de comprendre zfs et ses limites.

Dernièrement j’aime bien remettre en question des croyances :wink: et du coup, là j’essaye de re comprendre pourquoi ceph et pas zfs.

Et du coup, tu me dis que proxmox fait ça tout seul?

Donc si on récapitule, tu as 3 nœuds zfs/proxmox.
Zfs est un espèce de super Raid local, et proxmox gère les VMs sur chaque nœud.

Et là, tu me dis que tes clusters zfs sont repliqués entre eux, et aussi que proxmox est au courant, du coup, en cas de problème sur un nœud la VM minio serait redémarré sur un autre nœud ?

Du coup, je veux bien, c’est intéressant :slight_smile: j’ai une question subsidiaire. Quand le minio obtient le ack de l’écriture sur le FS, est que celui ci est déjà répliqué de l’autre côté ? Ou c’est asynchrone et du coup en cas de panne, tu perds la dernière transaction, mais bon, c’est pas trop grave non plus, on est pas des banques :wink:

j’ai un peu maquetté dessus.
En fait tu déclares:

  • 3 zpool (zpool1 par exemple) , 1 sur chaque nœuds (quand tu les crées, tu ne les actives pas !)
  • 1 storage ZFS au niveau Datacenter (zpool1),

Ensuite tu peux programmer des réplications de ta VM/LXC sur d’autres noeuds et avec la fréquence de ton choix .
Ainsi ta VM/LXc est présente (niveau volume) sur les nœuds de ton choix, et la bascule HA peut de se faire moyennant une différence de snapshot entre les deux nœuds entrant en jeu pour la bascule.
Donc ce n’est pas du système de fichier distribué mais une réplication asynchrone.
Franchement les bascules prennent peu de temps sur du test, tout dépends ensuite du taux d’écriture sur la VM/LXC et donc les différences de volumétrie entre deux repliques.

1 « J'aime »

Quel avantage Ceph vs ZFS pour une utilisation comme backend de storage pour Promox ?

Proxmox peut utiliser de multiples backend de stockage, dont ceph et ZFS (y compris en même temps)

Soit le backend fait la réplication nativement (cas de ceph), soit proxmox peut s’en charger (cas avec ZFS).

Dans ce dernier cas, pour ZFS, il utilise le mécanisme de snapshots et de send/recv. A intervalle régulier (cron), il va faire un nouveau snapshot, transmettre sur le noeud réplique ce qui a changé depuis le dernier snapshot et supprimer l’ancien snapshot.

Au final c’est un peu comme du ceph mais avec un léger différé et pas temps réel (réplication asychrone dixit @anon6747921)

Comme on a le stockage des VM ou containers répliqués, on peut tirer parti de la haute dispo de proxmox… si un noeud ne répond plus dans le cluster, proxmox peut décider de redémarrer la VM ou le container sur un autre noeud avec la dernière version du stockage dispo.

Comparé à ceph, ZFS est intéressant car ça peut s’installer progressivement:

  • un premier noeud proxmox+ZFS… pas de réplique.
  • on ajoute un second noeud proxmox+ZFS , on passe proxmox en cluster de 2 noeuds et on peut faire une réplication entre les 2, container/VM par container/VM avec la fréquence de son choix pour chaque

Il y a un peu plus de souplesse car ZFS peut utiliser des disques entiers, des partitions, voire même… des fichiers. Facile aussi d’ajouter dans un pool un SSD ou une partition de SSD en cache de lecture (et de la retirer). Il y a aussi un usage non négligeable de la RAM dispo pour le cache, qui permet d’avoir des perf vraiment bonnes.

Pour ceph, il faut 3 noeuds pour démarrer (sauf erreur) et un bon réseau (de préférence dédié) entre les noeuds, ce qui est n’est pas indispensable pour les send/recv de ZFS.

Dans mon cas, j’utilise aussi ces send/recv pour faire un backup froid, distants, via une ligne VDSL. Je ne pense pas pouvoir faire ça aussi simplement avec ceph.

ZFS et ceph ne cochent pas les mêmes cases. Une bonne redondance au sein d’un pool ZFS apporte un très bon niveau de sécurité pour les données, la réplique me permet d’avoir une copie « chaude » et la réplique distante un backup « froid », le tout avec une seule techno, ce qui me facilite la vie :slight_smile:

Dernier point entre les deux qui risque… les perfs… toujours difficile à comparer et sujet à débat mais voici une publication sur le sujet: https://jtsiskom.undip.ac.id/index.php/jtsiskom/article/view/13155 (le résumé est en anglais)

« ZFS has a higher performance of reading and writing operation than Ceph in IOPS, CPU usage, throughput, OLTP and data replication duration, except the CPU usage in writing operation. The test results are expected to be a reference in the selection of storage systems for data center applications. »

Et histoire d’embrouiller tout le monde… on peut créer des OSD ceph sur des pool ZFS :wink:
Ceci peut être une solution hybride qui permet pour certaines données sensibles une réplication à la ceph, et pour d’autre un simple stockage ZFS répliqué ou pas.

Tu peux faire un « cluster » ceph avec un seul nœud et ajouter au faire er à mesure aussi.

Et le send/recv, apparemment tu peux faire pareil avec export/import :

https://machinenix.com/ceph/how-to-export-a-ceph-rbd-image-from-one-cluster-to-another-without-using-a-bridge-server

Quelle redondance dans ce cas ? Ceph fait un pseudo-raid local sur les disques ?

C’est un peu tiré par les cheveux, non :wink:

« cluster » ceph un seul noeud, boudiou !
tu fais comment pierre pour avoir des repliques en 3/2 ? …

la vitesse.
les perf.

visiblement il faut impérativement du SSD et du 10Gb : moi j’ai pas le sou.
Pourtant cela fait un an que ça tourne ainsi à ilinux !
Niveau scalabilité (mot horrible) c’est le must have. (par contre si ca part en noeud de boudin : on doit juste pleurer !!!)
Mais pour les montées en charge avec du HDD et du 1 Gigabit , faut oublié.
Même avec de la RAM et pas mal de hdd, on a même testé avec un lien 4Gbit (LACP, agrégat) : les perf. vs ZFS , c’est le jour et la nuit).
Donc je sais pas. … je n’arrive pas à trancher.

Hmmm intéressant. J’ai l’habitude de Ceph car de nos jours c’est une technologie omniprésente avec la prolification des architectures hyperconvergentes.

Je n’ai pas touché à Proxmox depuis un moment déjà, je vais en déployer un sur mon lab histoire de m’y remettre. Je me souviens qu’à l’époque le backend privilégié pour les architectures composées uniquement de deux noeuds était DRBD.

Salut @cquest . Concretement, mes promox sont sur des LVM.

J4ai 2 serveurs identiques. Je n’en utilise qu’un pour le moment ( mais d’ici peu , j’aurai la fibre, et j’y brancherai le nouveau ) .

Donc dans l’idée, je monte mon proxmox classique, et j’ajoute des disques qui seront mis en ZFS .
Je pensais faire du RAID1 , et je vois rque ZFS s’en charge tout seul … visiblement .
Donc je prends mes 2 disques de 1TO , et je fais du ZFS sur les 2 genre zpool create poupoule raidz2 sd[ab]?

Avec juste 2 disques, c’est du mirroir qu’il faut faire:

zpool create poupoule mirror sd[ab]

Tu as très sûrement intérêt à fonctionner en 4K (à faire à la création du pool, on ne peut pas le changer après):

zpool create poupoule -o ashift=12 mirror sd[ab]

à utiliser la compression (on y perd très rarement):

zfs set compress=on poupoule

et une dernière optimisation, pour les metadata:

zfs set xattr=sa poupoule

OK !

et du coup , question très bête : Si j’ai d’autres disques, je les ajoute dans le poooool ?
Ou je crée un autre pool ?

Pour l’optimisation, je crée un pool de de cache avec un SSD ?

Oui, tu pourra les ajouter au pool, mais c’est un peu moins souple que BTRFS pour ça qui permet d’ajouter/retirer des disques et de combiner des disques de taille différente.

Imaginons que tu démarres avec 2 disques en mirror, si tu as 2 nouveaux disques, tu peux en faire un mirror que tu ajoute au pool (zpool add poupoule mirror sd[cd])

Les disques s’ajoutent en effet sous forme de « vdev », chaque vdev pouvant être de type:

  • mirror (copie entre tous les disques du vdev),
  • raidz (un disque de redondance en gros comme du raid 5),
  • raidz2 (2 disque de redondance comme le raid 6,
  • raidz3 (3 disques en redondance).

Un disque peut aussi être ajouté seul, sans aucune redondance, ou bien être déclaré comme « spare » et prendra automatiquement le relais d’un disque du pool qui serait détecté comme problématique. Bien sur ça n’a d’intérêt que sur de gros pool.
La redondance se fait au niveau de chaque vdev, pas globalement au niveau du pool.

Pour le SSD, tu peux l’ajouter en totalité dans le pool comme cache, voire n’ajouter que des partitions de celui-ci pour garder si besoin une partie pour d’autres usages.

Le cache peut s’ajouter/retirer du pool à loisir, ce qui n’est pas le cas de tous les types de vdev !
Pas possible de retirer un vdev raidzX du pool, ni de lui adjoindre de nouveaux disques.

Sur mon serveur de stockage principal, j’ai un pool avec:

  • un vdev raidz de 4 disques
  • un second vdev avec un raidz de 4 disques
  • un disque en spare
  • un ssd en cache de lecture
  • un autre ssd en cache d’écriture (un Intel Optane de 16Go, qui encore les écritures bien mieux que de la flash et suffit en taille pour ça)

  pool: opendatarchives
 state: ONLINE
  scan: scrub paused since Thu May 20 05:00:02 2021
	scrub started on Thu May 20 01:00:05 2021
	11.3T scanned, 8.96T issued, 55.1T total
	0B repaired, 16.28% done
config:

	NAME                              STATE     READ WRITE CKSUM
	opendatarchives                   ONLINE       0     0     0
	  raidz1-0                        ONLINE       0     0     0
	    ata-HUH721010ALN600_2YJGG2XD  ONLINE       0     0     0
	    ata-HUH721010ALN600_2YJGL0HD  ONLINE       0     0     0
	    ata-HUH721010ALN600_2YHD9W9D  ONLINE       0     0     0
	    ata-HUH721010ALN600_2YHEWP4D  ONLINE       0     0     0
	  raidz1-1                        ONLINE       0     0     0
	    ata-HUH721010ALN600_2YJGHSHD  ONLINE       0     0     0
	    ata-HUH721010ALN600_2YJGE3PD  ONLINE       0     0     0
	    ata-HUH721010ALN600_2YJEAVXD  ONLINE       0     0     0
	    ata-HUH721010ALN600_2YJGGJ3D  ONLINE       0     0     0
	logs	
	  nvme0n1p1                       ONLINE       0     0     0
	cache
	  sdb2                            ONLINE       0     0     0
	spares
	  sdq                             AVAIL

OK !

merci pour les amples explications, c’est super clair !
Il est possible de faire du raidz avec des disques de tailles différentes ?

Non, dans un vdev, les disques doivent être de taille identique, ou pour être plus exact, c’est la taille du plus petit qui sera utilisée…

2+2+1 en raidz ça donne 1+1+1 soit 2To utilisables :frowning:
mais… si tu remplaces le dernier disque:
2+2+2 en raidz donne 2+2+2 soit 4To utilisables :slight_smile:

C’est aussi comme ça qu’on peut upgrader un vdev, en remplaçant les disques un à un et au final, ZFS étendra la capacité utilisable.

salut, c’est ici le service après vente de ZFS ? :smiley:

C’est cool d’en apprendre plus sur ce truc. Comme tu l’as bien vendu j’ai voulu essayer sur ma tour.
J’ai donc une poule en raidz qui fait 7.2 To faite avec deux disques (un 4To et un 10 To), à terme j’aimerais y mettre davantage de disques (un autre de 10To et deux de 4To) pour améliorer la redondance mais ce sera quand j’aurai mieux démellé les fils d’alims de la tour qui sont super mal gaulés avec les prises SATA.

Je cherchais de la doc concernant le chiffrement sur ZFS mais j’ai pas dû assez chercher.

Actuellement j’ai un disque de 4To chiffré avec LUKS qui me sert de source à ce que je sauvegarde avec borg backup, dont je mets les archives dans mon pool. si j’ajoute mon disque chiffré juste avec « zpool add sdb » ça va tout exploser ?

La première fois que j’ai voulu jouer avec zfs j’ai voulu ajouter un disque qui était branché en USB, ce qui a fait tourner dans le vide la commande « zpool add ». J’ai fini par interrompre la commande et redémarrer. ce après quoi le pool que j’avais créé était introuvable. o_o
Après une destruction du pool et un autre essai avec uniquement des disques en SATA3 ça s’est mieux passé, ma pool en raidz se porte bien.

Je ne sais pas trop comment je pourrai l’intégrer à mon pool. Je pensais

  1. trouver comment activer du chiffrement dans zfs
  2. déplacer le contenu de mon disque chiffré vers mon sous ensemble de pool chiffré
  3. formater mon disque LUKS en ext4
  4. ajouter au pool mon disque ext4
  5. conquérir le monde

J’ai aussi un SSD de 500 Go dont je pourrai utiliser une partie comme cache, mais j’ai du mal a savoir combien d’espace il serait raisonnable d’y mettre.

Je ne sais pas comment tu as pu créer un pool de 7.2To avec deux disques de 4 et 10To.

J’espère que c’est pas en partitionnant le 10To en faisant du RAIDZ dessus !
Redondance foireuse garantie :frowning:

Pour le chiffrement, ZFS le gère désormais directement, pas besoin de LUKS ou autre.
Voici un bon point de départ :

https://pve.proxmox.com/wiki/ZFS_on_Linux#zfs_encryption

Le chiffrement se fait par « dataset » (la terminologie ZFS de ce qu’on appellerait habituellement un filesystem) et il faut l’activer au moment du zfs create car on ne peut pas le changer après.

Pour le disque USB, il ne faut pas forcément mettre tous ses œufs/disques dans le même même pool. Un disque USB, utilisé temporairement pour faire un sauvegarde peut très bien être dans un pool dédié, seul, et tu profitera de la synchro ZFS pour mettre à jour ce backup « distant » depuis ton pool fixe et ce sans même déchiffrer le dataset d’origine si il est chiffré.

Pour le cache, il y a celui d’écriture (alias log ou ZIL), qui sur des HDD permet de réordonner les I/O avant de faire les écriture définitives en plus d’être un filet de sécurité à l’écriture ainsi qu’un gain de temps. Quelque Go suffisent (j’ai 8Go sur un petit optane 3D XPoint pour un pool de 8x10To).

Il y a celui de lecture (cache), qui limite les accès aux HDD, là, c’est comme tu veux, et plus il y en a plus ça limitera les lectures lentes. Les versions actuelles de ZFS (2.x) le gèrent même en persistant entre reboot (ce qui n’était pas le cas il y a encore peu). Ce cache de lecture n’a pas besoin d’être redondant, si on le perd, les lecture se feront depuis les HDD.

Sur de gros pool, on peut aussi utiliser des disques rapides (SSD) en priorité pour y mettre ce qui est souvent lu (metadata par exemple), mais là il faut de la redondance car ce n’est pas stocké ailleurs.

ZFS v2 a apporté par mal de nouvelles features, donc attention aux tutos anciens qui contournaient certaines limites comme l’absence de chiffrement natif, donc passait par LUKS ou autre.

1 « J'aime »