Bonjour à tous!
Je suis confronté dans mon entreprise à une problématique concernant la virtualisation de SQL Serveur (fin de leasing du matériel physique, problématique d’hébergement etc.)
N'étant pas un spécialiste SQL serveur, je m'interroge sur :
- l'impact de la virtualisation d'un SQL serveur (d'une dizaine de base dont 2 de 4To). Avez-vous eux des cas gênants n'étant pas spécialement répertoriés sur le web etc.
- le moyen de virtualiser une machine SQL de 10To avec le moins de coupure possible, sachant que c'est une machine pouvant difficilement être arrêtée plus d'une journée... (VMware converter prendrait au moins 3 jours à la virtualiser...), faut-il selon vous la convertir ou bien réinstaller un serveur SQL? Sachant que nos restauration de base via EMC Avamar prennent vraiment beaucoup de temps... une restauration SQL directement? Je ne m'y connais pas vraiment, avez-vous une idée à me proposer?  
 
Merci d'avance  

Si ton idée est de faire du PtoV d'un serveur SQL critique tu peux déjà oublier cette idée.
 
Déploie un serveur virtuelle standard, fais une installation SQL propre et après migre tes bases dessus.

Faut faire gaffe au licensing.
Après il vaut mieux souvent faire du multi instance que des vm sql hébergés sur le même hote. Le seul cas où on fera des VM c'est si les softs qui ont besoin du sql server ont besoin d'installer des binaires particulier sur le serveur sql et où on préfèrera donc les isoler plus fortement.

Merci de vos réponses    
 

 
A ok, ça à le mérite d'être plutôt clair.
 

Et quels sont les procédés conseillés pour la migration des bases? Notamment pour des grosses bases.
Ça nécessite une coupure où il existe des procédés de bascule avec copie des delta?
 

En effet, j'avais oublié que ça apportait une problématique supplémentaire

Pour ca il y a des milliers d'exemples sur le net
Ex: http://blogs.developpeur.org/fabri [...] autre.aspx
 
Je ne suis pas DBA mais une bascule à chaud me parait tendu ne serait ce que sur l'impact que ca va avoir sur les performances du serv et des IOs...

si ta la bonne version de sql server et que le soft supporte, tu fous ta base en mirroring sur l'autre serveur, met à jour les connection strings pour mettre les 2 serveurs, attend que ça soit bien répliqué, tu switchs, tu coupe le mirroring, tu rechanges les connection string pour mettre que le nouveau serveur et zou c'est fini, le tout à chaud ou presque .
 
Sinon backup/restore puis tu stoppes, backup/restore le delta, change les connections string et tu repars. Bon ça t'oblige à un peu recréer manuellement certaines infos mais bon (les lusers and co).

Va falloir quand même que je trouve une solution à chaud malheureusement...
 
J'ai lu quelque chose d'intéressant, voilà ce que je propose :
- Créer une VM avec ma version de sql serveur
- Démapper la LUN de mon serveur physique (je suis en SAN)
- Mapper la LUN sur la nouvelle VM (RDM de VMware)
- Remonter la base à partir de la LUN
- Créer un nouveau vdisk sur ma VM
- Migrer à chaud la base de ma LUN mappée vers le nouveau vdisk
 
Ça vous semble faisable?

c'est pas à chaud ça, ton démappage, mappage c'est pas transparent

Oui je sais bien, mais le coupure reste quand même minime par rapport à d'autres solutions. Juste le temps de dé-mapper et remapper la LUN et remonté la base sur le nouveau serveur. Moins d'une heure je dirais normalement? non?

ouai ca le fera. Un log shipping  t'apportes plus de sécurité et de controle à mon sens pour assurer le temps du downtime (plié en 20 min ou rollback tout aussi rapide), mais tu n'es pas censé en recontré bcp.  
Check bien le licensing comme mis plus haut, et fait un test si possible avec un petite DB.