[Cloud Disk Array] Parfois de mauvaise perf

Heureux possesseur d'un Cloud Disk Array, nous avons ces derniers temps eu quelques problèmes de perf assez importantes.

On utilise Proxmox V4.4 (l'upgrade en V5 d'ici quelques semaines), avec des containers LXC.
Donc pour le moment on doit utiliser la configuration Tunables en mode HAMMER, vu que l'on est obligé d'utiliser le more krbd.

Le problème de perf que l'on obeserve provient d'un "rollback" d'un snapshot effectué sur un container.
Je m'explique, on fait un snapshot d'un container, voir plusieurs. Et on décide de faire un "rollback" sur un ancien snapshot, et à ce moment précis tout nos serveurs virtuelles (une petite cinquantaine, tous avec disque principal sur le Ceph) dans notre cluster proxmox (4 serveurs) sont bloqué, car en attente d'IO disponible.
Cela dure plusieurs seconde, voir parfois 1-2 minutes.
Si cela touchait que le serveur physique ou on lance la commande, ce serait """"compréhensible"""", mais là cela touche la totalité de notre infra.

Donc nous avons cherché à comprendre le pourquoi du comment, et on a trouvé que le Cloud Disk Array, basé sur Ceph, diminuait en performance lors de rollback de snapshots, avec des latences atteignant jusqu'à 47-50 secondes.

Situation avant le rollback:

osd fs_commit_latency(ms) fs_apply_latency(ms)
2 0 0
9 0 0
0 0 0
11 0 1
1 0 0
10 0 0
3 1 2
4 0 0
5 0 0
6 0 0
7 0 0
8 0 0

Situation pendant le rollback

osd fs_commit_latency(ms) fs_apply_latency(ms)
2 0 18163
4 0 21806
9 0 16942
0 0 18921
11 0 17599
1 0 9883
10 0 10030
3 0 10847
5 0 19072
6 0 9242
7 0 8703
8 0 18993

osd fs_commit_latency(ms) fs_apply_latency(ms)
2 0 0
4 0 10941
5 0 0
6 0 0
10 0 0
11 0 11575
0 0 42556
1 0 0
3 0 0
7 0 0
8 0 1
9 0 13964

et après le rollback:

osd fs_commit_latency(ms) fs_apply_latency(ms)
2 0 2
4 0 1
9 0 2
0 0 4
11 0 22
1 0 1
10 0 0
3 0 0
5 0 2
6 0 0
7 0 0
8 0 3

En fouillant un peu les configurations Ceph du Cloud Disk Array, on a trouvé deux paramètres qui pourrait poser problème:

osd_client_op_priority = 63
osd_recovery_op_priority = 3

Selon la documentation de Ceph, il semblerait que la valeur par défaut de "osd recovery op priority" est de 10. Sachant que plus la valeur est faible, plus la priorité est haute, cela veut dire que lorsqu'un client lance une commande, il passe en toute dernière priorité, et lors d'une recovery il y a une très haute priorité.

Nous ne savons pas si ces paramètres ont une influence sur notre problème, ce n'est qu'une hypothèse totalement gratuite de notre part. Simplement, nous aimerions configurer/optimiser la réaction du système avec notre utilisation du système de rollback, sans que tout l'environnement traine les pieds.

Pouvez-vous nous aider?
Merci d'avance.

Alessandro Perucchi