[technique] INCIDENT cluster ceph/openstack : remplacement de deux disques KO / migration debian 8 => ubuntu 14.04

Laurent GUERBY laurent at guerby.net
Mer 4 Nov 20:09:28 CET 2015 

Bonsoir,

Cette nuit un disque dur et un SSD ont laché, nous les avons remplacés,
le SSD par un Samsung SM863 480G garanti pour 3080 TB de write. 

Nous avons continué les migrations cette apres-midi et il reste
seulement deux machines sur les 11 du cluster sous debian : g1 avec le
SSD systeme a changer selon SMART et g9.

Trois autres SSD Samsung SM863 480G ont ete commandés, l'objectif est
d'avoir ces disques longue duree comme disque systeme + ceph
et des disques moins chers en ceph pur. Les pieces
de la machine skylake sont arrivées sauf le boitier prévu demain.

Nous avons remplacé la carte graphique nvidia GPGPU de g4 (la machine
donnée par ISF et qui n'a pas de carte graphique integree) par une
carte fanless ce qui a ramené le niveau de bruit a la normale
dans la salle tetaneutral.net a TLS00.

Enfin nous avons replacé le cache du pool erasure coding 
par du disque rotationnel plutot que SSD pour eviter d'user
les SSD prematurement. Nous avons du reconstruire quelques
meta données a la main, merci a sileht pour les scripts :).

Le cluster semble plus stable avec des machines a 2 et 3 jours d'uptime,
on va voir sur la duree une fois toutes les machines migrees, les
filesystem sous XFS et le materiel dégradé remplacé.

Sincèrement,

Laurent

On Mon, 2015-11-02 at 21:42 +0100, Laurent GUERBY wrote:
> 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