[technique] [INCIDENT] perte de disque sur le cluster 20151130 17h et recovery tres difficile / arret des VM

[maxime]

Félicitations pour tout ce qui a été fait. Merci beaucoup.

Je souhaite à toute l'équipe et aux membres de l'asso mes meilleurs
voeux pour 2016.

With Data Love <3

Maxime


Le 01/01/2016 20: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
>