Questionnement sur virtualisation d'une nouvelle infra Win Server 2016

Bonjour,

Je suis sur un projet de renouvellement de serveur pour une petite PME. Le serveur actuel en Win Server 2003 joue les rôles de serveur d'infra (AD), serveur de fichiers et SQL Server (2000... pour un ERP). Ces rôles sont implantés sur la même machine physique.

Pour ses avantages relatifs à la sauvegarde, test et pour un projet de mise en oeuvre d'un serveur de PRA, le nouveau serveur ous Win Server 2016 SE sera virtualisé avec Hyper-V (core ou full ?). Par contre s'il n'y a pas de discussion sur l'utilité de virtualiser SQL Server, je suis incertain sur l'approche à suivre concernant les rôles d'infra et de fichiers. Car dans cette PME, ces rôles sont très très peu sollicités : une trentaine d'objets pour l'AD, 1 ou 2 GPO, le DNS bien sûr mais pas de serveur d'impression, pas de DHCP. Au pire seuls les rôles RADIUS et WSUS pourraient être désormais utilisés. Quant au service de fichiers, il n'est sollicité faiblement que par 2-3 personnes.

Afin de simplifier l'exploitation, optimiser l'empreinte CPU/RAM/disque de ces rôles et diminuer les coûts, je me demandais ce qui serait le mieux :
1. Installation de ces rôles sur l'OS hôte (si full), avec sauvegarde soit via Backup server, soit Veeam. Ce qui me laisse 2 VM pour SQL Server et une VM de test
2. Installation de ces rôles sur la même VM que SQL Server. Ce qui me laisse une VM de test. Mais il paraîtrait que Microsoft décline le support si VM mutualisant AD et SQL Server ?
3. Installation de ces rôles sur une VM dédié. Plus la VM de SQL Server, ce qui m'oblige à reprendre une licence pour avoir 2 VM de plus (pour la VM de test).

Je suis bien conscient que les "meilleures" pratiques poussent vers la solution 3 mais entre un grand compte et une petite PME, je vois comme une grande différence. Or mes observations sur le vieux serveur indiquent que SQL Server consommera 99% de la CPU et 100% des accès disques, en dehors des traitements HNO.

J'aurais aimé connaître vos idées, conseils et recommandations sur ce choix ? Merci

Le cout des licences système des OS est assez faible et la solution 3 idéale. N'oubliez pas qu'en mati_ère de VM vous licenciez tous les processeurs existants; donc cela ne change pas le cout qui est directement lié à la machine !

A 9

Bonjour Frédéric et merci pour ta réponse.

Pour le coût pas tout à fait. La licence de base Win Server 2016 (celle avec les CAL) est facturé avec aux procs et aussi aux coeurs désormais. De base tu payes pour 2 procs et 16 coeurs. Si tu a un mono-proc de 6 coeurs, tu payes la même chose qu'un bi-proc de 2x8 coeurs. C'est d'ailleurs très bête puisque que SQL Server 2016 en licence proc facture de base en version processeur 2 procs de 2x4 coeurs..... Et si tu ne fais pas attention, les 8 coeurs supplémentaires à payer coûtent fort cher !
Ensuite de base pour un Win Server 2016, tu as droit à 2 VM. Au-delà c'est facturé par paire de VM supplémentaires pour le prix d'une licence complète. Pour une standard édition, c'est dans les 600-700€. Certes ce n'est pas la ruine mais quand tu as une dizaine de petits points comme cela, ça commence à faire un budget non négligeable pour une petite structure.

Je viens justement de lire attentivement le chapitre 13. Maintien des performances de ton livre, notamment la partie sur les VM. C'est fort intéressant. Par contre je suis resté un peu sur ma main avec le passage concernant les CPU et le parallélisme. Cela ne m'a pas vraiment aidé quant aux choix d'un seul proc ou d'un biproc pour ce nouveau serveur (ça fait partie des petits points à 500-600€....).
Compte tenu du faible nombre d'accès concurrents sur notre serveur actuel, "on" m'a plutôt conseillé un mono-proc de plus hautes fréquences qu'un bi-proc tournant moins vite. Mais bon, en restant dans des budgets raisonnables, les différences de fréquences sont relativement faibles (10-15%) donc j'imagine que le différence de perfs ne doit pas être significative...
Il y a quelques autres services qui tourneront sur le serveur, donc je pense que plus de coeurs permettra de mieux distribuer la charge. Donc je pense partir sur un bi-proc.

C'est une question de noeud NUMA.
Si la VM peut "tenir" sur un noeud NUMA et donc ne pas accéder à de la mémoire foreign plus lente (car il faut passer par un bus), alors il ne faut pas hésiter.
Si par contre on affect 2 sockets / x cores à la VM, il est crucial de bien caler l'architecture vNUMA sur la pNUMA. Un simple click pour Hyper-V, un petit tour dans le fichier vmx pour VMware si on est < à 8 cores.

Il faut juste bien partir du principe que le nombre de cores est une question de capacité et non de performance. Avoir 512 cores ne diminuera pas le worker time d'une requête non parallélisée. Cela permet juste d'encaisser plus de charge.
Lorsque l'on a besoin de bcp de mémoire (plusieurs TB), alors il est clairement plus avantageux de disposer de plusieurs sockets. Qui en prime offriront plus de lignes PCI (les IOs).

Donc pour répondre à votre question, il est clair qu'il vaut mieux 1 proc E5-2643 v4 que 2 procs E5-4640 v4.
Un de mes favoris est le E5-2687W v4 en 12 cores. Ce qui sur une carte mère 2 sockets fournis 24 cores physiques, de quoi abattre bien du boulot (entendre par là fait j'ai tout interet à booster mes IO disque).

cdlt
Christophe

Bonjour Christophe et merci pour ta réponse.
Malheureusement ... elle arrive un peu tard car la machine a déjà été acquise.
Autant dire qu'en phase avant vente, quand il s'est agit du choix du proc, la problématique NUMA ,a guère été abordée ... C'est un point que j'ai découvert pas plus tard que la semaine dernière en installant les VM et en découvrant Hyper-V.
Le commercial a réussi à me refourguer 2 sockets E5-2630v4 ... dont le prix global correspond grosso modo à un E5-2650v4 ... en plus j'aurais pu prendre ce 2650 sans supplément de licence puisque Windows Server et SQL Server sont licenciés par CAL et non au proc. Mais bon, je pense qu'un seul E5-2630 aurait suffit pour nos besoins SQL Server et l'autre CPU servira pour les autres VM.
Dans un premier temps je vais affecter un noeud NUMA (un socket complet avec ses 8 coeurs + 16Go) à la VM portant SQL server, et l'autre noeud se répartira entre Hyper-V et les autres VM.
Le seul point qui me chatouillait, c'est qu'avec 32Go au total, je n'affectait que 16Go à SQL Server (en local memory). Mais après les premiers tests, SQL Server ne monte qu'à 6Go, j'aurais donc encore de la marge. Au pire je rachèterai un peu de RAM que j'affecterai aux autres VM (elles consomment 6Go max...) et je rapatrierai l'ensemble des 32Go sur le CPU utilisé par la VM SQL Server.

Je repréciserai mieux ce que je mettrai en place une fois que cela sera fait.
En tout cas, tout ce que je peux dire d'après les premiers tests, sans aucune optimisation aucune, sur une requête "lourde" d'analyse, le nouveau serveur met 3s pour répondre là où l'ancien mettait 1:05. Un gain de 2000%, c'est toujours bon à prendre !!!


D'ailleurs puisque l'on parle de NUMA, je poserai bien une question sur ce sujet qui me semble à la fois clair ... et un peu obscur sous Hyper-V.

Ce que j'ai à peu près compris en théorie :
> Petit rappel de terminologie : socket (ou CPU) = processeur physique / core = coeurs physique / processeur logique (alias Logical P ou thread) = hyperthreading (2 par coeur)
> Et au niveau VM : vsocket = CPU virtuel / virtual processor (ou vcore) = thread vu par la VM
> Cette gestion NUMA peut être utilisée pour une architecture mono-socket ou multi-sockets
> Cette gestion se base sur la notion de noeud NUMA. Au plus simple, si l'on a 2 sockets avec 8 coeurs chacun (soit 16 au total) et 32Go au total, on peut définir deux noeuds NUMA correspondant chacun à un socket avec ses 8 coeurs et 16 Go de RAM.
> Ce qu'il faut comprendre, c'est que la latence la plus faible est obtenue quand ces coeurs travaillent avec les 16Go de leur noeud NUMA (la local memory qui leur est directement attachée, par opposition avec la foreign memory qui dépend qu'un autre noeud, donc d'un autre socket).
> La gestion est flexible : on peut avoir une correspondance stricte entre un noeud NUMA physique (1CPU/8c/16Go) et un noeud NUMA virtuel (ou vNUMA) d'une VM (8 processors à 16Go). Mais on peut aussi avoir des vNUMA plus petits ou plus grands que le NUMA physique.
> on peut donc paramétrer l'hyperviseur pour qu'une VM n'utilise qu'une fraction d'un noeud NUMA (ex: pour 1UC/8c/16Go --> VM1:2c/4Go, VM2:4c/8Go, VM3:2c/4Go)
> Mais on peut configurer une VM afin qu'elle utilise les ressources de plusieurs noeuds NUMA physique (ex: pour 2xUC/2x8c/2x16Go --> VM1:10c/16+4Go (spanning), VM2:6c/12Go (sans spanning)). Dans ce dernier cas de VM1, on parle de débordement NUMA (ou spanning). Par contre cela veut dire que la VM va être amenée à utiliser de la mémoire étrangère, ce qui moins performant en terme de latence. Ce n'est donc pas optimal mais la VM tournera quand même très bien.
> L'optimum pour les perfs étant d'avoir des vNUMA égales ou plus petites aux NUMA physiques, sans chevauchement donc.

Et en pratique, sur Hyper-V :
> Il faut choisir entre mémoire dynamique ou gestion NUMA : si l'on active la première, cela désactive la seconde.
> La config NUMA d'une VM n'est pas gravé dans le marbre : elle peut être modifiée mais cela se fait VM arrêtée
> Il n'y a pas de vérification dans la config NUMA : on peut mettre n'importe quoi. Exemple : 40 virtual processors alors que l'on en a que 32. Hyper-V prend la config .... mais la VM plantera au démarrage ! De même on peut mettre n'importe quoi en RAM, Hyper-V n'allouera au maximum que ce qui est allouable.
> De même, il n'y pas de lien dynamique entre la config hardware et la config VM. Si on change/ajoute une CPU ou que l'on modifie la RAM, cela n'est pas pris en compte. Il faut faire soit même la modif que l'on souhaite dans la config des VM.


Il y a plusieurs choses que je ne pige pas trop :

1. Dans Hyper-V, il y a 4 principaux paramètre mémoire/processor à saisir.
> Pour les paramètres processors OK : le nombre de processors et le nombre max de processor par noeud NUMA. Là-dessus pas de souci.
> Là où c'est moins clair, c'est avec les 2 paramètres mémoire (mémoire dynamique désactivé). Dans l'onglet mémoire, la quantité de mémoire globale correspond à la RAM dont disposera réellement la VM. Par contre dans la config NUMA, je ne pige pas trop à quoi sert de spécifier la quantité max de mémoire par noeud NUMA, à part faire varier le nombre de noeuds NUMA si on baisse la quantité de mémoire ??? On peut mettre n'importe quoi, par exemple 60Go alors qu'il n'y a que 32Go, cela n'a pas d'impact.

2. Au départ on m'a indiqué que virtual processor = cores physiques. mais sur ma bécane j'ai configuré une VM avec 16 logical proccessors/un vsocket et un vNUMA et ai fait un stress test. Alors que je m'attendais à trouver 100% d'un NUMA utilisé, je constate que seulement la moitié d'une seule CPU est utilisée sur le moniteur de ressource de la machine hôte (le noeud NUMA 1 est à 50% mais le noeud NUMA 2 est à 0%). Alors ?
Alors si j'en crois et article, il faut plutôt raisonner par virtual processors = logical processors (= nb de cores physique sans hyperthreading ou 2x nb de cores physique sans hyperthreading).
https://www.petri.com/about-hyper-v-...or-limitations
Dans les faits c'est simple mais on s'embrouille un peu avec les terminologies !

3. Si je comprends bien l'article suivant, du point de vue des perfs il peut être intéressant de bidouiller les vNUMA d'une VM pour artificiellement augmenter le nombre de socket vituels, afin de mieux coller aux NUMA physiques ???
http://www.sqlservercentral.com/arti...zation/125226/



Merci d'avance pour votre éclairage, même si cette question est un peu éloignée un peu de SQL Serve

Si je puis me permettre... Ce sujet va être abordé (avec d'autres sujet sur le hardware) par Christophe Laporte mardi prochain lors du master class Orsys qui se déroule de lundi à vendredi en compagnie de Christophe déjà cité, mais aussi Rudi Bruchez (alias Rudib sur developpez), Dominique Verrière, Arian Papillon et moi même.
A voir : https://www.youtube.com/watch?v=Ryw-qussElw
Le contenu de ce master class : http://www.orsys.fr/?formation=stage_0_MCQ
Il reste de la place au cas ou ces sujets vous intéressent !
Comme c'est de la formation professionnelle, cela peut être pris en charge par votre entreprise par l'intermédiaire de votre OPCA.

A +