[technique] Charge des serveurs KVM

[Laurent Coustet]

On 10/06/2013 12:17, Mehdi Abaakouk wrote:
> Salut,
>
> On Fri, Jun 07, 2013 at 11:45:04PM +0200, ed at zehome.com wrote:
>> Le 2013-06-03 12:07, Jérôme Nicolle a écrit :
>>> Est ce que ganeti a une commande magique pour sortir un rapport
>>> de l'état de charge ? Est ce qu'on a des graphes des I/O Wait sur
>>> chaque noeud ?
>>
>> Ganeti non, il faut faire ça sur chaque machine. Les paramètres à
>> regarder de près sont: - utilisation mémoire - utilisation CPU -
>> répartition de l'utilisation CPU. (usr, sys, idle) - contexts
>> switchs
>
> Y'a la checkmk qui surveille toute l'infra:
>
> http://nagios.tetaneutral.net/check_mk/
>
> sinon y'a un munin pour certain machine dont le cluster:
>
> http://nagios.tetaneutral.net/munin/

A ce que je voit le cluster est très très limité par les IO quand même !
Le CPU il se tourne les pouces.
Et la mémoire, et bien, ça mériterais probablement un test de KSM. 
(Kernel Samepage Merging) Mais bon avec ganeti il ne laissera pas faire 
facilement de l'overcommit donc bon; l'intérêt reste limité.

Il me parait clair que vu le nombre de machines virtuelles, il serait
intéressant de disposer de serveurs ayant 64G+ de mémoire. des VM a 256M
c'est quand même short de nos jours.

(Sachant que des carte mère pour 32G c'est facile à trouver. Pour 64G ou 
128G je ne sais pas si ça existe "a pas cher" (> 4 slots))

>> - AIO native - vhost_net - Trasparent HugePages
>
> Pour c'est trois options la debian squeeze est un peu vielle, il
> faut utiliser les kernel/kvm des backports et mettre à jour ganeti.
> (ou mieux passer à wheezy)

Ce n'est pas nécessaire. Qemu se compile très facilement/bien sous
squeeze. Après il suffit de générer des noyaux possédant les features
recherchées. (En prod j'utilise 3.4.y et plus récemment en cours de
déploiement 3.9.y)

Pour qemu, on déploie du 1.5.0.
Pour ganeti on construit aussi nos propre packages avec quelque patchs
customs.

Tout ça sur squeeze.

>> - Cache none
>
> Ca dépends des VMs (du besoin) mais dans presque tous les cas et par
> défaut c'est ce que est utilisé.
>
>> - DRBD protocol A ou B plutôt que C
>
> Seul le protocol C assure ceci: "Loss of a single node is guaranteed
>  not to lead to any data loss." et "Data loss is, of course, both
> nodes (or their storage subsystems) are irreversibly destroyed at the
> same time." <- C'est des rigolos chez drbd :)
>
> Le A est pour un cas bien particulier et le B pour les gens qui sont
> sure de jamais avoir de coupure d'élec donc pas nous :).

Certes, mais il faut relativiser. On parle de réplication *réseau*.
Protocol C ça veut dire qu'on attend que l'*AUTRE* noeud ai fait son fsync.

En A ou B tu fsync sur la machine locale tout de même hein!
Du coup lorsque les disques sont saturés sur un *autre* noeud, en
protocole C tu es impacté aussi. Pas cool ;-)

En productions j'utilise généralement le protocole B pour cette raison.

>> - Quelques sysctl pour empêcher CFS de s'énerver pour rien et
>> augmenter le débit d'instructions
>
> Si tu as des références (doc, blog, ...), j'ai jamais eu à en arrivé
>  jusque la, mais je suis très intéressé.

Et bien très récemment les paramètres non orthodoxes que j'utilise:

# Use hugepages as much as possible
echo always > /sys/kernel/mm/transparent_hugepage/enabled
# Disable automatic hugepages defrag
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
# Increase context switch cost
kernel.sched_migration_cost = 5000000

Le dernière paramètre est particulièrement important (10x la valeur par
défaut) pour les noyaux 3.0+. Cela permet d'augmenter (largement) la
bande passante CPU au détriment (d'un peu) de réactivité.

>> - ...
>
> On a changé et tuné le scheduler des disks aussi on est passé de cfq
>  à deadline.

Yep, par contre, deadline n'a pas de support cgroups, donc aucune
répartition possible de ce coté la.

>> Il est aussi largement possible d'utiliser cgroups afin de
>> prioriser / limiter les VM en terme de CPU, et d'IO. (débit, iops,
>>  burst, ...) (ça permet d'avoir des VM réactives chez tout le
>> monde, même si quelqu'un fait un dd if=/dev/vda of=/dev/null
>> conv=direct bs=1M) C'est très efficace si c'est bien fait.
>
> Pourquoi pas mais dans les faits à chaque fois que la répartition des
> IO semblait problèmatique (c'est pas arrivé souvent), y'avait un vrai
> problème dans le VM qui généré les IO.
>
> C'est sur que ca serait plus préventif et embecherai que les IO d'une
> VM géne ceux d'une autres.

Yep exactement.

> Le top serait que ca soit géré par ganeti (et malheureusement je
> crois pas) sinon faudrait surement écrire des hooks ganeti, et
> maintenant que ca tourne depuis longtemps c'est plus compliqué pour
> les tests. Faudra y penser si on agrandi le cluster.

Ganeti ne gère pas les cgroups c'est un peu normal, mais je pense que
tout ça est largement scriptable.