Discussion :

[Francky8]

Bonjour,

Je vais devoir installé un SQL Server 2008 sur un W2008 R2 dans une machine virtuelle VMware ESXI. J'ai lu plusieurs articles sur le sujet (notamment sur ce site ... merci) et je déconseille fortement pour l'instant un SGBD "critique" dans un environnement virtuel. Cela concerne un environnement de DEV pas critique. Donc ... pourquoi pas ... en plus ca me permettra de voir le fonctionnement de sql server sous VMware.
J'ai noté qu'il est intéressant d'activer l'accès direct pour SQL Server au sous-système disque. Est-ce que cette solution correspond à la notion de datastore RDM ? Si oui, est-ce que cela singifie que je dois demander à mon manager VMware de créer un datastore pour mes data sql server en RDM au lieu de VMFS ?
Par avance, merci pour vos réponses.

Franck

[SQLpro]

Au moins du Raw Device mapping.

A +

[Francky8]

OK. Merci pour le retour.
Je vais donc demander un RDM (raw device mapping) pour l'espace des data et log.
Est-ce qu'il faudrait que l'install de SQL Server (les binaires de sql server) soit faite sur un RDM plutot que sur un datastore WMFS ? Est-ce préférable sur le plan des perf ?

Franck

[SQLpro]

L'installe on s'en fout car les IO de Windows, des exe SQL et des bases systèmes (sauf TEMPDB) c'est peanuts.

SI vous voulez des perf :
1) RAID 10 pour les journaux
2) RAID 1 (minimum) pour les data
3) un fichier de n Go par CPU pour les data de tempdb n estimé après activité mesure par profileur SQL)
4) régler la taille de tout vos fichiers de données pour 3 ans d'exploitation
5) régler la taille de vos fichiers de JT à 20/30 % de la taille des datas
6) si plusieurs bases, alors RAID 10 partout et croisez les fichiers de data et JT des différentes bases pour ventiler les IO
7) autant que faire se peut, tailler vos LUN sur des disques physiques entiers (et non pas dans la masse, c'est à dire sur des disques physiques partagés entre différentes LUN).

A +

[kagemaru]

Hello

Le RDM pour les perf : ce n'est pas cela qui va t'aider. Pour avoir migré pas mal d'applications de vmfs vers rdm, avec même schéma de LUN, cela ne donne rien. Bien que désormais le RDM ne pose plus de pb pour faire du vmotion, je reste tjrs réticent à l'utiliser. Cela reste réservé à des quorums de cluster, des oracle fs pour du RAC par exemple.

Pour du DEV, il ne faut pas couper les cheveux en quatre et utiliser justement des VMFS qui permettent plus de souplesse.

Je verrais aussi le RDM pour la sécurité des écritures, comme tu écris directement sur le volume logique donc pas de cache file system intermédiaire. Donc éventuellement, un journal de transactions d'un base de prod ultra-critique.

Je ne sais pas ce que tu auras comme LUN pour tes data/log SQL ...surtout si c'est du DEV....Je te souhaite d'avoir déjà d'avoir des LUNs qui ne reposent pas sur les même disques mais encore une fois, pour du DEV ce n'est pas l'essentiel. Si tu as plus de détails, ils sont les bienvenus.

[mikedavem]

Bonsoir,

D'accord avec Kagemaru. La différence de performances entre VMFS et RDM est mimime. D'après les benchmarks que j'ai pû voir et ce que j'ai vu implémenté il y a un gain minime de performances pour les accès séquentiels alors que pour les accès de type RANDOM ce n'est pas forcément le cas.

Il vaut mieux effectuer un alignement des partitions VMFS à la rigueur et veiller à ce que les datastores soient réellement dédiés à SQL Server.

++