[technique] Incident : performance du cluster ceph jusqu'a dimanche 20141214 soir / mise a jour firefly => giant head / recovery ok

[Laurent GUERBY]

Le Monday 15 December 2014 à 11:29 +0100, Laurent GUERBY a écrit :
> Nous allons encore rajouter quelques disques aujourd'hui et verifier
> des reglages BIOS sur la machine n7 mais cela devrait etre transparent.

Nous avons passé avec succes le BIOS de n7 (Dell R310) de "ATA" a "RAID
mode" qui veut dire en fait AHCI. Par sécurité nous avions débranché les
disques car lors de la manipulation les messages du BIOS etant plutot
inquietants, et nous n'avions pas trouvé de documentation.

Trois disques 4 TB ont été ajoutés a g4 mais l'un des 4TB a fait une
erreur de lecture (et echec selftest smart) apres quelques heures
d'ecriture ceph, nous allons le remplacer cette apres midi.

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%         8         479139696

Mehdi a passé le mode par defaut des OSD en backfill basse priorité
ce qui evite de saturer le cluster quand on doit redemarrer un OSD
(qui revient aux parametres par defaut).

ceph tell osd.* injectargs '--osd-recovery-max-active 1'
ceph tell osd.* injectargs '--osd-max-backfills 1'

cat /etc/ceph/ceph.conf
...
osd_recovery_op_priority = 1
osd_recovery_max_active = 1
osd_max_backfills = 1


Le reequilibrage du cluster ceph s'est fini ce matin apres un peu plus
de 2 jours pour ~ 50% d'objets a deplacer :

Tue Dec 16 00:34:34 CET 2014 == 167048/6499436 objects degraded (2.570%); 3444694/6499436 objects misplaced (53.000%)
Tue Dec 16 04:14:23 CET 2014 == 121142/6389181 objects degraded (1.896%); 3195067/6389181 objects misplaced (50.007%)
Tue Dec 16 13:44:09 CET 2014 == 39946/6043929 objects degraded (0.661%); 2417736/6043929 objects misplaced (40.003%)
Tue Dec 16 23:51:29 CET 2014 == 25204/5624138 objects degraded (0.448%); 1574764/5624138 objects misplaced (28.000%)
Wed Dec 17 08:51:10 CET 2014 == 2324/5347210 objects degraded (0.043%); 962506/5347210 objects misplaced (18.000%)
Wed Dec 17 17:00:12 CET 2014 == 5255/5254174 objects degraded (0.100%); 525438/5254174 objects misplaced (10.000%)
Wed Dec 17 21:56:10 CET 2014 == 3278/5147034 objects degraded (0.064%); 257887/5147034 objects misplaced (5.010%)
Thu Dec 18 03:38:48 CET 2014 == 447/5042073 objects degraded (0.009%); 50441/5042073 objects misplaced (1.000%)
Thu Dec 18 05:06:39 CET 2014 == OK

# ceph -s
   cluster 1fe74663-8dfa-486c-bb80-3bd94c90c967
     health HEALTH_OK
     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 806, quorum 0,1,2 g1,g2,g3
     osdmap e27724: 24 osds: 23 up, 23 in
      pgmap v7564727: 4864 pgs, 7 pools, 8416 GB data, 2121 kobjects
            19910 GB used, 24992 GB / 47306 GB avail
                4864 active+clean
  client io 102397 B/s rd, 11888 kB/s wr, 270 op/s


Nous avons (re)crée un pool en erasure coding 4+1 et les tests sont en
cours (copie de 4 TB d'un disque sur un pool repliqué 2 a un disque du
pool EC 4+1 sur une VM), pour le moment tout marche bien.

Mehdi a identifié un bug sur le client KVM lors du changement de pg_num,
nous devons ouvrir un ticket a ce sujet mais pour le moment on va
laisser les pg_num inchangés.

Sincèrement,

Laurent