[technique] Incident : freeze de certaines VM et du cluster ceph ce dimanche 20141228 7h-17h

[Laurent GUERBY]

Bonsoir,

Ce matin sur g2 une des machines du cluster ceph+openstack avec 32GB de
RAM le OOM killer du kernel s'est activé :

Dec 28 03:04:50 g2 kernel: [1332869.080266] qemu-system-x86 invoked oom-killer: gfp_mask=0x3000d0, order=1, oom_score_adj=0
Dec 28 03:04:50 g2 kernel: [1332869.147266] qemu-system-x86 invoked oom-killer: gfp_mask=0x3000d0, order=1, oom_score_adj=0
Dec 28 07:14:23 g2 kernel: [1347828.381869] ceph-osd invoked oom-killer: gfp_mask=0x2040d0, order=2, oom_score_adj=0

Ce qui a entrainé l'arret de deux OSD supplementaires. Malgré
le redemarrage des trois OSD qui etaient down les VM bloquées
ne sont pas reparties et ceph affichait un grand nombre de "slow
request" avec plusieurs heures d'attentes. A defaut d'autre solution
grace aux details fournis par la commande "ceph health detail"
j'ai relancé tous les OSD avec des "slow request" et le
cluster est reparti sans aucun "slow request" qui etaient
donc probablement dues a des bugs de ceph. Il faudra
peut-etre prevoir un redemarrage regulier des OSD.

La cause du OOM sur g2 etait un manque de 
memoire libre (free+cache+buffer) :

$ for i in g1 g2 g3 g4 n7 stri; do echo $(ssh $i "egrep -E '^(MemFree|Cached|Buffers)' /proc/meminfo" 2> /dev/null|awk '{ sum+=$2 } END {print sum}'  ) == $i;done
7614620 == g1
3062148 == g2
6220152 == g3
7303196 == g4
11685936 == n7
5782120 == stri

Apres avoir procedé a un reequilibrage des VM :

7584568 == g1
7009208 == g2
6611900 == g3
7194924 == g4
7012856 == n7
6766500 == stri

Pour reference la memoire theorique prise par les VM, le
reste etant pris par openstack + les OSD ceph (qui sont
a 1.5 a 2GB de RAM piece, donc par disque) :

# tools/openstack-mem.py 
g1    13 17408
g2    19 15616
g3    19 19200
g4     9 14080
n7    15 25600
stri  19 13568
total 94 105472

Nous allons ajouter une machine "g5" avec 32GB RAM d'ici quelques
jours.

Un autre soucis lors du redemarrage est que les process nova-compute
sur certaines machines etaient bien presents (donc ok pour nagios)
mais non fonctionnels ce qu'a précisé la commande suivante :

# nova service-list
+----+------------------+-----------+----------+---------+-------+----------------------------+-----------------+
| Id | Binary           | Host      | Zone     | Status  | State | Updated_at                 | Disabled Reason |
+----+------------------+-----------+----------+---------+-------+----------------------------+-----------------+
| 1  | nova-consoleauth | openstack | internal | enabled | up    | 2014-12-28T17:36:47.000000 | -               |
| 2  | nova-scheduler   | openstack | internal | enabled | up    | 2014-12-28T17:36:47.000000 | -               |
| 3  | nova-cert        | openstack | internal | enabled | up    | 2014-12-28T17:36:47.000000 | -               |
| 4  | nova-conductor   | openstack | internal | enabled | up    | 2014-12-28T17:36:47.000000 | -               |
| 5  | nova-compute     | g3        | nova     | enabled | down  | 2014-12-28T09:17:17.000000 | None            |
| 6  | nova-compute     | g2        | nova     | enabled | down  | 2014-12-28T09:17:20.000000 | None            |
| 7  | nova-compute     | g1        | nova     | enabled | up    | 2014-12-28T17:36:41.000000 | None            |
| 8  | nova-console     | openstack | internal | enabled | up    | 2014-12-28T17:36:47.000000 | -               |
| 9  | nova-compute     | stri      | nova     | enabled | up    | 2014-12-28T17:36:48.000000 | None            |
| 10 | nova-compute     | n7        | nova     | enabled | down  | 2014-12-28T09:17:24.000000 | None            |
| 11 | nova-compute     | g4        | nova     | enabled | down  | 2014-12-28T17:18:04.000000 | -               |
+----+------------------+-----------+----------+---------+-------+----------------------------+-----------------+

Apres quelques /etc/init.d/nova-compute stop et start tout est rentré dans l'ordre.

Autres commandes d'interet pour surveiller openstack :

cinder service-list
neutron agent-list

Une derniere bizarrerie d'openstack est qu'il est possible de "nova
live-migration" une VM online en precisant le host de destination, mais
pour une VM stopée la commande "nova migrate" ne permet pas elle de
preciser vers ou la deplacer : c'est openstack qui choisit.

Sincèrement,

Laurent