ZFS vous connaissez?

Il copie son pool sur un autre, temporaire (donc avec des disques pour stocker tout ça)
puis, il casse le pool d’origine, le recrée avec un disque de plus et remet ses données dessus.

C’est lourd, mais seul passage quand on n’a pas trop anticipé. Ridicule aussi de faire un raidz2 avec 4 disques, autant avoir 2 vdev de 2 disques (mirror + mirror).

Pour revenir à ta question de comment organiser ton pool, quel niveau de redondance veux-tu et de quel espace de stockage as-tu besoin à brève et moyenne échéance (2 3 4 ou 5To) ?

tu sais exactement ce que j’ai comme disque lol :wink:
plus sérieusement :
je pensais mettre 6 disques sur un zpool (6 x 1 To) par serveur. (je garde 3 slot SATA pour mettre du ssd ou étendre , si je touche des disques pas trop cher)
Et comme j’ai 3 serveurs … j’aurais 3 zpool, avec des replicas type proxmox.
niveau de redondance, je sais pas trop , je sais qu’avec ceph j’ai 6 x 2To (des disques seagate pa cher) donc avec du 3/2 de 12 To on a plus que 4To utilisable au max.
Sur ceph je peux perdre 2 disques sur 6. vu que l’algo sait bosser avec 2 copies (vs 3 en temps normal)

Et ici les adhérents consomment vraiment rien en Go … c’est bizarre d’ailleurs même pas 200Go en 1 ans !
Et je me demande si je pourrai mettre ces disques (des ST2000DM008) , qui ne sont pas vieux même pas un an, dans le serveur supermicro ?

Si tu n’as pas besoin pour démarrer de tant d’espace, fais un zpool avec des vdev mirror et au fur et à mesure du besoin.

Avec sda - sdf ça donne en mirror :

zpool create -o ashift=12 poupoule mirror sda sdb (pour démarrer, avec 1To utilisable)

zpool add poupoule mirror sdc sdd (pour ajouter un 1T en mirror en plus dans le pool)

Avantage : tu pourras retirer ces vdev plus tard si besoin

Tu peux faire pareil en raidz1 pour démarrer avec 2To (sur 3 disques), puis ajouter un deuxième vdev de 2To (et 3 disques). Par contre, ensuite l’évolution ça sera un remplacement d’un paquet de 3 disques 1To par des plus gros (en replace un à un, quand tous les disques d’un vdev sur « upgradés », l’espace supplémentaire devient dispo).

Donc avec du raidz1 ça donne:

zpool create -o ashift=12 poupoule raidz1 sda sdb sdc
plus tard…
zpool add poupoule raidz1 sdd sde sdf

Le raidz2 commencerai à valoir le coup pour 6 disques, mais il t’obligera à changer les 6 disques si tu veux passer à la taille au dessus. Pour ça que je l’utilise sur des vdev de 8 disques.

Si tu veux un poil de redondance en plus, tu peux ajouter un disque en spare (et aussi le retirer du pool quand tu veux) :

zpool add poupoule spare sdg

Comme souvent le tout est de choisir un équilibre entre espace disponible et redondance. La redondance peut être inférieure sur un serveur plus orienté backup (c’est ce que je fais : 1 disque sur 5 en redondance sur le backup mais 2 sur 8 sur le principal). Du coup il y a aussi potentiellement plus d’espace et donc je peux conserver les snapshots sur une plus longue période.

Merci pour toutes ces explications que je dois analyser. :wink:

Ok, je comprends mieux ZFS, merci bien pour cet article d’introduction.

du coté kubernetes, les choses ont l’air de bouger, et j’ai l’impression que l’on pourrait utiliser zfs:

https://github.com/openebs/zfs-localpv

Mais en fait, on est parti sur une autre stratégie.

Pour un Nextcloud par exemple, il faut:

  • une base de donnée
  • des fichiers

Pour la base de donnée, la réplication se passe à ce niveau là, pas besoin ni de zfs, ni de ceph.

Pour les fichiers, on utilise une api comptaible s3. Pour le moment on utilise ceph pour cela, mais il existe aussi minio.

Mais du coup, si on prends l’exemple de minio, il tourne sur un seul nœud, n’est-ce pas?

Donc, si la machine est off, plus de minio.

Mais, grace a zfs, pour les updates, ou changement de disque, tu bouges le service d’une machine a lautre avant j’imagine.

Reste le cas de la panne, la, si une machine tombe, il faut que tu interviennes, pour soit:

  • restart sur une autre machine, et tu repars du snapshot de l’heure d’avant par exemple
  • ou tu répares la machine et en avant.

Et aussi, si tu as un utilisateur qui a besoin de 55TB du coup, tu peux pas. Mais on est d’accord, c’est assez rare :wink:

Du coup, je pense que je préfère ceph pour la tranquillité d’esprit.
Si une machine tombe, c’est pas grave, pour update, j’update les nœuds un après l’autre sans me soucier de applicatif.
(Et pour kubernetes, pour les apps qui tournent dessus, c’est pareil :slight_smile: )

3 messages ont été scindés en un nouveau sujet : Postgres replication - kubernetes

C’est ce que proxmox gère tout seul avec son fonctionnement en haute-dispo au sein d’un cluster de noeuds physiques… avec ZFS ou ceph en stockage (entre autres).

Le but de cette discussion n’est pas de convaincre que ZFS c’est THE solution, mais de le faire connaitre. Ensuite chacun voit pour ses usages, son archi si ça peut être utile ou pas, mais au moins savoir que ça existe et ce que ça fait (et ne fait pas) est un élément de plus au moment de choisir.

2 « J'aime »

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