Bonjour,
Ce n’est plus un secret, aujourd’hui, les solutions de virtualisation de desktop, les infrastructures et leurs technologies liées, sont matures.
Un des gros challenges, a été d’offrir des solutions de stockage performantes, permettant de reprendre des pics d’IOPS, tel que les Boot Storm et les Login Storm.
Pour cela, on a le choix entre, des solutions d’accélération dans la baie, tel que le FAST Cache pour EMC et les Flash Pools de NetApp, chacun y allant de sa propre solution, qui est évidemment la meilleure… ou plus simplement des solutions AFA (All-Flash Array) tel que Violin, XtremIO, FashRay ou EF550, les prix ayant bien baissés.
Les entreprises ont donc mis en place une infrastructure VDI, commencé à déployer les zéros clients et leurs pools de VDI, qu’elles ont mis à disposition de leurs utilisateurs.
Au départ, tout fonctionnait parfaitement, puis arrive, insidieusement, des ralentissements sur les postes, des black screens, voire des pertes de connexions.
Et tout naturellement, on se dit ‘’Ah, c’est le stockage que l’on m’a fourni, qui ne tient pas ! Je l’ai vu dans une présentation ce que donne une baie, qui ne tient pas la route !’’.
Branlebas de combat ! On appelle le partenaire et on lui dit que ça baie ne fonctionne plus…
La baie ? Et bien elle fonctionne correctement… Regardez ces latences… nulles ! De temps en temps, un petit pic à 50 ms, lors d’un recompose.
Alors on commence à remonter dans les couches et notamment on analyse les ESXi, à l’aide d’ESXTOP. Et c’est là que l’on tombe dessus ! Le CPU Ready.
Vulgairement le CPU ready est le temps, qu’une VM attend, pour que le VMkernel lui alloue un cycle CPU. C’est une latence CPU. Et évidemment comme toute latence, elle devrait être nulle.
Une des problématiques est d’interpréter les charts du vCenter, c’est pour cela que l’ESXTOP est plus simple d’utilisation.
Voici une KB, qui va vous aider à convertir les informations du vCenter.
Trop souvent, on ne calcule pas correctement le nombre de VM par core.
Dans la littérature, il est dit que l’on peut mettre jusqu’à 10 VMs par core, ce qui est définitivement trop !
Idéalement, 5 VMs par core est un bon calcule, mais ce n’est pas toujours possible de le respecter, question coût et nombre de serveurs ESXi.
7 VMs par core, c’est le consensus, mais attention vous jouez déjà avec le feu, sur toutes les infrastructures auditées, on a déjà un peu de CPU Ready, mais cela ne se ressent pas trop dans le poste VDI.
Maintenant passons aux calculs.
Premièrement, le poste VDI ? Un ou deux vCPU ?
Je vous réponds deux, sans hésiter, quand on voit le bruit de fond, que génèrent les postes, liés aux agents installés (Nexthink, AppSense, Norskale, anti-virus, App-v, SCCM)
Il est utopique d’espérer tenir avec 1 vCPU.
Un de mes clients (il se reconnaitra ;-P) a bien tenu, avec 1 vCPU, mais à la fin, il a dû se résigner à passer à deux, ce qui a amélioré les performances à l’utilisation, notamment Office 2013, qui est extrêmement gourmand.
Pour le calcul de la mémoire, c’est simple :
4 GB pour l’hyperviseur (depuis la version ESXi 5.5)
10 GB pour les éventuels services tel que les solutions vShield Endpoint.
Cela donne 14 GB de base et pour les postes VDI, environ 3 GB par VM, évidemment n’oubliez pas la réservation, pour le HA, afin de garantir la perte d’un Host, en cas de problème ou plus simplement, lors du patching des ESXi.
Pour le nombre de VM par core, voici la formule:
((VM par core) x (nbr de core x nbr de socket))/Nbr vCPU VM
Cela donne :
Pour un Dual socket 8 cores
16 cores * 5 vms /core => 40 VMs à 2 vCPU
16 cores * 7 vms /core => 56 VMs à 2 vCPU
16 cores * 10 vms /core => 80 VMs à 2 vCPU
Pour un Dual socket 14 cores
28 cores * 5 vms /core => 70 VMs à 2 vCPU
28 cores * 7 vms /core => 98 VMs à 2 vCPU
28 cores * 10 vms /core => 140 VMs à 2 vCPU
Et si l’on prend le plus gros CPU du moment le E5-2699 v3 (18 cores)
http://ark.intel.com/products/family/78583/Intel-Xeon-Processor-E5-v3-Family#@Server
36 cores * 5 vms /core => 90 à 2 vCPU
36 cores * 7 vms /core => 126 à 2 vCPU
36 cores * 10 vms /core => 180 à 2 vCPU
Jolie consolidation… mais le prix du socket est proche de 15’000CHF (12’500 €) trop cher…
Mais il ne faut pas seulement prendre en considération le nombre de core, mais également la fréquence, qui a son importance ainsi que le cache du processeur.
Il vaut mieux avoir un 14 core à 2.8 Ghz, plutôt qu’un 18 core à 2 Ghz, en résumé.
Aller ! Tous à vos calculettes et n’ayez pas peur du consensus !
Salut et merci pour cet article ….. On parle de quel type de desktop virtuel ? Workstation ou serveur type rds / xenapp ?
Cela me semble optimiste 40 vm’s type 2008R2 bi-cpu sur un esxi…. A vrai dire on a jamais testé et on reste dans le ratio nombre de coeur sur l’esxi = nombre de coeur alloué aux vm’s environ. Avec un delta d’une ou deux.
Sur quelle base tu t’appuies pour réaliser ton calcul ?
Si c’est l’expérience cela va très bien 😉
Hello,
Je parle de solutions telles qu’Horizon View ou Xen Desktop.
Donc des brocker, permettant de rediriger les flux PCoIP ou ICA directement sur le poste.
Mon background vient plus précisément d’environnements VMware, avec les postes virtuels sous Windows 7 et Windows 8.1.
Pour la consolidation de VM par Core, il a la littérature, mais surtout, là, je parle d’expériences faites chez des clients.
Ces infrastructures varient entre 50 postes VDI, jusqu’à 1800 postes VDI.
Ok merci pour la précision 😉 on parle bien de Workstation et non pas de serveur mutualisé ….. On va garder ça en tête pour l’environnement serveur :
http://cdn.ws.citrix.com/wp-content/uploads/2013/01/New_table.jpg
http://blogs.citrix.com/2013/01/07/whats-the-optimal-xenapp-6-5-vm-configuration
Même si l’article commence à daté et que les technos PROC évoluent trés vite…. Mais bon les OS et les PROGS eux aussi évoluent en terme de gourmandise CPU 😉
En tout cas merci beauoup pour ton retour d’expérience ………