[technique] Intervention cluster Ceph 16/01/2019 / HGST

[Laurent GUERBY]

Bonsoir,

A noter que nous avons acheté des disques de la gamme HGST
(1x4 TB et 2x6 TB) :

https://www.ldlc.com/fiche/PB00261135.html
Device Model:     HGST HUS726T4TALA6L4
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches

https://www.ldlc.com/fiche/PB00261133.html
Device Model:     HGST HUS726T6TALE6L4
User Capacity:    6,001,175,126,016 bytes [6.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches

D'apres :

https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Hardware
#Blackblaze
https://www.backblaze.com/blog/2018-hard-drive-failure-rates/

Cette gamme de disque a un taux de panne annualisé autour de 0.5%
et elle monte jusqu'a 12 TB a 45-50 EUR/TB, le constructeur
les garanti 5 ans.

Sincèrement,

Laurent


On Wed, 2019-01-16 at 07:51 +0100, Mehdi Abaakouk via technique wrote:
> Bonjour,
> 
> Nous avons procéder hier au remplacement de 3 disques HS du cluster
> et 
> au rajout d'un onduleur.
> 
> Lors du remplacement d'un des disques sur la machine g5, celle-ci a 
> rebooté de façon inattendu rebootant quelque VMs (en peu avant 12h):
> 
> * scriptbox.tetaneutral.net
> * himalia.tetaneutral.net
> * rodo.tetaneutral.net
> * canalsud.tetaneutral.net
> * gllm.tetaneutral.net
> 
> Malheureusement les VMs ne sont pas reparti suite au reboot (IO
> error 
> dans les VMs alors que les disque étaient OK et clean vu de 
> l’extérieur).
> 
> Après pas mal de recherche, ce matin, j'ai trouvé que lors d'une mise
> à 
> jour nous avons loupé la mise à jour de permissions des clients ceph
> [1]
> (en meme temps y'avait rien sur le sujet dans les release notes et
> la 
> procédure d'upgrade...).
> 
> Ceci empêchait qemu de supprimer le précédent lock en écriture des 
> disques de ces VMs, provoquant les erreurs.
> 
> Après avoir appliqué les nouvelles permissions, j'ai rebooté les 5
> VMs 
> qui sont reparti normalement.
> 
> 
> Ensuite pendant le déplacement de certaines machines sur le
> nouvelles 
> onduleur, g11 n'a pas voulu redémarrer, nous avons du remplacer 
> l'alimentation.
> Quand la machine a redémarré, nous nous sommes pas aperçu de suite
> que 
> un des disques n'était plus détecté (surement mal reconnecté).
> 
> Le cluster restera en mode dégradé jusqu'à la prochaine intervention 
> (peu être Vendredi), vu le nombre de disques du cluster ceci n'aura
> pas 
> d'impact sur la prod.
> 
> A+,
> Mehdi
> 
> 
> [1] 
> http://lists.ceph.com/pipermail/ceph-users-ceph.com/2017-September/02
> 0693.html
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique