[technique] INCIDENT cluster ceph/openstack : explication via bug kernel ext4+xattr / netconsole

Ven 6 Nov 09:50:57 CET 2015

Bonjour,

Apres l'activation de netconsole sur les machines du cluster :

https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openstack-tools/revisions/master/entry/setup-netconsole.sh

Mehdi a ouvert un ticket sur kernel.org sur les backtrace collectees :

https://bugzilla.kernel.org/show_bug.cgi?id=107301
"system hang during ext4 xattr operation"

L'explication la plus probable de nos soucis est que nous avons
depassé une certaine limite via ceph sur ext4/xattr qui a revelé cette
"race condition" presente depuis longtemps dans le kernel.
La machine qui a le plus de cores (24 sur g4) est aussi celle
qui freeze le plus souvent.

Nous avons migré les OSD sur SSD de ext4 a xfs (reste un seul qu'on va
changer cette apres-midi) mais pour les 60 TB de données sur rotationnel
ca va prendre tres longtemps, reste a esperer que les developpeurs
kernel trouveront une solution rapidement, et qu'elle sera backportée.

Sincèrement,

Laurent

On Wed, 2015-11-04 at 20:09 +0100, Laurent GUERBY wrote:
> 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
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 