Explorer une solution de haute disponibilité et de reprise d’activité IaaS
Les combinaisons de fonctionnalités que vous pouvez déployer dans Azure pour IaaS sont nombreuses. Cette section aborde cinq exemples courants d’architectures SQL Server HADR (haute disponibilité et reprise d’activité) dans Azure.
Haute disponibilité dans une seule région (Exemple 1) - Groupes de disponibilité Always On
Si vous avez uniquement besoin de haute disponibilité (sans reprise d’activité), l’une des méthodes les plus répandues, quel que soit l’endroit où vous utilisez SQL Server, consiste à configurer un groupe de disponibilité. L’image ci-dessous montre un exemple de groupe de disponibilité dans une seule région.
Pourquoi cette architecture est-elle intéressante ?
Cette architecture protège les données en les copiant sur des machines virtuelles différentes.
Elle vous permet de respecter l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO) avec une perte de données minimale, voire nulle, si vous l’implémentez correctement.
Cette architecture fournit une méthode simple et standardisée permettant aux applications d’accéder à la fois aux réplicas principaux et aux réplicas secondaires (si des réplicas en lecture seule sont utilisés).
Elle améliore la disponibilité durant les scénarios de mise à jour corrective.
Cette architecture ne nécessitant aucun stockage partagé, elle entraîne moins de complications qu’une instance de cluster de basculement (FCI).
Haute disponibilité dans une seule région (Exemple 2) - Instance de cluster de basculement Always On
Avant l’introduction des groupes de disponibilité, les FCI étaient le moyen le plus populaire d’implémenter la haute disponibilité dans SQL Server. Toutefois, les FCI ont été conçues quand les déploiements physiques étaient dominants. Dans un monde virtualisé, les FCI n’offrent pas les mêmes protections que sur le matériel physique, car il est rare qu’une VM ait un problème. Les FCI ont été conçues pour offrir une protection contre les défaillances de carte réseau ou de disque, deux problèmes peu susceptibles de se produire dans Azure.
Cela dit, les FCI ont leur place dans Azure. Elles remplissent leur fonction, et tant que vous connaissez leurs capacités et leurs limitations, elles constituent une solution parfaitement acceptable. L’image ci-dessous, tirée de la documentation Microsoft, montre une vue d’ensemble d’un déploiement de FCI avec des espaces de stockage direct.
Pourquoi cette architecture est-elle intéressante ?
Les FCI demeurent une solution de disponibilité populaire.
Le stockage partagé s’améliore avec des fonctionnalités telles que le disque partagé Azure.
Cette architecture répond à la plupart des RTO et RPO pour la haute disponibilité (bien que la reprise d’activité ne soit pas gérée).
Cette architecture fournit une méthode simple et standardisée permettant aux applications d’accéder à l’instance en cluster de SQL Server.
Elle améliore la disponibilité durant les scénarios de mise à jour corrective.
Reprise d’activité (Exemple 1) - Groupe de disponibilité Always On multirégion ou hybride
Si vous utilisez des groupes de disponibilité, une option consiste à configurer le groupe de disponibilité sur plusieurs régions Azure ou éventuellement en tant qu’architecture hybride. Tous les nœuds qui contiennent les réplicas participent donc au même WSFC. Cela suppose une bonne connectivité réseau, en particulier dans le cas d’une configuration hybride. L’une des principales considérations à prendre en compte est la ressource témoin pour le WSFC. Cette architecture nécessite que les services AD DS et DNS soient disponibles dans chaque région et potentiellement au niveau local dans le cas d’une solution hybride. L’image ci-dessous montre un groupe de disponibilité unique configuré sur deux emplacements avec Windows Server.
Pourquoi cette architecture est-elle intéressante ?
Cette architecture est une solution qui a fait ses preuves. Elle équivaut aujourd’hui à avoir deux centres de données dans une topologie de groupe de disponibilité.
Cette architecture fonctionne avec les éditions Standard et Entreprise de SQL Server.
Les groupes de disponibilité assurent naturellement la redondance avec des copies supplémentaires des données.
Cette architecture utilise une fonctionnalité qui fournit à la fois haute disponibilité et reprise d’activité.
Reprise d’activité (Exemple 2) - Groupe de disponibilité distribué
Un groupe de disponibilité distribué est une fonctionnalité propre à l’édition Entreprise qui a été introduite dans SQL Server 2016. Un groupe de disponibilité distribué est différent d’un groupe de disponibilité traditionnel. Au lieu d’avoir un WSFC sous-jacent où tous les nœuds contiennent des réplicas participant à un groupe de disponibilité, comme décrit dans l’exemple précédent, un groupe de disponibilité distribué se compose de plusieurs groupes de disponibilité. Le réplica principal contenant la base de données en lecture/écriture est appelé « principal global ». Le principal du deuxième groupe de disponibilité est appelé « redirecteur » et maintient le ou les réplicas secondaires de ce groupe de disponibilité synchronisés. Il s’agit essentiellement d’un groupe de disponibilité de groupes de disponibilité.
Cette architecture facilite la gestion d’éléments tels que des quorums dans la mesure où chaque cluster gère son propre quorum (ce qui signifie qu’il a aussi son propre témoin). Un groupe de disponibilité distribué fonctionne si vous utilisez Azure pour toutes les ressources ou une architecture hybride.
L’image ci-dessous montre un exemple de configuration d’un groupe de disponibilité distribué. Notez la présence de deux WSFC. Imaginez que chaque WSFC se trouve dans une région Azure différente ou que l’un se trouve au niveau local et l’autre dans Azure. Chaque WSFC a un groupe de disponibilité avec deux réplicas. Le principal global du groupe de disponibilité 1 maintient le réplica secondaire du groupe de disponibilité 1 synchronisé ainsi que le redirecteur, qui est également le principal du groupe de disponibilité 2. Ce réplica maintient le réplica secondaire du groupe de disponibilité 2 synchronisé.
Pourquoi cette architecture est-elle intéressante ?
Cette architecture fait du WSFC un point de défaillance unique si la communication est interrompue pour tous les nœuds.
Dans cette architecture, un principal ne synchronise pas tous les réplicas secondaires.
Cette architecture peut fournir une restauration automatique d’un emplacement à un autre.
Reprise d’activité (Exemple 3) - Copie des journaux de transaction
La copie des journaux de transaction est l’une des méthodes HADR les plus anciennes pour configurer la reprise d’activité pour SQL Server. Comme décrit ci-dessus, l’unité de mesure est la sauvegarde de fichier journal. Sauf si le passage à un secours semi-automatique est planifié pour éviter la perte de données, il est très probable qu’une perte de données se produise. En matière de reprise d’activité, il est toujours préférable de supposer une perte de données, même minime. L’image ci-dessous, tirée de la documentation Microsoft, montre un exemple de topologie de copie des journaux de transaction.
Pourquoi cette architecture est-elle intéressante ?
Utilisée depuis plus de 20 ans, la copie des journaux de transaction est une fonctionnalité qui a fait ses preuves.
La copie des journaux de transaction est facile à déployer et à administrer puisqu’elle est basée sur la sauvegarde et la restauration.
La copie des journaux de transaction tolère les réseaux qui ne sont pas robustes.
La copie des journaux de transaction répond à la plupart des objectifs RTO et RPO pour la reprise d’activité.
La copie des journaux de transaction est un bon moyen de protéger les FCI.
Reprise d’activité (Exemple 4) - Azure Site Recovery
Pour ceux qui ne souhaitent pas implémenter une solution de reprise d’activité basée sur SQL Server, Azure Site Recovery est une option possible. Cependant, la plupart des professionnels des données préfèrent une approche centrée sur les bases de données, celle-ci ayant généralement un RPO inférieur.
L’image ci-dessous, tirée de la documentation Microsoft, montre où vous rendre dans le portail Azure afin de configurer la réplication pour Azure Site Recovery.
Pourquoi cette architecture est-elle intéressante ?
Azure Site Recovery ne se limite pas à SQL Server.
Azure Site Recovery peut atteindre le RTO et éventuellement le RPO.
Azure Site Recovery est fourni dans le cadre de la plateforme Azure.