Il est important de choisir la bonne taille de machine virtuelle pour obtenir des performances optimales d'une base de données relationnelle dans le cloud public. Microsoft recommande de continuer à utiliser les mêmes options d'ajustement des performances de base de données que celles applicables à SQL Server dans des environnements de serveurs sur site. Utiliser "optimisé pour la mémoire" Tailles des machines virtuelles pour optimiser les performances des charges de travail SQL Server. Collectez les données de performances du déploiement existant pour identifier l'utilisation de la mémoire RAM et de l'UC tout en choisissant les instances appropriées. La plupart des déploiements choisissent une série D, E ou M.

Notes:

Pour augmenter la redondance et la haute disponibilité, les machines virtuelles SQL Server doivent être identiques "ensemble de disponibilité" ou différent "zones de disponibilité". Lorsque vous créez des VM Azure, vous devez choisir entre configurer des ensembles de disponibilité et des zones de disponibilité ; une VM Azure ne peut pas participer aux deux.

Pour la haute disponibilité, la configuration DE SQL Server AOAG ou toujours sur l'instance de cluster de basculement (FCI) est la meilleure option. Pour AOAG, cela implique plusieurs instances de SQL Server sur des machines virtuelles Azure sur un réseau virtuel. Si une haute disponibilité est requise au niveau de la base de données, envisagez de configurer les 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), En outre, les bases de données utilisateur peuvent être installées avec le serveur de fichiers Server message Block (SMB) en tant qu'option de stockage. Cela s'applique à SQL Server autonome et à SQL Server FCI.

Azure NetApp Files fournit un stockage de fichiers haute performance pour répondre à toutes les charges de travail exigeantes et réduit le coût total de possession SQL Server par rapport aux solutions de stockage bloc. Avec le stockage en mode bloc, les machines virtuelles ont imposé des limites en termes d'E/S et de bande passante pour les opérations sur disques ; les seules limites en bande passante réseau sont appliquées à Azure NetApp Files. En d'autres termes, aucune limite d'E/S au niveau des VM n'est appliquée à la 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 exécuter aussi bien que SQL Server sur des machines virtuelles plus importantes. Azure NetApp Files réduit les coûts de déploiement de SQL Server en réduisant les coûts de licence du calcul et des logiciels. Pour obtenir une analyse détaillée des coûts et des performances lors du déploiement de Azure NetApp Files pour SQL Server, consultez le "Avantages liés au déploiement de Azure NetApp Files pour SQL Server".

Créer des partages disponibles en continu via le portail Azure ou l'interface de ligne de commande Azure Dans le portail, sélectionnez l'option Activer la propriété disponibilité continue. Pour l'interface de ligne de commande Azure, spécifiez le partage en tant que partage disponible en continu à l'aide de la 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, voir "Créer un partage disponible en continu".

Notes:

Azure NetApp Files prend en charge trois niveaux de services : standard (16 Mbit/s par téraoctet), Premium (64 Mbit/s par téraoctet) et Ultra (128 Mbit/s par téraoctet). Pour optimiser les performances de la charge de travail de la base de données, il est important de provisionner une taille de volume appropriée. Avec Azure NetApp Files, la performance du volume et la limite de débit reposent sur une combinaison des facteurs suivants :

Pour plus d'informations, voir "Niveaux de service pour Azure NetApp Files".

Comme pour tout déploiement, le test des machines virtuelles et du stockage est crucial. Pour la validation du stockage, des outils tels que HammerDB, Apploader, le "Outil de banc d'essai du stockage SQL Server (SB)", Ou tout script personnalisé ou FIO avec le mélange de lecture/écriture approprié doit être utilisé. N'oubliez pas cependant que la plupart des charges de travail SQL Server, y compris les charges de travail OLTP occupées, sont 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 en 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 interrompre l'accès aux applications et sans aucune migration de données.

Voici un autre exemple de test des performances en temps réel avec HammerDB effectué pour le déploiement décrit dans ce livre blanc. Pour ce test, nous avons utilisé une petite instance avec huit CPU virtuels, un disque SSD premium de 500 Go et un volume Azure NetApp Files SMB de 500 Go. HammerDB a été configuré avec 80 entrepôts et 8 utilisateurs.

Le graphique suivant montre que Azure NetApp Files a pu fournir 2,6 fois le nombre de transactions par minute à une latence 4 fois plus faible en utilisant un volume de taille comparable (500 Go).

Un test supplémentaire a été réalisé en redimensionnant une instance plus grande avec des CPU virtuels 32 x et un volume Azure NetApp Files 16 To. Le nombre de transactions par minute a augmenté, avec une latence uniforme d'un millième de seconde. HammerDB a été configuré avec 80 entrepôts et 64 utilisateurs pour ce test.

Azure NetApp Files permet le redimensionnement transparent et sans interruption des volumes. Il est possible de modifier les niveaux de service sans temps d'indisponibilité et sans impact sur les applications. Cette fonctionnalité est unique et permet une gestion dynamique des coûts qui évite d'avoir à dimensionner la base de données avec des mesures de pointe. Vous pouvez utiliser des charges de travail avec état stable, ce qui vous évite des coûts initiaux. La réorganisation du volume et le changement dynamique au niveau des services vous permettent d'ajuster à la demande la bande passante et le niveau de services des volumes Azure NetApp Files sans interrompre les E/S tout en maintenant l'accès aux données.

Les offres PaaS Azure, telles que LogicApp ou les fonctions, peuvent être utilisées pour redimensionner facilement le volume en fonction d'un déclencheur de règle d'alerte ou de bande Web spécifique afin de répondre aux demandes des workloads tout en gérant dynamiquement les coûts.

Prenons l'exemple d'une base de données qui nécessite 250 Mbit/s pour un fonctionnement stable. Cependant, elle nécessite également un débit maximal de 400 Mbit/s. Dans ce cas, le déploiement doit être effectué avec un volume de 4 To conforme au niveau de service Premium afin de répondre aux exigences de performances stables. Pour gérer les pics de charge de travail, il est possible d'augmenter la taille du volume à l'aide des fonctions Azure de jusqu'à 7 To pour une période donnée, puis de réduire la taille du volume afin d'exploiter le déploiement de façon économique. Cette configuration évite le sur-provisionnement du stockage.