[technique] INCIDENT cluster ceph/openstack : migration debian 8 => ubuntu 14.04 / changement 3 SSD + 1 RAM
Laurent GUERBY
laurent at guerby.net
Lun 2 Nov 21:42:24 CET 2015
Bonsoir,
Nous avons passé la journée a TLS00 avec Mehdi, au niveau materiel :
- changement de 3 SSD qui avaient des Reallocated_Sector_Ct > 0
ces SSDs etaient bien au dela de leur "TB write" attendus (~ 75-150 TB
write pour cette generation). Il reste un SSD qui a
Reallocated_Sector_Ct que nous allons changer aussi
- changement d'une RAM reperee par une erreur MCE.
Il y a une autre machine qui a eu des erreurs MCE (plus rares)
mais nous n'avons pas encore pu avoir l'identification
de la barrete.
Au niveau logiciel comme nous soupconnons des problemes kernel
mis en evidence par ceph 0.94.5 et/ou l'utilisation plus poussee du
cluster ("soft lockup" en masse surtout sur la machine avec beaucoup de
core) nous avons décidé de passer a ubuntu trusty 14.04 qui est l'OS
actuellement recommandé pour ceph (et openstack) :
http://docs.ceph.com/docs/master/start/os-recommendations/
5 machines physiques sont maintenant sous ubuntu donc reste 6 a migrer,
la procedure est maintenant bien rodée. 4 OSD ont été migrés a XFS qui
est le filesystem recommandé (mais que nous ne pouvions utiliser sous
debian a cause de bug kernel cf l'an dernier) plutot que ext4.
Mehdi a partiellement migré a ubuntu la VM de management openstack,
il reste cette partie la a finir aussi.
Les VM adherents et infrastructure devraient etre up mais
quelques reboots sont sans doute encore a prevoir.
Comme nous avons utilisé quasiment tout le spare nous allons commander
rapidement une ou deux machines neuves basées sur Intel Skylake et DDR4
avec ASRock Q170M vPro :
http://www.ldlc.com/fiche/PB00196789.html
Coté SSD la nouvelle génération offre 10 a 20 fois plus de "TB write"
garantis que l'ancienne pour a peu pres le meme prix, par exemple le
Samsung SSD SM863 480 Go est garanti 5 ans ou 3000 TB write :
http://www.ldlc.com/fiche/PB00193406.html
Un résumé en tableau de la nouvelle gamme "PM/SM863" de Samsung :
http://www.anandtech.com/show/9455/samsung-releases-pm863-sm863-enterprise-sata-ssds-up-to-384tb-with-3d-vnand
"3000 TB write" correspond a trois reecriture quotidiennes de
l'integralité des 480G du disque pendant 5 ans. Les nouveaux
SSD Intel ont le meme genre de garantie maintenant.
Pour reference notre SSD qui a le plus de write est a 228 TB en 9891
heures soit 412 jours soit 553 GB write/jour (c'est celui qu'on doit
encore changer).
Sincèrement,
Laurent
On Thu, 2015-10-29 at 14:05 +0100, Laurent GUERBY wrote:
> Bonjour,
>
> Le cluster n'etant toujours pas stable nous avons migré
> ceph en 0.94.5 ce qui a permis de recuperer nos OSD
> qui ne voulait pas demarrer.
>
> Nous avons aussi remplacé un disque dur defaillant,
> et ajouté un SSD au cluster le temps de remplacer
> les deux autres SSD defaillants.
>
> Avec un ecran nous avons pu observer sur deux machines differentes
> des "BUG: softlockup - CPU#12 stuck for 22s! [ceph-osd:xxx" et
> la console ne repondait plus vraiment.
>
> En regardant en detail il y a une correlation entre
> la version du kernel et l'uptime des machines :
>
> g1 === 10:52:14 up 3 days, 2:44, 2 users, load average: 5.90, 6.56, 7.21
> g2 === 10:52:14 up 1 day, 2:16, 0 users, load average: 5.64, 5.79, 5.84
> g3 === 10:52:14 up 11:25, 0 users, load average: 5.48, 5.87, 6.27
> g4 === 10:52:14 up 55 min, 1 user, load average: 38.11, 17.31, 12.59
> g5 === 10:52:15 up 148 days, 12:54, 0 users, load average: 6.41, 6.01, 5.95
> g6 === 10:52:15 up 36 min, 0 users, load average: 7.59, 7.37, 6.41
> n7 === 10:52:15 up 149 days, 21:14, 2 users, load average: 12.56, 10.58, 10.13
> g8 === 10:52:15 up 17:12, 0 users, load average: 12.00, 10.85, 10.55
> g9 === 10:52:15 up 21:56, 0 users, load average: 8.37, 8.21, 8.06
> g10 === 10:52:15 up 1 min, 0 users, load average: 4.11, 1.28, 0.45
> stri === 10:52:15 up 1:34, 0 users, load average: 5.74, 6.40, 5.77
>
> g1 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
> g2 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
> g3 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
> g4 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
> g5 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
> g6 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
> n7 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
> g8 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
> g9 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19)
> g10 === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19)
> stri === Linux version 3.16.0-4-amd64 (debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
>
> g5 et n7 avaient 148+ jours d'uptime avec le kernel 3.16.7-ckt9-3~deb8u1
> nous avons donc downgradé toutes les autres machines de ckt11-1+deb8u3 a
> 3.16.7-ckt9-3~deb8u1.
>
> Meme avec cela ce matin il y a encore eu un reboot mais rien sur
> l'ecran : il est possible que les travaux en cours a TLS00 perturbent
> notre alimentation car les ouvriers sont sur le meme tableau que nous.
> La partie decoupe et percussion s'est terminee ce matin, il reste
> cependant de la soudure dans les jours qui viennent (d'apres google la
> norme EN 61000-3-12 est censé fixer les limites d'harmoniques d'un
> poste a souder a l'arc).
>
> 20 VM ne sont pas reparties a cause d'erreur dans la base openstack,
> Mehdi va regarder depuis Tokyo, 103 VM sont a priori fonctionnelles.
>
> Si le taux de plantage de machine physique ne diminue pas nous
> installerons un onduleur a double conversion 3kVA en amont
> des machines.
>
> Sincèrement,
>
> Laurent
>
> On Tue, 2015-10-27 at 23:45 +0100, Laurent GUERBY wrote:
> > Bonsoir,
> >
> > Dans la suite des aventures au pays de Murphy la machine g4 a planté
> > plusieurs fois dans la journée, comme c'est probablement un probleme
> > materiel je l'ai remplacée par une machine donnée par l'association ISF
> > http://www.isf.cc/ a tetaneutral.net la semaine derniere. En transvasant
> > les disques cela a l'air de fonctionner depuis un peu plus d'une heure.
> >
> > J'ai envoyé une requete sur la liste des utilisateurs ceph
> > et notre probleme d'OSD qui ne demarre pas semble
> > etre corrigé en 0.94.4 (on est en 0.94.2) :
> >
> > http://tracker.ceph.com/issues/13060
> > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-October/005727.html
> >
> > On ne peut pas utiliser directement 0.94.4 a cause d'un bug ceph/KVM
> > deja identifié sur ceph-users :
> >
> > https://www.mail-archive.com/ceph-users@lists.ceph.com/msg24339.html
> > http://tracker.ceph.com/issues/13559
> >
> > Et d'un autre bug qu'on a reporté il y a un moment et dont le fix a eté
> > commité seulement apres 0.94.4 :
> >
> > http://tracker.ceph.com/issues/10399
> >
> > 0.94 est une release LTS de ceph, reste a voir si on package une
> > 0.94.4 + fix qui nous interessent (probable).
> >
> > Sincèrement,
> >
> > Laurent
> >
> > On Mon, 2015-10-26 at 22:53 +0100, Laurent GUERBY wrote:
> > > Bonsoir,
> > >
> > > Le cluster est toujours en recovery mais ca n'impacte plus trop les VM
> > > visiblement.
> > >
> > > Il reste 3 VM adherents down (ilico, phoeneeks, uind) que je ne peux pas
> > > redemarrer a cause d'un etat openstack incoherent ("cannot xxx while it
> > > is in task_state powering-off"), il faudra que Mehdi jette un oeil
> > > depuis Tokyo :).
> > >
> > > Sincèrement,
> > >
> > > Laurent
> > >
> > > On Mon, 2015-10-26 at 12:48 +0100, Laurent GUERBY wrote:
> > > > Bonjour,
> > > >
> > > > Le cluster est toujours en recovery :
> > > >
> > > > 102 requests are blocked > 32 sec
> > > > recovery 2954723/65811225 objects degraded (4.490%)
> > > > recovery 2587563/65811225 objects misplaced (3.932%)
> > > > recovery 13/10406629 unfound (0.000%)
> > > >
> > > > pg 87.16 is active+recovery_wait+undersized+degraded+remapped, acting
> > > > [30,8,16,25,18,2147483647,1,14,39,9], 7 unfound
> > > > pg 87.7b is active+recovery_wait+undersized+degraded+remapped, acting
> > > > [17,30,15,2147483647,25,1,9,35,39,16], 6 unfound
> > > >
> > > >
> > > > Les "unfound" sont sur un pool utilisé par une seule VM, a priori
> > > > il n'y aura pas de perte de donnée malgré la perte de 3 disques (2 dans
> > > > le pool SSD qui est en redondance triple, et 1 dans le pool HDD qui est
> > > > soit triple soit 4+1 en cours de migration vers 4+2) mais la recovery
> > > > risque de durer encore une journee.
> > > >
> > > > Une fois la recovery finie nous ajouterons quelques disques
> > > > SSD neufs et proposerons une migration des petits disques systeme
> > > > (20G) sur le pool ceph SSD : les VMs qui sont sur le pool ceph SSD sont
> > > > deja revenues en ligne.
> > > >
> > > > Sincèrement,
> > > >
> > > > Laurent
> > > >
> > > > On Mon, 2015-10-26 at 08:31 +0100, Laurent GUERBY wrote:
> > > > > Bonjour,
> > > > >
> > > > > A 23h04 dimanche 20151025 la machine physique "stri" du cluster a planté
> > > > > et ce lundi 20151026 a 5h17 la machine "g2" du cluster a aussi planté.
> > > > >
> > > > > Avec IPMI j'ai redemarré stri et la machine est revenue, avec vPro
> > > > > sur g2 j'ai fait un fsck manuel sur sda2 puis la machine est
> > > > > revenue.
> > > > >
> > > > > Pendant le redemarrage g1 a 7h56 a aussi disparu, la aussi
> > > > > redemarrage au vPro.
> > > > >
> > > > > Apres ces redemarrages il y a actuellement 3 OSD avec un soucis :
> > > > >
> > > > > osd.0 hdd sur g1 refuse de demarrer sur un ASSERT :
> > > > > http://tracker.ceph.com/issues/13594
> > > > >
> > > > > osd.12 SSD n'existe plus (?) sur stri
> > > > > root at stri:/var/log/ceph# /etc/init.d/ceph start osd.12
> > > > > /etc/init.d/ceph: osd.12 not found (/etc/ceph/ceph.conf defines osd.14
> > > > > osd.13 osd.15 , /var/lib/ceph defines osd.14 osd.13 osd.15)
> > > > >
> > > > > osd.4 SSD sur g2 pareil :
> > > > > root at g2:/var/log/ceph# /etc/init.d/ceph start osd.4
> > > > > /etc/init.d/ceph: osd.4 not found (/etc/ceph/ceph.conf defines mon.g2
> > > > > osd.1 osd.21 osd.7 , /var/lib/ceph defines mon.g2 osd.1 osd.21 osd.7)
> > > > >
> > > > > Probablement un probleme puppet, j'attend le retour de Mehdi.
> > > > >
> > > > > En l'etat actuel les VM sont quasiment toutes down.
> > > > >
> > > > > Sincèrement,
> > > > >
> > > > > Laurent
> > > >
> > >
> >
>
Plus d'informations sur la liste de diffusion technique