Consolidation de SQL Server

Dans l’entreprise, la décision d’effectuer une consolidation est plus un processus descendant qu’ascendant. Dans la majorité des cas, la direction souhaite accomplir plus avec moins de moyens, et espère récupérer certains coûts. Ainsi, la consolidation de SQL Server s’inscrit dans une transformation nettement plus large au sein d’une entreprise. De même, une société peut pousser à la consolidation de SQL Server lorsque son centre de calcul a atteint ou quasiment atteint ses limites en termes de capacité et qu’un nouveau centre de calcul n’est pas à l’ordre du jour.

Toutefois, le principal facteur de la consolidation que je rencontre régulièrement vous semblera peut-être familier : la prolifération de SQL Server. SQL Server a toujours été un cheval de Troie dans de nombreux environnements. Il entre en douce par la porte de derrière et s’insinue partout car il est facile à installer et à déployer dès lors qu’une entreprise a besoin d’un serveur de base de données. Il peut s’installer sur n’importe quelle plate-forme, des périphériques mobiles jusqu’aux serveurs. Un effet secondaire de ce phénomène est le développement de la mentalité « une base de données par instance ».

Au final, l’entreprise se retrouve avec une base de données isolée, qui est hébergée sur un serveur autonome typiquement sous-utilisé et/ou offrant un niveau de disponibilité médiocre. Dans certains cas, la seule machine SQL Server d’une entreprise est un poste de travail qui n’a jamais été conçu pour la production. Mais comme le personnel a commencé à utiliser l’instance et a apprécié la solution créée par-dessus la base de données, cette machine est devenue stratégique. Ces derniers temps, vous obtiendrez peutêtre des gains de performances plus significatifs pour vos installations SQL Server avec une étagère pleine de serveurs lames qu’avec un serveur au format rack 4U acheté il y a seulement trois ans.

Comme de nombreuses entreprises hébergent des téraoctets de données qu’il faut gérer, vous devez envisager soigneusement tous les aspects, allant des achats du matériel aux opérations. La consolidation va au-delà du simple empilage d’instances SQL Server ou de l’utilisation de plusieurs bases de données dans une seule instance. Il faut prendre en compte la capacité de refroidissement nécessaire pour éviter une surchauffe des serveurs, ainsi que les besoins globaux en énergie pour les nombreux serveurs de votre centre de calcul. Pour que la consolidation fonctionne, il vous faudra très probablement acheter de nouveaux serveurs. La supposition selon laquelle vous pouvez utiliser vos serveurs existants peut ne pas être judicieuse. Si vous reconfigurez ces derniers, vous n’aurez pas de véritable plan de repli après la consolidation.

En revanche, envisagez de réaffecter le matériel existant afin d’actualiser le développement, l’assurance qualité (QA) ou les environnements de mise en production. Lors de l’évaluation de votre stratégie de consolidation, vous devez décider de la quantité et du type des nouveaux matériels nécessaires et déterminer le coût. D’autre part, posez-vous la question de savoir si chaque instance de votre environnement a été déployée et est administrée de la même manière. Mon expérience pratique auprès des entreprises de toutes tailles montre qu’aucune n’a déployé SQL Server exactement de la même manière, même si chaque organisation a publié des standards.

La gestion de ces environnements constitue un cauchemar pour les DBA. Si chaque instance est différente en termes d’ordres de tri, de niveaux de Service Pack, d’options de base de données, de paramètres de configuration et autres, vous devez avoir toutes ces variations en tête, ou une action accomplie sur un serveur risque d’être préjudiciable pour un autre serveur. La consolidation peut vous aider à résoudre ces problèmes. En fait, elle représente fréquemment le catalyseur de déploiements normalisés et d’autres modèles (par ex. opérations, processus, administrations) dans un environnement.