Pourquoi NE PAS multiplier les instances SQL Server

Pourquoi installe-t-on plusieurs instances sur le même serveur?

Dans le monde de la virtualisation et des conteneurs, le réflexe naturel d’un administrateur système est souvent d’isoler : une application = un service = une instance.

Pour les administrateurs de bases de données, les raisons peuvent être les suivantes :

• Gérer séparément la sécurité par base de données.
• Isoler les performances entre applications.
• Permettre un basculement différencié (Failover) entre applications.
• Faire cohabiter plusieurs versions de SQL Server sur le même serveur.

Aucune de ces raisons ne nécessite réellement des instances différenciées.

Je vais détailler un peu plus dans cet article, mais les réponses simples à ces différents problèmes sont :

• Gérer séparément la sécurité par base de données ⮕ Chaque base de données possède son propre ensemble de permissions. Pas besoin d’instances séparées.
• Isoler les performances entre applications ⮕ Utiliser le Resource Governor pour allouer des ressources spécifiques à des groupes d’utilisateurs ou de charges de travail.
• Permettre un basculement différencié (Failover) entre applications ⮕ Utiliser les Groupes de Disponibilité (Availability Groups) pour gérer le basculement au niveau des bases de données.
• Faire cohabiter plusieurs versions de SQL Server sur le même serveur ⮕ Utiliser le niveau de compatibilité des bases de données pour gérer les différences de comportement entre versions.

Pourquoi ce n’est pas une bonne idée

Installer plusieurs instances sur la même machine physique ou virtuelle est un anti-pattern qui dégrade les performances globales.

SQL Server est nativement conçu pour la consolidation, voyons et comment il gère ses ressources.

SQLOS : Le système d’exploitation dans le système

SQL Server ne se contente pas de demander des ressources à Windows comme un logiciel classique. Il possède sa propre couche d’abstraction, SQLOS, qui gère :

• L’ordonnancement (scheduling) : SQL Server gère ses propres threads sans attendre que Windows le fasse.
• La mémoire : Il possède son propre gestionnaire de pages pour optimiser le cache.
• Les E/S : Il arbitre lui-même les priorités d’écriture et de lecture.

Le problème de la colocation

Lorsque vous installez deux instances sur la même machine, vous installez deux « mini systèmes d’exploitation » qui ignorent l’existence l’un de l’autre. Chaque SQLOS va tenter de s’approprier le maximum de ressources :

• Guerre de la mémoire : Par défaut, chaque instance tentera de consommer toute la RAM disponible. Sans configuration manuelle stricte (Max Server Memory), le serveur finira par swapper sur le disque.
• Concurrence CPU : Les schedulers des deux instances vont se battre pour les mêmes cœurs physiques, provoquant des changements de contexte (context switching) excessifs au niveau du processeur Windows.

Contrairement à d’autres moteurs de base de données, SQL Server est conçu pour héberger de nombreuses bases de données au sein d’une seule et même instance. Il est nativement « multi-tenant ».

La gestion granulaire des ressources

Au lieu de créer plusieurs instances pour séparer les projets, il est bien plus efficace d’utiliser une seule instance et de gérer les ressources en interne :

• Sécurité isolée : Chaque base de données possède ses propres permissions. Un utilisateur de la Base A n’a aucun privilège sur la Base B, même s’ils partagent la même instance.
• Resource Governor (Édition Enterprise, aussi en Standard depuis SQL Server 2025) : Cet outil permet de brider ou de garantir des ressources (CPU, RAM, IOPS) à certains groupes d’utilisateurs au sein de l’instance.

Les Groupes de Disponibilité (AG)

L’un des arguments souvent avancés pour multiplier les instances est le besoin de basculement (Failover) différencié. On pense à tort qu’il faut une instance par application pour qu’elles puissent basculer indépendamment.

Mais nous avons les Groupes de disponibilité (Availability Groups, AG).

Avec les AG, l’unité de basculement n’est plus l’instance, mais le groupe de bases de données.

• Vous pouvez avoir une seule instance SQL Server.
• À l’intérieur, vous créez plusieurs Groupes de Disponibilité (AG1, AG2, AG3).
• AG1 peut être actif sur le Nœud A, tandis que AG2 est actif sur le Nœud B.

Pourquoi consolider ? Les bénéfices concrets

Optimisation du cache (Buffer Pool)

Une instance unique gère un cache global. Si une base de données est très active le matin et une autre l’après-midi, SQL Server réallouera dynamiquement l’espace mémoire interne sans intervention humaine. Avec deux instances, la mémoire est « statique » et perdue pour l’autre instance si elle n’est pas utilisée.

Simplicité de maintenance

• Patching : Un seul Cumulative Update (CU) à passer par serveur.
• Monitoring : Un seul jeu d’alertes et de compteurs de performance à surveiller.
• Licensing : En consolidant, vous réduisez souvent le nombre de cœurs nécessaires pour maintenir les mêmes performances, ce qui peut réduire la facture.

Moins de « Context Switching »

En laissant un seul SQLOS gérer tous les threads de la machine, Windows travaille moins. Le processeur passe plus de temps à exécuter vos requêtes SQL et moins de temps à arbitrer les disputes entre deux instances gourmandes.

Le problème des versions de SQL Server

Un argument classique pour justifier plusieurs instances : Mon application est certifiée pour SQL Server 2016, je ne peux pas l’installer sur une instance SQL Server 2022.

C’est une confusion entre la version du moteur (binaires) et le niveau de compatibilité (logique). En réalité, SQL Server est conçu pour faire tourner des bases de données avec des comportements hérités de toutes les versions depuis SQLServer 2008. La compatibilité est garantie par Microsoft sur une application, non pas sur la version de l’instance, mais au niveau de compatibilité de la base de données.

Microsoft garantit qu’une base de données réglée sur un niveau de compatibilité spécifique (ex: Niveau 130 pour SQL 2016) se comportera de la même manière, qu’elle soit hébergée sur une instance 2016, 2019 ou 2022.

Ne confondez plus moteur et comportement

Imaginez le moteur SQL Server (l’instance) comme le processeur de votre ordinateur. Il est plus rapide, plus sécurisé et plus moderne à chaque version. Le Database Compatibility Level, lui, est la « règle du jeu » que vous imposez au moteur pour une base précise.

• L’Instance (Le moteur) : Gère les fichiers, la mémoire, le parallélisme et la sécurité globale. Plus elle est récente, plus elle est performante.
• Le Niveau de Compatibilité (La logique) : Définit comment le T-SQL est interprété et comment l’optimiseur de requêtes doit se comporter.

Pourquoi privilégier le niveau de compatibilité plutôt que l’instance multiple ?

Installer une vieille instance (ex: SQL 2014) sur un serveur moderne présente des risques majeurs :

1. Failles de sécurité : Les vieilles instances ne reçoivent plus de mises à jour de sécurité critiques.
2. Incompatibilité OS : Faire tourner SQL 2014 sur Windows Server 2022 n’est pas supporté et peut provoquer des crashs du SQLOS.
3. Performances bridées : Un vieux moteur ne sait pas utiliser efficacement les processeurs modernes ou les disques NVMe.

La bonne approche : Installez une instance unique dans la version la plus récente (SQL Server 2022). Attachez-y vos bases et réglez leur niveau de compatibilité sur leur version d’origine.