[technique] [INCIDENT] perte de disque sur le cluster 20151130 17h et recovery tres difficile / arret des VM
Laurent GUERBY
laurent at guerby.net
Ven 1 Jan 21:16:04 CET 2016
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
>
Plus d'informations sur la liste de diffusion technique