Discussion :

[agdid04]

Bonjour,

Je cherche à savoir s'il y a des risques en virtualisant les servers de prod (pr 2008) par rapport aux servers physiques ?

Que dit Microsoft sur le sujet ....?

Merci de vos lumières.

@+

[SQLpro]

1) MS ne garantit en aucune façon la virtualisation des serveurs SQL. En cas de problème MS peut vous demander de dévirtualiser avant d'intervenir
2) la sauvegarde d'une VM par snapshot ne permet pas la reprise de la base (elle à toutes les chances d'apparaître corrompue au redémarage) si le service VSS n'est pas activé
3) VSS "freeze" les bases de données le temps de faire le snapshot. De ce fait les transactions sont retardées; Sur un gros serveur ou un serveur fortement sollicité ceci prose des problèmes de disponibilité des données.
4) le remise en place d'une VM après snapshot est une opération relativement longue et risquée par rapport aux systèmes de haute disponibilité intégrés à SQL Server (mirroring, clustering, AlwaysOn...
5) le temps de latence avec une haute dispo par VM est énorme en comparaison avec une haute dispo faite par un des systèmes de haute disponibilité intégrés à SQL Server...
Par exemple le basculement sur un serveur de secours avec mirroring ou AlwaysOn (solutions intégrées à SQL Server) peut être instantané selon le paramétrage ce qui est impossible pour une VM...

Extrait de mon livre sur SQL Server à paraître dans 3 mois :
"
les couches supplémentaires apportées par la virtualisation (VMWare, Hyper V...) ne font qu’apporter du bruit, donc une perte naturelle de performances (au mieux 2% de pertes mais souvent beaucoup plus, de l’ordre de 8 à 15 % !)... Mais ce n’est pas tout :
• Microsoft n’offre aucune garantie que SQL Server fonctionne correctement dans un système virtualisé (y compris sur Hyper V) et recommande de reproduire les dysfonctionnements sur une machine physique en cas d’appel à la hot line ;
• un grand nombre de compteurs de performances n’offre plus de données fiables (toutes les métriques incorporant le temps, prennent en compte le temps réel ce qui inclut les temps de gestion de la VM, et les temps d’utilisation des autres machines, si plusieurs VM figurent sur la même machine...) ;
• le diagnostic des problèmes de performance devient très difficile à établir car il n’est pas facile de savoir sur quelle couche investiguer et comment ses différentes couches interagissent ;
• la sauvegarde des VM n’est pas fiable pour les bases SQL Server, du fait des opérations d’écriture asynchrones et non sérialisées, sauf à utiliser un outil supplémentaire (VSS par exemple) qui « gèle » les bases le temps de procéder à la copie des fichiers, ce qui rend indisponible la pleine utilisation des bases le temps de procéder au snapshot de la VM ;
• le coût de licence entre l’OS, la VM et SQL Server devient supérieur à celui d’une machine physique sans VM lorsque la solution porte sur des volumétries importantes (plus de 100 utilisateurs, plus de 300 Go de bases de données, plus de 8 CPU, plus de 64 Go de RAM...).


Un article sur le sujet :

http://blog.developpez.com/sqlpro/p8...virtualisation

Le pire étant une VM avec un stockage sur SAN non dédié... !

À lire en complément :
http://blog.developpez.com/sqlpro/p8...et_le_stocakge

A +

[agdid04]

1) MS ne garantit en aucune façon la virtualisation des serveurs SQL. En cas de problème MS peut vous demander de dévirtualiser avant d'intervenir
2) la sauvegarde d'une VM par snapshot ne permet pas la reprise de la base (elle à toutes les chances d'apparaître corrompue au redémarage) si le service VSS n'est pas activé
3) VSS "freeze" les bases de données le temps de faire le snapshot. De ce fait les transactions sont retardées; Sur un gros serveur ou un serveur fortement sollicité ceci prose des problèmes de disponibilité des données.
4) le remise en place d'une VM après snapshot est une opération relativement longue et risquée par rapport aux systèmes de haute disponibilité intégrés à SQL Server (mirroring, clustering, AlwaysOn...
5) le temps de latence avec une haute dispo par VM est énorme en comparaison avec une haute dispo faite par un des systèmes de haute disponibilité intégrés à SQL Server...
Par exemple le basculement sur un serveur de secours avec mirroring ou AlwaysOn (solutions intégrées à SQL Server) peut être instantané selon le paramétrage ce qui est impossible pour une VM...

Extrait de mon livre sur SQL Server à paraître dans 3 mois :
"
les couches supplémentaires apportées par la virtualisation (VMWare, Hyper V...) ne font qu’apporter du bruit, donc une perte naturelle de performances (au mieux 2% de pertes mais souvent beaucoup plus, de l’ordre de 8 à 15 % !)... Mais ce n’est pas tout :
• Microsoft n’offre aucune garantie que SQL Server fonctionne correctement dans un système virtualisé (y compris sur Hyper V) et recommande de reproduire les dysfonctionnements sur une machine physique en cas d’appel à la hot line ;
• un grand nombre de compteurs de performances n’offre plus de données fiables (toutes les métriques incorporant le temps, prennent en compte le temps réel ce qui inclut les temps de gestion de la VM, et les temps d’utilisation des autres machines, si plusieurs VM figurent sur la même machine...) ;
• le diagnostic des problèmes de performance devient très difficile à établir car il n’est pas facile de savoir sur quelle couche investiguer et comment ses différentes couches interagissent ;
• la sauvegarde des VM n’est pas fiable pour les bases SQL Server, du fait des opérations d’écriture asynchrones et non sérialisées, sauf à utiliser un outil supplémentaire (VSS par exemple) qui « gèle » les bases le temps de procéder à la copie des fichiers, ce qui rend indisponible la pleine utilisation des bases le temps de procéder au snapshot de la VM ;
• le coût de licence entre l’OS, la VM et SQL Server devient supérieur à celui d’une machine physique sans VM lorsque la solution porte sur des volumétries importantes (plus de 100 utilisateurs, plus de 300 Go de bases de données, plus de 8 CPU, plus de 64 Go de RAM...).


Un article sur le sujet :

http://blog.developpez.com/sqlpro/p8...virtualisation

Le pire étant une VM avec un stockage sur SAN non dédié... !

À lire en complément :
http://blog.developpez.com/sqlpro/p8...et_le_stocakge

A +

Merci bien de ces pécieuses infos.

@+