Azure SQL Database Managed Instance est devenu généralement disponible fin 2018. Depuis lors, de nombreuses organisations ont commencé à migrer vers Managed Instance pour bénéficier des avantages d'un environnement géré. Les organisations profitent de sauvegardes gérées, de nombreuses fonctionnalités de sécurité intégrées, d'un SLA de disponibilité de 99,99 % et d'un environnement toujours à jour dans lequel elles ne sont plus responsables des correctifs de SQL Server ou du système d'exploitation.
Une taille ne fait pas toujours adapté à tous. Managed Instance fournit deux niveaux de performances. L'usage général est conçu pour les applications avec des exigences de performances et de latence d'E/S typiques et fournit une haute disponibilité intégrée. Le critique commercial est conçu pour les applications qui nécessitent une faible latence d'E/S et des exigences de haute disponibilité plus élevées. Business Critical fournit également deux secondaires non lisibles et un secondaire lisible. Le secondaire lisible est un excellent moyen de répartir la charge de travail hors du principal, ce qui peut réduire le niveau de service requis pour le principal, ce qui réduit les dépenses globales de l'instance.
Lorsque Managed Instance a été lancé pour la première fois, vous pouviez choisir entre les processeurs Gen4 et Gen5. Gen4 est toujours décrit dans la documentation, mais cette option n'est pratiquement pas disponible actuellement. Pour cet article, je ne couvrirai que les configurations utilisant les processeurs Gen5.
Chaque niveau de service prend en charge de 4 à 80 processeurs logiques, également appelés cœurs virtuels ou vCores. La mémoire est allouée à environ 5,1 Go par vCore. General Purpose fournit jusqu'à 8 To de stockage Azure Blob hautes performances, tandis que Business Critical fournit jusqu'à 4 To de stockage SSD local ultra-rapide.
Mémoire
Avec seulement 5,1 Go de mémoire par vCore, une instance avec moins de vCore pourrait rencontrer des difficultés. Les options pour les configurations vCore sont 4, 8, 16, 24, 32, 40, 64 et 80 vCores. Si vous faites le calcul sur chacune des options vCore ((number of vCores) × (5.1 GB) ), vous obtiendrez les combinaisons cœur/mémoire suivantes :
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
Pour de nombreuses organisations, j'ai aidé à passer de l'instance sur site à l'instance gérée, j'ai constaté une réduction significative de la mémoire. Les configurations typiques sur site seraient de 4 vCores et 32 Go de mémoire, ou de 8 vCores et 64 Go. Les deux représentent une réduction de plus de 30 % de la mémoire. Si l'instance était déjà sous pression mémoire, cela peut causer des problèmes. Dans la plupart des cas, nous avons pu optimiser l'instance sur site pour aider à alléger la pression de la mémoire avant de passer à l'instance gérée, mais dans quelques cas, le client a dû opter pour une instance vCore plus élevée pour alléger la pression de la mémoire. .
Stockage
Le stockage est un peu plus difficile à planifier et à prendre en compte, car il faut tenir compte de plusieurs facteurs. Pour le stockage, vous devez tenir compte des besoins de stockage globaux pour la taille de stockage et les besoins d'E/S. Combien de Go ou de To sont nécessaires pour l'instance SQL Server et à quelle vitesse le stockage doit-il être ? Combien d'IOPS et de débit l'instance sur site utilise-t-elle ? Pour cela, vous devez référencer votre charge de travail actuelle à l'aide de perfmon pour capturer la moyenne et le maximum de Mo/s et/ou prendre des instantanés de sys.dm_io_virtual_file_stats pour capturer l'utilisation du débit. Cela vous donnera une idée du type d'E/S et du débit dont vous avez besoin dans le nouvel environnement. Plusieurs clients avec lesquels j'ai travaillé ont manqué cette partie essentielle de la planification de la migration et ont rencontré des problèmes de performances en raison de la sélection d'un niveau d'instance qui ne prenait pas en charge leur charge de travail.
Ceci est essentiel pour la ligne de base, car avec les serveurs sur site, il est courant que le stockage soit fourni à partir d'un SAN ultra-rapide avec des capacités de débit élevées vers des machines virtuelles de plus petite taille. Dans Azure, vos limites d'IOPS et de débit sont déterminées par la taille du nœud de calcul, et dans le cas de Manage Instance, elles sont déterminées par le nombre de vCores alloués. Pour un usage général, il existe une limite de 30 à 40 000 IOPS par instance ou de 500 à 12 500 IOPS par fichier en fonction de la taille du fichier. Le débit par fichier est également basé sur une taille allant de 100 Mio/s pour les fichiers jusqu'à 128 Go, et jusqu'à 480 Mio/s pour les fichiers de 4 To et plus. Dans Business Critical, les IOPS vont de 5,5 000 à 110 000 par instance ou 1 375 IOPS par vCore.
Les consommateurs doivent également prendre en compte le débit d'écriture du journal pour l'instance. Usage général est de 3 Mo/s par vCore avec un maximum de 22 Mo/s pour l'instance et Business Critical est de 4 Mo/s par vCore avec un maximum de 48 Mo/s pour l'ensemble de l'instance. D'après mon expérience de travail avec les clients, beaucoup ont largement dépassé ces limites de débit d'écriture. Pour certains, cela a été un succès, et pour d'autres, ils ont pu optimiser et modifier leur système pour réduire la charge.
Outre la nécessité de connaître le débit global et les exigences d'E/S, la taille de stockage est également liée au nombre de vCores choisis. À usage général :
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Pour les entreprises critiques :
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
Pour un usage général, une fois que vous avez atteint 8 vCores, vous pouvez maximiser le stockage disponible, ce qui fonctionne bien pour ceux qui n'ont besoin que d'un usage général. Mais lorsque vous avez besoin de Business Critical, les choses peuvent être plus difficiles. J'ai travaillé avec de nombreux clients qui ont plusieurs To alloués à des machines virtuelles avec 4, 8, 16 et 24 processeurs logiques. Pour chacun de ces clients, ils devraient déplacer au moins 32 vCores juste pour répondre à leurs besoins de stockage, une option coûteuse. Azure SQL Database a un problème similaire avec la taille maximale de la base de données, et Microsoft a proposé une option Hyperscale. Nous nous attendons à ce que cela devienne une option pour Managed Instance à un moment donné pour traiter les limites de stockage de la même manière.
La taille de tempdb est également corrélée au nombre de vCores. Dans le niveau Usage général, vous obtenez 24 Go par vCore (jusqu'à 1 920 Go) pour les fichiers de données, avec une limite de taille de fichier journal tempdb de 120 Go. Pour le niveau Business Critical, tempdb peut croître jusqu'à la taille de stockage d'instance actuellement disponible.
OLTP en mémoire
Pour ceux qui profitent actuellement de l'OLTP en mémoire (ou envisagent de le faire), notez qu'il n'est pris en charge que dans le niveau de service Business Critical. La quantité d'espace disponible pour les tables en mémoire est également limitée par les vCores :
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Conclusion
Lors de la planification d'une migration vers Azure SQL Managed Instance, plusieurs considérations doivent être prises en compte avant de décider de migrer. Vous devez d'abord bien comprendre vos besoins en matière de mémoire, de processeur et de stockage, car cela déterminera la taille de l'instance. Il est tout aussi important de connaître vos exigences en matière d'E/S de stockage. Les IOPS et le débit du niveau Usage général sont directement liés aux vCores et à la taille des fichiers de base de données. Pour Business Critical, il est lié au nombre de vCores. Si vous avez une charge de travail très intensive en E/S, Business Critical est le niveau de service le plus attrayant car il fournit des IOPS et des débits plus élevés. Le défi avec Business Critical est la capacité de stockage inférieure et ne prend en charge que 1 To pour l'ensemble de l'instance jusqu'à 16 vCores.
Avec une planification appropriée et une éventuelle déconsolidation d'instances plus grandes en instances gérées plus petites, cette offre peut être une option de migration très viable pour de nombreuses organisations. L'attrait réside dans les avantages d'avoir des sauvegardes gérées, une haute disponibilité intégrée avec un SLA de 99,99 %, des fonctionnalités et des options de sécurité supplémentaires, et de ne pas avoir à se soucier de corriger un système d'exploitation ou une instance SQL Server.
