Groupes de disponibilité AlwaysOn pour la haute

Guide de l'architecture AlwaysOn : création d'une solution de haute
disponibilité et de récupération d'urgence utilisant les groupes de
disponibilité AlwaysOn
Article technique SQL Server
Auteurs : Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft)
Relecteurs techniques : Lindsey Allen (MS), Juergen Thomas (MS), Mike Weiner (MS), Prem
Mehra (MS), Yorihito Tada (MS), Curt Matthews (MS), Amitabh Tamhane (MS), Aditya Samant
(MS), Daniel Janik (MS), Jimmy May (MS), David P Smith (ServiceU), Richard Waymire (SolidQ),
Brent Ozar (Brent Ozar PLF), Wolfgang Kutschera (bwin.party), Paul S. Randal (SQLskills.com),
Gianluca Hotz (SolidQ), Ayad Shammout (Caregroup)
Responsable du contenu : Glenn Minch (Microsoft)
Date de publication : juin 2012
S'applique à : SQL Server 2012
Résumé : les groupes de disponibilité SQL Server 2012 AlwaysOn offrent une solution unique
de haute disponibilité et de récupération d'urgence (HADR) qui optimise et harmonise les
fonctionnalités héritées utilisées jusqu'ici. Avant SQL Server 2012, plusieurs clients utilisaient la
mise en miroir de bases de données pour fournir une haute disponibilité locale dans un centre
de données, et la copie des journaux de transaction pour la récupération d'urgence sur un centre
de données distant. Avec SQL Server 2012, ce modèle de conception standard peut être remplacé
par une architecture qui utilise des groupes de disponibilité pour la haute disponibilité et la
récupération d'urgence à la fois. Ce document décrit les principales conditions de topologie
requises pour ce modèle de conception spécifique, notamment les éléments à prendre en
considération pour la configuration du quorum, les étapes nécessaires pour créer l'environnement,
et un flux de travail qui permet de gérer un événement de récupération d'urgence dans la topologie.

2
Copyright
Ce document est fourni « en l'état ». Les informations et les opinions exprimées dans ce document,
y compris les adresses URL et les autres références à des sites Internet, peuvent faire l'objet de
modifications sans préavis. Vous assumez tous les risques liés à son utilisation.
Certains exemples mentionnés dans ce document ne sont fournis qu'à titre indicatif et sont fictifs.
Toute ressemblance ou similitude avec des éléments réels est purement fortuite et involontaire.
Ce document ne vous concède aucun droit de propriété intellectuelle portant sur les produits Microsoft.
Vous pouvez copier et utiliser ce document à titre de référence pour un usage interne.
© 2012 Microsoft. Tous droits réservés.

3
Sommaire
Introduction .................................................................................................................................................. 4
Architecture héritée : Mise en miroir de bases de données pour la haute disponibilité et copie
des journaux de transaction pour la récupération d'urgence ...................................................................... 4
Groupes de disponibilité AlwaysOn pour la haute disponibilité et la récupération d'urgence .................... 5
Planification du déploiement et éléments à prendre en compte ................................................................ 6
Conditions préalables pour la topologie ................................................................................................... 6
Unité de basculement ............................................................................................................................... 7
Éléments à prendre en compte pour remplacer la copie des journaux de transaction ........................... 7
Modèle de quorum et votes de nœud ...................................................................................................... 7
Outils pour afficher ou modifier le modèle de quorum et les votes de nœud ..................................... 9
Configurer le mode de quorum WSFC ................................................................................................ 10
Utilisation des vues de gestion dynamique (DMV) et du tableau de bord AlwaysOn
pour afficher les informations de quorum .......................................................................................... 10
Configurer les votes de nœud ............................................................................................................. 12
Connectivité client .................................................................................................................................. 13
Chaînes de connexion pour la mise en miroir de bases de données héritée ..................................... 13
Écouteur de groupe de disponibilité ................................................................................................... 13
Prise en charge des connexions à plusieurs sous-réseaux.................................................................. 13
Générer la solution de groupe de disponibilité .......................................................................................... 14
Éléments à prendre en considération pour l'analyse ................................................................................. 20
Récupération après sinistre ........................................................................................................................ 21
Rebasculer sur le centre de données principal ........................................................................................... 25
Conclusion ................................................................................................................................................... 28
Références .................................................................................................................................................. 28
Annexe A : Exemple de groupes de disponibilité HA/DR à 3 centres de données ..................................... 29

4
Introduction
Microsoft SQL Server 2012 AlwaysOn offre plusieurs choix de conception pour que vous puissiez choisir
la solution de haute disponibilité (HA) et de récupération d'urgence (DR) la mieux adaptée à votre
application. Il existe plusieurs modèles de conception pour générer des solutions HA et DR SQL
Server 2012 AlwaysOn. Ce livre blanc décrit une solution qui utilise les groupes de disponibilité
AlwaysOn pour la haute disponibilité et la récupération d'urgence. C'est une solution essentiellement
basée sur le stockage non partagé, car chaque instance de SQL Server dans la topologie possède sa
propre copie des données, et n'a pas besoin de partager le stockage. Pour plus d'informations sur les
choix de conception, consultez Modèles de conception pour la haute disponibilité et la récupération
d'urgence SQL Server 2012 AlwaysOn.
Avant SQL Server 2012, une architecture de déploiement HA et DR standard impliquait l'utilisation
de la mise en miroir de bases de données pour la haute disponibilité locale et la copie des journaux de
transaction pour la récupération d'urgence distante. Avec SQL Server 2012, des groupes de disponibilité
avec plusieurs serveurs secondaires peuvent remplacer la solution héritée qui utilise la mise en miroir
de bases de données et la copie des journaux de transaction.
Ce document décrit les éléments à prendre en compte pour la planification et vous guide à travers
les étapes nécessaires pour créer des groupes de disponibilité répondant aux exigences de haute
disponibilité et de récupération d'urgence. Il décrit également les étapes nécessaires à la récupération
d'urgence, et explique comment revenir au centre de données principal une fois qu'il a été restauré.
Vous devez avoir une connaissance de base des concepts liés aux groupes de disponibilité AlwaysOn,
à la haute disponibilité et à la récupération d'urgence pour saisir le contenu de ce document. Pour plus
d'informations sur les fonctionnalités complètes de la solution AlwaysOn, consultez le livre blanc Guide
de solutions Microsoft SQL Server AlwaysOn pour la haute disponibilité et la récupération d'urgence.
Le public visé par ce livre blanc comprend les administrateurs de base de données SQL Server et les
architectes des technologies. Ce document est également utile pour les administrateurs système qui
collaborent avec les administrateurs de base de données pour gérer Windows Server, les services de
domaine Active Directory (AD DS), les clusters de basculement Windows Server (WSFC), et la mise en réseau.
Architecture héritée : Mise en miroir de bases de données pour la haute
disponibilité et copie des journaux de transaction pour la récupération
d'urgence
Avant SQL Server 2012, l'architecture de déploiement SQL Server la plus utilisée par les clients impliquait
la mise en miroir de bases de données pour la haute disponibilité dans le centre de données principal, et
la copie des journaux de transaction pour la récupération d'urgence entre plusieurs centres de données.
Pour cette solution, la mise en miroir de bases de données est configurée dans le centre de données
principal. Pour un basculement automatique, il convient de configurer la mise en miroir de bases de
données en mode synchrone avec un témoin (une troisième instance de SQL Server). Si vous ne pouvez
tolérer aucune perte de données, le paramètre de mode haute sécurité de la mise en miroir de bases de
données (synchrone) est activé pour garantir qu'aucune perte de données n'est possible entre les deux
serveurs situés dans le centre de données principal. Pour améliorer la disponibilité de la base de données
dans le centre de données principal, une troisième instance de SQL Server est configurée pour servir de
témoin et permettre le basculement automatique entre les serveurs partenaires de mise en miroir
de bases de données.

5
Si une panne du centre de données principal rend indisponibles les instances des serveurs partenaires
de mise en miroir de bases de données, la copie des journaux de transaction est utilisée pour la récupération
d'urgence. La copie des journaux de transaction implique la sauvegarde continue des journaux de transaction
de la base de données principale. Les sauvegardes des journaux de transaction sont ensuite copiées
dans une instance de SQL Server, dans le centre de données de récupération d'urgence. Les sauvegardes
des journaux de transaction entrants sont restaurées dans l'ordre, en continu. Vous pouvez également
choisir de configurer la copie des journaux de transaction pour les charges de travail en lecture seule,
mais les connexions en lecture seule doivent être déconnectées avant que les sauvegardes des journaux
de transaction entrants soient appliquées. La Figure 1 représente cette architecture de solution.
Figure 1 : Mise en miroir de bases de données pour la haute disponibilité et copie des journaux de transaction pour la
récupération d'urgence
Pour plus d'informations sur cette solution spécifique, et un exemple pratique, consultez l'étude de cas
technique Haute disponibilité et récupération d'urgence pour la couche Données SAP de Microsoft : une
étude de cas technique SQL Server 2008.
Groupes de disponibilité AlwaysOn pour la haute disponibilité et la
récupération d'urgence
Les groupes de disponibilité AlwaysOn peuvent être utilisés pour remplacer la solution de mise en miroir
de bases de données et de copie de journaux de transaction décrite précédemment. L'utilisation des
groupes de disponibilité pour la haute disponibilité et la récupération d'urgence offre les avantages
suivants :
 Vous pouvez grouper plusieurs bases de données utilisateur dans une seule unité de basculement.
En revanche, la mise en miroir de bases de données n'autorise qu'une seule base de données
utilisateur comme unité de basculement.
 Plusieurs serveurs secondaires (groupes de disponibilité) permettent aux utilisateurs d'unifier
la haute disponibilité et la récupération d'urgence dans une seule technologie, au lieu d'utiliser
plusieurs technologies comme dans la solution précédente.
 Les réplicas secondaires peuvent également être configurés pour autoriser les charges de travail
en lecture seule, afin d'obtenir les données presque en temps réel. Contrairement à la copie des
journaux de transaction, les connexions en lecture seule en cours sur les réplicas secondaires
n'ont pas besoin d'être déconnectées pour voir les modifications de données en cours sur le
réplica principal. Les réplicas secondaires peuvent également être utilisés pour réduire la charge
des opérations de sauvegarde complète de la base de données et des journaux de transaction.