Un des gros challenges, a \u00e9t\u00e9 d\u2019offrir des solutions de stockage performantes<\/strong>, permettant de reprendre des pics d\u2019IOPS<\/strong>, tel que les Boot Storm<\/strong> et les Login Storm<\/strong>.<\/p>\n Pour cela, on a le choix entre, des solutions d\u2019acc\u00e9l\u00e9ration<\/strong> dans la baie, tel que le FAST Cache<\/strong> pour EMC<\/strong> et les Flash Pools<\/strong> de NetApp<\/strong>, chacun y allant de sa propre solution, qui est \u00e9videmment la meilleure\u2026 ou plus simplement des solutions AFA (<\/strong>All-Flash Array) <\/em><\/strong>tel que Violin, XtremIO, FashRay<\/strong> ou EF550<\/strong>, les prix ayant bien baiss\u00e9s. Les entreprises ont donc mis en place une infrastructure VDI<\/strong>, commenc\u00e9 \u00e0 d\u00e9ployer les z\u00e9ros clients<\/strong> et leurs pools de VDI<\/strong>, qu’elles ont mis \u00e0 disposition de leurs utilisateurs.<\/p>\n Au d\u00e9part, tout fonctionnait parfaitement<\/strong>, puis arrive, insidieusement, des ralentissements<\/strong> sur les postes, des black screens<\/strong>, voire des pertes de connexions<\/strong>.<\/p>\n Et tout naturellement, on se dit \u2018\u2019Ah, c\u2019est le stockage que l\u2019on m\u2019a fourni, qui ne tient pas\u00a0! Je l\u2019ai vu dans une pr\u00e9sentation<\/strong> ce que donne une baie, qui ne tient pas la route\u00a0!\u2019\u2019.<\/p>\n Branlebas de combat\u00a0!<\/strong> On appelle le partenaire et on lui dit que \u00e7a baie ne fonctionne plus\u2026<\/strong><\/p>\n La baie\u00a0? Et bien elle fonctionne correctement\u2026<\/strong> Regardez ces latences\u2026 nulles<\/strong>\u00a0! De temps en temps, un petit pic \u00e0 50 ms, lors d\u2019un recompose<\/strong>.<\/p>\n Alors on commence \u00e0 remonter dans les couches et notamment on analyse les ESXi<\/strong>, \u00e0 l\u2019aide d\u2019ESXTOP<\/strong>. Et c\u2019est l\u00e0 que l\u2019on tombe dessus\u00a0! Le CPU Ready<\/strong>.<\/p>\n Vulgairement le CPU ready<\/strong> est le temps, qu\u2019une VM attend<\/strong>, pour que le VMkernel<\/strong> lui alloue un cycle CPU<\/strong>. C\u2019est une latence CPU<\/strong>. Et \u00e9videmment comme toute latence, elle devrait \u00eatre nulle.<\/p>\n Une des probl\u00e9matiques est d\u2019interpr\u00e9ter les charts<\/strong> du vCenter<\/strong>, c\u2019est pour cela que l\u2019ESXTOP<\/strong> est plus simple d\u2019utilisation.<\/p>\n Voici une KB<\/strong>, qui va vous aider \u00e0 convertir les informations du vCenter<\/strong>.<\/p>\n http:\/\/kb.vmware.com\/selfservice\/microsites\/search.do?language=en_US&cmd=displayKC&externalId=2002181<\/a><\/p>\n Trop souvent, on ne calcule<\/strong> pas correctement le nombre de VM par core<\/strong>.<\/p>\n Dans la litt\u00e9rature, il est dit que l\u2019on peut mettre jusqu\u2019\u00e0 10 VMs par core<\/strong>, ce qui est d\u00e9finitivement trop\u00a0!<\/strong><\/p>\n Id\u00e9alement, 5 VMs par core<\/strong> est un bon calcule<\/strong>, mais ce n\u2019est pas toujours possible de le respecter, question co\u00fbt et nombre de serveurs ESXi<\/strong>.<\/p>\n 7 VMs par core<\/strong>, c\u2019est le consensus<\/strong>, mais attention vous jouez d\u00e9j\u00e0 avec le feu, sur toutes les infrastructures audit\u00e9es, on a d\u00e9j\u00e0 un peu de CPU Ready, mais cela ne se ressent pas trop dans le poste VDI.<\/p>\n Maintenant passons aux calculs.<\/p>\n Premi\u00e8rement, le poste VDI\u00a0? Un ou deux vCPU\u00a0?<\/strong><\/p>\n Je vous r\u00e9ponds deux, sans h\u00e9siter<\/strong>, quand on voit le bruit de fond, que g\u00e9n\u00e8rent les postes, li\u00e9s aux agents install\u00e9s (Nexthink, AppSense, Norskale, anti-virus, App-v, SCCM<\/strong>)<\/p>\n Il est utopique d\u2019esp\u00e9rer tenir avec 1 vCPU.<\/strong><\/p>\n Un de mes clients (il se reconnaitra\u00a0;-P) a bien tenu, avec 1 vCPU<\/strong>, mais \u00e0 la fin, il a d\u00fb se r\u00e9signer \u00e0 passer \u00e0 deux<\/strong>, ce qui a am\u00e9lior\u00e9 les performances<\/strong> \u00e0 l\u2019utilisation, notamment Office 2013<\/strong>, qui est extr\u00eamement gourmand<\/strong>.<\/p>\n Pour le calcul de la m\u00e9moire<\/strong>, c\u2019est simple\u00a0:<\/p>\n 4 GB pour l’hyperviseur<\/strong> (depuis la version ESXi 5.5<\/strong>)<\/p>\n 10 GB pour les \u00e9ventuels services<\/strong> tel que les solutions vShield Endpoint<\/strong>.<\/p>\n Cela donne 14 GB de base<\/strong> et pour les postes VDI, environ 3 GB par VM<\/strong>, \u00e9videmment n\u2019oubliez pas la r\u00e9servation, pour le HA<\/strong>, afin de garantir la perte d’un Host, en cas de probl\u00e8me ou plus simplement, lors du patching des ESXi.<\/p>\n Pour le nombre de VM par core,<\/strong> voici la formule<\/strong>:<\/p>\n ((VM par core) x (nbr de core x nbr de socket))\/Nbr vCPU VM<\/strong><\/p>\n Cela donne\u00a0:<\/p>\n Pour un Dual socket 8 cores<\/strong><\/p>\n 16 cores * 5 vms \/core => 40 VMs \u00e0 2 vCPU<\/strong><\/p>\n 16 cores * 7 vms \/core => 56 VMs \u00e0 2 vCPU<\/strong><\/p>\n 16 cores * 10 vms \/core => 80 VMs \u00e0 2 vCPU<\/strong><\/p>\n Pour un Dual socket 14 cores<\/strong><\/p>\n 28 cores * 5 vms \/core => 70 VMs \u00e0 2 vCPU<\/strong><\/p>\n 28 cores * 7 vms \/core => 98 VMs \u00e0 2 vCPU<\/strong><\/p>\n 28 cores * 10 vms \/core => 140 VMs \u00e0 2 vCPU<\/strong><\/p>\n Et si l\u2019on prend le plus gros CPU du moment<\/strong> le E5-2699 v3 (18 cores)<\/strong><\/p>\n http:\/\/ark.intel.com\/products\/family\/78583\/Intel-Xeon-Processor-E5-v3-Family#@Server<\/a><\/p>\n 36 cores * 5 vms \/core => 90 \u00e0 2 vCPU<\/strong><\/p>\n 36 cores * 7 vms \/core => 126 \u00e0 2 vCPU<\/strong><\/p>\n 36 cores * 10 vms \/core => 180 \u00e0 2 vCPU<\/strong><\/p>\n Jolie consolidation\u2026 mais le prix du socket est proche de 15\u2019000CHF (12’500 \u20ac)<\/strong> trop cher\u2026<\/p>\n Mais il ne faut pas seulement<\/strong> prendre en consid\u00e9ration le nombre de core<\/strong>, mais \u00e9galement la fr\u00e9quence<\/strong>, qui a son importance ainsi que le cache du processeur<\/strong>.<\/p>\n Il vaut mieux avoir un 14 core \u00e0 2.8 Ghz<\/strong>, plut\u00f4t qu’un 18 core \u00e0 2 Ghz<\/strong>, en r\u00e9sum\u00e9.<\/p>\n Aller\u00a0! Tous \u00e0 vos calculettes et n\u2019ayez pas peur du consensus\u00a0!<\/strong><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Bonjour, Ce n\u2019est plus un secret, aujourd\u2019hui, les solutions de virtualisation de desktop, les infrastructures et leurs technologies li\u00e9es, sont matures. Un des gros challenges, a \u00e9t\u00e9 d\u2019offrir des solutions de stockage performantes, permettant de reprendre des pics d\u2019IOPS, tel que les Boot Storm et les Login Storm. Pour cela, on a le choix entre, des solutions d\u2019acc\u00e9l\u00e9ration dans la Continue reading CPU Ready l\u2019autre ennemi du VDI<\/span>
\n<\/span><\/p>\n![\"CPU_Schedule_ESXi\"](\"https:\/\/i0.wp.com\/www.virtualementvotre.ch\/blog\/wp-content\/uploads\/2014\/10\/CPU_Schedule_ESXi.png\")
<\/a><\/p>\n<\/a><\/p>\n