L'une des questions qui est le plus souvent posée est la suivante : peut-on réellement virtualiser des serveurs comme Microsoft SQL, sans perte de performance radicale? La réponse est OUI!
Parfois, certains administrateurs de bases de données (DBA) puristes montent aux barricades : « Microsoft SQL/MySQL/Oracle DB ne peuvent pas être efficacement virtualisés! ». Faux, rien de plus faux. Tout est une question d’adaptation et de suivre les meilleures pratiques.
La principale crainte des administrateurs de bases de données (DBA – Database Administrator) vient du fait qu’ils ne sont pas habitués à partager leurs ressources avec d’autres systèmes. Pas question de couper la tarte et d’en donner des parts à d’autres, toutes ces belles pointes de processeurs, de mémoires et de stockage! Et bien, il ne faut pas s’inquiéter, on peut prioriser l’attribution des ressources, et vous faire passer en avant de la file.
Les ressources maximales des machines virtuelles ont déjà été un obstacle de taille. Il n’y a pas si longtemps, on ne pouvait pas attribuer à une machine virtuelle une grande quantité de processeurs ou de mémoire virtuelle. Les dernières versions des différents « hypervisors* » sur le marché nous permettent une très grande flexibilité au niveau de l’assignation des ressources. Par exemple, vSphere 5.1 versus vSphere 4.1 permet d’attribuer 4 fois plus de mémoire et jusqu’à 8 fois plus de processeurs virtuels à la même machine virtuelle.
Une autre raison qui a longtemps empêché les administrateurs de systèmes de virtualiser des serveurs de base de données n’a aucun rapport avec la virtualisation en soit : les mauvaises pratiques. En effet, Microsoft publie dans son cursus officiel de certification les meilleurs pratiques à respecter pour son moteur de base de données, Microsoft SQL Serveur. Idem pour Oracle ou MySQL.
Le non-respect de ces bonnes pratiques est parfois plus visible dans un environnement virtuel. Par exemple, un serveur Microsoft SQL, avec une soixantaine de bases de données sur la même partition, toutes configurées en mode « auto-grow* » va causer une fragmentation qui va ralentir n’importe quel serveur. Comme la fragmentation du système de fichier est plus apparente dans un environnement virtualisé, le ralentissement semble pire. Mais en réalité, un serveur dédié nous permet de tricher sur ce genre d’indicateur de performance, ce qui n’est plus possible dans un serveur virtuel.
Au bout du compte, consultez les meilleures pratiques du fabriquant de moteur de base de données avant de blâmer la couche de virtualisation! Vous allez atteindre le nirvana de la haute disponibilité, et enfin entrer dans le fan-club de la virtualisation!
Si vous voulez des cas précis de mauvaises pratiques ou de plus grande capacité, voici quelques chiffres :
Mauvaises pratiques : un cas concret
Un cas d’une entreprise, utilisant Microsoft SQL Serveur, qui a vécu un ralentissement horrible en virtualisant. Le pauvre serveur SQL contenait plus d’une centaine de bases de données. Chaque base de données était configurée en mode « Auto-grow* » d’un MB d’incrément. Donc, à chaque fois qu’une des bases de données devait grossir, elle réclamait une tranche d’1 MB au système d’exploitation. Si 100 BD font ça à chaque fois qu’elles grossissent… On se retrouve avec un système de fichiers plus fragmenté qu’un météorite qui entre dans l’atmosphère!
Lexique
Confiez la satisfaction de vos besoins technologiques aux experts de Vertisoft.
Contactez-nous sans plus tarder !
Hébergement de données sécurisé
Solutions de Téléphonie IP
