Tu comprends ce que fais le gars ?
You only need some other let say temporay(tmp) zfs pool
- zfs send / recive from curent pool to tmp pool
- destroy curent pool
- add your new disk
- create a ne pool using the new disk
- zfs let say receive/send from tmp pool to your new pool
- end task
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 
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.
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:
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:
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
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 
)
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.
Justement, j’essaye de comprendre zfs et ses limites.
Dernièrement j’aime bien remettre en question des croyances 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 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
j’ai un peu maquetté dessus.
En fait tu déclares:
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.
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:
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
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
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 :
Quelle redondance dans ce cas ? Ceph fait un pseudo-raid local sur les disques ?
C’est un peu tiré par les cheveux, non
« 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 ?