[technique] Passage a straw2 was: [INCIDENT] perte de disque sur le cluster 20151130 17h et recovery tres difficile / arret des VM
Laurent GUERBY
laurent at guerby.net
Sam 16 Jan 16:48:34 CET 2016
Bonjour,
Nous allons commencer par l'activation de straw2 pour essayer de
reequilibrer l'usage des disques qui varie actuellement entre 40 et 80%
a cause (a priori) de straw.
Sincèrement,
Laurent
On Fri, 2016-01-01 at 21:16 +0100, Laurent GUERBY wrote:
> 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