Désolé de déterrer ce topic (un petit moment que je ne suis pas passé sur le forum)
Citation:
- T'as un serveur physique sous-dimensionné ? Qu'est-ce qui t'empêche de joindre à ton cluster de nouveaux serveurs plus puissants, et shooter les anciens serveurs une fois la réplication effectuée ?
- T'as des serveurs physiques sur-dimensionnés ? Qu'est-ce qui t'empêche de faire la démarche inverse, ou simplement mutualiser le serveur en lui ajoutant d'autres bases de données ?
Rien du tout effectivement mais je pense que la virtualisation te sera plus profitable si l'on regarde le CAPEX / OPEX. Mais encore une fois il ne faut pas se réduire à une vision base de données mais à l'ensemble des serveur du systèmes d'information (serveurs de mail, serveurs applicatifs, contrôleurs de domaine etc ...)
Prenons l'exemple d'un serveur sous-dimensionné. Que fait-on dans le cas où je n'ai pas d'autres serveurs ou bases à consolider à un instant T ? J'achète un serveur moins puissant et j'utilise le plus puissant pour mutualiser d'autres choses? On perd du point de vue CAPEX (achat des serveurs) et OPEX (coût de la maintenance du serveur, coût des employées à installer, déployer ou migrer ton serveur de bases de données etc ...) Que fait-on maintenant si mon serveur SQL que j'ai mutualisé avec d'autres instances SQL Server ne suffit plus? J'achète de nouveau un serveur et je dispatche mes bases données sur ceux-ci? Même chose ici pour le CAPEX et OPEX.
Avec la virtualisation j'ai une certaine souplesse d'architecture que je peux partager avec l'ensemble de mes serveurs, diminuer mes ressources quand je sais que mon serveur n'en aura pas besoin ou les augmenter provisoirement pendant une grosse période d'activité ciblée ...
Pensez bien que je ne suis pas en train de convaincre de virtualiser à tout prix .. simplement prendre en compte la virtualisation dans certains où celle-ci permet de répondre à un besoin client
Citation:
Dans tous les cas, si c'est SQL Server qui s'occupe de gérer les accès disques/CPU/mémoire directement, ce sera forcément plus performant que si c'est la couche VM, puisque dans ses algos, non seulement il sait qu'il doit écrire telle information à tel endroit, mais aussi lire telle autre information à côté, et donc ordonnancer les IO de façon à ce qu'elles soient les plus performantes possibles (réduire l'amplitude des mouvements des têtes).
Je prends l'exemple de VMware qui est tout à fait capable de gérer les CPU de manière efficiente avec SQL Server. Par exemple lors que le nombre de VCPU est inférieur au nombre de processeurs sur un nœud NUMA alors les threads allouées à SQL Server seront automatiquement localisés sur un seul nœud NUMA avec un accès direct à sa mémoire locale. Si le nombre de VCPU devient supérieure, il est possible d'activer pour la VM l'accès à l'architecture physique et laisser SQL Server de gérer ses propres ressources en fonction de la nouvelle configuration.
Dire que SQL Server puisse écrire et optimiser les écritures sur disque avec gestion des têtes de lectures relève presque du mythe maintenant. En effet depuis l'apparition des contrôleurs RAID et des stockages d'entreprises où l'écriture des données sont en généralement directement acquittées depuis les caches SQL Server n'est plus au courant de l'architecture disque sous jacente. Par ailleurs les différentes contrôleurs et cache des stockages possèdent leurs propre algorithmes de répartition des blocs de données sur disque. Ils sont capables par exemple de rassembler plusieurs blocs et d'optimiser les débits d'écritures en faisant du séquentiel (vs aléatoire)
Citation:
Alors après, on va dire "ouais, mais la VM, elle a un cache IO et va tout arranger".
Ceci relève également du mythe car VMware (et sûrement Hyper-V .. à vérifier) ne cachent pas les IO avec des hôtes Windows. Le fait de buffériser impliquerait la question suivante : que se passe-t-il en cas de crash ? Est-ce que je reste intègre? VMware répond à la question avec le KB 1008542
On Windows hosts, VMware hosted products use unbuffered IO by default.
et ici
VMware ESX acknowledges a write or read to a guest operating system only after that write or read is acknowledged by the hardware controller to ESX. Applications running inside virtual machines on ESX are afforded the same crash consistency guarantees as applications running on physical machines or physical disk controllers.
Citation:
Sinon, pur le coup des licences, c'est pas parce que le serveur à 32 cœurs que je suis obligé d'avoir 32 licences... Si je n'en ai besoin que de 4, j'achète 4 licences, et je n'active que 4 cœurs dans la config de SQL Server... La VM n'apporte pas un kopeck à ce niveau.
SQLPro a déjà bien répondu à la question donc on revient au point 1 qui fait que la virtualisation peut être plus intéressante du point de vue CAPEX ici.
++