[technique] Charge des serveurs KVM

[Mehdi Abaakouk]

On Mon, Jun 10, 2013 at 02:02:43PM +0200, Laurent Coustet wrote:
> 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.

Yep c'est clairement les disques :)

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

On a déjà testé c'est pas flagrant, on gagne un peu de RAM mais sans
plus.

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


Yep, moi aussi pour le boulot peu importe la distribution ou version de
celle-ci quand on a besoin d'une feature on backport/compile nous meme les
packages, c'est loin d'être un problème.

Mais les serveurs étant maintenu par des bénévoles, il faut faire
au plus simple et rester au plus prêt de ce qui est livré par les distributions.
Plus y'a de chose faite à la mano ou spécifique, plus faut documenter et plus les
gens auront peur de toucher au serveur.

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

Certes le risque de perte de données est minime, mais il existe. Et
surtout lorsque nous avons mis le cluster en place les coupures
d'électricité était un facteur trés important (qu'il est nettement moins
maitnenant).

Personnellement, si je voudrais multiplier par 2 les IO disques j'opterai
plutôt pour l'achat d'un seconds disques pour chaques nodes et
répartirait les VMs dessus. (Dans le cas de l'asso bien sur ;))

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

Super merci beaucoup !

-- 
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/bd7ecd5c/attachment.sig>