Discussion :

[Glouferu]

Bonjour,

Je travail actuellement dans une société qui possède une 20aine de serveur sql virtualisés à l'aide HyperV + SAN LeftHand.
Le souhait du DSI serait de faire revenir ces serveurs sur des machines physiques en cluster failover.

J'ai commencé par cartographier les besoins de chaque serveur SQL (indicateurs de performances : I/O Disk, CPU, Ram, Tempdb ...), ce qui me permet d'identifier clairement les regroupement possibles par type de bases.

Par contre, je me demande comment je vais pouvoir configurer chaque instance de manière à ce qu'elles cohabitent dans les meilleurs conditions possibles.

Je sais qu'il est possible de :
* Définir la quantité de RAM utilisée par instance
* Définir les CPU utilisés par instance
* Configurer le ressource gouverneur pour définir les priorités plus finement


Mais j'ai peur d'effets de bord auxquelles je n'aurais pas penser !
Avez-vous un retour d'expérience sur ce genre de configuration?

Par avance,
Merci.

[zinzineti]

Mais j'ai peur d'effets de bord auxquelles je n'aurais pas penser !
Avez-vous un retour d'expérience sur ce genre de configuration?
Par avance,
Merci.

à ta place je demanderais un accompagnement à une entreprise spécialiste de ce genre de chose. ça ne devrait pas être difficile de convaincre ton manager pour cet accompagnement.
Du courage

[SQLpro]

Bonjour,

Je travail actuellement dans une société qui possède une 20aine de serveur sql virtualisés à l'aide HyperV + SAN LeftHand.
Le souhait du DSI serait de faire revenir ces serveurs sur des machines physiques en cluster failover.

J'ai commencé par cartographier les besoins de chaque serveur SQL (indicateurs de performances : I/O Disk, CPU, Ram, Tempdb ...), ce qui me permet d'identifier clairement les regroupement possibles par type de bases.

Par contre, je me demande comment je vais pouvoir configurer chaque instance de manière à ce qu'elles cohabitent dans les meilleurs conditions possibles.

Je sais qu'il est possible de :
* Définir la quantité de RAM utilisée par instance
* Définir les CPU utilisés par instance
* Configurer le ressource gouverneur pour définir les priorités plus finement


Mais j'ai peur d'effets de bord auxquelles je n'aurais pas penser !
Avez-vous un retour d'expérience sur ce genre de configuration?

Par avance,
Merci.

ATTENTION : l'un des piège les plus important de la reconcentration est la collation des différentes bases.
En effet, si les développeurs utilisent des tables temporaires, et qu'il n'ont pas prévu de les créer correctement (et en général c'est hélas vrai dans 98% des cas) il est impératif que chaque base figure dans un serveur ayant la même collation d'installation que la base de prod....

A +

[Glouferu]

ATTENTION : l'un des piège les plus important de la reconcentration est la collation des différentes bases.
En effet, si les développeurs utilisent des tables temporaires, et qu'il n'ont pas prévu de les créer correctement (et en général c'est hélas vrai dans 98% des cas) il est impératif que chaque base figure dans un serveur ayant la même collation d'installation que la base de prod....

A +

Bonjour,

Coté collation nous sommes carrés puisque tout est en "French_CI_AS".
En ce qui concerne les tables temporaires, j'essai de faire en sorte qu'ils en utilisent le moins possible ... et les branches de DEV sont iso avec la PRD ainsi que les environnements de recettes !
Mais effectivement, je n'avais pas pensé aux collations

Personnellement, ce qui m'inquiète s'est de faire cohabiter une base de données SharePoint avec un CubeOLAP ainsi qu'une base de données Métier.

Voyez-vous d'autres points importants à prendre en compte?

à ta place je demanderais un accompagnement à une entreprise spécialiste de ce genre de chose. ça ne devrait pas être difficile de convaincre ton manager pour cet accompagnement.
Du courage

C'est un projet qui ne me fait pas peur... et c'est justement là ou je me dis que je passe peut-être à coté de quelque chose de très important. Et qui pourrait foutre le projet dans le mur ...


Cdt,

[mikedavem]

Il y a pas mal de choses à voir quand on fait de la consolidation de bases de données (mon dernier mandat consiste à consolider 200 instances SQL Server).

Il existe différents axes de réflexion en fonction des architectures et contexte clients. En voici quelque unes :

- La sécurité (sensibilité des données, privilèges des comptes de connexion, overlap des noms de connexion, option de bases de données, isolation des données sur le filesystem)
- Les collations de serveurs et de bases de données
- Les noms de bases de données (overlapp)
- Les ressources utilisés par chaque base (CPU, IO, Network, mémoire)
- Les versions, éditions, service pack et CU utilisés
- La classification des applications associées (par domaine, par sensibilité des données, par découpage "politique" liée à l'entreprise etc ..)
- Contraintes d'architectures et / ou dépendances fonctionnelles applicatives ....


Bref les seuls métriques liées à SQL Server ne sont pas les seuls éléments à prendre en compte. En fonction du contexte client cela peut être simple comme compliqué à mettre en oeuvre un projet de consolidation. Les réponses ne sont malheureusement pas toutes faites :-)

++