Re: [FRsAG] Recherche baie 42U 19" et accessoires
Hello, Pour ma part, problème résolu, j'ai trouvé ma baie ! Merci ! Pidroid-B Le lun. 3 févr. 2020 à 14:01, cam.la...@azerttyu.net a écrit : > Salut > > J'ai 4 baies 42u qui traînent et une demi baie dans mon stockage sur Lyon. > Je les gardes pour souvenir ... > > Si cela peut intéresser du monde. Je dois avoir des photos qui > traînent aussi pour les personnes intéressées. > > Km > > Le lun. 3 févr. 2020 à 12:18, Pi Droid a écrit : > > > > Hello, > > > > Oui, via leboncoin, à moins d'avoir raté une offre, frais de port > inclus, j'ai une "possibilité" de baie + quelques accessoires pour environ > 500 €, j'ai également regardé cablematic ou j'en arrive à 700€ approx > > J'ai également vu d'autres possibilités sur ebay entre autre... mais > rien en dessous de 500€. > > J'espère avoir la chance d'en trouver une pour bien moins que ça (je > croise les doigts :p) > > > > merci > > > > Le lun. 3 févr. 2020 à 11:55, Antoine Nivard a > écrit : > >> > >> Salut, > >> > >> Tu as regardé sur le boncoin? parfois, il y a de bonne affaire... > >> > >> a+, > >> > >> Antoine > >> > >> Le 03-02-2020 10:55, Pi Droid a écrit : > >> > >> Tiens ça pourrait être bien que je précise ou je suis ^^ > >> La Rochelle et je peux venir la chercher dans un rayon de 200km approx > autour > >> > >> Le lun. 3 févr. 2020 à 10:37, Jarod G. a > écrit : > >>> > >>> Tiens si quelqu'un a les mêmes specs mais en 24U sur Strasbourg (ou à > envoyer, je paye les frais de ports sans problème) ça m'intéresse :) > >>> > >>> Le 03/02/2020 à 10:28, Pi Droid a écrit : > >>> > >>> Bonjour, > >>> > >>> Je suis à la recherche depuis quelques temps d'une baie 42U 19" de > largeur 600mm et de profondeur 1000mm très bon marché. > >>> Ayant des difficultés à trouver, je tente via différents canaux... > >>> Bref, si vous avez besoin de vous débarrasser d'une baie à moindre > coût, n'hésitez pas à me contacter. > >>> De même si vous avez quelques accessoires de baie : écrou cage, > étagère, rail L universelle, passe câble... > >>> > >>> Merci d'avance, > >>> > >>> Pidroid-B > >>> > >>> ___ > >>> Liste de diffusion du FRsAG > >>> http://www.frsag.org/ > >>> > >>> -- > >>> Amicalement, > >>> Jarod G. > >>> > >>> GPG : 71E5 89D2 ADA9 F401 56CE 4374 B11B 7C56 F111 C320 > >>> > >>> ___ > >>> Liste de diffusion du FRsAG > >>> http://www.frsag.org/ > >> > >> > >> ___ > >> Liste de diffusion du FRsAG > >> http://www.frsag.org/ > >> > >> ___ > >> Liste de diffusion du FRsAG > >> http://www.frsag.org/ > > > > ___ > > Liste de diffusion du FRsAG > > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
[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 VSizeVFree v2cold 1 11 0 wz--n- 16.37t 1.08t ~# lvs -a v2cold LVVG Attr LSizePool 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-ao4.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 / * 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
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
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 / * 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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
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- (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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] [JOBS] Recherche Profils SysOps/DevOps/SRE
Hello, Je fais suivre à mon réseau. A+ Le mer. 11 août 2021 à 21:53, Un a écrit : > Le 11/08/2021 à 16:44, un+fr...@pontesprit.net a écrit : > > Le 11/08/2021 à 09:28, Jean-Yves LENHOF via FRsAG a écrit : > >> Le 2021-08-11 09:09, Nicolas GIRARDI a écrit : > >>> Bonjour. > >>> > >>> J’espère que mon message respecte la charte. N’hésitez pas à corriger > >>> le cas échéant. > >>> > >>> J’ai 2 postes ouverts dont voici la fiche de poste. > >>> > >>> > >>> > >>> > >>> Le salaire dépendra de l’expérience/profil du candidat. > >>> S’il manque des infos ou vous avez des questions je réponds > >>> rapidement en PM. > >>> > >>> Bonne journée à tous. > >>> > >>> Nicolas Girardi. > >> > >> Ah là là... les parisiens qui croient que Paris est le centre du > >> monde et donc qui ne mettent même pas que c'est la boite semble > >> localisée à Paris... > > halala, ces gens qui connaissent pas le télétravail ! ;-) > > > > > Alors moi, je voulais juste me moquer aimablement du Mr qui se > moquais des (méchants) Parisiens et signaler que le télétravail est une > possibilité pour ce genre de contrainte de lieu. > > Je suis content que certains trouvent le salaire 60k (max, certes) > évoqué soit limite ou que d'autre soient en mesure d'imposer un > télétravail, mais je rappel que ça n'est pas le cas de tout le monde > (quid de la majorité ?), et ceci même avec de nombreuse années > d'expérience. > > Si depuis le temps que j'entends des déclarations semblable, cela > s'était matérialisé, le télétravail aurai été généralisé bien avant la > pandémie et les salaires dans ce secteur bien supérieur. > Mais c'est bien d'avoir de l'ambition... > > > -- > A: Yes. > >Q: Are you sure? > >>A: Because it reverses the logical flow of conversation. > >>>Q: Why is top posting annoying in email? > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
