[technique] Charge des serveurs KVM

[Mehdi Abaakouk]

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/

> Un système hébergent beaucoup de VM nécessitent un tuning spécifique
> de qemu/kvm/linux pour avoir de bonne performances

Surtout que nos contraites matériels ne sont pas forcement celle d'une entreprise.

> Par exemple:
>   - virtio blk & virtio-net

C'est déjà le cas

>   - 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)

>   - 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 :).

>   - 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é.

>   - ...

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

> 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.

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.


A+

-- 
Mehdi Abaakouk
mail: sileht at sileht.net
irc: sileht
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 836 octets
Desc: Digital signature
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20130610/4cdd29fe/attachment.sig>