[Linux] Virtualisation et Asterisk.

[Frédéric MADROLLE]

Ca fait un moment que je voulais répondre à ce thread pour donner mon 
expérience
et du coup mon avis.

Je donne mon avis d'entrée de jeu :
Asterisk dans une domU c'est pas une bonne idée, préférer une machine 
dédiée pour Asterisk.

Cette affirmation est un peu moins vraie si l'on ne fait que de la 
téléphonie en SIP (c'est à dire
sans carte additionnelle FXO/FXS comme une TDM400P).

Début d'explication dans la suite.

Antoine Delaporte a écrit :
> Le Mon, Mar 10, 2008 at 02:05:25PM +0100, Mehdi AMINI écrivait:
>   
>>>> En resume ma reponse: si ton * est sur une machine virtualise, et
>>>>         
>>>  > qu'en plus certaiens domU te fond des calculs, la regullarite de la
>>>  > puissance cpu donne a ton * sera mediocre
>>>       
>> Xen est réputé pourtant ordonnancer équitablement le temps processeur
>> entre les domU, c'est à dire qu'un DomU qui voudrait bouffer tt le
>> proc ne devrait pas pouvoir le faire au détriment des autres. Ceci est
>> valable si ton appli peut se contenter de la fraction de temps
>> processeur attribuée à ton Dom.
>>     
> C'est quand tu vx que l'on se refait une maquette :D
>
> Mais de toutes facon, dans ce cas la il faut utiliser le SIP en monde
> re-invite et paf, le tour est joué !
>   
L'ordonnanceur de Xen n'est pas mal foutu, mais ça ne fait pas des miracles.
Comme l'a dit Antoine, Asterisk n'a pas de besoin d'une puissance 
extraordinaire, mais
d'une régularité parfaite. Si tu pendant une communication tu as un pic 
de charge, même
de courte durée, ça s'entend ! Surtout si la communication passe par une 
carte additionnelle.
Une communication purement réseau sera plus difficilement perturbée.
>   
>> Le scheduler de xen est d'ailleurs paramêtrable.
>>     
> Certes.
>   
Mais ça ne fait pas des miracles. Même en rendant une domU 4x fois plus 
prioritaire que les autres,
le pic de charge se fait entendre (en communication via une carte 
additionnelle).
C'est mieux mais encore pas parfait.
>   
>>> C'est con, j'ai utilisé Xen sur des gros bi-procs mais je n'avais pas
>>>  regardé ça : ne peut-on pas affecter en dur un CPU à une DomU. Si tu
>>>  refiles un CPU à ta DomU *, elle ne devrait plus avoir de souci,
>>>  n'est-ce pas ?
>>>       
>> C'est plus complexe dans la mesure où il y a d'une part l'attribution
>> des coeurs physique à un DomU et de l'autre le nombre de coeur
>> virtuels que voit la machine.  Effectivement si tu n'attribues qu'un
>> coeur à une machine virtuelle et que ce coeur n'est accessible par
>> aucun autre DomU, alors le DomU en question ne sera jamais préempté.
>> Mais si tu reserves un coeur à un DomU, en lui laissant utiliser un
>> 2nd coeur qui est partagé avec d'autre domU, le noyau de la DomU
>> ordonnancera de la même manière entre les 2 coeurs, bien que sur un
>> des 2 coeurs il y ait risque de preemption par un autre DomU.
>>     
>
> Sans oublié que la Dom0, bin, elle n'a pas de coeur, elle prend tout les
> autres ;) Et bon, si on juge nécessaire de faire tourner des choses sur
> la dom0, pex, un seveur nfs, ou une target iscsi....
>   
L'allocation d'un coeur à la domU Asterisk ne règle qu'une partie du 
problème.
Il reste des éléments commun (les différents bus) qui génèrent des 
interruptions.

Dans la pratique, j'entends toutes les 5 minutes les applications de 
monitoring et
sans doute le filtrage antispam / antivirus de temps en temps.

En communication purement réseau, j'ai eu que très rarement des 
perturbations
dans la comm...

J'ai même essayé Asterisk directement dans la dom0, ça améliore encore 
un peu,
mais c'est tout.

Frédéric.