Planifier, déployer et vérifier Azure SQL

  • 10 minutes

Après avoir sélectionné une charge de travail à migrer ou à créer dans Azure SQL, vous devez planifier votre déploiement, déployer en conséquence et vérifier que le déploiement a réussi. Dans cette unité, vous apprenez différentes méthodes pour chaque étape du processus.

Planification du prédéploiement

Avant de commencer à déployer des éléments dans Azure, il est important de comprendre vos besoins et la façon dont ils sont mappés aux offres dans Azure SQL. Utilisez ce que vous avez appris dans le module d’introduction à Azure SQL pour créer un plan. Vous devez répondre aux questions suivantes :

  • Méthode de déploiement : portail Azure ou interface de ligne de commande ?
  • Option de déploiement : machine virtuelle, base de données, pool élastique, instance managée ou pool d’instances ?
  • Modèle d’achat (Azure SQL Database uniquement) : DTU ou vCore ?
  • Niveau de service : usage général, critique pour l’entreprise ou hyperscale ?
  • Matériel : Gen5 ou quelque chose de nouveau ?
  • Dimensionnement : nombre de vCores et taille maximale des données ?

Peut-être qu’avant de répondre aux questions précédentes, vous devez aussi choisir une charge de travail qui va être migrée vers Azure SQL ou née dans le cloud. Si vous effectuez une migration, de nombreux outils et ressources sont disponibles pour vous aider à planifier, évaluer, migrer et optimiser vos bases de données et vos applications. Des ressources sont fournies à la fin de ce module.

Limites des ressources

Le module d’introduction à Azure SQL a décrit les limites, les tarifs et les capacités comme les IOPS ou l’OLTP en mémoire. D’autres limites de ressources sont affectées par votre choix d’Azure SQL Managed Instance, d’Azure SQL Database ou par des options de ces choix :

  • Mémoire
  • Taille maximale du journal
  • Débit du journal des transactions
  • IOPS des données
  • Taille de tempdb
  • Nombre maximal de workers simultanés
  • Rétention des fichiers de sauvegarde

Les limites pour Azure SQL Managed Instance et Azure SQL Database dépendent de votre choix de modèle d’achat, de niveau de service et du nombre de vCores ou de DTU seulement dans Azure SQL Database.

Azure SQL Managed Instance et SQL Database sont des offres PaaS (Platform as a Service). La restriction de ces choix ne doit pas vous empêcher d’utiliser pleinement un service managé SQL Server.

Dans une instance Azure SQL Database de niveau Usage général, votre choix de calcul provisionné ou serverless affecte également ces limites. Avant d’effectuer un déploiement, examinez ce qui est inclus dans ce que vous prévoyez de déployer de façon à être sûr de commencer avec ce dont vous avez besoin.

Les ressources Azure SQL ont des limites de ressources globales par abonnement et par région. Si vous avez besoin d’augmenter vos limites, vous pouvez demander une augmentation de quota dans le portail Azure.

Déploiement

Une fois que vous avez terminé la planification de votre prédéploiement, il est temps de mettre votre plan en action. Au cours de cette étape, déployez Azure SQL en utilisant le portail Azure ou la ligne de commande, déterminez la configuration réseau et établissez une première connexion.

Pour Azure SQL Database et Azure SQL Managed Instance, il existe essentiellement six volets dans le portail Azure à renseigner pendant un déploiement.

Diagramme des volets de déploiement pour Azure SQL.

Serveur

Quand vous créez une instance d’Azure SQL Managed Instance, la spécification du nom du serveur est identique à celle de SQL Server. Pour les bases de données et les pools élastiques, un serveur Azure SQL Database est nécessaire. Un serveur Azure SQL Database est un serveur logique qui joue le rôle d’un point d’administration central pour une base de données unique ou en pool. Il comprend des connexions, des règles de pare-feu, des règles d’audit, des stratégies de détection des menaces et des groupes de basculement. Vous en saurez plus sur ces éléments après.

Ce serveur logique n’expose pas d’accès ou de fonctionnalités au niveau de l’instance, comme avec Azure SQL Managed Instance. Pour les serveurs Azure SQL Database, le nom du serveur doit être unique dans l’ensemble d’Azure.

Calcul et stockage

Dans le module précédent de ce parcours d’apprentissage, vous avez découvert les options disponibles et les recommandations en matière de calcul et de stockage, notamment les niveaux de service, les modèles d’achat et les générations de matériel. Vous devez sélectionner la configuration souhaitée durant le déploiement. Vous devez aussi déterminer le nombre de vCores et la Taille maximale des données.

En règle générale, si vous effectuez une migration, utilisez une taille similaire à celle que vous utilisez localement. Vous pouvez aussi utiliser des outils, comme l’outil de recommandation de références SKU de l’Assistant Migration de données, pour estimer le nombre de vCores et la Taille maximale des données en fonction de votre charge de travail actuelle.

La taille maximale des données n’est pas nécessairement la taille de vos données aujourd’hui. C’est la quantité maximale d’espace de données qui peut être allouée à votre base de données. Cela vous aide aussi à comprendre l’espace de journal alloué, qui s’adapte à la Taille maximale des données.

Configuration du réseau

Les options de mise en réseau pour Azure SQL Database et Azure SQL Managed Instance sont différentes. Quand vous déployez une instance Azure SQL Database, la valeur par défaut est Aucun accès.

Vous pouvez sélectionner un point de terminaison public ou privé. Dans l’exercice qui suit cette unité, utilisez le point de terminaison public et définissez l’option Autoriser les services et ressources Azure à accéder à ce serveur sur oui. D’autres services Azure, par exemple Azure Data Factory ou Machines virtuelles Azure, peuvent accéder à la base de données si vous la configurez. Vous pouvez aussi sélectionner Ajouter l’adresse IP du client actuel si vous voulez être en mesure de vous connecter à partir de l’adresse IP de l’ordinateur client que vous avez utilisé pour déployer Azure SQL Database.

Avec Azure SQL Managed Instance, vous déployez dans un réseau virtuel Azure et un sous-réseau dédié aux instances managées, ce qui vous permet d’avoir une adresse IP privée sécurisée. Azure SQL Managed Instance peut connecter un réseau local à une instance managée, connecter une instance managée à un serveur lié ou à un autre magasin de données local, et connecter une instance managée à d’autres ressources.

Vous pouvez aussi activer un point de terminaison public afin de pouvoir vous connecter à l’instance managée à partir d’Internet sans un réseau privé virtuel (VPN). Cet accès est désactivé par défaut.

Source de données

Dans Azure SQL Database, vous pouvez sélectionner la base de données AdventureWorksLT comme exemple lors du déploiement dans le portail Azure. Dans Azure SQL Managed Instance, vous déployez d’abord l’instance et ensuite les bases de données qu’elle contient. Vous ne pouvez pas avoir l’exemple de base de données avec le déploiement, comme SQL Server. Vous trouverez plus d’informations sur les exemples de bases de données AdventureWorks sur GitHub.

Vous pouvez aussi déployer une base de données vide ou créer une base de données basée sur la restauration d’une sauvegarde à partir d’une sauvegarde géorépliquée.

Classements de base de données

Dans SQL Server et Azure SQL, les classements indiquent au moteur de base de données comment traiter certains caractères et certaines langues. Un classement fournit les règles de tri, et les propriétés de respect de la casse et des accents pour vos données.

Quand vous créez une nouvelle base de données SQL ou une instance managée, prenez en compte les paramètres régionaux requis des données que vous utilisez. Le classement défini affecte les caractéristiques de nombreuses opérations dans la base de données. Dans le produit SQL Server tel qu’il est livré, les paramètres régionaux du système d’exploitation déterminent généralement le classement par défaut.

Dans Azure SQL Managed Instance, définissez le classement du serveur lors de la création de l’instance. Il ne peut pas être changé ultérieurement. Le classement du serveur définit la valeur par défaut pour toutes les bases de données dans cette instance d’Azure SQL Managed Instance, mais vous pouvez modifier les classements au niveau de la base de données et de la colonne.

Dans Azure SQL Database, vous ne pouvez pas définir le classement du serveur. Il est défini par défaut sur le classement SQL_Latin1_General_CP1_CI_AS, qui est le plus courant, mais vous pouvez définir le classement de la base de données. Pour diviser cette valeur en plusieurs parties :

  • SQL signifie qu’il s’agit d’un classement SQL Server, et non pas d’un classement Windows ou binaire.
  • Latin1_General spécifie l’alphabet ou la langue à utiliser lors du tri.
  • CP1 fait référence à la page de codes utilisée par le classement.
  • CI signifie qu’il ne respecte pas la casse. CS signifie qu’il respecte la casse.
  • AS signifie qu’il respecte les accents. AI signifie qu’il ne respecte pas les accents.

D’autres options sont disponibles. Par exemple, les largeurs de caractères et l’encodage UTF-8. Vous trouverez plus de détails sur ce que vous pouvez faire et ne pas faire avec Azure SQL dans la documentation.

Choisir d’utiliser Microsoft Defender pour le cloud

Quand vous déployez Azure SQL Database dans le portail Azure, il vous est demandé si vous voulez activer Microsoft Defender pour le cloud dans le cadre d’un essai gratuit. Cliquez sur Démarrer l’essai gratuit. Après l’essai gratuit, Microsoft Defender pour le cloud est facturé sur la base des tarifs du niveau Standard de Microsoft Defender pour le cloud.

Après l’avoir activé, vous bénéficiez des fonctionnalités liées à l’identification et à l’atténuation des vulnérabilités potentielles de la base de données, et à la détection des menaces. Découvrez plus en détail ces fonctionnalités dans le prochain module de ce parcours d’apprentissage sur la sécurité.

Dans Azure SQL Managed Instance, vous pouvez activer Microsoft Defender pour le cloud sur l’instance après le déploiement.

Examen des sélections

Dans le volet Vérifier et créer, passez en revue vos sélections pour le déploiement et les conditions de la Place de marché Azure.

Conseil

Vous disposez également de l’option Télécharger un modèle pour l’automatisation, qui fournit un modèle Azure Resource Manager (modèle ARM) pour des déploiements configurables et répétables. Cette unité ne couvre pas les modèles ARM. Si cela vous intéresse, découvrez-en plus sur les Specs de modèle.

Détails de l’implémentation de déploiement clé

Même si Azure prend en charge le déploiement pour vous, vous devez connaître certains détails sur l’implémentation du déploiement. Tous les services sont basés sur la dorsale Azure connue sous le nom de Azure Service Fabric. Comprendre les principes selon lesquels certains de ces services sont déployés et mis à l’échelle sur Azure Service Fabric vous aide à comprendre les différents comportements que vous risquez de voir.

Azure SQL Managed Instance

En arrière-plan, pour Azure SQL Managed Instance, Azure déploie un anneau dédié, parfois appelé cluster virtuel, pour votre service. Cette architecture permet de fournir une sécurité et une prise en charge native des réseaux virtuels.

En raison de cette architecture, les opérations de déploiement et de mise à l’échelle peuvent prendre plus de temps. Par exemple, lorsque vous augmentez ou diminuez la taille des clusters, Azure déploie un nouveau cluster virtuel pour vous, puis les amorce avec vos données. Vous pouvez considérer chaque instance comme étant en cours d’exécution sur une seule machine virtuelle.

Les pools d’instances Azure SQL ont été introduits pour réduire la durée des déploiements. Vous pouvez prédéployer un pool de ressources dédiées. Le déploiement dans un pool et la mise à l’échelle au sein d’un pool sont plus rapides que les déploiements traditionnels. Vous bénéficiez également d’une densité d’empaquetage supérieure, car vous pouvez déployer plusieurs instances dans une même machine virtuelle.

Azure SQL Database

Azure SQL Database est contenu dans un serveur de base de données logique. Dans la plupart des cas, une instance SQL Server dédiée héberge la base de données SQL, mais vous n’avez pas à vous soucier de la gestion de l’instance.

Le serveur de base de données logique vous permet de vous connecter à quelque chose. Il vous permet aussi de regrouper et de gérer ensemble certaines autorisations et configurations. Au sein de chaque serveur de base de données logique, il y a une base de données primaire logique, qui peut fournir des diagnostics au niveau de l’instance.

Azure SQL Database - Hyperscale

Le niveau Hyperscale dans Azure SQL Database, qui n’est pas disponible dans Azure SQL Managed Instance, a une architecture unique pour Azure SQL. L’équipe Azure SQL a créé une nouvelle architecture Hyperscale pour le cloud. Cette architecture comprend un système de mise en cache multicouche qui peut vous aider au niveau de la vitesse et de la mise à l’échelle. La mise à l’échelle et d’autres opérations ne sont dès lors plus liées à la taille des données et peuvent être effectuées dans un délai constant, en quelques minutes. L’utilisation du stockage étendu permet aussi les sauvegardes d’instantanés.

Dans un module ultérieur du parcours d’apprentissage sur les concepts de base d’Azure SQL, vous découvrirez l’architecture et comment elle affecte les performances et la disponibilité. Un élément à prendre en compte lors de la phase de déploiement est qu’une fois que vous avez déplacé une base de données vers le niveau Hyperscale, il n’est pas possible de revenir en arrière aux niveaux Usage général ou Critique pour l’entreprise.

Gouvernance des ressources

Quand vous augmentez ou que vous diminuez les ressources dans un niveau de service, les limites pour les dimensions, comme le processeur, le stockage et la mémoire, peuvent varier jusqu’à un certain point. Bien qu’il y ait plusieurs facettes dans l’approche de la gouvernance dans Azure SQL, les trois technologies principales suivantes sont utilisées pour gouverner l’utilisation des ressources dans Azure SQL :

  • Les objets de travail Windows permettent de gérer et de gouverner un groupe de processus comme un tout. Les objets de travail sont utilisés pour gouverner la validation de la mémoire virtuelle du fichier, les limites de la plage de travail, l’affinité du processeur et les limites de débit. Vous pouvez utiliser la vue de gestion dynamique sys.dm_os_job_object pour voir les limites en place.
  • Resource Governor est une fonctionnalité SQL Server qui aide les utilisateurs, Azure dans le cas présent, à gouverner les ressources telles que le processeur, les E/S physiques et la mémoire. Azure SQL Managed Instance autorise également les pools et les groupes de charges de travail définis par l’utilisateur pour Resource Governor.
  • Le Gestionnaire de ressources du serveur de fichiers est disponible dans Windows Server. Il régit les quotas de répertoires de fichiers, qui sont utilisés pour gérer la taille maximale des données.

D’autres implémentations pour gouverner le débit du journal des transactions sont intégrées au moteur de base de données pour Azure, à travers la gouvernance du débit du journal des transactions. Ce processus limite les débits d’ingestion élevés pour les charges de travail comme BULK INSERT, SELECT INTO et la création des index. Ils sont suivis et appliqués à un niveau inférieur à la seconde. Ils sont actuellement mis à l’échelle de façon linéaire dans un niveau de service.

Vérification

Une fois que vous avez terminé votre déploiement, il est temps de le vérifier. Dans cette étape, vous vérifiez généralement les résultats dans le portail Azure ou Azure CLI, vous exécutez des requêtes qui vérifient la configuration de votre déploiement et vous l’ajustez si nécessaire.

Pour Azure SQL Managed Instance et Azure SQL Database, la première chose que vous pouvez faire est de vérifier l’état de la base de données ou de l’instance avec le Portail Azure ou l’Azure CLI. Ensuite, vous pouvez consulter les détails du déploiement et le journal d’activité pour vous assurer qu’il n’y a aucun échec ou problème actif.

Pour Azure SQL Managed Instance, vous pouvez consulter le journal des erreurs, ce qui constitue une action courante dans SQL Server local ou dans une machine virtuelle Azure. Cette fonctionnalité n’est pas disponible dans Azure SQL Database.

Enfin, vous allez probablement vérifier que votre réseau est correctement configuré, obtenir le nom du serveur et vous connecter dans un outil comme SQL Server Management Studio ou Azure Data Studio. Vous pouvez exécuter les requêtes suivantes pour mieux comprendre ce que vous avez déployé et vérifier que cela a été correctement déployé :

SELECT @@VERSION
SELECT * FROM sys.databases
SELECT * FROM sys.objects
SELECT * FROM sys.dm_os_schedulers
SELECT * FROM sys.dm_os_sys_info
SELECT * FROM sys.dm_os_process_memory --Not supported in Azure SQL Database
SELECT * FROM sys.dm_exec_requests
SELECT SERVERPROPERTY('EngineEdition')
SELECT * FROM sys.dm_user_db_resource_governance -- Available only in Azure SQL Database and SQL Managed Instance
SELECT * FROM sys.dm_instance_resource_governance -- Available only in Azure SQL Managed Instance
SELECT * FROM sys.dm_os_job_object -- Available only in Azure SQL Database and SQL Managed Instance

Une requête liée à la mémoire de processus du système d’exploitation n’est pas prise en charge dans Azure SQL Database, même si elle peut sembler fonctionner. Cette requête n’est pas prise en charge car, avec Azure SQL Database, certains éléments liés au système d’exploitation vous sont épargnés pour vous permettre de vous concentrer sur la base de données.

Les trois dernières requêtes sont disponibles seulement dans Azure SQL Database et Azure SQL Managed Instance. La première, sys.dm_user_db_resource_governance, retourne les paramètres de configuration et de capacité utilisés par les mécanismes de gouvernance des ressources dans la base de données ou le pool élastique actuels. Vous pouvez obtenir des informations similaires pour Azure SQL Managed Instance avec la deuxième requête sys.dm_instance_resource_governance. La troisième, sys.dm_os_job_object, retourne une seule ligne décrivant la configuration de l’objet de travail qui gère le processus SQL Server ainsi que les statistiques de consommation des ressources.

Les deux exercices suivants explorent tous les détails liés au déploiement d’Azure SQL Database ou d’Azure SQL Managed Instance. Utilisez votre abonnement Azure pour déployer Azure SQL Database. Après le déploiement, vous allez utiliser différentes requêtes de vérification et préexécuter des notebooks SQL dans Azure Data Studio pour comparer SQL Database, SQL Managed Instance et SQL Server 2019.

Contrôle des connaissances

1.

Parmi les options suivantes, lesquelles ont des limites qui dépendent de votre option de déploiement et du niveau de service ?

2.

Pour la vérification des déploiements, de nouvelles requêtes sont spécifiques à Azure SQL Database et à Azure SQL Managed Instance. Lesquelles des requêtes suivantes sont disponibles seulement pour Azure SQL PaaS (platform as a service) ?