La sélection de la bonne taille de machine virtuelle est importante pour des performances optimales d’une base de données relationnelle dans un cloud public. Microsoft vous recommande de continuer à utiliser les mêmes options de réglage des performances de base de données applicables à SQL Server dans les environnements de serveur locaux. Utiliser "mémoire optimisée" Tailles de machines virtuelles pour les meilleures performances des charges de travail SQL Server. Collectez les données de performances du déploiement existant pour identifier l’utilisation de la RAM et du processeur tout en choisissant les bonnes instances. La plupart des déploiements choisissent entre les séries D, E ou M.

Remarques :

Pour augmenter la redondance et la haute disponibilité, les machines virtuelles SQL Server doivent être dans le même "ensemble de disponibilité" ou différent "zones de disponibilité" . Lors de la création de machines virtuelles Azure, vous devez choisir entre la configuration de groupes de disponibilité et de zones de disponibilité ; une machine virtuelle Azure ne peut pas participer aux deux.

Pour une haute disponibilité, la configuration de SQL Server AOAG ou Always On Failover Cluster Instance (FCI) est la meilleure option. Pour AOAG, cela implique plusieurs instances de SQL Server sur des machines virtuelles Azure dans un réseau virtuel. Si une haute disponibilité est requise au niveau de la base de données, envisagez de configurer des groupes de disponibilité SQL Server.

Microsoft SQL Server peut être déployé avec un partage de fichiers SMB comme option de stockage. À partir de SQL Server 2012, les bases de données système (master, model, msdb ou tempdb) et les bases de données utilisateur peuvent être installées avec le serveur de fichiers Server Message Block (SMB) comme option de stockage. Ceci s’applique à la fois à SQL Server autonome et à SQL Server FCI.

Azure NetApp Files fournit un stockage de fichiers hautes performances pour répondre à toute charge de travail exigeante et réduit le coût total de possession de SQL Server par rapport aux solutions de stockage en blocs. Avec le stockage en bloc, les machines virtuelles ont imposé des limites d’E/S et de bande passante pour les opérations de disque ; seules les limites de bande passante réseau sont appliquées à Azure NetApp Files. En d’autres termes, aucune limite d’E/S au niveau de la machine virtuelle n’est appliquée à Azure NetApp Files. Sans ces limites d’E/S, SQL Server exécuté sur des machines virtuelles plus petites connectées à Azure NetApp Files peut fonctionner aussi bien que SQL Server exécuté sur des machines virtuelles beaucoup plus grandes. Azure NetApp Files réduit les coûts de déploiement de SQL Server en réduisant les coûts de calcul et de licence logicielle. Pour une analyse détaillée des coûts et des avantages en termes de performances liés à l'utilisation Azure NetApp Files pour le déploiement de SQL Server, consultez le "Avantages de l'utilisation Azure NetApp Files pour le déploiement de SQL Server" .

Créez des partages disponibles en continu avec le portail Azure ou Azure CLI. Dans le portail, sélectionnez l'option de propriété Activer la disponibilité continue. pour l'interface de ligne de commande Azure, spécifiez le partage comme un partage disponible en continu à l'aide de l' az netappfiles volume create with the smb-continuously-avl option définie sur $True . Pour en savoir plus sur la création d'un nouveau volume à disponibilité continue, consultez "Création d'un partage disponible en continu" .

Remarques :

Azure NetApp Files prend en charge trois niveaux de service : Standard (16 Mo/s par téraoctet), Premium (64 Mo/s par téraoctet) et Ultra (128 Mo/s par téraoctet). Le provisionnement de la taille de volume appropriée est important pour des performances optimales de la charge de travail de la base de données. Avec Azure NetApp Files, les performances du volume et la limite de débit sont basées sur une combinaison des facteurs suivants :

Pour plus d'informations, consultez la section "Niveaux de service pour Azure NetApp Files" .

Comme pour tout déploiement, le test de la machine virtuelle et du stockage est essentiel. Pour la validation du stockage, des outils tels que HammerDB, Apploader ou tout script personnalisé ou FIO avec le mélange lecture/écriture approprié doivent être utilisés. Gardez toutefois à l’esprit que la plupart des charges de travail SQL Server, même les charges de travail OLTP chargées, sont plus proches de 80 à 90 % en lecture et de 10 à 20 % en écriture.

Pour démontrer les performances, un test rapide a été effectué sur un volume utilisant des niveaux de service premium. Dans ce test, la taille du volume a été augmentée de 100 Go à 2 To à la volée sans aucune interruption de l'accès aux applications et sans migration de données.

Voici un autre exemple de test de performances en temps réel avec HammerDB effectué pour le déploiement couvert dans cet article. Pour ce test, nous avons utilisé une petite instance avec huit vCPU, un SSD Premium de 500 Go et un volume SMB Azure NetApp Files de 500 Go. HammerDB a été configuré avec 80 entrepôts et huit utilisateurs.

Le graphique suivant montre qu’Azure Azure NetApp Files a pu fournir 2,6 fois plus de transactions par minute avec une latence 4 fois inférieure lors de l’utilisation d’un volume de taille comparable (500 Go).

Un test supplémentaire a été effectué en redimensionnant vers une instance plus grande avec 32x vCPU et un volume Azure NetApp Files de 16 To. Il y a eu une augmentation significative des transactions par minute avec une latence constante de 1 ms. HammerDB a été configuré avec 80 entrepôts et 64 utilisateurs pour ce test.

Azure NetApp Files permet un redimensionnement de volume transparent et sans interruption et la possibilité de modifier les niveaux de service sans aucun temps d’arrêt et sans effet sur les applications. Il s’agit d’une capacité unique permettant une gestion dynamique des coûts qui évite d’avoir à effectuer un dimensionnement de base de données avec des métriques de pointe. Vous pouvez plutôt utiliser des charges de travail stables, ce qui évite les coûts initiaux. Le remodelage du volume et le changement dynamique du niveau de service vous permettent d’ajuster la bande passante et le niveau de service des volumes Azure NetApp Files à la demande presque instantanément sans interrompre les E/S, tout en conservant l’accès aux données.

Les offres Azure PaaS telles que LogicApp ou Functions peuvent être utilisées pour redimensionner facilement le volume en fonction d’un déclencheur de règle d’alerte ou de webhook spécifique afin de répondre aux demandes de charge de travail tout en gérant dynamiquement les coûts.

Par exemple, considérons une base de données qui nécessite 250 Mo/s pour un fonctionnement stable ; cependant, elle nécessite également un débit maximal de 400 Mo/s. Dans ce cas, le déploiement doit être effectué avec un volume de 4 To dans le niveau de service Premium pour répondre aux exigences de performances à l'état stable. Pour gérer la charge de travail de pointe, augmentez la taille du volume à l’aide des fonctions Azure jusqu’à 7 To pour cette période spécifique, puis réduisez le volume pour rendre le déploiement rentable. Cette configuration évite le surprovisionnement du stockage.