Aller plus loin avec la disponibilité
Azure SQL Database et Azure SQL Managed Instance fournissent par défaut des options de disponibilité performantes dans les différents niveaux de service. Vous pouvez effectuer différentes autres choses pour augmenter ou modifier la disponibilité de vos bases de données/instances. Vous pourrez constater directement l’impact sur le contrat de niveau de service (SLA). Dans cette unité, vous allez voir comment vous pouvez aller plus loin avec différentes options de disponibilité dans Azure SQL.
Zones de disponibilité
Dans le niveau Critique pour l’entreprise dans Azure SQL Database, vous pouvez choisir (sans frais supplémentaires) une configuration redondante interzone si votre région la prend en charge. Globalement, le groupe de disponibilité Always On qui s’exécute derrière les bases de données et les instances gérées de niveau Critique pour l’entreprise est déployé dans trois Zones de disponibilité au sein d’une région. Une Zone de disponibilité est fondamentalement un centre de données distinct au sein d’une région donnée. Il y a toujours une séparation physique entre les Zones de disponibilité. Cette capacité protège contre les défaillances catastrophiques qui peuvent se produire dans une région pour un centre de données.
Du point de vue des performances, il peut y avoir une légère augmentation de la latence du réseau, car votre groupe de disponibilité est alors réparti entre des centres de données à une certaine distance les uns des autres. Pour cette raison, Zones de disponibilité n’est pas activée par défaut. Vous pouvez choisir d’utiliser ce qui est communément appelé déploiement « Plusieurs zones de disponibilité » ou « Une seule zone de disponibilité ». La configuration de cette option est aussi simple que d’ajouter un paramètre à une commande PowerShell/Azure CLI ou de cocher une case dans le portail Azure.
Les Zones de disponibilité étant relativement nouvelles dans Azure SQL, elles sont actuellement disponibles seulement dans certaines régions et pour certains niveaux de service. Au fil du temps, cette capacité va probablement être prise en charge dans davantage de régions et plus de niveaux de service. Par exemple, le niveau usage général pour Azure SQL Database a récemment publié un aperçu pour le déploiement de plusieurs AZ.
Contrat SLA pour Azure SQL
Azure SQL fait l’objet d’un contrat de niveau de service (SLA), qui fournit une garantie financière quant à l’engagement d’atteindre et de maintenir des niveaux de service. Si votre niveau de service n’est pas atteint et maintenu comme décrit dans le contrat SLA, vous pouvez bénéficier d’un crédit pour une partie de vos frais mensuels pour le service.
Actuellement, la plus haute disponibilité (99,995 %) peut être atteinte pour un déploiement du niveau Critique pour l'entreprise Azure SQL Database avec des zones de disponibilité configurées. De plus, le niveau Critique pour l’entreprise est la seule option sur le marché qui fournit des contrats SLA pour un RPO et un RTO de 5 à 30 secondes, respectivement.
- RPO signifie objet du point de récupération. Il représente la quantité de données que vous êtes susceptible de perdre dans le pire des cas.
- RTO signifie objectif de délai de récupération. Elle représente le temps nécessaire à la sauvegarde et à l’exécution de nouveau en cas de sinistre.
Pour les déploiements à usage général ou critiques pour l’entreprise monozones d’Azure SQL Database ou d’Azure SQL Managed Instance, le contrat SLA est de 99,99 %.
Le SLA du niveau Hyperscale dépend du nombre de réplicas. N’oubliez pas que vous choisissez le nombre de réplicas que vous avez dans le niveau Hyperscale. Si vous n’en avez pas, le comportement de basculement est plus semblable à celui du niveau Usage général. Si vous disposez de réplicas, un comportement de basculement est davantage similaire au niveau Critique pour l’entreprise. Voici les contrats SLA basés sur le nombre de réplicas :
- 0 réplica : 99,5 %
- 1 réplica : 99,9 %
- 2 réplicas ou plus : 99,99 %
Géoréplication et groupes de basculement automatique
En dehors de la sélection du niveau de service (et des Zones de disponibilité là où elles sont applicables), il existe d’autres options pour obtenir une échelle lecture ou la possibilité de basculer vers une autre région : la géoréplication et les groupes de basculement automatique. Dans SQL Server local, la configuration de l’une ou l’autre de ces options est une opération qui nécessite beaucoup de planification, de coordination et de temps.
Le cloud, et en particulier Azure SQL, a simplifié ce processus. Vous pouvez configurer la géoréplication et les groupes de basculement automatique en quelques clics dans le Portail Azure ou en quelques commandes dans PowerShell/Azure CLI.
Les considérations suivantes visent à vous aider à décider si la géoréplication ou les groupes de basculement automatique sont les mieux adaptés à votre scénario :
| Fonctionnalités | Géoréplication | Groupes de basculement |
|---|---|---|
| Basculement automatique | Non | Oui |
| Basculement simultanément de plusieurs bases de données | Non | Oui |
| L'utilisateur doit mettre à jour la chaîne de connexion après le basculement | Oui | Non |
| Prise en charge de SQL Managed Instance | Non | Oui |
| Peut être dans la même région que l’élément principal | Oui | Non |
| Réplicas multiples | Oui | Non |
| Prise en charge de l’échelle lecture | Oui | Oui |