Qu'est-ce qu'un pool d'instances (Aperçu) ? 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.

Les pools d'instances permettent de déployer plusieurs instances avec des ressources partagées, lesquelles fournissent une infrastructure pratique et rentable pour migrer plusieurs bases de données à partir d'instances SQL Server sans avoir à consolider des charges de travail plus petites et moins exigeantes en termes de calcul sur une SQL Managed Instance 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
• Temps de déploiement d’instances prévisible et rapide (jusqu’à 5 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

L'actualisation de l'Aperçu 2024 des pools d'instances offre les nouvelles fonctionnalités suivantes :

• La configuration du pool (par exemple la taille de calcul, la licence, les propriétés) peut être mise à jour à l'aide de PowerShell ou d'Azure CLI.
• Le matériel de la série Premium est désormais pris en charge.
• Vous pouvez déplacer une instance dans et hors du pool à l'aide de PowerShell ou d'Azure CLI.

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. Les clusters virtuels représentent 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 tous les pools d'instances appartiennent au même cluster virtuel. Les instances d'un pool et les instances uniques déployées sur le même sous-réseau ne partagent pas les ressources de calcul allouées aux processus SQL Server et aux composants de passerelle. La prévisibilité des performances est ainsi garantie. Après le déploiement initial du pool, les opérations de gestion sur les instances d'un pool sont plus rapides, car le cluster virtuel a déjà été étendu lors de l'approvisionnement du pool.

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). Lorsque vous déployez, par exemple, 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. Étant donné que 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 uniques, sur le même sous-réseau.

La principale différence entre les deux modèles de déploiement est que vous pouvez créer plusieurs processus SQL Server au sein de la même machine virtuelle lorsque vous utilisez un pool d'instances, qui sont des ressources régies à l'aide d'objets de traitement Windows. Les instances uniques n'ont qu'un seul processus SQL Server sur le nœud 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 fonctionnalités qui présentent des risques de sécurité plus élevés, ou de contrôler fermement les autorisations d'accès à ces fonctionnalités, telles que l'intégration CLR, la sauvegarde et restauration natives, l'email 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 managée déployée dans un pool a une instance d’agent SQL distincte.

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 :

¹ Les options vCore pour les instances groupées 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.

Limites

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

Étapes suivantes

Configurer un pool d'instances