Expliquer les options PaaS pour le déploiement de SQL Server dans Azure

Platform as a Service (PaaS) fournit un environnement de développement et de déploiement complet dans le cloud, qui peut être utilisé pour les applications simples basées sur le cloud et pour les applications d’entreprise avancées.

Azure SQL Database et Azure SQL Managed Instance font partie de l’offre PaaS pour Azure SQL.

• Azure SQL Database – Partie d’une famille de produits basés sur le moteur SQL Server, dans le cloud. Il offre aux développeurs une grande flexibilité dans la création de nouveaux services d’application et des options de déploiement granulaires à grande échelle. SQL Database offre une solution nécessitant peu de maintenance qui peut être une option intéressante pour certaines charges de travail.

• Azure SQL Managed Instance : Il est préférable pour la plupart des scénarios de migration vers le cloud, car il fournit des services et des fonctionnalités entièrement managés.

Chaque offre fournit un certain niveau d’administration que vous avez sur l’infrastructure, selon le degré d’efficacité des coûts.

Modèles de déploiement

Azure SQL Database est disponible dans deux modèles de déploiement différents :

• Base de données unique : Base de données unique facturée et gérée au niveau de chaque base de données. Vous gérez chacune de vos bases de données individuellement du point de vue de la mise à l’échelle et de la taille des données. Chaque base de données déployée dans ce modèle a ses propres ressources dédiées, même si elle est déployée sur le même serveur logique.

• Pools élastiques : Groupe de bases de données gérées ensemble et partagent un ensemble commun de ressources. Les pools élastiques fournissent une solution économique pour le modèle d’application software as a service, car les ressources sont partagées entre toutes les bases de données. Vous pouvez configurer des ressources en fonction du modèle d’achat DTU ou du modèle d’achat vCore.

Modèle d’achat

Dans Azure, tous les services prennent en charge le matériel physique et vous avez la possibilité de choisir entre deux modèles d’achat différents :

Unité de transaction de base de données (DTU)

Le modèle d’achat DTU est calculé en fonction d’une formule combinant les ressources de calcul, de stockage et d’E/S. C’est un bon choix pour les clients qui souhaitent des options de ressources simples et préconfigurées.

Le modèle d’achat DTU est fourni dans plusieurs niveaux de service différents, tels que De base, Standard et Premium. Chaque niveau a des fonctionnalités variables, offrant un large éventail d’options lors du choix de cette plateforme.

En termes de performances, le niveau De base est utilisé pour les charges de travail moins exigeantes, tandis que le niveau Premium est utilisé pour les exigences de charge de travail intensives.

Les ressources de calcul et de stockage dépendent du niveau DTU et fournissent une gamme de fonctionnalités de performances à une limite de stockage fixe, à la rétention des sauvegardes et au coût.

Pour plus d’informations sur le modèle d’achat DTU, consultez la vue d’ensemble du modèle d’achat DTU.

vCore

Le modèle d’achat vCore vous permet d’acheter un nombre spécifié de vCores en fonction de vos charges de travail données. vCore est le modèle d’achat par défaut lors de l’achat de ressources Azure SQL Database. Les bases de données vCore ont une relation spécifique entre le nombre de cœurs et la quantité de mémoire et de stockage fournie à la base de données. Le modèle d’achat vCore est pris en charge par Azure SQL Database et Azure SQL Managed Instance.

Vous pouvez également acheter des bases de données vCore dans trois niveaux de service différents :

Le niveau de service Usage général offre deux options de calcul : provisionnée et serverless. Les ressources approvisionnées sont préallouées et facturées toutes les heures en fonction des vCores configurés, idéals pour les charges de travail cohérentes. Les ressources serverless sont automatiquement mises à l’échelle en fonction de la demande et sont facturées par seconde, ce qui rend économique les charges de travail variables.

Sans serveur

Le terme « Serverless » peut être trompeur, car vous déployez toujours votre base de données Azure SQL sur un serveur logique pour la connexion. Serverless est un niveau de calcul qui met automatiquement à l’échelle les ressources en fonction de la demande de charge de travail. Lorsque la charge de travail ne nécessite plus de ressources de calcul, la base de données est suspendue et seul le stockage est facturé pendant la période inactive. Lors d’une tentative de connexion, la base de données reprend et devient disponible.

Le paramètre permettant de contrôler la suspension est appelé délai depause automatique, avec une valeur minimale de 60 minutes et une valeur maximale de sept jours. Si la base de données reste inactive pendant cette durée, elle s’interrompt.

Une fois la base de données inactive pendant l’heure spécifiée, elle s’interrompt jusqu’à une tentative de connexion ultérieure. La configuration d’une plage de mise à l’échelle automatique de calcul et d’un délai de mise à l’échelle automatique affecte les performances de la base de données et les coûts de calcul.

Les applications utilisant serverless doivent être configurées pour gérer les erreurs de connexion et inclure une logique de nouvelle tentative, car la connexion à une base de données suspendue génère une erreur de connexion.

Une autre différence entre le modèle vCore serverless et le modèle vCore standard d’Azure SQL Database est qu’avec serverless, vous pouvez spécifier un nombre minimal et maximal de vCores. Les limites de mémoire et d’E/S sont proportionnelles à la plage spécifiée.

L’image montre l’écran de configuration d’une base de données serverless dans le portail Azure. Vous avez la possibilité de sélectionner un minimum aussi bas que la moitié d’un vCore et un maximum aussi élevé que 16 vCores.

Serverless n’est pas entièrement compatible avec toutes les fonctionnalités d’Azure SQL Database, car certains d’entre eux nécessitent des processus en arrière-plan pour s’exécuter constamment, tels que :

• Géoréplication
• Rétention des sauvegardes à long terme
• Une base de données de travaux dans des travaux élastiques
• La base de données de synchronisation dans SQL Data Sync (Data Sync est un service qui réplique les données entre un groupe de bases de données)

Sauvegardes

L’une des fonctionnalités les plus importantes de l’offre Platform as a Service est les sauvegardes. Dans ce cas, le système effectue automatiquement des sauvegardes sans intervention de vous. Le stockage géoredondant Azure stocke ces sauvegardes et, par défaut, les conserve pendant entre 7 et 35 jours, en fonction du niveau de service de la base de données. Les bases de données de base et vCore sont par défaut de sept jours de rétention, et les administrateurs peuvent ajuster cette valeur pour les bases de données vCore. Vous pouvez prolonger le temps de rétention en configurant la conservation à long terme (LTR), ce qui vous permet de conserver les sauvegardes pendant jusqu’à 10 ans.

Pour fournir une redondance, vous pouvez également utiliser le stockage d’objets blob géoredondants accessible en lecture. Ce stockage réplique vos sauvegardes de base de données dans une région secondaire de votre préférence. Il vous permet également de lire à partir de cette région secondaire si nécessaire. Les sauvegardes manuelles des bases de données ne sont pas prises en charge et la plateforme refuse toute demande.

Les sauvegardes de base de données sont effectuées selon une planification donnée :

• Complète – Une fois par semaine
• Différentielle – Toutes les 12 heures
• Rapport– Toutes les 5 à 10 minutes en fonction de l’activité du journal des transactions

Cette planification de sauvegarde doit répondre aux besoins de la plupart des objectifs de point de récupération/temps (RPO/RTO), cependant, chaque client doit évaluer s’il répond aux besoins de votre entreprise.

Il existe plusieurs options disponibles pour la restauration d’une base de données. En raison de la nature de Platform as a Service, vous ne pouvez pas restaurer manuellement une base de données à l’aide de méthodes conventionnelles, telles que l’émission de la commande RESTORE DATABASET-SQL.

Quelle que soit la méthode de restauration implémentée, il n’est pas possible de restaurer sur une base de données existante. Si une base de données doit être restaurée, la base de données existante doit être supprimée ou renommée avant de lancer le processus de restauration. En outre, gardez à l’esprit que, selon le niveau de service de plateforme, les temps de restauration ne sont pas garantis et peuvent varier. Il est recommandé de tester le processus de restauration pour obtenir une métrique de référence sur la durée pendant laquelle une restauration peut prendre.

• Restaurer à l’aide du portail Azure : À l’aide du portail Azure, vous avez la possibilité de restaurer une base de données sur le même serveur logique pour Azure SQL Database, ou vous pouvez utiliser la restauration pour créer une base de données sur un nouveau serveur dans n’importe quelle région Azure.

• Restaurer à l’aide de langages de script : PowerShell et Azure CLI peuvent être utilisés pour restaurer une base de données.

Pour plus d’informations sur les sauvegardes automatisées, consultez Sauvegardes automatisées - Azure SQL Database et Azure SQL Managed Instance.

Géoréplication active

La géoréplication est une fonctionnalité de continuité d’activité qui réplique de façon asynchrone une base de données vers jusqu’à quatre réplicas secondaires. À mesure que les transactions sont validées sur le réplica principal (et ses réplicas dans la même région), les transactions sont envoyées aux serveurs secondaires à relire. Étant donné que cette communication est effectuée de façon asynchrone, l’application appelante n’a pas besoin d’attendre que le réplica secondaire valide la transaction avant que SQL Server ne retourne le contrôle à l’appelant.

Les bases de données secondaires sont lisibles et peuvent être utilisées pour décharger les charges de travail en lecture seule, ce qui libère des ressources pour les charges de travail transactionnelles sur le serveur principal ou place les données plus proches de vos utilisateurs finaux. En outre, les bases de données secondaires peuvent se trouver dans la même région que la région primaire ou dans une autre région Azure

Vous pouvez lancer un basculement manuellement par l’utilisateur ou par programme par l’application. Si un basculement se produit, vous pouvez mettre à jour les chaînes de connexion d’application pour refléter le nouveau point de terminaison de la base de données primaire.

Groupes de basculement

Les groupes de basculement sont basés sur la technologie utilisée dans la géoréplication, mais fournissent un point de terminaison unique pour la connexion. La principale raison d’utiliser des groupes de basculement est qu’ils fournissent des points de terminaison qui peuvent être utilisés pour router le trafic vers le réplica approprié. Votre application peut ensuite se connecter après un basculement sans modification de chaîne de connexion.