Virtualisation SQL Server

Version imprimable

01/12/2014, 11h31
croftman

Virtualisation SQL Server

Bonjour à tous !

Je vais bientôt changer l'infra de ma boite et je pars pour l'instant sur un cluster de serveur.
Chaque serveur aura 48go de ram et 2 proc Xeon E5-2609 4C 2.4GHz (pas encore définitif) 2 disques SAS 300Gb 10K (système) et 3 disque SAS 1To 7.2K (à revoir peut être)

On a 15 utilisateurs sédentaires et une quarantaine nomade, qui ne sont jamais connectés en même temps, le record doit être de 30 utilisateurs connectés en même temps.

J'ai 2 BDD SQL Server (SAGE), une de 1.3go et une autre de 100mo, je voulais savoir si la solution de virtualisation est ici un choix raisonnable ?

Ça m’embêterait d'installer un serveur SQL à coté de l'HyperV ou même sur une machine séparé :)

Merci ! :P
01/12/2014, 14h20
joujousagem2006

merci de lire article de SQLPRO sur ce sujet

C'est un article très intéressant

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

cordialement
01/12/2014, 15h49
SQLpro

Dans votre cas, cela ne devrait pas poser de problème.

A +
01/12/2014, 15h54
croftman

Citation:

Envoyé par joujousagem2006

merci de lire article de SQLPRO sur ce sujet

C'est un article très intéressant

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

cordialement

Merci ! Je l'ai bien sur lu avant de poster :)

Citation:

Envoyé par SQLpro

Dans votre cas, cela ne devrait pas poser de problème.

A +

Ok super merci :)
01/12/2014, 16h24
SQLpro
Grosso modo la frontière c'est :
- quelques dizaines à quelques centaines de Go
- quelques dizaine à une centaine d'utilisateur
- quelques transactions par secondes au plus
- des heures creuses
- pas de nécessité d'une très haute disponibilité
Si vous êtes en dehors de ces clous alors, mieux vaut dévertualiser !

a +
04/12/2014, 10h03
croftman

Ok je vois, on a un prestataire (celui qui va nous réinstaller l'ERP SAGE) qui persiste et ne veux pas virtualiser le SQL, ou du moins ne veux rien garantir quand au bon fonctionnement.

Je pense pourtant que ça passerait corrrectement, dans la liste, 'des heures creuses' ça veut dire quoi? parce-que les employés ne travaillent pas uniquement en heures creuses :mrgreen:

Ensuite 'pas de nécessité d'une très haute disponibilité' : à quel point ? Disons que l'erp est le point centrale, il est sollicité toute la journée tout le temps :)

Il faudrait donc dé-virtualiser ? Dans ce cas est-ce judicieux de placer le serveur SQL sur la même machine que le cluster ? (le sql sur un des serveurs et un sql backup sur le second) ou vaut-il mieux placer une machine à part dédié au serveur SQL ? D'après votre article (ci dessus) il faudrait placer le SQL sur une machine dédié.

Merci pour vos réponses !
05/12/2014, 11h12
SQLpro

Citation:

Envoyé par croftman

Ok je vois, on a un prestataire (celui qui va nous réinstaller l'ERP SAGE) qui persiste et ne veux pas virtualiser le SQL, ou du moins ne veux rien garantir quand au bon fonctionnement.

C'est parfaitement normal. Même Microsoft ne garantie pas un serveur SQL virtualisé, et si vous faites appel à la hot line MS, alors ils peuvent vous demander de dévirtualiser afin de reproduire le problème sur une machine physique pour isoler la cause !

Citation:

Je pense pourtant que ça passerait corrrectement, dans la liste, 'des heures creuses' ça veut dire quoi? parce-que les employés ne travaillent pas uniquement en heures creuses :mrgreen:
[/CODE]Pensez est une chose; EN être sûr en est une autre. Mon expertise et mes nombreuses expérience montre que dans la plupart des cas de dégradation des perf, la virtualisation est en cause ![CODE]

Ensuite 'pas de nécessité d'une très haute disponibilité' : à quel point ? Disons que l'erp est le point centrale, il est sollicité toute la journée tout le temps :)

Vous pouvez perdre quelques heures à une journée de production. C'est à dire la fréquence de vos sauvegardes....

Citation:

Il faudrait donc dé-virtualiser ? Dans ce cas est-ce judicieux de placer le serveur SQL sur la même machine que le cluster ? (le sql sur un des serveurs et un sql backup sur le second) ou vaut-il mieux placer une machine à part dédié au serveur SQL ? D'après votre article (ci dessus) il faudrait placer le SQL sur une machine dédié.

Merci pour vos réponses !

Oui, pour bien fonctionner les SGBDR comme Oracle ou SQL Server ont besoin d'une machine dédiée et aucune autre application ne doit tourner dessus, pas même un antivirus !

A 9
05/12/2014, 14h53
croftman

Citation:

Envoyé par SQLpro

C'est parfaitement normal. Même Microsoft ne garantie pas un serveur SQL virtualisé, et si vous faites appel à la hot line MS, alors ils peuvent vous demander de dévirtualiser afin de reproduire le problème sur une machine physique pour isoler la cause !Vous pouvez perdre quelques heures à une journée de production. C'est à dire la fréquence de vos sauvegardes....

Oui, pour bien fonctionner les SGBDR comme Oracle ou SQL Server ont besoin d'une machine dédiée et aucune autre application ne doit tourner dessus, pas même un antivirus !

A 9

mmm je me tate quoi faire alors !

Quand vous dites 'Vous pouvez perdre quelques heures à une journée de production' je ne comprends pas très bien ? ça veut dire que je le temps que les sauvegardes du SQL se fasse la production s'en voit ralentit ? Les backups peuvent être faits hors des heures de travail non ?
05/12/2014, 16h34
SQLpro

Citation:

Envoyé par croftman

mmm je me tate quoi faire alors !

Quand vous dites 'Vous pouvez perdre quelques heures à une journée de production' je ne comprends pas très bien ? ça veut dire que je le temps que les sauvegardes du SQL se fasse la production s'en voit ralentit ? Les backups peuvent être faits hors des heures de travail non ?

NON.. Les sauvegardes ne servent en principe pas à faire de la haute dispo, mais à reprendre les données en cas d'erreur. Par exemple si un utilisateur a augmenté par erreur le pris de certains produits de 10000 % eu lieu de 10, il va falloir retrouver dans une sauvegardes, les valeurs antérieures juste avant l'erreur.

La hautre dispo c'est d'avoir un serveur de secours capable de reprendre la main en cas d'avarie importante au serveur principal. Cela se fait au minimum par du "log shipping" (asynchrone et manuel avec une perte de données équivalente en moyenne à la moitié de l'intervalle de passage des journaux transactionnel), voir avec du mirroring simple ou une solution "AlwaysOn" et dans ces deux derniers cas on peut être synchrone et automatique, donc sans aucune perte de données.

Ceci pour les solutions intégrées à SQL Server.

En revanche il existe une solution non garantie, spécifique à la virtualisation, qui consiste à se baser sur les snapshot de VM. Cette solution ne permet ni d'être synchrone, ni d'être automatisée, et n'offre aucune garantie de succès en cas de reprise de la VM dans le cadre de MS SQL Server.

Les sauvegardes ne ralentissent que peu la production. par exemple les sauvegardes de JT sont très peu intrusives et peuvent être faites fréquemment (par exemple toutes les 10 minutes) même en pleine production, cela n'est pas gênant, si votre organisation de stockage est bien faite !

A +