Qu’est-ce qu’un pool d’instances ? Azure SQL Managed Instance -

S’applique à :Azure SQL Managed Instance

Cet article fournit une vue d’ensemble de l’option de déploiement du pool d’instances pour Azure SQL Managed Instance, ce qui offre des avantages substantiels pour les clients.

Les pools d’instances permettent de déployer plusieurs instances avec des ressources partagées, qui fournissent une infrastructure pratique et économique pour migrer plusieurs bases de données à partir d’instances SQL Server sans avoir à consolider des charges de travail plus petites et moins gourmandes en ressources de calcul sur une instance managée SQL plus grande.

Pour commencer, consultez Créer un pool d'instances.

Vue d’ensemble

Les pools d'instances dans Azure SQL Managed Instance vous permettent de déployer plusieurs instances avec des ressources partagées sur une seule machine virtuelle sous-jacente au sein d'un cluster virtuel.

Les pools d'instances offrent les avantages fondamentaux suivants :

• Elles peuvent héberger des instances 2-vCore, uniquement disponibles dans les pools d'instances
• Durée de déploiement d’instance prévisible et rapide (jusqu’à 10 minutes).
• Elles fournissent une infrastructure permettant de réduire les coûts lors de la migration de plusieurs instances SQL Server.

Le diagramme suivant illustre un pool d'instances avec plusieurs instances managées déployées sur un cluster virtuel dans un sous-réseau de réseau virtuel :

Nouveautés

Le mois de novembre 2024 apporte les capacités suivantes :

• Créez des pools, créez des instances dans un pool et modifiez les paramètres de configuration du pool dans le portail Azure.
• Mettez à jour les paramètres de configuration du pool (par exemple, taille de calcul, licence, propriétés) à l’aide de PowerShell ou d’Azure CLI.
• Prise en charge du matériel de série premium.
• Déplacez une instance dans et hors du pool à l’aide de PowerShell ou d’Azure CLI.
• Prise en charge du pool d’instances pour la tarification de la capacité de réserve.

Architecture

Les pools d'instances ont une architecture similaire aux instances managées uniques. Pour prendre en charge les déploiements dans les réseaux virtuels Azure et assurer l'isolation et la sécurité des clients, les pools d'instances s'appuient sur des clusters virtuels. Un cluster virtuel représente un ensemble dédié de machines virtuelles isolées, déployées dans le sous-réseau du réseau virtuel du client. Toutes les instances uniques et pools d’instances au sein du même sous-réseau appartiennent au même cluster virtuel. Les instances au sein d’un pool ont des ressources de calcul allouées aux processus SQL Server et aux composants de passerelle, ce qui garantit des performances prévisibles. Après le déploiement initial du pool, les opérations de gestion sur les instances d’un pool sont plus rapides, car les processus SQL sont créés sur les ressources de calcul qui ont déjà été approvisionnées.

La taille de calcul de la machine virtuelle est basée sur le nombre total de vCores alloués au pool, qui sont distribués entre les instances du pool. Cette architecture permet de partitionner la machine virtuelle en plusieurs instances qui peuvent prendre en charge toutes les tailles possibles, notamment 2 vCores (exclusif aux pools d'instances). Par exemple, lorsque vous déployez un pool d’instances 8-vCore, vous pouvez déployer deux instances 2-vCore et une instance 4-vCore. Vous pouvez ensuite migrer vos bases de données SQL Server vers les instances du pool. Comme les pools d'instances prennent en charge l'intégration native des réseaux virtuels, vous pouvez déployer plusieurs pools d'instances, ainsi que plusieurs instances individuelles, sur le même sous-réseau.

Les pools d’instances fournissent un niveau élevé d’isolation, car chaque instance reçoit des vCores dédiés sur la machine virtuelle hôte sous-jacente. La principale différence de modèle de déploiement d’un pool d’instances par rapport à une seule instance managée est que, avec les pools d’instances, plusieurs processus SQL Server peuvent être créés dans la même machine virtuelle, qui sont régies par des ressources régies à l’aide d’objets de travail Windows. Si l’isolation au niveau du processus n’est pas suffisante, envisagez d’utiliser des instances uniques au lieu de pools d’instances, car les instances uniques n’ont qu’un seul processus SQL Server sur le nœud de la machine virtuelle, fournissant une isolation au niveau de la machine virtuelle

Le diagramme suivant illustre la principale différence architecturale entre les deux modèles de déploiement :

Scénarios d’application

Envisagez d'utiliser des pools d'instances pour les scénarios suivants :

• migration simultanée d'un groupe de petites instances SQL Server, lorsque les instances présentent les tailles 2 ou 4 vCores.
• Dans la scénario susmentionné, vous avez besoin d'une création ou d'une mise à l'échelle d'instances rapides et prévisibles. Il peut par exemple s'agir du déploiement d'un nouveau locataire dans un environnement d'application SaaS multi-locataire qui requiert des fonctionnalités au niveau de l'instance.
• Il est important d'avoir un coût fixe ou une limite de dépenses. Par exemple, si vous exécutez des environnements de développement-test ou de démonstration partagés d’une taille fixe (ou rarement modifiée), où vous déployez régulièrement des instances gérées quand cela est nécessaire.

Les pools d'instances sont particulièrement bien adaptés à la migration de plusieurs instances SQL Server, car le préapprovisionnement des ressources informatiques partagées en fonction de vos besoins totaux de migration réduit le coût global de propriété après la migration. Envisagez par exemple un scénario pour migrer quatre petites instances SQL Server locales vers Azure SQL Managed Instance. Sans pool d'instances, vous devez approvisionner quatre instances managées SQL distinctes avec au moins 4 vCores chacun, toutes avec leurs propres ressources dédiées. Un pool d'instances réduit ce coût puisque vous pouvez déployer toutes les instances avec 2 vCores chacune dans le pool où les ressources sont partagées par le pool.

Propriétés d'instance et de pool

Les propriétés suivantes sont configurées au niveau du pool pour toutes les instances du pool :

• Niveaux matériels
• Licence SQL Server, comme Azure Hybrid Benefit
• Fenêtre de maintenance

En outre, tenez compte des points suivants :

• Les instances managées créées dans des pools bénéficient des mêmes niveaux de compatibilité et des mêmes fonctionnalités que les instances managées uniques.
• Les fonctionnalités facultatives qui nécessitent que vous choisissiez des valeurs spécifiques (telles que le classement au niveau de l’instance, le fuseau horaire, le point de terminaison public pour le trafic de données, les groupes de basculement) sont configurées au niveau de l’instance et peuvent être différentes pour chaque instance d’un pool.
• Étant donné que les instances déployées dans un pool partagent la même machine virtuelle, envisagez de désactiver les fonctions qui présentent des risques de sécurité plus élevés ou de contrôler fermement les autorisations d'accès à ces fonctions, telles que l'intégration CLR, la sauvegarde et la restauration natives, l’e-mail de la base de données, etc.
• Vous pouvez configurer votre SQL Managed Instance pour utiliser l'authentification Microsoft Entra avant ou après son ajout au pool.
• Chaque instance gérée déployée dans un pool dispose d'un SQL Server Agent distinct.

Limites des ressources

Lorsque vous déployez une instance dans un pool, il existe des limites pour chaque instance mise en pool et pour les ressources utilisées par l'ensemble du pool.

Le tableau suivant détaille les limites des instances mises en pool et du pool :

¹ Options vCore pour les instances mises en pool dépendent du nombre de vCores disponibles dans le pool d’instances.
² La limite de stockage du pool est dictée par la somme du stockage pour toutes les instances du pool.

Pour toutes les autres limites au niveau de l'instance, examinez les limites des ressources.

Considérations relatives aux performances

Bien que les instances managées au sein des pools disposent d'un vCore et d'une RAM dédiés, elles partagent un disque local (pour tempdb) et des ressources réseau. Bien que peu probable, il est possible d'observer un effet de voisin bruyant lorsque plusieurs instances du pool consomment beaucoup de ressources en même temps.

Si vous rencontrez ce comportement, envisagez d'augmenter la taille du pool ou de redéployer les ressources à forte consommation en tant qu'instance unique en dehors du pool.

Facturation des pools d’instances

Les pools d'instances permettent de mettre à l'échelle le calcul et le stockage indépendamment. Vous payez pour :

• le calcul alloué au pool, mesuré dans vCores
• Le stockage associée à chaque instance mesurée en gigaoctets (les 32 premiers Go sont gratuits pour chaque instance).

Le prix des vCores pour un pool est facturé quel que soit le nombre d'instances déployées dans ce pool. La définition d'options de tarification différentes n'est pas possible pour les instances individuelles d'un pool. Toutes les instances du pool doivent utiliser le même modèle de licence. Le modèle de licence du pool peut être modifié après la création du pool.

Le prix du calcul (mesuré en vCores) dépend du fait que vous payez ou non le prix total de la licence SQL Server. Les deux options de prix suivantes sont disponibles :

• Licence incluse : le prix des licences SQL Server est inclus.
• Azure Hybrid Benefit : un prix réduit qui inclut Azure Hybrid Benefit pour SQL Server. Les clients peuvent choisir cette tarification en utilisant leurs licences SQL Server existantes avec Software Assurance.

Pour plus de détails sur la tarification des pools d'instances, reportez-vous à la section sur les pools d'instances de la page de tarification de SQL Managed Instance.

Tarification liée à la capacité de réserve

La capacité de réserve vous permet d’économiser sur le coût de calcul en fournissant une remise approfondie lorsque vous réservez le prix des ressources pour une période prédéterminée. Vous pouvez désormais allouer une capacité réservée à un pool d’instances, ce qui crée le moyen le plus rentable d’exécuter plusieurs instances.

Limites

Pour en savoir plus, examinez les limitations du pool d'instances.

Étapes suivantes

Configurer un pool d'instances