[technique] [INCIDENT] perte de disque sur le cluster 20151130 17h et recovery tres difficile / arret des VM
yarianlam
lam at yarian.eu
Sam 2 Jan 10:20:55 CET 2016
Bonjour à tou(te)s et Bonne Année !
Merci à toute l'équipe technique de l'asso qui se démène pour maintenir
un réseau neutre de qualité malgré toutes les embûches qui ont jonché le
chemin de cette année.
En vous souhaitant que 2016 roule et déroule sans problème et sans vous
bouffer la vie
Marc
Le 01/01/2016 21:16, Laurent GUERBY a écrit :
> Bonsoir,
>
> Le cluster est stable depuis quelques jours et nous avons pu finir la
> copie du pool EC 4+1 vers le nouveau pool EC 8+2 donc maintenant nous
> pouvons perdre jusqu'a 2 machines completes sur les 13 du cluster sans
> perdre de donnée.
>
> La recovery en décembre a été ralentie par des bugs sur l'EC :
>
> http://tracker.ceph.com/issues/13972
> http://tracker.ceph.com/issues/14009
>
> Et aussi par un probleme materiel le mardi 29 decembre 2015 lors du
> changement de la carte 2x10G de la machine g3 qui a refusé de redemarrer
> en bloquant au debut du "VGA BIOS". Nous avons alors commandé a LDLC
> (qui a maintenant une boutique a Toulouse a cote de Balma Gramont) une
> CM+RAM+proc et relancé le nouveau g3 jeudi 31 decembre. Une fois
> ramenée a la maison l'ancienne CM+RAM+proc de g3 a redemarré
> sans soucis, nous avons donc un spare ...
>
> Coté ceph nous avons supprimé les pools EC 4+1 (EC et cache) ce qui
> a l'air d'avoir libéré pas mal de mémoire sur les OSD probablement
> grace a la baisse du nombre de pg de 11000 a 3000.
>
> Il nous reste encore a :
> - passer sur une release officielle de ceph (on est sur 0.94.4+patch)
> - passer de straw straw2 car la repartition sur les
> disques est tres desequilibree : de 37% a 80% d'usage
> - passer de 768 a 1024 pg sur le pool disks
> - passer a 5 mon au lieu de 3
> - changer la configuration cache KVM
>
> Sincèrement,
>
> Laurent
>
> PS: RAM disponible en kB / uptime
> 12010884 == g1 == 21:12:34 up 52 days, 10:15, 1 user, load average: 5.52, 5.06, 4.56
> 16462352 == g2 == 21:12:35 up 52 days, 10:25, 0 users, load average: 2.33, 2.90, 2.96
> 28331672 == g3 == 21:12:36 up 1 day, 10:27, 1 user, load average: 1.66, 2.01, 2.13
> 12147428 == g4 == 21:12:37 up 31 days, 18:29, 0 users, load average: 4.18, 3.78, 3.80
> 14065604 == g5 == 21:12:37 up 52 days, 11:28, 0 users, load average: 3.71, 3.61, 3.59
> 13620056 == g6 == 21:12:38 up 52 days, 10:50, 0 users, load average: 2.17, 2.69, 2.91
> 10990636 == n7 == 21:12:39 up 52 days, 16:29, 0 users, load average: 2.57, 3.13, 3.16
> 14569472 == g8 == 21:12:39 up 52 days, 11:04, 0 users, load average: 2.08, 2.31, 2.29
> 12693760 == g9 == 21:12:40 up 32 days, 56 min, 0 users, load average: 3.97, 3.38, 3.26
> 13110304 == g10 == 21:12:41 up 31 days, 19:36, 0 users, load average: 4.63, 4.13, 3.81
> 14408244 == g11 == 21:12:41 up 42 days, 2:48, 0 users, load average: 2.02, 1.97, 1.81
> 13318532 == g12 == 21:12:42 up 42 days, 3:58, 0 users, load average: 2.40, 2.25, 2.12
> 16336764 == stri == 21:12:43 up 31 days, 18:55, 1 user, load average: 1.34, 1.36, 1.31
> 192065708 == TOTAL == Fri Jan 1 21:12:43 CET 2016
>
> Et etat du cluster:
> health HEALTH_OK
> osdmap e229721: 50 osds: 50 up, 50 in
> pgmap v38063769: 3072 pgs, 4 pools, 36300 GB data, 9148 kobjects
> 59982 GB used, 40675 GB / 100658 GB avail
>
> On Tue, 2015-12-01 at 13:52 +0100, Laurent GUERBY wrote:
>> Bonjour,
>>
>> Lundi 20151130 vers 17h nous avons un perdu un disque, avec
>> Mehdi nous avons alors pris la decision d'ajouter les
>> deux nouvelles machines au cluster pour compenser en activant
>> quelques bug fix ceph de repartition de donnee au passage.
>>
>> Malheureusement len recovery es OSD ont commencé a prendre enormement
>> de RAM jusqu'a plus de 10 GB RAM / TB disque alors que la documentation
>> ceph recommande 1 GB par TB.
>>
>> Une description plus technique est la :
>>
>> http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-December/006428.html
>>
>> Mehdi a reconstruit les packages ceph 0.94.5 avec trois bug fix
>> liés a la memoire mais cela n'a pas suffit. Nous avons ensuite :
>> - arrete toutes les VM
>> - revenu en arriere sur les repartition de donnees
>> - desactivé la plupart des actions ceph :
>> norecovery nobackfill notieragent noout nodown
>> - ajouté 64 GB de swap a chaque machine en swapfile
>> - forcé des release de RAM via ceph tell osd.N heap release
>> - et enfin volontairement arrete quelques OSD
>> qui n'arrivaient pas a rester stable, puis
>> nous les avons relancé progressivement au fur
>> et a mesure de l'amelioration
>>
>> Nous sommes actuellement revenus a un cluster
>> avec tous les OSD up et un recovery qui progresse
>> meme si le volume de donnee a replacer est tres consequent.
>>
>> Liste des trackers de bug ceph mentionnés sur IRC :
>>
>> http://tracker.ceph.com/issues/12565
>> http://tracker.ceph.com/issues/12681
>> http://tracker.ceph.com/issues/13642
>> http://tracker.ceph.com/issues/13692
>> http://tracker.ceph.com/issues/13821
>>
>> Nous allons relancer prudemment toutes les VM entre
>> aujourd'hui et demain.
>>
>> Sincèrement,
>>
>> Laurent
>>
>> root at g2:~# ceph -s
>> cluster 1fe74663-8dfa-486c-bb80-3bd94c90c967
>> health HEALTH_WARN
>> 2424 pgs backfill
>> 5 pgs backfilling
>> 3200 pgs degraded
>> 7 pgs recovering
>> 2793 pgs recovery_wait
>> 3200 pgs stuck degraded
>> 5 pgs stuck inactive
>> 5229 pgs stuck unclean
>> 401 pgs stuck undersized
>> 401 pgs undersized
>> recovery 6856503/105606816 objects degraded (6.492%)
>> recovery 39949831/105606816 objects misplaced (37.829%)
>> noout,noscrub,nodeep-scrub,notieragent flag(s) set
>> monmap e8: 3 mons at
>> {g1=192.168.99.251:6789/0,g2=192.168.99.252:6789/0,g3=192.168.99.253:6789/0}
>> election epoch 1374, quorum 0,1,2 g1,g2,g3
>> osdmap e221429: 50 osds: 50 up, 50 in; 2520 remapped pgs
>> flags noout,noscrub,nodeep-scrub,notieragent
>> pgmap v35402763: 11264 pgs, 6 pools, 44128 GB data, 13185 kobjects
>> 68298 GB used, 32359 GB / 100658 GB avail
>> 6856503/105606816 objects degraded (6.492%)
>> 39949831/105606816 objects misplaced (37.829%)
>> 6035 active+clean
>> 2704 active+recovery_wait+degraded
>> 2029 active+remapped+wait_backfill
>> 389 active+undersized+degraded+remapped+wait_backfill
>> 82 active+recovery_wait+degraded+remapped
>> 7 active+recovery_wait+undersized+degraded+remapped
>> 5 active+recovering+degraded
>> 5 undersized+degraded+remapped+wait_backfill+peered
>> 5 active+degraded+remapped+backfilling
>> 2 active+recovering+degraded+remapped
>> 1 active+degraded+remapped+wait_backfill
>> recovery io 170 MB/s, 42 objects/s
>> client io 0 B/s rd, 214 kB/s wr, 21 op/s
>>
>
>
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique
>
Plus d'informations sur la liste de diffusion technique