Haute disponibilité par niveau de service
Pour comprendre les options et les fonctionnalités de la disponibilité dans Azure SQL, vous devez comprendre les niveaux de service. Le niveau de service que vous sélectionnez va déterminer l’architecture sous-jacente de la base de données ou de l’instance gérée que vous déployez.
Deux modèles d’achat sont à prendre en compte : DTU et vCore. Cette unité se concentrera sur les niveaux de service vCore et leurs architectures pour la haute disponibilité. Les niveaux Standard et De base du modèle DTU sont équivalents au niveau Usage général et ses niveaux Premium sont équivalents au niveau Critique pour l’entreprise.
Usage général
Les bases de données et les instances gérées dans le niveau de service Usage général ont la même architecture de disponibilité. En utilisant la figure suivante comme guide, examinez d’abord l’application et l’anneau de contrôle. L’application se connecte au nom du serveur, qui se connecte ensuite à une passerelle (GW), qui dirige la connexion de l’application vers le serveur approprié, qui fonctionne sur une machine virtuelle. Avec le niveau « Usage général », le réplica principal utilise un disque SSD attaché localement pour la tempdb. Les fichiers de données et les fichiers journaux sont stockés dans le Stockage Premium Azure, qui est un stockage localement redondant (plusieurs copies dans une région). Les fichiers de sauvegarde sont ensuite stockés dans le Stockage Standard Azure, à savoir RA-GRS par défaut. « Stockage géo-redondant avec accès en lecture (RA-GRS) » est globalement redondant, avec des copies dans plusieurs régions.
Comme indiqué dans un module précédent du parcours d’apprentissage, Azure SQL repose entièrement sur Azure Service Fabric, qui sert de segment principal à Azure. Si Azure Service Fabric détermine qu’un basculement doit être effectué, le basculement sera similaire à celui d’une instance de cluster de basculement (FCI). Service Fabric recherche un nœud avec une capacité de rechange et lance une nouvelle instance SQL. Les fichiers de la base de données seront ensuite attachés, la récupération sera exécutée et les passerelles seront mises à jour pour diriger les applications vers le nouveau nœud. Aucun réseau virtuel, aucun écouteur ni aucune mise à jour n’est nécessaire. Cette capacité est intégrée.
Critique pour l’entreprise
Le niveau de service suivant à considérer est Critique pour l’entreprise, qui peut généralement atteindre les performances et la disponibilité les plus élevées de tous les niveaux de service d’Azure SQL (Usage général, Hyperscale, Critique pour l’entreprise). Critique pour l’entreprise est destiné aux applications stratégiques qui requièrent une faible latence et un temps d’arrêt minimal.
L’utilisation du niveau Critique pour l’entreprise est similaire au déploiement d’un groupe de disponibilité Always On en arrière-plan. Contrairement au niveau Usage général, les données et les fichiers journal dans Critiques pour l’entreprise sont tous exécutés sur un disque SSD à connexion directe, ce qui réduit considérablement la latence du réseau. (Usage général utilise le stockage distant.) Dans ce groupe de disponibilité, il existe trois réplicas secondaires. L’un d’entre eux peut être utilisé comme point de terminaison en lecture seule (sans frais supplémentaires). Une transaction peut effectuer une validation quand au moins l’un des réplicas secondaires a bien enregistré la modification pour son journal des transactions.
« Échelle lecture » avec l’une des réplicas secondaires prend en charge la cohérence au niveau de la session. Par conséquent, si la session en lecture seule se reconnecte après une erreur de connexion due à l’indisponibilité du réplica, elle peut être redirigée vers un réplica qui n’est pas à 100 % à jour par rapport au réplica en lecture-écriture. De même, si une application écrit des données à l’aide d’une session en lecture-écriture et les lit immédiatement à l’aide d’une session en lecture seule, les dernières mises à jour risquent de ne pas être immédiatement visibles sur le réplica. La latence est due à une opération de phase de restauration par progression asynchrone du journal des transactions.
Si un type de défaillance survient et que la structure de service détermine qu’un basculement est nécessaire, le basculement vers un réplica secondaire est rapide car celui-ci existe déjà et possède les données qui lui sont attachées. Dans un basculement, vous n’avez pas besoin d’un écouteur. La passerelle redirige votre connexion vers la passerelle primaire, même après un basculement. Ce passage s’effectue rapidement, puis la structure Fabric Service se charge de mettre en place un autre réplica secondaire.
Hyperscale
Le niveau de service Hyperscale est uniquement disponible dans Azure SQL Database. Ce niveau de service a une architecture unique, car il utilise une couche hiérarchisée de caches et de serveurs de pages pour étendre la capacité à accéder rapidement aux pages de base de données sans avoir à accéder directement au fichier de données.
Étant donné que cette architecture utilise des serveurs de pages appairés, vous avez la possibilité d’effectuer une mise à l’échelle horizontale pour placer toutes les données dans des couches de mise en cache. Cette nouvelle architecture permet également à Hyperscale de prendre en charge des bases de données d’une taille allant jusqu’à 100 To. Étant donné qu’elle utilise des instantanés, des sauvegardes de bases de données quasi instantanées peuvent avoir lieu quelle que soit la taille. Les restaurations de bases de données prennent quelques minutes, plutôt que quelques heures ou jours. Vous pouvez également effectuer un scale-up ou un scale-down en temps constant pour adapter le système à vos charges de travail.
Il est intéressant de noter le mode de retrait du service d’enregistrement dans cette architecture. Le service d’enregistrement est utilisé pour alimenter les réplicas ainsi que les serveurs de pages. Les transactions peuvent être validées lorsque le service de journalisation est renforcé dans la zone d’atterrissage, de sorte que la consommation des modifications par un réplica de calcul secondaire n’est pas nécessaire pour une validation. Contrairement à d’autres niveaux de service, vous pouvez déterminer si vous souhaitez des réplicas secondaires. Vous pouvez configurer entre zéro et quatre répliques secondaires, que vous pouvez toutes utiliser pour l’échelle de lecture.
Comme pour les autres niveaux de service, un basculement automatique se produira si Service Fabric détermine que cela est nécessaire, mais le temps de récupération dépend de l’existence de réplicas secondaires. Par exemple, si vous n’avez pas de réplicas et qu’un basculement se produit, le scénario sera similaire à celui du niveau de service Usage général : Service Fabric a tout d’abord besoin de rechercher la capacité de rechange. Si vous avez un ou plusieurs réplicas, la récupération est plus rapide et s’aligne à celle du niveau de service Critique pour l’entreprise.
« Business Critical » maintient les performances et la disponibilité les plus élevées pour les charges de travail avec de faibles écritures de journaux qui nécessitent une faible latence, mais le niveau de service Hyperscale vous permet d’obtenir un débit de journaux plus élevé en termes de Mo/seconde. Ce niveau de service prend en charge les bases de données les plus volumineuses et fournit jusqu’à quatre réplicas secondaires pour des niveaux plus élevés d’échelle de lecture. Vous devrez donc tenir compte de votre charge de travail lorsque vous choisirez l’un ou l’autre.