Hello, TL;DR : Comment gérer efficacement les pools LVM-Thin sous proxmox ? sans risque de crash dû à des metadata à 100% ? Il y a quelque temps, j'avais basculé mes "datastores" Proxmox d'un traditionnel LVM à du LVM-Thin pour diverses raisons (snapshot, clone, overcommitment avec discard ...) Seulement, voilà, le 23/11/20 la VM 118 de type "NAS" (samba) voit son disque dédié aux données en erreur au fur et à mesure que l'on stocke dessus avec notamment la perte significative de données (Cf plus bas pour les logs) puis fini par basculer régulièrement en read only jusqu'au 29/11/20 (oui... je pense que vous noterez ici la concordance avec un potentiel petit souci de monitoring et je ne vous parle pas de la fin de vie de mon backup hors site chez C14... ). Après de nombreuses investigations, je découvre que le pool LVM-Thin sur lequel était le LV dédié aux données affiche un taux d'occupation de metadata à 100%. Quelques infos qui aideront, je l'espère, à la compréhension :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# vgs v2cold VG #PV #LV #SN Attr VSize VFree v2cold 1 11 0 wz--n- 16.37t 1.08t
~# lvs -a v2cold LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert data2cold v2cold twi-aotz-- 11.29t 52.09 38.59 [data2cold_tdata] v2cold Twi-ao---- 11.29t [data2cold_tmeta] v2cold ewi-ao---- 288.00m [lvol0_pmspare] v2cold ewi------- 128.00m ressource2cold v2cold -wi-ao---- 4.00t ... vm-118-disk-0 v2cold Vwi-a-tz-- <3.91t data2cold 31.33 vm-118-disk-1 v2cold Vwi-aotz-- <3.91t data2cold 31.05 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Afin de résoudre au plus vite la situation, voici les actions menées : - arrêt de toutes les vm utilisant data2cold - augmentation des metadata pour ce pool via la commande : lvextend --poolmetadatasize +160M v2cold/data2cold - augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold - tentative de redémarrage de la VM 118 en question (boucle de : boot + fsck + test d'écriture) mais ca retombe toujours en erreur. J'en ai conclu (à tort ?) que le LV vm-118-disk-0 de la VM était mort. - création d'un autre LV (vm-118-disk-1) sur ce même pool + restauration de backup et switch entre les deux LV sur la VM - la VM refonctionne à nouveau Maintenant après vérification, il est nécessaire de restaurer les autres VM également. Seulement voilà... J'aimerai fiabiliser mes pool LVM-Thin... J'ai lu de très très nombreux documents et sites sur le sujet (le plus pertinent et complet à mes yeux pour ceux qui veulent : https://bugzilla.proxmox.com/show_bug.cgi?id=1241 ) et suis "ravi" de voir que je ne suis pas le seul à avoir rencontré ce problème... Pour autant je n'ai pas trouvé de solution fiable et pérenne. En effet, voici mes conclusions : - La commande d'augmentation des metadata pour un pool n'est pas la bonne (ou n'est pas complète). Bref, je ne suis pas parvenu à augmenter le lvol0_pmspare alors que ce dernier est nécessaire pour les snapshots et réparations si j'ai bien compris. - J'ai tenté de calculer la taille des metadata avec la formule <ThinPool Size> / <Chunk Size> * 64 Ce qui a donné pour mes 3 pools : data0hot (taille 930G, chunk 512K) : 122 Mo data1middle (taille 1,64T, chunk 1M) : 111 Mo data2cold (taille 11,3T, chunk 2M) : 379 Mo Complètement décorrélé de ce que j'ai sous les yeux... - J'ai découvert les options thin_pool_autoextend_threshold et thin_pool_autoextend_percent dont l'interprétation varie selon la source (pas oser expérimenter du coup...) - Ma peur de me retrouver dans une situation encore plus dégradée me rend très réticent à toute expérimentation (heureusement seul data2cold est à refaire pour le moment). Et ma question : Comment bien gérer les LVM Thin-pool sous proxmox ? Je prends tout autre conseil également ! Merci d'avance, pidroid PS : concernant les incidents "monitoring" et "backup hors site", ils seront traités dans les plus bref délais.. je l'espère :-P ############################################################################### Kern.log de la VM 118:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nov 29 00:32:17 vm-118 kernel: [ 772.386502] EXT4-fs error (device dm-0): ext4_ext_map_blocks:4321: inode #82575362: comm kworker/u4:1: bad extent address lblock: 122881, depth:$ Nov 29 00:32:17 vm-118 kernel: [ 772.388484] EXT4-fs (dm-0): Delayed block allocation failed for inode 82575362 at logical offset 122881 with max blocks 2048 with error 117 Nov 29 00:32:17 vm-118 kernel: [ 772.388587] EXT4-fs (dm-0): This should not happen!! Data will be lost Nov 29 00:32:17 vm-118 kernel: [ 772.388587] Nov 29 00:32:17 vm-118 kernel: [ 772.426374] sd 2:0:0:2: [sdb] tag#169 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Nov 29 00:32:17 vm-118 kernel: [ 772.426382] sd 2:0:0:2: [sdb] tag#169 Sense Key : Aborted Command [current] Nov 29 00:32:17 vm-118 kernel: [ 772.426384] sd 2:0:0:2: [sdb] tag#169 Add. Sense: I/O process terminated Nov 29 00:32:17 vm-118 kernel: [ 772.426390] sd 2:0:0:2: [sdb] tag#169 CDB: Write(16) 8a 00 00 00 00 00 9d 9e 51 50 00 00 00 08 00 00 Nov 29 00:32:17 vm-118 kernel: [ 772.426393] print_req_error: I/O error, dev sdb, sector 2644398416 Nov 29 00:32:17 vm-118 kernel: [ 772.426472] Buffer I/O error on dev dm-0, logical block 330549546, lost async page write <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hello, Depuis plusieurs incidents du genre, je cree tous mes pools avec un meta de 1G, a adapter suivant tes besoins, mais cela tiens depuis plusieurs annees comme cela sans tomber chez nous. C'est sur que ce n'est pas satisfaisant comme reponse, mais chez nous ca marche... Je l'avais ajoute dans la supervision egalement ... A+ Nicolas
De: "Pi Droid" <pidroid.b@gmail.com> À: "frsag" <frsag@frsag.org> Envoyé: Mardi 1 Décembre 2020 17:11:10 Objet: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
Hello,
TL;DR : Comment gérer efficacement les pools LVM-Thin sous proxmox ? sans risque de crash dû à des metadata à 100% ?
Il y a quelque temps, j'avais basculé mes "datastores" Proxmox d'un traditionnel LVM à du LVM-Thin pour diverses raisons (snapshot, clone, overcommitment avec discard ...)
Seulement, voilà, le 23/11/20 la VM 118 de type "NAS" (samba) voit son disque dédié aux données en erreur au fur et à mesure que l'on stocke dessus avec notamment la perte significative de données (Cf plus bas pour les logs) puis fini par basculer régulièrement en read only jusqu'au 29/11/20 (oui... je pense que vous noterez ici la concordance avec un potentiel petit souci de monitoring et je ne vous parle pas de la fin de vie de mon backup hors site chez C14... ).
Après de nombreuses investigations, je découvre que le pool LVM-Thin sur lequel était le LV dédié aux données affiche un taux d'occupation de metadata à 100%.
Quelques infos qui aideront, je l'espère, à la compréhension :
~# vgs v2cold VG #PV #LV #SN Attr VSize VFree v2cold 1 11 0 wz--n- 16.37t 1.08t
~# lvs -a v2cold LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert data2cold v2cold twi-aotz-- 11.29t 52.09 38.59 [data2cold_tdata] v2cold Twi-ao---- 11.29t [data2cold_tmeta] v2cold ewi-ao---- 288.00m [lvol0_pmspare] v2cold ewi------- 128.00m ressource2cold v2cold -wi-ao---- 4.00t ... vm-118-disk-0 v2cold Vwi-a-tz-- <3.91t data2cold 31.33 vm-118-disk-1 v2cold Vwi-aotz-- <3.91t data2cold 31.05 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Afin de résoudre au plus vite la situation, voici les actions menées : - arrêt de toutes les vm utilisant data2cold - augmentation des metadata pour ce pool via la commande : lvextend --poolmetadatasize +160M v2cold/data2cold - augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold - tentative de redémarrage de la VM 118 en question (boucle de : boot + fsck + test d'écriture) mais ca retombe toujours en erreur. J'en ai conclu (à tort ?) que le LV vm-118-disk-0 de la VM était mort. - création d'un autre LV (vm-118-disk-1) sur ce même pool + restauration de backup et switch entre les deux LV sur la VM - la VM refonctionne à nouveau
Maintenant après vérification, il est nécessaire de restaurer les autres VM également. Seulement voilà... J'aimerai fiabiliser mes pool LVM-Thin... J'ai lu de très très nombreux documents et sites sur le sujet (le plus pertinent et complet à mes yeux pour ceux qui veulent : [ https://bugzilla.proxmox.com/show_bug.cgi?id=1241 | https://bugzilla.proxmox.com/show_bug.cgi?id=1241 ] ) et suis "ravi" de voir que je ne suis pas le seul à avoir rencontré ce problème... Pour autant je n'ai pas trouvé de solution fiable et pérenne.
En effet, voici mes conclusions :
- La commande d'augmentation des metadata pour un pool n'est pas la bonne (ou n'est pas complète). Bref, je ne suis pas parvenu à augmenter le lvol0_pmspare alors que ce dernier est nécessaire pour les snapshots et réparations si j'ai bien compris.
- J'ai tenté de calculer la taille des metadata avec la formule <ThinPool Size> / <Chunk Size> * 64 Ce qui a donné pour mes 3 pools : data0hot (taille 930G, chunk 512K) : 122 Mo data1middle (taille 1,64T, chunk 1M) : 111 Mo data2cold (taille 11,3T, chunk 2M) : 379 Mo Complètement décorrélé de ce que j'ai sous les yeux...
- J'ai découvert les options thin_pool_autoextend_threshold et thin_pool_autoextend_percent dont l'interprétation varie selon la source (pas oser expérimenter du coup...)
- Ma peur de me retrouver dans une situation encore plus dégradée me rend très réticent à toute expérimentation (heureusement seul data2cold est à refaire pour le moment).
Et ma question : Comment bien gérer les LVM Thin-pool sous proxmox ? Je prends tout autre conseil également !
Merci d'avance,
pidroid PS : concernant les incidents "monitoring" et "backup hors site", ils seront traités dans les plus bref délais.. je l'espère :-P
###############################################################################
Kern.log de la VM 118:
Nov 29 00:32:17 vm-118 kernel: [ 772.386502] EXT4-fs error (device dm-0): ext4_ext_map_blocks:4321: inode #82575362: comm kworker/u4:1: bad extent address lblock: 122881, depth:$ Nov 29 00:32:17 vm-118 kernel: [ 772.388484] EXT4-fs (dm-0): Delayed block allocation failed for inode 82575362 at logical offset 122881 with max blocks 2048 with error 117 Nov 29 00:32:17 vm-118 kernel: [ 772.388587] EXT4-fs (dm-0): This should not happen!! Data will be lost Nov 29 00:32:17 vm-118 kernel: [ 772.388587] Nov 29 00:32:17 vm-118 kernel: [ 772.426374] sd 2:0:0:2: [sdb] tag#169 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Nov 29 00:32:17 vm-118 kernel: [ 772.426382] sd 2:0:0:2: [sdb] tag#169 Sense Key : Aborted Command [current] Nov 29 00:32:17 vm-118 kernel: [ 772.426384] sd 2:0:0:2: [sdb] tag#169 Add. Sense: I/O process terminated Nov 29 00:32:17 vm-118 kernel: [ 772.426390] sd 2:0:0:2: [sdb] tag#169 CDB: Write(16) 8a 00 00 00 00 00 9d 9e 51 50 00 00 00 08 00 00 Nov 29 00:32:17 vm-118 kernel: [ 772.426393] print_req_error: I/O error, dev sdb, sector 2644398416 Nov 29 00:32:17 vm-118 kernel: [ 772.426472] Buffer I/O error on dev dm-0, logical block 330549546, lost async page write <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello, Bienvenue dans ce que beaucoup d'entre nous on du expérimenter une fois... et désolé pour toi! > La commande d'augmentation des metadata pour un pool n'est pas la bonne (ou n'est pas complète). Bref, je ne suis pas parvenu à augmenter le lvol0_pmspare alors que ce dernier est nécessaire pour les snapshots et réparations si j'ai bien compris. Tu as une solution pour résoudre le soucis du pmspare qui n'a plus la bonne taille : - Éteint toute tes VM utilisant le thinpool - Démonte tout ce qui tape dedans - Effectue ensuite un "lvconvert --repair v2cold/data2cold" A noter que cela peut prendre un peu de temps en fonction du CPU/vitesse du disque/taille/utilisation. C'est pas optimal mais je n'ai pas trouvé mieux. Cela devrait te créer un nouveau "data2cold_tmeta" de la même taille que le précédent (qui est déjà augmenté), te mettre l'ancien sous le nom " data2cold_tmeta0" vu comme un LV thin classique (pour backup). Mais surtout cela va te recrée le lvol0_pmspare à la bonne taille (identique à data2cold_tmeta). Je l'ai fais y'a pas une semaine pour résoudre un petit soucis de taille de meta sur un thinpool de 36T. Je l'avais déjà fait une ou deux fois avant. Je n'ai perdu aucune donnée à priori jusqu'ici :-) > augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold Je pense que c'était superflu, d'après ton lvs -a, tu n'utilise que ~52% de data sur les 11.3T que tu as maintenant. Sauf si ce message était dû au fait que tu as réservé plus que les 11T sur l'ensemble des LV thin de tes VM? Si c'est le cas, à toi de voir, si tu ne penses jamais utiliser tous les disques au maximum... Après si tu préfères la sécurité et que ta la capacité disponible! > tentative de redémarrage de la VM 118 en question (boucle de : boot + fsck + test d'écriture) mais ca retombe toujours en erreur. J'en ai conclu (à tort ?) que le LV vm-118-disk-0 de la VM était mort. > création d'un autre LV (vm-118-disk-1) sur ce même pool + restauration de backup et switch entre les deux LV sur la VM > la VM refonctionne à nouveau Si ça fait une semaine qu'elle tape la limitation de meta, possible que le filesystem est pris grave dans la figure en effet. J'ai tapé une seule fois 100% qui a fait tomber des services, j'ai eu de la chance, j'ai rien perdu comme donnée. Mais on a réagit en 15 minutes max. N'oublie pas de supprimer l'ancien LV thin qui n'est plus utilisé pour pas utiliser de la place. Si tu as fait un import de backup depuis l'interface, il va te créer une image disk-1, mais pas supprimer de lui même disk-0 par sécurité. Il faudra penser à supprimer le disk-0 directement en CLI. Je crois qu'elle n'est plus visible en GUI ensuite. > J'ai tenté de calculer la taille des metadata avec la formule <ThinPool Size> / <Chunk Size> * 64 Effectivement c'est une bonne technique, j'avais dû la voir à une époque mais elle m'était sortie de la tête. Même si avec ces calculs je trouve le double de ceux que j'aurais en vrai si je suis mon utilisation actuelle. Je ne sais pas si je suis fatigué et raté quelque chose, possible... Soit un détail m'échappe dans le calcul. Après ça vaut mieux trop que pas assez. Mais n'oublie pas que cela serait les valeurs maximum théorique utilisées et pas l'utilisation actuelle. Mais tu tombes comme moi sur une valeur supérieure à la réalité. Personnellement, j'ai pris l'habitude d'attribuer une volume énorme de metadata, je préfère voir large que trop petit. Typiquement, j'ai mis 10g de meta sur ces machines avec 32 et 36To de thinpool. J'avais une différence de simple au double sur l'utilisation entre les deux machines, je viens de voir que j'ai une en chunk 256K et une en chunk 512K. En vrai je ne sais pas comment c'est possible, je ne me souviens pas comment je les ai créé à l'époque ^^ Si on suit les calculs théoriques du dessus, dans le pire des cas je serais à 8Go max, donc je suis large. En vrai, je serais plutôt vers les 4/5Go. Inutile de dire que dans le second cas avec du chunk 512K, j'aurais plus 5Go théorique et 3Go réel. C'est pas grave, c'est quoi quelques giga de perdu sur autant de To? Pour avoir l'esprit tranquille? Bon toi avec tes 2M de chunk, tu consommeras effectivement largement moins. Donc tu devrais être tranquille maintenant avec tes 11To. > J'ai découvert les options thin_pool_autoextend_threshold et thin_pool_autoextend_percent dont l'interprétation varie selon la source (pas oser expérimenter du coup...) J'ai testé, cela marche pas trop mal, si tu dépasse le thin_pool_autoextend_threshold% d'utilisation des meta, cela augmente de thin_pool_autoextend_percent% celui-ci. Mais je me suis retrouvé avec un cas étrange où cela augmente le tmeta mais pas le pmspare. Je ne sais pas si c'est volontaire, un bug, un souci de configuration de mon côté. > Ma peur de me retrouver dans une situation encore plus dégradée me rend très réticent à toute expérimentation (heureusement seul data2cold est à refaire pour le moment). Compréhensible. Si tu as d'autres thinpool, il faudra sans doute redimensionner tous les tmeta et reconstruire les pmspare. Si les calculs théoriques te semblent un peu étranges par rapport à ce que tu vois, essaye de calculer par rapport à l'utilisation réel (Data% vs Meta%). Tu auras une idée de combien tu auras besoin, par exemple si tu consommes 80% de Meta avec 50% des Data, tu sais qu'il faudra sans doute au moins doubler le tmeta. Dans tous les cas avant manipulation, check l'état de tes backups. On ne sait jamais. Bon courage à toi P.S : Désolé des fôtes, il est tard :-) Johann Le mar. 1 déc. 2020 à 17:12, Pi Droid <pidroid.b@gmail.com> a écrit : > Hello, > > TL;DR : Comment gérer efficacement les pools LVM-Thin sous proxmox ? sans > risque de crash dû à des metadata à 100% ? > > Il y a quelque temps, j'avais basculé mes "datastores" Proxmox d'un > traditionnel LVM à du LVM-Thin pour diverses raisons (snapshot, clone, > overcommitment avec discard ...) > > Seulement, voilà, le 23/11/20 la VM 118 de type "NAS" (samba) voit son > disque dédié aux données en erreur au fur et à mesure que l'on stocke > dessus avec notamment la perte significative de données (Cf plus bas pour > les logs) puis fini par basculer régulièrement en read only jusqu'au > 29/11/20 (oui... je pense que vous noterez ici la concordance avec un > potentiel petit souci de monitoring et je ne vous parle pas de la fin de > vie de mon backup hors site chez C14... ). > > Après de nombreuses investigations, je découvre que le pool LVM-Thin sur > lequel était le LV dédié aux données affiche un taux d'occupation de > metadata à 100%. > > Quelques infos qui aideront, je l'espère, à la compréhension : > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > ~# vgs v2cold > VG #PV #LV #SN Attr VSize VFree > v2cold 1 11 0 wz--n- 16.37t 1.08t > > ~# lvs -a v2cold > LV VG Attr LSize > Pool Origin Data% Meta% Move Log Cpy%Sync Convert > data2cold v2cold twi-aotz-- 11.29t > 52.09 38.59 > [data2cold_tdata] v2cold Twi-ao---- 11.29t > > [data2cold_tmeta] v2cold ewi-ao---- 288.00m > > [lvol0_pmspare] v2cold ewi------- 128.00m > > ressource2cold v2cold -wi-ao---- 4.00t > ... > vm-118-disk-0 v2cold Vwi-a-tz-- <3.91t > data2cold 31.33 > vm-118-disk-1 v2cold Vwi-aotz-- <3.91t > data2cold 31.05 > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Afin de résoudre au plus vite la situation, voici les actions menées : > - arrêt de toutes les vm utilisant data2cold > - augmentation des metadata pour ce pool via la commande : lvextend > --poolmetadatasize +160M v2cold/data2cold > - augmentation du lv-thin suite à warning sur manque d'espace : lvextend > -L +300G v2cold/data2cold > - tentative de redémarrage de la VM 118 en question (boucle de : boot + > fsck + test d'écriture) mais ca retombe toujours en erreur. J'en ai conclu > (à tort ?) que le LV vm-118-disk-0 de la VM était mort. > - création d'un autre LV (vm-118-disk-1) sur ce même pool + restauration > de backup et switch entre les deux LV sur la VM > - la VM refonctionne à nouveau > > Maintenant après vérification, il est nécessaire de restaurer les autres > VM également. Seulement voilà... J'aimerai fiabiliser mes pool LVM-Thin... > J'ai lu de très très nombreux documents et sites sur le sujet (le plus > pertinent et complet à mes yeux pour ceux qui veulent : > https://bugzilla.proxmox.com/show_bug.cgi?id=1241 ) et suis "ravi" de > voir que je ne suis pas le seul à avoir rencontré ce problème... Pour > autant je n'ai pas trouvé de solution fiable et pérenne. > > En effet, voici mes conclusions : > > - La commande d'augmentation des metadata pour un pool n'est pas la bonne > (ou n'est pas complète). Bref, je ne suis pas parvenu à augmenter le > lvol0_pmspare alors que ce dernier est nécessaire pour les snapshots et > réparations si j'ai bien compris. > > - J'ai tenté de calculer la taille des metadata avec la formule <ThinPool > Size> / <Chunk Size> * 64 > Ce qui a donné pour mes 3 pools : > data0hot (taille 930G, chunk 512K) : 122 Mo > data1middle (taille 1,64T, chunk 1M) : 111 Mo > data2cold (taille 11,3T, chunk 2M) : 379 Mo > Complètement décorrélé de ce que j'ai sous les yeux... > > - J'ai découvert les options thin_pool_autoextend_threshold et > thin_pool_autoextend_percent dont l'interprétation varie selon la source > (pas oser expérimenter du coup...) > > - Ma peur de me retrouver dans une situation encore plus dégradée me rend > très réticent à toute expérimentation (heureusement seul data2cold est à > refaire pour le moment). > > Et ma question : Comment bien gérer les LVM Thin-pool sous proxmox ? > Je prends tout autre conseil également ! > > Merci d'avance, > > pidroid > > PS : concernant les incidents "monitoring" et "backup hors site", ils > seront traités dans les plus bref délais.. je l'espère :-P > > > ############################################################################### > > Kern.log de la VM 118: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Nov 29 00:32:17 vm-118 kernel: [ 772.386502] EXT4-fs error (device dm-0): > ext4_ext_map_blocks:4321: inode #82575362: comm kworker/u4:1: bad extent > address lblock: 122881, depth:$ > Nov 29 00:32:17 vm-118 kernel: [ 772.388484] EXT4-fs (dm-0): Delayed > block allocation failed for inode 82575362 at logical offset 122881 with > max blocks 2048 with error 117 > Nov 29 00:32:17 vm-118 kernel: [ 772.388587] EXT4-fs (dm-0): This should > not happen!! Data will be lost > Nov 29 00:32:17 vm-118 kernel: [ 772.388587] > Nov 29 00:32:17 vm-118 kernel: [ 772.426374] sd 2:0:0:2: [sdb] tag#169 > FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > Nov 29 00:32:17 vm-118 kernel: [ 772.426382] sd 2:0:0:2: [sdb] tag#169 > Sense Key : Aborted Command [current] > Nov 29 00:32:17 vm-118 kernel: [ 772.426384] sd 2:0:0:2: [sdb] tag#169 > Add. Sense: I/O process terminated > Nov 29 00:32:17 vm-118 kernel: [ 772.426390] sd 2:0:0:2: [sdb] tag#169 > CDB: Write(16) 8a 00 00 00 00 00 9d 9e 51 50 00 00 00 08 00 00 > Nov 29 00:32:17 vm-118 kernel: [ 772.426393] print_req_error: I/O error, > dev sdb, sector 2644398416 > Nov 29 00:32:17 vm-118 kernel: [ 772.426472] Buffer I/O error on dev > dm-0, logical block 330549546, lost async page write > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ >
Bienvenue dans ce que beaucoup d'entre nous on du expérimenter une fois... et désolé pour toi!
Suite à des expérimentations avec Ganeti, chez eux, le meta-disk est aussi external et... figé dans les constantes à 128 Mo. Autant dire qu'aux alentours de 4 To ça boum. Bon ça se modifie, se recompile mais trop de legacy pour nous avec Ganeti (prends pas en compte le nouveau mode turbo PVH de Xen sans recompil, mais pas que). Proxmox (que je ne connais pas), si j'en crois cette thread, laisse l'humain décider (il est pas con Proxmox :) On est en train de dev notre (tout petit) gestionnaire de cluster pour nos (tous petits) besoins. Le calcul (dans la doc DRBD) vérifié et avec de la marge, une fois extrapolé, ça donnerait ça... SECTOR_SIZE(o)= blockdev --getbsz /dev/xvda1 SECTOR_TOTAL = blockdev --getsz /dev/xvda1 DISK_SIZE(Mo) = (SECTOR_TOTAL * SECTOR_SIZE) / 1048576¹ PEER_TOTAL = 3 (en tiers III, sinon 2 en tiers II²) ¹1048576 = 1024² ²Tiers III : 1 prim, 2 sec, Tiers II, 1 prim, 1 sec. META_SIZE(Mo) = int((DISK_SIZE / 32768 * PEER_TOTAL)+2) Exemple SECTOR_SIZE(o)= 512 SECTOR_TOTAL = 6291456 DISK_SIZE(Mo) = 6291456 * 512 / 1048576 = 3072 META_SIZE(Mo) = int((3072 / 32768 * 3¹) + 2) = 2³ ³ int(1,28 + 1) Quelques valeurs (pour des secteurs de 512 et Tiers III) : 20 Go : 3 Mo 100 Go : 11 Mo 150 Go : 15 Mo 1 To : 94 Mo Comme on le voit, ça donne des volumes tous petits (et encore c'est du * 3 à cause du tiers 3) Notre use-case, c'est du NVMe, on a pas de grosses capas et essentiellement des petites VM (3 à 10..20 Go, quelques à 100/150 Go). Pas de LVM-thin. Le gestionnaire calcule et affecte le volume de meta à la création et à l'agrandissement mais laisse tel quel au rétrécissement. -- Be Seeing You Number Six
Salut, Merci pour ces retours ainsi que toutes ces explications ! Ça me rassure énormément :) @Johann
Tu as une solution pour résoudre le soucis du pmspare qui n'a plus la bonne taille : - Éteint toute tes VM utilisant le thinpool - Démonte tout ce qui tape dedans - Effectue ensuite un "lvconvert --repair v2cold/data2cold"
[...]
Elle est top cette procédure et les explications qui vont avec aussi :) Merci ! Je vais faire progressivement mes 3 thinpool en commencant par le moins sensible : data2cold
augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold Je pense que c'était superflu, d'après ton lvs -a, tu n'utilise que ~52% de data sur les 11.3T que tu as maintenant. Sauf si ce message était dû au fait que tu as réservé plus que les 11T sur l'ensemble des LV thin de tes VM? Si c'est le cas, à toi de voir, si tu ne penses jamais utiliser tous les disques au maximum... Après si tu préfères la sécurité et que ta la capacité disponible!
Effectivement, n'étant pas trop sûr de ce que je faisais, j'ai laissé les anciens LV Thin au cas où... Bien que je n'utilise que ~52%, j'ai probablement dépassé les 11T de provisionné. Vais pouvoir attaquer le ménage bientôt :)
J'ai tenté de calculer la taille des metadata avec la formule <ThinPool Size> / <Chunk Size> * 64 Effectivement c'est une bonne technique, j'avais dû la voir à une époque mais elle m'était sortie de la tête. Même si avec ces calculs je trouve le double de ceux que j'aurais en vrai si je suis mon utilisation actuelle. Je ne sais pas si je suis fatigué et raté quelque chose, possible... Soit un détail m'échappe dans le calcul. Après ça vaut mieux trop que pas assez. Mais n'oublie pas que cela serait les valeurs maximum théorique utilisées et pas l'utilisation actuelle. Mais tu tombes comme moi sur une valeur supérieure à la réalité.
Arf... j'aurai du rajouter la visu pour data0hot et data1middle dans le "lvs -a" et ce dernier est d'ailleurs réalisé a posteriori de la "réparation" (j'aurai du le préciser) data0hot (taille 930G, chunk 512K) : - calculé : 122 Mo - constaté : 120 Mo avec pour usage Data%=64.23 et Meta%=88.02% data1middle (taille 1,64T, chunk 1M) : - calculé : 111 Mo - constaté : 108 Mo avec pour usage Data%=3,02% et Meta%=11,93% Je me suis peut être trompé dans mes calculs. Mais comme tu le précises bien, autant voir large surtout qu'on n'est pas sur les mêmes ordres de grandeur entre Data et Meta
J'ai découvert les options thin_pool_autoextend_threshold et thin_pool_autoextend_percent dont l'interprétation varie selon la source (pas oser expérimenter du coup...) J'ai testé, cela marche pas trop mal, si tu dépasse le thin_pool_autoextend_threshold% d'utilisation des meta, cela augmente de thin_pool_autoextend_percent% celui-ci. Mais je me suis retrouvé avec un cas étrange où cela augmente le tmeta mais pas le pmspare. Je ne sais pas si c'est volontaire, un bug, un souci de configuration de mon côté.
Ah ok, du coup j'élimine cette option. Merci.
Dans tous les cas avant manipulation, check l'état de tes backups. On ne sait jamais.
Avec l'absence de backup hors-site, j'ai actuellement 3 duplication de backups sur site (ressource2cold... pas top ^^, un sur SoC et un autre sur mon LAB) et je refuse tout crash de météorite, inondation ou incendie sur ces prochains jours (et ceux d'après aussi :P ) @Stéphane Je ne connais pas du tout Ganeti (j'ai été voir un peu de quoi il s'agissait) C'est intéressant comme approche votre gestionnaire de cluster (et ca m'éclaire un peu plus sur le fonctionnement et rôle des metas) Pour ma part, je suis encore en mono-server sans HA et j'ai cru comprendre que Ceph sous Proxmox répondait également à ce besoin. Je m'orienterai probablement vers ce dernier si l'occasion (donc la réussite ^^) se présente. Encore merci à vous, c'est un grand soulagement de savoir que cet incident sera très prochainement clôturé et que j'en ressors grandi... A+ Pidroid
@Stéphane
Je ne connais pas du tout Ganeti (j'ai été voir un peu de quoi il s'agissait)
Imho, ce fut génial, ça l'est encore dans certains cas. Pas pour notre use-case.
C'est intéressant comme approche votre gestionnaire de cluster (et ca m'éclaire un peu plus sur le fonctionnement et rôle des metas)
Ben dès que t'as du DRBD, mais que tu veux laisser l'humain en priorité et refuser l'automagie "pacemaker/corosync"... Pas trop le choix. Sinon des scripts pour monter et descendre proprement les nodes (ce qu'on faisait jusqu'à présent)... Et laisser l'humain faire le reste. Ganeti nous a inspiré. Ce que l'on code est mille fois plus simple à utiliser mais limité à notre use-case GNU/Linux Debian Xen LVM DRBD.
Pour ma part, je suis encore en mono-server sans HA et j'ai cru comprendre que Ceph sous Proxmox répondait également à ce besoin. Je
CEPH c'est le top mais pour les riches (smile), il parait qu'il faut 4 bécanes pour être vraiment tranquille (j'ai gardé une thread au chaud sur ça par "les gens qui savent" : 3 ne seraient pas assez... Nous, on est pauvre et c'est du DRBD... Et vu notre use-case, c'est très bien en plus. Mais CEPH est à un autre niveau :) -- Be Seeing You Number Six
Effectivement, bon faut que je cible une sacrée réussite alors :D Voici ce que j'ai fait (uniquement sur data2cold pour l'instant) : - Augmenter encore la taille du metadata : lvextend --poolmetadatasize +224M v2cold/data2cold - Eteindre toutes les VM et containers utilisant le Thinpool - Désactiver le pool : lvchange -an v2cold/data2cold - Désactiver les Thin de ce pool : lvchange -an /dev/v2cold/* - Effectuer ensuite un "lvconvert --repair v2cold/data2cold" - Réactiver le pool : lvchange -ay v2cold/data2cold - Réactiver les Thin de ce pool : lvchange -ay v2cold - Redémarrer les VM et containers correspondants A priori, tout fonctionne ! \o/ Je vais attendre quelques jours avant d'attaquer les deux autres pool (soit le prochain full backup + weekend pour gérer l'interruption de service) Bonus PROXMOX : Pour identifier les anciens LV entre proxmox et les VM (oui j'ai oublié de les identifiés et avec deux LV de même taille, je ne savais plus lequel supprimer ^^), j'ai fait dans la VM : lsblk -o +SERIAL Cela renvoie en SERIAL par défaut : drive-<BUS><DEVICE> (ex : drive-scsi2) Oui ! Proxmox rajoute un serial par défaut sur chaque disque... pratique non ? (moi je viens tout juste de le découvrir ^^) Encore merci pour vos aides ! Pidroid
Le 02/12/2020 à 11:33, Stéphane Rivière a écrit :
Pour ma part, je suis encore en mono-server sans HA et j'ai cru comprendre que Ceph sous Proxmox répondait également à ce besoin. Je
CEPH c'est le top mais pour les riches (smile), il parait qu'il faut 4 bécanes pour être vraiment tranquille (j'ai gardé une thread au chaud sur ça par "les gens qui savent" : 3 ne seraient pas assez...
Nous, on est pauvre et c'est du DRBD... Et vu notre use-case, c'est très bien en plus. Mais CEPH est à un autre niveau :)
Alors, justement. J'ai fais un bout de lab ces derniers jours et Ceph en single node, pourquoi pas ? Je me suis inspiré de la doc ici pour construire une crushmap adéquate : https://linoxide.com/linux-how-to/hwto-configure-single-node-ceph-cluster/ Et ça fonctionne. Maintenant, on peut s'interroger sur l'intérêt. Mon use-case était de pouvoir mettre en place une réplication asynchrone avec rbd-mirror. Pas grand chose de plus que ce qu'offrirait un zfs send/receive finalement. Mais on peut trouver beaucoup d'autres avantages : accès à cephfs, rados gateway (S3), rbd-diff pour le backup, le dashboard/export prometheus de ceph-mgr, etc ... Et il reste toujours la possibilité d'évoluer vers plus cossu dans le futur (en évitant soigneusement d'avoir un cluster à deux nœuds, il faut passer tout de suite à 3). En réalité, on est dans un cas de RAID en userspace avec une tonne de fonctionnalités additionnelles. Le système survivra sans problème à la perte d'un disque et le fonctionnement de Ceph intègre nativement la notion de hot-spare, pas toujours trivial à faire avec mdadm. Bref, on est pas dans un scénario de haute-dispo mais l'apport en fonctionnalités de Ceph est quand même un gros plus par rapport à mdadm ou ZFS. Maintenant, est-ce que d'après vous j'ai loupé un truc dans le setup ou est-ce que c'est réellement viable ? (en dehors du fait que c'est un gros hack par rapport à ce pourquoi Ceph est prévu). Merci, Julien
Hello, Si tu veux faire vraiment faire du Ceph sur un seul serveur, je te conseille d'avoir 3 OSD (sur 3 disques différents) et la triple réplication. Ca permettra d'assurer la consistance des données et de ne pas en perdre. D'un point de vue technique ça fonctionnera sans problème, ceph se moque de savoir si tu as 1 ou 50 racks, 1 ou 300 serveurs. Mais c'est forcément une utilisation peu courante et ca n'a pas été pensé pour. Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément nécessaires, ni une bonne idée. Étienne ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, December 2nd, 2020 at 3:10 PM, Julien Escario <julien.escario@altinea.fr> wrote:
Le 02/12/2020 à 11:33, Stéphane Rivière a écrit :
Pour ma part, je suis encore en mono-server sans HA et j'ai cru
comprendre que Ceph sous Proxmox répondait également à ce besoin. Je
CEPH c'est le top mais pour les riches (smile), il parait qu'il faut 4
bécanes pour être vraiment tranquille (j'ai gardé une thread au chaud
sur ça par "les gens qui savent" : 3 ne seraient pas assez...
Nous, on est pauvre et c'est du DRBD... Et vu notre use-case, c'est très
bien en plus. Mais CEPH est à un autre niveau :)
Alors, justement. J'ai fais un bout de lab ces derniers jours et Ceph en
single node, pourquoi pas ?
Je me suis inspiré de la doc ici pour construire une crushmap adéquate :
https://linoxide.com/linux-how-to/hwto-configure-single-node-ceph-cluster/
Et ça fonctionne.
Maintenant, on peut s'interroger sur l'intérêt. Mon use-case était de
pouvoir mettre en place une réplication asynchrone avec rbd-mirror. Pas
grand chose de plus que ce qu'offrirait un zfs send/receive finalement.
Mais on peut trouver beaucoup d'autres avantages : accès à cephfs, rados
gateway (S3), rbd-diff pour le backup, le dashboard/export prometheus de
ceph-mgr, etc ...
Et il reste toujours la possibilité d'évoluer vers plus cossu dans le
futur (en évitant soigneusement d'avoir un cluster à deux nœuds, il faut
passer tout de suite à 3).
En réalité, on est dans un cas de RAID en userspace avec une tonne de
fonctionnalités additionnelles. Le système survivra sans problème à la
perte d'un disque et le fonctionnement de Ceph intègre nativement la
notion de hot-spare, pas toujours trivial à faire avec mdadm.
Bref, on est pas dans un scénario de haute-dispo mais l'apport en
fonctionnalités de Ceph est quand même un gros plus par rapport à mdadm
ou ZFS.
Maintenant, est-ce que d'après vous j'ai loupé un truc dans le setup ou
est-ce que c'est réellement viable ? (en dehors du fait que c'est un
gros hack par rapport à ce pourquoi Ceph est prévu).
Merci,
Julien
Liste de diffusion du FRsAG
Le 02/12/2020 à 15:20, Etienne Menguy a écrit :
Hello,
Si tu veux faire vraiment faire du Ceph sur un seul serveur, je te conseille d'avoir 3 OSD (sur 3 disques différents) et la triple réplication. Ca permettra d'assurer la consistance des données et de ne pas en perdre.
Ah ? Intéressant, tu pourrais ajouter du détail sur ça ? Ou alors c'est simplement le même argument que pour le RAID6 vs RAID5 : plus de redondance, c'est plus de sécurité. Parce qu'avec un "size=2" sur trois disques, la perte d'un OSD (aka un disque) n'est pas un soucis tant que le rebalance peut se faire. J'essaie juste de faire le tour des contraintes, histoire de savoir dans quoi je m'embarque si je pousse une idée aussi farfelue en prod un jour.
D'un point de vue technique ça fonctionnera sans problème, ceph se moque de savoir si tu as 1 ou 50 racks, 1 ou 300 serveurs. Mais c'est forcément une utilisation peu courante et ca n'a pas été pensé pour.
Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément nécessaires, ni une bonne idée.
En fait, cela dépend fortement de l'interconnexion entre les nœuds : si ils sont répartis par deux dans deux racks différents avec interco simple, le risque de perdre le quorum est très important. Il vaut mieux en avoir 3 dans ce cas. En revanche, dans un même rack avec deux switchs différents en redondance, trois ou quatre ne change rien, si ce n'est dans la provision des disques pour éviter d'arriver à 100% d'occupation en cas de rebalance à la suite de la perte d'un nœud. Merci ! Julien
Ah ? Intéressant, tu pourrais ajouter du détail sur ça ? C'est principalement pour avoir moins de chances de perdre des données. Mais également, le problème de n'avoir que 2 fois la donnée c'est qu'en cas d'inconsistance ( si l'une des copie de l'objet change) tu ne sauras pas dire quelle version est la bonne. Tu vas devoir corriger en espérant que ce soit bien la primaire qui soit correcte.
Au passage si c'est pour des raisons de coûts, si tu as beaucoup de disques tu peux tester l'erasure coding, ça fonctionne aussi sur rbd et cephfs depuis quelques versions.
En fait, cela dépend fortement de l'interconnexion entre les nœuds : si ils sont répartis par deux dans deux racks différents avec interco simple, le risque de perdre le quorum est très important. Il vaut mieux en avoir 3 dans ce cas. En revanche, dans un même rack avec deux switchs différents en redondance, trois ou quatre ne change rien, si ce n'est dans la provision des disques pour éviter d'arriver à 100% d'occupation en cas de rebalance à la suite de la perte d'un nœud.
Même pour les monitors je pense que 2 est une prise de risque, on ne sait jamais ce qui peut arriver. Étienne ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, December 2nd, 2020 at 3:51 PM, Julien Escario <julien.escario@altinea.fr> wrote:
Le 02/12/2020 à 15:20, Etienne Menguy a écrit :
Hello,
Si tu veux faire vraiment faire du Ceph sur un seul serveur, je te conseille d'avoir 3 OSD (sur 3 disques différents) et la triple réplication.
Ca permettra d'assurer la consistance des données et de ne pas en perdre.
Ah ? Intéressant, tu pourrais ajouter du détail sur ça ? Ou alors c'est
simplement le même argument que pour le RAID6 vs RAID5 : plus de
redondance, c'est plus de sécurité.
Parce qu'avec un "size=2" sur trois disques, la perte d'un OSD (aka un
disque) n'est pas un soucis tant que le rebalance peut se faire.
J'essaie juste de faire le tour des contraintes, histoire de savoir dans
quoi je m'embarque si je pousse une idée aussi farfelue en prod un jour.
D'un point de vue technique ça fonctionnera sans problème, ceph se moque de savoir si tu as 1 ou 50 racks, 1 ou 300 serveurs.
Mais c'est forcément une utilisation peu courante et ca n'a pas été pensé pour.
Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément nécessaires, ni une bonne idée.
En fait, cela dépend fortement de l'interconnexion entre les nœuds : si
ils sont répartis par deux dans deux racks différents avec interco
simple, le risque de perdre le quorum est très important. Il vaut mieux
en avoir 3 dans ce cas.
En revanche, dans un même rack avec deux switchs différents en
redondance, trois ou quatre ne change rien, si ce n'est dans la
provision des disques pour éviter d'arriver à 100% d'occupation en cas
de rebalance à la suite de la perte d'un nœud.
Merci !
Julien
Liste de diffusion du FRsAG
Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément nécessaires, ni une bonne idée.
Je n'utilise pas CEPH. Voilà le notes que j'avais pris à l'époque. Aucune idée de la pertinence. Ces colistiers ont du vécu :) Leurs messages m'ont semblé assez clairs. J'en avais conclu que c'était super mais nécessitait une certaine "aisance" et, qu'en attendant, on continuerai avec DRBD... Laissé les emails : les archives sont publiques et ça permet de les contacter pour des précisions... 1 Architecture richard@demongeot.biz : CEPH étant (massivement) distribué, il devient de plus en plus performant avec le volume de disques que tu lui affectes. Selon la documentation, le minimum préconisé est de faire "3 copies", sur "3 machines différentes". CEPH préfère par ailleurs un accès direct au disque, et ne pas avoir de raid sur les disques. Setup standard CEPH : +--------------+ +--------------+ +--------------+ | Hôte1 | | Hôte2 | | Hôte3 | | HDD1 HDD2 | | HDD3 HDD4 | | HDD5 HDD6 | +--------------+ +--------------+ +--------------+ Ton premier bloc sera sur les disques 1, 3 et 5; Ton second sur les disques 2, 4 et 5; Etc. CEPH s’amusera à les placer différemment à chaque fois. Du coup, si tu n'as que 3 disques, les 3 seront "identiques", mais la fragmentation va te faire perdre en performance vis à vis de DRBD. Si tu as 12 disques ou plus, réparti dans plusieurs châssis, tu va pouvoir tirer parti de l'ensemble des axes / ports disques. Et plus tu rajoutes de disque, plus ta performance s'améliore :). 2 Algorithme frsag@frsag.org : Question de précision de l'algorithme de répartition des blocs de données (PG en langage ceph). Le manque de précision est du a une optimisation pour trouver plus rapidement le lieu ou est stocké le PG, du coup il y a une variation de quelques pourcents (voir dizaine) entre la quantité de données sur chaque disque. Les paramètres recommandés sont : 3 replicas, 2 nécessaires pour activer les écritures. Si on n'a que 3 noeuds et qu'on en perd un, on n'a pas *exactement* 33% des PG hors ligne, mais un peu plus ou un peu moins, ce qui fait qu’on se retrouve potentiellement avec des écritures bloquées sur une partie du cluster. D’où le 4 pour avoir une marge de manœuvre. 3 Incident wallace@morkitu.org : Ceph sur trois noeuds dans le moule Proxmox, ça marche quand tout est ok. Si tu perds un nœud le quorum en prend un coup comme pour Proxmox mais ça passe. On a découvert avec douleur qu'un cluster Proxmox trois nœuds qui démarre à froid (coupure courant de nuit dans une entreprise malgré l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un nœud ceph mort (l'équipe sur place faisait une maintenance sur les disques la veille) refuse de démarrer et donc tu ne peux pas faire repartir. Proxmox dans ce cas on peut toujours dire tel host a un point plus grand pour le quorum et/ou baisser le nombre de voix de chaque membre ça passe. Ceph on a pas trouvé et la seule façon a été de reconfigurer le cluster pour demander une réplication sur 2 noeuds au lieu de 3. Du coup gros travail de Ceph qui a bien saturé ses liens pendant 3 jours mettant des perfs assez faibles pour les vms. -- Be Seeing You Number Six
Si on n'a que 3 noeuds et qu'on en perd un, on n'a pas exactement 33% des PG hors ligne, mais un peu plus ou un peu moins, ce qui fait qu’on se retrouve potentiellement avec des écritures bloquées sur une partie du cluster. Il y a peut être des cas particuliers avec la configuration, mais je n'ai jamais vu cette situation. Que ce soit en coupant 1 osd d'un cluster de 3 osd, ou un rack d'un cluster de trois racks.
En effet un serveur aura plus ou moins d'un tiers des PG, mais tous les PG auront 2 copies donc le cluster acceptera les lectures/écritures.
On a découvert avec douleur qu'un cluster Proxmox trois nœuds qui démarre à froid (coupure courant de nuit dans une entreprise malgré l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un nœud ceph mort (l'équipe sur place faisait une maintenance sur les disques la veille) refuse de démarrer et donc tu ne peux pas faire repartir. Difficile à analyser sans avoir les logs, mais si le cluster était en bonne santé au moment de l'arrêt ce n'est pas normal.
Mais il arrive que Ceph fasse des choses surprenantes. Étienne ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, December 2nd, 2020 at 4:05 PM, Stéphane Rivière <stef@genesix.org> wrote:
Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément nécessaires, ni une bonne idée.
Je n'utilise pas CEPH. Voilà le notes que j'avais pris à l'époque.
Aucune idée de la pertinence. Ces colistiers ont du vécu :) Leurs
messages m'ont semblé assez clairs.
J'en avais conclu que c'était super mais nécessitait une certaine
"aisance" et, qu'en attendant, on continuerai avec DRBD...
Laissé les emails : les archives sont publiques et ça permet de les
contacter pour des précisions...
1 Architecture
richard@demongeot.biz : CEPH étant (massivement) distribué, il devient
de plus en plus performant avec le volume de disques que tu lui
affectes. Selon la documentation, le minimum préconisé est de faire "3
copies", sur "3 machines différentes".
CEPH préfère par ailleurs un accès direct au disque, et ne pas avoir de
raid sur les disques.
Setup standard CEPH :
+--------------+ +--------------+ +--------------+
| Hôte1 | | Hôte2 | | Hôte3 |
| HDD1 HDD2 | | HDD3 HDD4 | | HDD5 HDD6 |
+--------------+ +--------------+ +--------------+
Ton premier bloc sera sur les disques 1, 3 et 5;
Ton second sur les disques 2, 4 et 5;
Etc. CEPH s’amusera à les placer différemment à chaque fois.
Du coup, si tu n'as que 3 disques, les 3 seront "identiques", mais la
fragmentation va te faire perdre en performance vis à vis de DRBD.
Si tu as 12 disques ou plus, réparti dans plusieurs châssis, tu va
pouvoir tirer parti de l'ensemble des axes / ports disques. Et plus tu
rajoutes de disque, plus ta performance s'améliore :).
2 Algorithme
frsag@frsag.org : Question de précision de l'algorithme de répartition
des blocs de données (PG en langage ceph). Le manque de précision est du
a une optimisation pour trouver plus rapidement le lieu ou est stocké le
PG, du coup il y a une variation de quelques pourcents (voir dizaine)
entre la quantité de données sur chaque disque.
Les paramètres recommandés sont : 3 replicas, 2 nécessaires pour activer
les écritures.
Si on n'a que 3 noeuds et qu'on en perd un, on n'a pas exactement 33%
des PG hors ligne, mais un peu plus ou un peu moins, ce qui fait qu’on
se retrouve potentiellement avec des écritures bloquées sur une partie
du cluster.
D’où le 4 pour avoir une marge de manœuvre.
3 Incident
wallace@morkitu.org : Ceph sur trois noeuds dans le moule Proxmox, ça
marche quand tout est ok. Si tu perds un nœud le quorum en prend un coup
comme pour Proxmox mais ça passe.
On a découvert avec douleur qu'un cluster Proxmox trois nœuds qui
démarre à froid (coupure courant de nuit dans une entreprise malgré
l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un nœud ceph mort
(l'équipe sur place faisait une maintenance sur les disques la veille)
refuse de démarrer et donc tu ne peux pas faire repartir.
Proxmox dans ce cas on peut toujours dire tel host a un point plus grand
pour le quorum et/ou baisser le nombre de voix de chaque membre ça passe.
Ceph on a pas trouvé et la seule façon a été de reconfigurer le cluster
pour demander une réplication sur 2 noeuds au lieu de 3. Du coup gros
travail de Ceph qui a bien saturé ses liens pendant 3 jours mettant des
perfs assez faibles pour les vms.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Be Seeing You
Number Six
Liste de diffusion du FRsAG
Bonjour, Le 02/12/2020 à 16:05, Stéphane Rivière a écrit :
Je n'utilise pas CEPH. Voilà le notes que j'avais pris à l'époque. Aucune idée de la pertinence. Ces colistiers ont du vécu :) Leurs messages m'ont semblé assez clairs.
3 Incident
wallace@morkitu.org : Ceph sur trois noeuds dans le moule Proxmox, ça marche quand tout est ok. Si tu perds un nœud le quorum en prend un coup comme pour Proxmox mais ça passe.
On a découvert avec douleur qu'un cluster Proxmox trois nœuds qui démarre à froid (coupure courant de nuit dans une entreprise malgré l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un nœud ceph mort (l'équipe sur place faisait une maintenance sur les disques la veille) refuse de démarrer et donc tu ne peux pas faire repartir.
Comme pour le lvm-thin, ce retour d'expérience est précieux pour construire et faire évoluer les infrastructures Proxmox et Ceph. Sur le lvm-thin, on va mettre une supervision sur ce point précis :-) J'ai testé le même type d'incident (coupure de courant) avec 5 serveurs Proxmox (6.3) dont 3 noeuds Ceph (15.2). J'ai cassé un serveur Proxmox et un noeud Ceph avant de couper brutalement le courant. Au redémarrage, J'ai allumé 2 serveurs Proxmox ayant 2 noeuds Ceph: -> J'ai eu droit un beau message du contrôleur RAID du genre "flushing cache", car il y avait des données dans la mémoire du contrôleur lors de l'arrêt brutal, et donc il a écrit les données sur les disques au rallumage. -> Le Ceph a un peu rallé avec "Health Warning" (active+undersized), mais il était accessible -> Le Proxmox a refusé de démarrer les VMs car le quorum n'était pas là. J'ai rallumé un Proxmox supplémentaire (pour arriver à 3): -> Les VMs sont reparties. J'ai rallumé le reste : dernier noeud Ceph et 2 derniers proxmox: -> Après quelques minutes, le Ceph est repassé en Health OK -> Le proxmox cassé ne s'est pas réintégré (différence de numéro de version dans corosync) Je vais essayer d'être un peu plus pénible avec Ceph en provoquant des coupures brutales à des moments différents. -- *Emmanuel DECAEN*
'jour
Je vais essayer d'être un peu plus pénible avec Ceph en provoquant des coupures brutales à des moments différents.
Il me semble avoir lu sur le forum Proxmox que leurs devs conseillent de mettre 5 noeuds Ceph dans un cluster (hyperconvergé ou dédié Ceph). Comme ça, on peut en perdre 2 en même temps (coupure brutale) et on peut continuer en R/W (si le nombre de réplicant est suffisant bien sûr, il faut écrire les données sur trois noeuds). Il faut donc aussi au moins trois monitors et trois managers. Je les ai bêtement suivi leur conseil et ça fonctionne plutôt bien. Par contre, avec 5 noeuds et 40 OSD (8 SSD 2TB par noeuf), le facteur limitant en IOps c'est le réseau : deux ports 10 Gbps LACP dédiés pour le trafic Ceph c'est pas assez. Le bench rados le montre clairement (60 secondes, 16 threads 4 MB) : Total time run: 60.055428 Total writes made: 14405 Write size: 4194304 Object size: 4194304 Bandwidth (MB/sec): 959.447 Stddev Bandwidth: 24.6301 Max bandwidth (MB/sec): 1008 Min bandwidth (MB/sec): 892 Average IOPS: 239 Stddev IOPS: 6 Max IOPS: 252 Min IOPS: 223 Average Latency(s): 0.066696 Stddev Latency(s): 0.0290787 Max latency(s): 0.361495 Min latency(s): 0.0267153 Il faudrait taper dans du 40 Gbps et diminuer la latence. David
Bonjour, Le 03/12/2020 à 12:49, David Touitou a écrit :
'jour
Je vais essayer d'être un peu plus pénible avec Ceph en provoquant des coupures brutales à des moments différents. Il me semble avoir lu sur le forum Proxmox que leurs devs conseillent de mettre 5 noeuds Ceph dans un cluster (hyperconvergé ou dédié Ceph). Comme ça, on peut en perdre 2 en même temps (coupure brutale) et on peut continuer en R/W (si le nombre de réplicant est suffisant bien sûr, il faut écrire les données sur trois noeuds). Il faut donc aussi au moins trois monitors et trois managers.
Par contre, avec 5 noeuds et 40 OSD (8 SSD 2TB par noeuf), le facteur limitant en IOps c'est le réseau : deux ports 10 Gbps LACP dédiés pour le trafic Ceph c'est pas assez. Le bench rados le montre clairement (60 secondes, 16 threads 4 MB) : Total time run: 60.055428 Bandwidth (MB/sec): 959.447 Average IOPS: 239 Average Latency(s): 0.066696
Effectivement le réseau 10 Gbps est très vite bloquant avec du SSD. Quand je vois que je charge déjà à quasiment 8 Gbps en lecture avec du disque rotatif, j'imagine bien avec du SSD. Avec 5 OSD (4 disques rotatifs de 1,2 To en RAID5 chacun): En écriture: $ rados bench -p testbench 120 write Total time run: 120.064 Bandwidth (MB/sec): 572.128 Average IOPS: 143 Average Latency(s): 0.111835 En lecture aléatoire: $ rados bench -p testbench 100 rand Total time run: 100.114 Bandwidth (MB/sec): 784.268 <-- Average IOPS: 196 Average Latency(s): 0.080419 Ceci étant, je pense que j'ai des optimisations à faire sur la partie block device, car les résultats sont bien inférieurs. J'ai suivi ce petit guide pour le test : https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/1.3/html/... Avec des blocs de 64K, en écriture, j'arrive à atteindre 400 Mo/s, mais en lecture, ça tombe à 200 Mo/s. Ca me parait plutôt mauvais à comparer aux résultats du rados bench. -- *Emmanuel DECAEN*
Maintenant, est-ce que d'après vous j'ai loupé un truc dans le setup ou est-ce que c'est réellement viable ? (en dehors du fait que c'est un gros hack par rapport à ce pourquoi Ceph est prévu).
Aucune idée. Mais SPOF sur le node... mais j'imagine que dans certains cas, ça doit être bien :) DRBD a au moins le mérite de proposer de la migration à chaud, du n TIERS, etc. avec une mise en œuvre qui doit être rigoureuse mais quiest peu coûteuse... -- Be Seeing You Number Six
participants (8)
-
David Touitou -
Emmanuel DECAEN -
Etienne Menguy -
Johann -
Julien Escario -
Nicolas Parpandet -
Pi Droid -
Stéphane Rivière