Expliquer les options de déploiement
Azure SQL Database est une plateforme PaaS (platform as a service) offrant une scalabilité élevée avec une maintenance minimale, ce qui en fait une excellente solution pour des charges de travail spécifiques. Adaptée au développement de nouvelles applications, elle offre aux développeurs une grande flexibilité dans la création de services et propose des options de déploiement granulaires à grande échelle. Cette solution à faible maintenance est idéale pour diverses charges de travail, assurant un développement d’applications efficace et optimisé.
Comprendre les modèles de déploiement
Lors du déploiement d’Azure SQL Database, vous avez le choix entre deux modèles de déploiement principaux : base de données unique et pools élastiques. Dans le modèle de pools élastiques, les ressources sont partagées entre plusieurs bases de données au sein du même pool, tandis que dans le modèle de base de données unique, les ressources sont gérées indépendamment pour chaque base de données.
Comme pour les machines virtuelles, vous pouvez déployer SQL Database en utilisant différentes méthodes, notamment PowerShell, Azure CLI ou le Portail Azure.
Base de données unique
Le modèle de déploiement de base de données unique constitue le moyen le plus simple d’utiliser Azure SQL Database. Dans ce modèle, vous gérez chaque base de données individuellement en termes de mise à l’échelle et de taille de données. Chaque base de données a ses propres ressources dédiées, même si plusieurs bases de données sont déployées sur le même serveur logique.
Vous pouvez surveiller l’utilisation des ressources de chaque base de données par le biais du Portail Azure. Cette fonctionnalité vous permet de suivre et d’évaluer facilement les performances de vos bases de données.
Pools élastiques
Les pools élastiques vous permettent d’allouer des ressources de stockage et de calcul à un groupe de bases de données, simplifiant ainsi la gestion puisque vous n’avez pas besoin de gérer individuellement chaque base de données. Ils sont plus faciles à mettre à l’échelle que les bases de données uniques, car les modifications apportées au pool élastique ajustent automatiquement les ressources pour toutes les bases de données incluses.
Ce modèle est économique pour les applications SaaS (software as a service), car les ressources sont partagées entre toutes les bases de données. Vous pouvez configurer les ressources à l’aide du modèle d’achat DTU ou vCore.
Il est important de surveiller en permanence les ressources pour identifier les pics de performances susceptibles d’affecter d’autres bases de données dans le pool. Révisez régulièrement votre stratégie d’allocation afin de garantir des ressources suffisantes pour toutes les bases de données.
Les pools élastiques conviennent parfaitement aux architectures multilocataires avec une faible utilisation moyenne, où chaque locataire a sa propre copie de la base de données.
Comprendre les modèles d’achat
Une fois que vous avez choisi le modèle de déploiement approprié pour votre base de données SQL, l’étape suivante consiste à sélectionner le modèle d’achat qui correspond le mieux à vos exigences en matière de charge de travail et de budget. Azure SQL Database propose deux modèles d’achat : le modèle vCore et le modèle DTU. Chaque modèle présente des avantages. Il est donc important de comprendre lequel correspond le mieux à vos exigences en matière de charge de travail et à vos considérations de coût.
Modèle vCore
Dans ce modèle d’achat, qui est celui que nous recommandons, les ressources de calcul et de stockage sont découplées. Cela signifie que vous pouvez mettre à l’échelle les ressources de stockage et de calcul indépendamment les unes des autres. Cette flexibilité vous permet d’ajuster les ressources en fonction de vos besoins spécifiques sans affecter d’autres composants.
Dans le modèle d’achat vCore, vos coûts dépendent de plusieurs facteurs : niveau de service, configuration matérielle, nombre de vCores et quantité de mémoire, stockage de base de données réservé, stockage de sauvegarde réel, etc.
Remarque
Pour plus d’informations sur les tarifs, voir la page des tarifs Azure SQL Database.
Un niveau de service est une configuration prédéfinie qui détermine le niveau de performance, le type de stockage, la haute disponibilité, les options de récupération d’urgence et la disponibilité de certaines fonctionnalités pour votre base de données.
Le modèle d’achat vCore propose trois options de niveau de service :
| Niveau de service | Fonctionnalité |
|---|---|
| Usage général | Ce niveau de service est conçu pour les opérations moins intensives et offre une sélection équilibrée et économique d’options de calcul et de stockage. Il inclut à la fois les niveaux de calcul approvisionnés et serverless, offrant ainsi la flexibilité nécessaire pour répondre aux demandes de charge de travail variables tout en optimisant le budget. |
| Critique pour l’entreprise | Ce niveau est idéal pour les applications qui nécessitent un stockage à faible latence et haute performance. Il prend en charge OLTP en mémoire et inclut un réplica en lecture seule intégré. Il offre également plus de mémoire par cœur et utilise un stockage SSD local, ce qui le rend idéal pour les charges de travail sensibles aux performances. |
| Hyperscale | Ce niveau est adapté aux applications avec des bases de données volumineuses et des exigences élevées en matière de débit. Hyperscale introduit des fonctionnalités avancées de mise à l’échelle horizontale qui permettent d’ajouter des nœuds de calcul à mesure que la taille des données augmente. Il est exclusivement pris en charge sur des bases de données SQL uniques et permet une mise à l’échelle significative des ressources de stockage et de calcul, au-delà des limites des niveaux de service Usage général et Critique pour l’entreprise. |
Modèle DTU
Le modèle DTU comprend trois niveaux de service : Essentiel, Standard et Premium. Les ressources de calcul et de stockage dépendent du niveau DTU, offrant une gamme de fonctionnalités de performance avec des limites de stockage, une rétention de sauvegarde et des coûts fixes.
Par exemple, si votre base de données atteint sa limite de stockage maximale, vous devez augmenter votre capacité de DTU, même si l’utilisation du calcul est faible. Par ailleurs, les opérations de mise à l’échelle sur Azure SQL Database peuvent provoquer de brèves interruptions de connexion à la fin du processus. Ce problème peut se produire dans deux principaux scénarios :
- Lancement d’une opération de mise à l’échelle qui nécessite un basculement interne.
- Ajout ou suppression de bases de données dans le pool élastique.
Remarque
Pour gérer les erreurs de connexion, implémentez une logique de nouvelle tentative appropriée dans votre application.
Il est essentiel de comprendre l’interaction entre les modèles de déploiement et d’achat pour optimiser le niveau de performance et la rentabilité. En choisissant soigneusement la bonne combinaison, vous pouvez vous assurer que votre déploiement Azure SQL Database répond aux demandes de votre application tout en respectant le budget.
Par exemple, si vous optez pour le modèle de déploiement de base de données unique, vous préférerez peut-être le modèle d’achat vCore pour sa flexibilité dans la mise à l’échelle indépendante des ressources de calcul et de stockage. En revanche, si vous choisissez le modèle de déploiement de pool élastique, le modèle d’achat DTU peut être plus économique puisqu’il vous permet de partager des ressources entre plusieurs bases de données au sein du pool.
Effectuer une sauvegarde et une restauration
Azure offre des fonctionnalités de sauvegarde et de restauration transparentes pour SQL Database. Voici quelques fonctionnalités clés :
Sauvegarde continue
Azure SQL Database garantit des sauvegardes régulières, en les copiant en continu dans un stockage géo-redondant avec accès en lecture (RA-GRS). Les sauvegardes complètes sont effectuées chaque semaine, les sauvegardes différentielles toutes les 12 à 24 heures, et les sauvegardes du journal des transactions toutes les 5 à 10 minutes.
La géo-restauration
Avec les sauvegardes géo-redondantes par défaut, vous pouvez facilement restaurer les bases de données dans différentes régions, ce qui est utile dans les scénarios de récupération d’urgence moins stricts. Le stockage de sauvegarde est facturé séparément, mais il est créé sans coût supplémentaire avec la taille maximale du niveau de données sélectionné. La durée de la géo-restauration dépend de la taille de la base de données, des journaux des transactions et des demandes de restauration simultanées.
Remarque
La géorestauration est disponible quand la propriété de redondance du stockage de sauvegarde a la valeur stockage de sauvegarde géoredondant.
Restauration à un instant dans le passé (PITR)
Vous permet de configurer une stratégie de rétention à un instant dans le passé spécifique pour chaque base de données, allant de 1 à 35 jours (la valeur par défaut est de sept jours). Vous pouvez également restaurer des bases de données à un instant dans le passé spécifique au sein du même serveur à l’aide du Portail Azure, de PowerShell, de l’interface CLI ou de l’API REST.
Conservation à long terme (LTR)
La rétention à long terme est utile pour les scénarios qui nécessitent la définition de la stratégie de conservation au-delà de ce qui est offert par Azure. Vous pouvez définir une stratégie de conservation jusqu’à 10 ans, et cette option est désactivée par défaut.
Pour plus d’informations sur les sauvegardes automatisées, consultez Sauvegardes automatisées - Azure SQL Database et Azure SQL Managed Instance.
Activer le réglage automatique
Le réglage automatique est une fonctionnalité intégrée puissante qui applique le Machine Learning pour optimiser les performances de vos requêtes. Il identifie automatiquement les opportunités de réglage et les implémente pour améliorer l’efficacité de votre base de données.
Le réglage automatique comprend actuellement les fonctionnalités suivantes :
- Identification des requêtes coûteuses
- Forçage du dernier plan d’exécution correct
- Ajout d’index
- Suppression d’index
Les services Azure utilisent des algorithmes avancés pour déterminer les meilleurs index pour vos motifs de requête. Ces index sont initialement testés sur une copie de votre base de données avant d’être appliqués à l’environnement en direct, garantissant ainsi une interruption minimale.
Toutes les bases de données héritent de la configuration du serveur parent, et vous pouvez facilement désactiver cette fonctionnalité si nécessaire. Cette flexibilité permet aux développeurs de garder le contrôle tout en bénéficiant d’améliorations automatisées des performances.
Utiliser la requête élastique
La requête élastique vous permet d’exécuter des requêtes T-SQL sur plusieurs bases de données dans SQL Database. Cette fonctionnalité est utile pour les applications utilisant des noms en trois et quatre parties qui ne peuvent pas être modifiés et améliore la portabilité en facilitant la migration.
Les requêtes élastiques prennent en charge les scénarios de partitionnement suivants :
| Niveau de service | Fonctionnalité |
|---|---|
| Partitionnement vertical | Également appelé « requêtes de bases de données croisées ». Les données sont partitionnées verticalement sur plusieurs bases de données avec des schémas différents. Par exemple, vous pouvez avoir une base de données pour les données client et une autre pour les informations de paiement. Le partitionnement vertical vous permet d’exécuter des requêtes entre ces bases de données. |
| Partitionnement horizontal | Également appelé « partitionnement » (« sharding » en anglais). Les données sont partitionnées horizontalement pour répartir les lignes sur plusieurs bases de données ayant fait l’objet d’un scale-out et partageant toutes le même schéma. Cette topologie prend en charge les modèles monolocataires et multilocataires. |
Cette flexibilité fait des requêtes élastiques un outil puissant pour la gestion et l’interrogation des données sur plusieurs bases de données.
Configurer des travaux élastiques
La fonctionnalité de tâche élastique remplace SQL Server Agent pour Azure SQL Database, à l’instar de la fonction d’administration multiserveur dans une instance SQL Server locale.
Avec les tâches élastiques, vous pouvez exécuter des commandes T-SQL sur divers déploiements cibles, notamment des bases de données SQL Database, des pools élastiques SQL Database et des bases de données SQL Database dans des cartes de partitions. Ces ressources de base de données peuvent s’étendre à différents abonnements et régions Azure. La fonctionnalité d’exécution parallèle est utile pour automatiser les tâches de maintenance de base de données, garantissant ainsi l’efficacité et la cohérence de vos déploiements.
Déplacer des données à l’aide de SQL Data Sync
SQL Data Sync permet une synchronisation incrémentielle des données sur plusieurs bases de données, qu’elles s’exécutent sur SQL Database ou sur un serveur SQL Server local. Cette fonctionnalité est utile pour décharger les charges de travail de production intensives vers une base de données distincte pour des opérations analytiques ou non planifiées.
SQL Data Sync repose sur une topologie de hub, où une base de données du groupe de synchronisation est désignée comme hub. Le groupe de synchronisation peut inclure plusieurs bases de données membres, et la synchronisation se produit entre le hub et les bases de données membres individuelles. Les modifications sont suivies à l’aide de déclencheurs d’insertion, de mise à jour et de suppression via une table historique créée sur la base de données utilisateur.
Lors de la création d’un groupe de synchronisation, vous devez spécifier une base de données pour y stocker les métadonnées du groupe de synchronisation. Cette base de données de métadonnées peut être nouvelle ou existante, mais elle doit résider dans la même région que votre groupe de synchronisation.
Pour plus d’informations sur la configuration de SQL Data Sync, consultez Tutoriel : Configurer SQL Data Sync entre des bases de données dans Azure SQL Database et SQL Server.