AlwaysOn Architecture Guide - Building a High...

Guide de l'architecture AlwaysOn : création d'une solution de haute disponibilité et de récupération d'urgence en utilisant des instances de cluster de basculement et des groupes de disponibilité

Article technique SQL Server

Auteurs : Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft)

Relecteurs techniques : Min He (Microsoft), Chuck Heinzelman (Microsoft), Alexi Khalyako (Microsoft), Charles Mathews (Microsoft), Prem Mehra (Microsoft) , Juergen Thomas (Microsoft), Mike Weiner (Microsoft), Amitabh Tamhane (Microsoft), Brent Ozar (Brent Ozar PLF), Gianluca Hotz (SolidQ), David P. Smith (ServiceU), Michael Steineke (Edgenet), Glenn Berry (SQLskills.com)

Responsable du contenu : Glenn Minch (Microsoft)

Date de publication : juin 2012

S'applique à : SQL Server 2012

Résumé : Les instances de cluster de basculement (FCI) SQL Server 2012 AlwaysOn et les groupes de disponibilité AlwaysOn fournissent une solution de haute disponibilité et de récupération d'urgence complète. Avant SQL Server 2012, de nombreux clients utilisaient les instances de cluster de basculement pour fournir une haute disponibilité locale dans un centre de données, et la mise en miroir de bases de données pour la récupération d'urgence sur un centre de données distant. Avec SQL Server 2012, ce modèle de conception peut être remplacé par une architecture qui utilise des instances FCI pour la haute disponibilité et des groupes de disponibilité pour répondre aux exigences d'entreprise de la récupération d'urgence. Les groupes de disponibilité reposent sur les fonctionnalités de Windows Server Failover Clustering (WSFC) et fournissent plusieurs fonctions non disponibles dans la mise en miroir de bases de données. 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 le stockage asymétrique, les votes de quorum, les étapes nécessaires pour créer l'environnement, et un flux de travail qui vous indique comment les rôles de travail participants peuvent gérer un événement de récupération d'urgence dans la nouvelle topologie.

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.

2

SommaireIntroduction................................................................................................................................................4

Instances de cluster de basculement (FCI) pour la haute disponibilité locale et mise en miroir de bases de données pour la récupération d'urgence......................................................................................4

Instances de cluster de basculement pour la haute disponibilité locale et groupes de disponibilité pour la récupération d'urgence...................................................................................................................5

Éléments de planification à prendre en considération................................................................................7

Conditions requises pour le cluster de basculement Windows Server....................................................7

Stockage asymétrique.............................................................................................................................7

Dénomination et chemin d'accès de l'instance.......................................................................................7

Mode de disponibilité et mode de basculement.....................................................................................8

Modèle de quorum et votes de nœud.....................................................................................................8

Outils pour afficher et modifier le modèle de quorum et les votes de nœud....................................11

Configurer le mode de quorum WSFC...............................................................................................11

Utilisation des vues de gestion dynamique (DMV) et du tableau de bord AlwaysOn pour afficher les informations de quorum.........................................................................................12

Configurer les votes de nœud...........................................................................................................13

Connectivité client.................................................................................................................................14

Charges de travail en lecture/écriture...............................................................................................14

Charges de travail en lecture seule....................................................................................................14

Prise en charge des connexions à plusieurs sous-réseaux.................................................................15

Configurer la solution FCI+AG....................................................................................................................15

Conditions préalables requises pour l'installation.................................................................................15

Configuration de la solution dans le centre de données principal.........................................................16

Configuration de la solution dans le centre de données de récupération d'urgence...................................21

Éléments à prendre en considération pour l'analyse................................................................................25

Récupération après sinistre.......................................................................................................................26

Rebasculer sur le centre de données principal..........................................................................................32

Conclusion.................................................................................................................................................36

Références.................................................................................................................................................37

3

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. Pour plus d'informations sur les modèles de conception d'une solution de haute disponibilité et de récupération d'urgence SQL Server 2012 AlwaysOn, consultez Modèles de conception pour la haute disponibilité et la récupération d'urgence SQL Server 2012 AlwaysOn .

Ce livre blanc décrit une solution qui utilise les instances de cluster de basculement (FCI) pour la haute disponibilité (HA) et les groupes de disponibilité (AG) pour la récupération d'urgence (DR). Cette architecture combine une solution de stockage partagé (FCI) et une solution de stockage non partagé (AG).

Avant SQL Server 2012, une architecture de déploiement HA et DR standard impliquait l'utilisation d'instances FCI pour la haute disponibilité locale et la mise en miroir de bases de données (DBM) pour la récupération d'urgence distante. Avec SQL Server 2012, les groupes de disponibilité peuvent remplacer le composant de mise en miroir de bases de données de la solution.

Ce document aborde les éléments à prendre en compte et vous guide à travers les étapes requises pour générer la solution. 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 instances de cluster de basculement (FCI), aux groupes de disponibilité (AG), à la haute disponibilité (HA) et à la récupération d'urgence (DR) 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. Pour plus d'informations sur les étapes de migration, consultez le livre blanc Guide de migration : migration vers le clustering de basculement SQL Server 2012 et les groupes de disponibilité à partir des déploiements de mise en miroir et de clustering antérieurs.

Le public cible de 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.

Instances de cluster de basculement (FCI) pour la haute disponibilité locale et mise en miroir de bases de données pour la récupération d'urgenceComme mentionné dans l'introduction, avant SQL Server 2012, une architecture de déploiement SQL Server standard impliquait l'utilisation d'instances FCI pour une haute disponibilité locale, et l'utilisation de la mise en miroir de bases de données (DBM) pour la récupération d'urgence entre les centres de données. Cette solution est appelée une solution FCI+DBM. Dans celle-ci, une instance de cluster de basculement est configurée dans le centre de données principal à l'aide d'un stockage sur disque partagé (via le réseau SAN, par exemple) pour assurer la protection de SQL Server au niveau de l'instance. Si une défaillance matérielle se produit sur l'un des nœuds, un autre nœud peut prendre la relève en tant qu'hôte de l'instance FCI au sein du même centre de données.

La mise en miroir de bases de données est utilisée entre le site principal et le site de récupération d'urgence pour assurer une protection au niveau de la base de données. En cas de panne du centre de données principal, ou si le stockage partagé dans le centre de données principal est défaillant, le serveur miroir du centre de données de récupération d'urgence peut être utilisé pour restaurer le service dans

4

http://msdn.microsoft.com/library/hh923056.aspx





http://go.microsoft.com/fwlink/?LinkId=255048


les applications. Le centre de données de récupération d'urgence héberge une autre instance FCI sur un WSFC distinct, avec son propre stockage partagé. La Figure 1 illustre cette architecture de solution.

Figure 1 : Instances de cluster de basculement (FCI) pour la haute disponibilité et mise en miroir de bases de données pour la récupération d'urgence

En général, le centre de données de récupération d'urgence est éloigné du centre de données principal, et la session de mise en miroir est configurée en mode asynchrone « haute performance » afin de réduire la charge de traitement des transactions. Occasionnellement, la mise en miroir de bases de données synchrone entre les centres de données est également constatée.

Pour plus d'informations, et un exemple pratique de cette solution spécifique, consultez Haute disponibilité et récupération d'urgence sur ServiceU : une étude de cas technique SQL Server 2008 .

Instances de cluster de basculement pour la haute disponibilité locale et groupes de disponibilité pour la récupération d'urgence Avec SQL Server 2012, une solution semblable utilise les instances FCI pour une haute disponibilité locale, comme dans la solution FCI+DBM, et les groupes de disponibilité (AG) pour la récupération d'urgence. Cette solution est appelée une solution FCI+AG.

La Figure 2 illustre la solution qui utilise des instances FCI pour la haute disponibilité locale et des groupes de disponibilité pour la récupération d'urgence entre les centre de données.

5



Figure 2 : Instances de cluster de basculement (FCI) pour la haute disponibilité et groupes de disponibilité pour la récupération d'urgence

La Figure 2 représente deux instances FCI, une dans le centre de données principal et l'autre dans le centre de données de récupération d'urgence. Chaque instance FCI comporte deux nœuds et son propre stockage partagé. Les quatre nœuds, toutefois, font partie du même WSFC. Tous les nœuds doivent obligatoirement appartenir au même WSFC pour obtenir des groupes de disponibilité.

La Figure 2 illustre une topologie de scénario simple avec deux centres de données, chacun hébergeant un réplica du groupe de disponibilité sur une instance FCI à deux nœuds. L'architecture permet d'apporter des variantes à cette topologie :

Plusieurs centres de données Plusieurs réplicas, jusqu'à cinq : un réplica principal et un à quatre réplicas secondaires Plus de deux nœuds dans chaque instance FCI si des nœuds passifs supplémentaires sont requis

pour la haute disponibilité Il n'est pas nécessaire que tous les réplicas d'un groupe de disponibilité résident sur des

instances FCI ; certains peuvent résider sur des instances SQL Server non FCI autonomes Plusieurs groupes de disponibilité en fonction du regroupement logique des bases de données

de votre environnement applicatif

Les paragraphes de ce livre blanc concernent la topologie illustrée dans la Figure 2 ; toutefois, les notions générales s'appliquent aux autres variantes.

Étant donné que les quatre nœuds distribués sur les deux sites font partie du même WSFC, d'autres éléments doivent être pris en compte pour utiliser le stockage partagé visible uniquement aux nœuds du centre de données local. Il faut également adapter le vote et le modèle du quorum. Ce document décrit, entre autres, ces éléments.

Le groupe de disponibilité peut être configuré avec une ou plusieurs bases de données utilisateur, et peut utiliser le déplacement des données synchrone ou asynchrone. Les réplicas synchrones augmentent la latence des transactions de base de données parce que le serveur principal doit s'assurer que les enregistrements ont été renforcés dans les journaux du réplica secondaire avant que le réplica principal valide la transaction.

Il est également important de noter que l'instance SQL Server de récupération d'urgence ne doit pas être nécessairement une instance FCI. Un groupe de disponibilité peut également avoir une instance autonome de SQL Server pour le réplica secondaire. Avec les groupes de disponibilité, vous pouvez combiner des instances autonomes et FCI dans une même topologie, sur le même WSFC. La Figure 3 illustre une topologie mixte.

6

Figure 3 : Instance de cluster de basculement (FCI) pour la haute disponibilité locale et groupes de disponibilité pour la récupération d'urgence (instance de récupération d'urgence en tant qu'instance autonome)

Dans la suite de ce document, il est supposé que les réplicas principal et secondaire sont des instances FCI hébergées, et non des instances autonomes.

Éléments de planification à prendre en considération Cette section décrit les éléments à prendre en considération pour la planification, les conditions requises et les composants nécessaires pour implémenter une solution FCI+AG pour la haute disponibilité et la récupération d'urgence.

Conditions requises pour le cluster de basculement Windows ServerL'évolution fondamentale entre une solution FCI+DBM et une solution FCI+AG est que l'on passe de l'utilisation de deux instances FCI sur deux WSFC distinct à l'utilisation de deux instances FCI sur un WSFC unique . Tous les réplicas d'un groupe de disponibilité doivent exister sur un WSFC unique dans un seul domaine Active Directory, même entre les centres de données.

Stockage asymétriqueDeux instances FCI, une pour chaque site sur un même WSFC multisite, soulèvent des questions sur la façon dont le stockage partagé est géré. Chaque instance FCI a son propre stockage partagé. Les nœuds dans le stockage principal partagent le stockage entre eux pour former une instance FCI de stockage partagé, et les nœuds du site de récupération d'urgence partagent le stockage entre eux pour former une autre instance FCI de stockage partagé. Le stockage sur le site principal n'est pas visible aux nœuds sur le site de récupération d'urgence, et vice versa. Cette organisation du stockage, où un disque du cluster est partagé entre un sous-ensemble des nœuds dans un WSFC, est appelé un stockage asymétrique. Avant qu'on introduise le stockage asymétrique, le stockage partagé devait être visible à tous les nœuds dans le WSFC (stockage symétrique). Le stockage asymétrique a été introduit en tant qu'option de déploiement pour Windows Server 2008, via un correctif. Le stockage asymétrique est également pris en charge dans Windows Server 2008 R2 via le Service Pack 1. Pour plus d'informations sur ce correctif logiciel, consultez l'article de la Base de connaissances Correctif logiciel pour l'ajout du stockage asymétrique au composant logiciel enfichable MMC de gestion du cluster de basculement pour un cluster de basculement exécutant Windows Server 2008 ou Windows Server 2008 R2 .

Cette amélioration Windows Server est la fonctionnalité clé qui permet l'architecture de la solution FCI + AG décrite dans ce livre blanc. En l'activant, vous pouvez associer la solution de stockage partagé (instance FCI) et la solution de stockage non partagé (groupes de disponibilité) dans une seule solution de haute disponibilité et de récupération d'urgence. Par conséquent, elle permet également d'utiliser des lettres de lecteur identiques pour les ressources de disque partagées entre les centres de données.

Notez que lorsque vous configurez le stockage asymétrique, vous pouvez voir un message pendant les tests de validation WSFC signalant que « Le disque ayant l’id XYZ est visible ou peut être mis en cluster uniquement à partir d’un sous-ensemble de nœuds ». Pour le stockage asymétrique, cela est prévu et ne doit pas vous inquiéter.

Dénomination et chemin d'accès de l'instanceLes deux instances FCI doivent utiliser des noms d'instance différents dans le même WSFC, par exemple, « INST_A » pour le nom de l'instance FCI principale et « INST_B » pour le nom de l'instance FCI de récupération d'urgence. (Contrairement aux groupes de disponibilité, la mise en miroir de bases de données permet à chaque instance FCI d'utiliser le même nom si les instances FCI se trouvent sur des WSFC 7

http://support.microsoft.com/kb/976097



distincts. Dans la figure 1, les deux instances FCI utilisent le même nom d'instance, INST_A, avec la solution FCI+DBM).

Chaque instance FCI a son propre stockage partagé, qui n'est pas accessible par les nœuds de l'autre centre de données, et qui doit utiliser des lettres de lecteur identiques pour les disques, ainsi que des chemins d'accès de fichier identiques pour les fichiers de base de données et les fichiers du journal des transactions dans les deux instances FCI. Un chemin d'accès et des lettres de lecteurs identiques ne sont pas obligatoires, mais si les chemins d'accès de fichier diffèrent, vous devrez effectuer un RESTORE WITH MOVE manuel lorsque vous restaurerez les bases de données du réplica sur le serveur secondaire. De plus, des chemins d'accès hétérogènes entre les deux instances FCI invalideront les opérations ultérieures d'ajout de fichier, telles que la création de groupes de fichiers ou de fichiers journaux ou de données secondaires. Pour plus d'informations, notamment un scénario décrivant un problème et sa résolution, consultez Résoudre une opération d'ajout de fichier ayant échoué (groupes de disponibilité AlwaysOn).

Mode de disponibilité et mode de basculementPour le groupe de disponibilité créé entre les deux instances FCI, vous pouvez choisir entre les modes de disponibilité avec validation synchrone ou asynchrone. Si le mode de disponibilité est synchrone, le réplica principal ne valide pas les transactions utilisateur tant qu'elles ne sont pas envoyées et renforcées sur les réplicas secondaires. Cela peut ajouter une latence aux transactions utilisateur mais réduit le risque de perte de données sur le réplica secondaire en garantissant que les transactions sont envoyées à l'instance FCI de récupération d'urgence avant qu'une validation soit signalée dans la transaction du réplica principal.

Si le mode de disponibilité est asynchrone, les transactions utilisateur du réplica principal n'attendent pas d'être renforcées dans les journaux du réplica secondaire. Cela réduit la latence des transactions, mais augmente le risque de perte de données en cas de panne.

Concernant les modes de basculement, lorsque les instances FCI sont utilisées dans une topologie de groupe de disponibilité, le mode de basculement du groupe de disponibilité doit être manuel (non automatique). Toutefois, dans chaque instance FCI, le basculement FCI de l'instance de SQL Server sur d'autres nœuds est automatique.

Modèle de quorum et votes de nœudRemarque : les modèles de quorum et les thèmes associés abordés dans ce livre blanc s'appliquent aux solutions exécutées sur les systèmes d'exploitation Windows Server 2008 et Windows Server 2008 R2, avec les Service Packs et les mises à jour logicielles appropriés.

Étant donné que l'infrastructure sous-jacente de la solution FCI+AG est un WSFC, il est important de déterminer le modèle de quorum adéquat. La configuration du quorum est gérée au niveau du WSFC, quel que soit le nombre d'instances FCI, le nombre de réplicas et le nombre de groupes de disponibilité hébergés dans le WSFC.

Dans WSFC, il existe quatre modèles de quorum : Nœud majoritaire, Nœud et partage de fichiers majoritaires, Nœud et disque majoritaires, Aucune majorité - Disque uniquement. Pour plus d'informations sur les modèles de quorum, consultez Guide pas à pas du cluster de basculement : configuration du quorum dans un cluster de basculement.

8

http://technet.microsoft.com/library/cc770620(v=WS.10).aspx


http://msdn.microsoft.com/library/hh510190

Il est important de prendre en compte le nombre de nœuds votants avant de sélectionner un modèle de quorum. L'affectation des votes de nœud appropriés joue un rôle important dans la conception de la haute disponibilité et de la récupération d'urgence. Par défaut, chaque nœud dans un cluster de basculement possède un vote, mais cette configuration peut ne pas être adaptée à votre solution de haute disponibilité et de récupération d'urgence spécifique, selon les nœuds de distribution dans le centre de données principal et dans le centre de données de récupération d'urgence. Un correctif logiciel est disponible (http://support.microsoft.com/kb/2494036) et vous permet d'affecter 1 vote à certains nœuds et 0 vote à d'autres nœuds dans le WSFC. La propriété NodeWeight du nœud WSFC représente le vote du nœud spécifique. La valeur « 0 » signifie que le nœud n'a pas de vote. La valeur « 1 » signifie que le nœud a un vote de quorum. Ce correctif doit être installé sur chaque nœud de la topologie.

Les recommandations générales pour le vote de quorum d'une solution HA+DR AlwaysOn sont fournies dans la rubrique Réglages recommandés pour le vote de quorum de la documentation en ligne de SQL Server. Elles doivent être considérées comme des instructions permettant de déterminer le schéma de vote de la solution AlwaysOn. En prenant en considération ces instructions, afin de garantir que le quorum des nœuds dans le centre de données principal n'est pas affecté par les pannes dans le centre de données de récupération d'urgence, ou par les pertes de connectivité entre les deux centres de données, pour la solution FCI+AG présentée à la figure 2, le schéma de vote est le suivant :

1 vote sur chaque nœud dans le centre de données principal 0 vote sur chaque nœud dans le centre de données de récupération d'urgence

Cette attribution de vote se traduit par un total de 2 votes pour le WSFC. À titre de recommandation, le nombre total de votes du WSFC doit être impair. S'il existe un nombre pair de nœuds votants (comme dans notre exemple de topologie), envisagez d'ajouter un témoin de partage de fichiers, puis sélectionnez le modèle de quorum Nœud et partage de fichiers majoritaires.

Remarque : dans de nombreux environnements d'entreprise, il est courant qu'un partage de fichiers soit détenu et gère par une équipe différente. Cette équipe a alors le contrôle d'un vote de nœud, et influence ainsi l'état du cluster de basculement. Un partage de fichiers possède un vote et, par conséquent, doit toujours être disponible. Il est recommandé d'utiliser une solution de clustering ou d'autres technologies de haute disponibilité pour garantir la disponibilité du vote du partage de fichiers.

Alternativement, vous pouvez ajouter un nœud supplémentaire et utiliser le modèle de quorum Nœud majoritaire. Le nœud supplémentaire doit figurer dans le WSFC, mais ne doit pas nécessairement faire partie de la configuration FCI. Il doit également se trouver dans le même centre de données principal, en colocation avec les deux autres nœuds WSFC qui existent dans ce centre de données.

La Figure 4 illustre l'allocation de vote avec le modèle de quorum Nœud et partage de fichiers majoritaires.

9

http://msdn.microsoft.com/library/hh270280.aspx#RecommendedAdjustmentstoQuorumVoting


Figure 4 : Solution de haute disponibilité et de récupération d'urgence FCI+AG avec attributions de vote de nœud

Dans la Figure 4, chaque nœud dans le centre de données principal a un vote. Un témoin de partage de fichiers est aussi présent dans le centre de données principal, et possède également un vote. Les deux nœuds du centre de données de récupération d'urgence n'ont pas de vote et ne peuvent pas affecter le quorum.

Pour cette architecture de déploiement, vous pouvez également choisir le modèle de quorum Nœud et disque majoritaire (avec un disque asymétrique) ou Aucune majorité - Disque uniquement (avec un disque asymétrique). Avant que le stockage asymétrique ne soit disponible dans un WSFC, un disque partagé pouvait servir de ressource de quorum s'il était visible à tous les nœuds WSFC. Avec le stockage asymétrique, le stockage du cluster peut être visible à un sous-ensemble de nœuds tout en étant utilisé en tant que ressource du quorum. Avec le modèle de quorum asymétrique Aucune majorité - Disque uniquement, vous pouvez implémenter un scénario « de dernier recours », où le WSFC conserve le quorum tant qu'un seul nœud a un contact avec le disque asymétrique qui agit en tant que ressource de quorum.

Pour cela, vous pouvez utiliser la ligne de commande de cluster.exe ; cependant, vous ne pouvez pas utiliser le gestionnaire de cluster de basculement, ni Windows PowerShell. Pour obtenir un exemple de cette configuration, consultez la section Modifier la configuration de quorum dans un cluster de basculement avec stockage asymétrique de l'article Guide pas à pas du cluster de basculement : configuration du quorum dans un cluster de basculement.

Important : l'utilisation d'un disque asymétrique en tant que ressource de quorum fournit de nombreux avantages, mais requiert également beaucoup plus d'expertise et une planification du cluster très rigoureuse. Vous devez maîtriser parfaitement cette configuration avant de la déployer dans un environnement de production.

En cas de panne du centre de données principal vous obligeant à basculer le service sur le centre de données de récupération d'urgence, vous devez réévaluer la configuration du quorum. Chaque nœud du centre de données de récupération d'urgence doit bénéficier d'un vote, et chaque nœud du centre de données principal doit être privé de vote (valeur « 0 ») jusqu'à ce que le service soit restauré. En supposant qu'il existe deux nœuds dans l'instance FCI et que le centre de données principal connaît une panne de longue durée, vous devrez également configurer un témoin de partage de fichiers (ou tout autre vote supplémentaire) dans le centre de données de récupération d'urgence, et définir le modèle du quorum en conséquence. Lorsque le centre de données principal peut reprendre l'activité, les votes doivent de nouveau être modifiés et le modèle de quorum doit être réévalué. Nous aborderons un scénario pas à pas de récupération d'urgence et le flux de traitement associé plus loin dans ce document.

10



http://technet.microsoft.com/library/cc770620(v=ws.10).aspx#BKMK_asymmetric

http://technet.microsoft.com/library/cc770620(v=ws.10).aspx#BKMK_asymmetric

Le modèle de quorum et les affectations de vote présentés à la figure 4 supposent que la solution comprend deux réplicas, un dans chaque centre de données. Si vous disposez de davantage de centres de données, et vous projetez de déplacer une partie de votre solution sur un troisième centre, les décisions de modèle de quorum et d'affectation de vote peuvent varier.

Outils pour afficher et modifier le modèle de quorum et les votes de nœudIl existe plusieurs façons de consulter et de modifier le modèle de quorum du cluster et/ou les votes de quorum. Le tableau suivant répertorie les différents outils permettant d'effectuer ces tâches.

Pour afficher le modèle de quorum Pour modifier le modèle de quorum

Gestionnaire du cluster de basculement Windows

Windows PowerShellCluster.exe

Vues de gestion dynamique (DMV) SQL Server Tableau de bord AlwaysOn dans SQL Server

Management Studio

Gestionnaire du cluster de basculement Windows Windows PowerShell

Cluster.exe

Remarque : seul Cluster.exe peut être utilisé pour définir le modèle de quorum sur (asymétrique) « Nœud et disque majoritaire (asymétrique) »

ou « Aucune majorité - (asymétrique) Disque uniquement »

Pour afficher les votes de nœud Pour modifier les votes de nœudWindows PowerShell

Cluster.exeVue de gestion dynamique (DVM) SQL Server

Tableau de bord AlwaysOn

Windows PowerShellCluster.exe

Configurer le modèle de quorum WSFCVoici des exemples d'utilisation de Windows PowerShell via la ligne de commande pour afficher le modèle de quorum existant, et pour le modifier.

Pour afficher le modèle de quorum existant

Get-ClusterQuorum

Pour configurer le modèle de quorum Nœud majoritaire

Set-ClusterQuorum -NodeMajority

Pour modifier le modèle de quorum en Nœud et partage de fichiers majoritaires

Set-ClusterQuorum -NodeAndFileShareMajority \\FileShare\Witness

Le partage de fichiers témoin que vous choisissez ne doit pas figurer sur un nœud qui participe déjà à la configuration WSFC AlwaysOn. Toutefois, il peut être placé dans un partage sur une autre configuration WSFC. Il doit exister dans le même domaine Active Directory que le WSFC. De plus, le compte du service de cluster WSFC nécessite des autorisations en lecture et en écriture sur le témoin de partage de fichiers. Le Gestionnaire du cluster de basculement fournit la logique intégrée permettant d'ajouter ces autorisations au témoin de partage de fichiers, à condition que le compte qui modifie le modèle de quorum dispose des autorisations appropriées sur le partage de fichiers.

11

Utilisation des vues de gestion dynamique (DMV) et du tableau de bord AlwaysOn pour afficher les informations de quorumBien que vous ne puissiez pas définir ou modifier le modèle de quorum ou les votes de nœud dans les outils SQL Server, vous pouvez utiliser des requêtes Transact-SQL sur les vues de gestion dynamique (DMV) et utiliser le tableau de bord AlwaysOn dans SQL Server Management Studio pour afficher les votes de nœud et le modèle de quorum du cluster Windows qui héberge le groupe de disponibilité.

Pour afficher le modèle de quorum du cluster Windows qui héberge le groupe de disponibilité, interrogez la vue de gestion dynamique sys.dm_hadr_cluster (http://technet.microsoft.com/fr-fr/library/hh212952(v=sql.110).aspx).

SELECT cluster_name, quorum_type_desc, quorum_state_descFROM sys.dm_hadr_cluster;

Lorsque cette requête est exécutée dans l'exemple utilisé dans ce livre blanc, elle retourne les valeurs suivantes.

cluster_name quorum_type_desc quorum_state_desc------------ ---------------- -----------------contosocluster NODE_AND_FILE_SHARE_MAJORITY NORMAL_QUORUM

Pour afficher les votes de nœud, interrogez la vue de gestion dynamique sys.dm_hadr_cluster_members.

SELECT member_name, number_of_quorum_votesFROM sys.dm_hadr_cluster_members;

Lorsque cette requête est exécutée dans l'exemple utilisé dans ce livre blanc, elle retourne les valeurs suivantes. L'affectation de vote est abordée dans une section ultérieure.

member_name number_of_quorum_votes------------------ ----------------------PrimaryNode1 1PrimaryNode2 1DRNode1 0DRNode2 0Témoin de partage de fichiers 1

Vous pouvez également utiliser le tableau de bord AlwaysOn dans SQL Server Management Studio pour afficher les votes de quorum et l'état du cluster. La Figure 5 illustre ces informations pour un cluster Windows avec le modèle de quorum Nœud majoritaire (l'état du cluster et les votes de quorum sont en surbrillance).

12

http://technet.microsoft.com/library/hh231519(v=sql.110).aspx

http://technet.microsoft.com/en-us/library/hh212952(v=sql.110).aspx

Figure 5 : Affichage de votes de quorum et de l'état du cluster dans le tableau de bord AlwaysOn

Bien que la colonne Vote de quorum ne soit pas affichée par défaut, vous pouvez l'ajouter dans le tableau de bord en cliquant avec le bouton droit sur l'en-tête de colonne de la table Réplica de disponibilité, puis en sélectionnant la colonne spécifique à afficher.

Pour un modèle de quorum Nœud et partage de fichiers majoritaires, ce tableau de bord AlwaysOn affichera uniquement les nœuds, pas le partage de fichiers. Pour afficher des informations de quorum complètes, cliquez sur Afficher des informations de quorum de cluster à droite. Une fenêtre indépendante apparentée à celle de la Figure 6 s'affiche.

Figure 6 : Informations sur le quorum du cluster pour le modèle de quorum Nœud et partage de fichiers majoritaires

Configurer les votes de nœudLa propriété NodeWeight du nœud WSFC représente le vote du nœud spécifique. Les exemples suivants montrent comment configurer le nœud NodeWeight pour un nœud dans un WSFC avec Windows PowerShell. Pour exécuter Windows PowerShell sur le nœud serveur, cliquez sur Démarrer, pointez sur Outils d'administration, puis sur Modules Windows PowerShell. Dans cet exemple, DRNode1 représente un nœud WSFC spécifique situé dans le centre de données de récupération d'urgence.

13

Pour afficher les paramètres de vote de tous les nœuds

Get-ClusterNode | fl NodeName, NodeWeight

Pour définir le vote d'un nœud sur « 0 »

(Get-ClusterNode "DRNode1").NodeWeight=0

Remarque : la valeur « 0 » signifie que le nœud n'a pas de vote. La valeur « 1 » signifie que le nœud a un vote de quorum.

Connectivité clientLes méthodes de connexion de l'instance FCI dans SQL Server 2012 sont les mêmes que dans les versions précédentes, toutefois, lorsque vous passez d'une solution utilisant la mise en miroir de bases de données à une solution utilisant des groupes de disponibilité, vous devrez appliquer et planifier un certain nombre de modifications avant de pouvoir utiliser les nouvelles fonctionnalités du serveur secondaire lisible. Pour plus d'informations sur cette migration, et pour consulter les instructions et les étapes détaillées, consultez Guide de migration : migration vers le clustering de basculement SQL Server 2012 et les groupes de disponibilité à partir des déploiements de mise en miroir et de clustering antérieurs.

Charges de travail en lecture/écriture Pour les charges de travail en lecture/écriture exécutées sur les bases de données de disponibilité dans un groupe de disponibilité, vous disposez de deux options pour vous connecter au réplica principal. La première option consiste à vous connecter directement au nom de réseau virtuel (VNN) de l'instance FCI, chaque réplica ayant un VNN FCI distinct. La seconde option consiste à utiliser le nom de l'écouteur de groupe de disponibilité. L'écouteur de groupe de disponibilité est l'option par défaut car elle fournit la transparence et la redirection automatique sur le réplica principal actuel, et parce que le nom dans la chaîne de connexion reste identique pour toutes les instances. L'écouteur de groupe de disponibilité est un VNN lié à une ou plusieurs adresses TCP/IP et ports d'écoute ; il est utilisé pour la connexion automatique à n'importe quel réplica de groupe de disponibilité sans qu'il soit nécessaire d'en désigner un explicitement dans la chaîne de connexion.

Si vous migrez vos connexions de charge de travail en lecture/écriture d'une solution de mise en miroir de bases de données qui utilise l'attribut de partenaire de basculement, vous pouvez continuer à utiliser votre chaîne de connexion de mise en miroir de bases de données, mais uniquement si le groupe de disponibilité est configuré avec un seul réplica secondaire. Vous pouvez ensuite utiliser le nom de serveur du réplica principal d'origine comme source de données et (facultatif) le nom du réplica secondaire comme partenaire de basculement. Toutefois, ce n'est pas une solution viable à long terme.

Charges de travail en lecture seule Pour les connexions de charge de travail en lecture seule, vous disposez également de deux options. Vous pouvez utiliser le VNN de l'instance FCI, ou vous pouvez utiliser l'écouteur du groupe de disponibilité et spécifier le nouvel attribut ApplicationIntent dans la chaîne de connexion comme étant « ReadOnly ».

14



Si vous utilisez une chaîne de connexion de mise en miroir de bases de données héritée, vous pouvez vous connecter au groupe de disponibilité uniquement tant que le groupe de disponibilité est un réplica secondaire unique, configuré pour l'activité de lecture/écriture.

Si vous souhaitez tirer parti du routage en lecture seule, vous devez utiliser le nom de l'écouteur du groupe de disponibilité avec l'attribut ApplicationIntent et la valeur « ReadOnly ». Vous devez également référencer une base de données de disponibilité dans le groupe de disponibilité. Le groupe de disponibilité doit également être configuré pour le routage en lecture seule sur les réplicas secondaires lisibles, en créant des URL et des listes de routage en lecture seule. Pour plus d'informations sur ce processus, consultez Configurer le routage en lecture seule pour un groupe de disponibilité (SQL Server).

Prise en charge des connexions à plusieurs sous-réseauxL'écouteur du groupe de disponibilité peut également exploiter l'attribut de connexion MultiSubnetFailover dans les bibliothèques clientes. Il est recommandé que les chaînes de connexion du groupe de disponibilité indiquent l'attribut MultiSubnetFailover pour les topologies de sous-réseaux multiples lorsqu'elles référencent un nom d'écouteur de groupe de disponibilité. L'option de connexion MultiSubnetFailover active la prise en charge des connexions à plusieurs sous-réseaux et ouvre les sockets TCP pour les adresses IP de l'écouteur du groupe de disponibilité en parallèle. Pour les bibliothèques clientes héritées qui ne prennent pas en charge l'attribut MultiSubnetFailover, vous devez définir un délai d'expiration de la connexion cliente approprié.

Pour plus d'informations sur la connectivité client et les éléments à prendre en compte pour un basculement d'application, consultez Connectivité client et basculement d'application (groupes de disponibilité AlwaysOn) dans la documentation en ligne de SQL Server.

Configurer la solution FCI+AG Ce flux de travail décrit les étapes requises pour générer la solution FCI+AG. Bien que toutes les étapes ne soient pas décrites ici de façon détaillée, l'objectif de cette section est d'aider à clarifier la séquence du flux de travail et les tâches de chaque rôle de travail impliqué. La documentation afférente est référencée le cas échéant. Les étapes sont classées par rôle de travail car la plupart des entreprises de grande taille répartissent les fonctions entre les rôles d'administrateur de base de données, d'administrateur Windows Server (ou cluster) et d'administrateur réseau. Il est par conséquent important de mettre en place une communication efficace et de coordonner les activités entre les différents rôles.

Conditions préalables requises pour l'installationAvant de déployer votre solution de groupes de disponibilité AlwaysOn, il est important de vérifier que votre système satisfait les conditions, y compris en ce qui concerne les mises à jour. Pour plus d'informations sur les conditions préalables pour le déploiement d'une solution utilisant les groupes de disponibilité AlwaysOn, consultez Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server). Nous vous recommandons vivement de lire cette rubrique avant de continuer.

La même version du système d'exploitation Windows Server et les mêmes mises à jour logicielles doivent être installées sur tous les nœuds. Le système d'exploitation serveur doit être au minimum Windows Server 2008 SP2, ou Windows Server 2008 R2 SP1 avec au moins les mises à jour suivantes :

15

http://msdn.microsoft.com/library/ff878487(v=sql.110).aspx


http://msdn.microsoft.com/library/hh213417(v=sql.110).aspx



Stockage asymétrique (si vous utilisez Windows Server 2008) : http://support.microsoft.com/kb/976097

Votes de nœud : http://support.microsoft.com/kb/2494036 Test de validation du disque pendant la validation du cluster :


Des mises à jour supplémentaires peuvent être requises.

Configuration de la solution dans le centre de données principalLa Tableau 1 illustre le flux de travail requis pour configurer les nœuds du centre de données principal, et suppose qu'il existe deux nœuds.

16




Étape Administrateur de base de données

Windows Server \Administrateur de cluster

Administrateur réseau

1. Ajoutez la fonctionnalité de clustering de basculement aux deux nœuds situés dans le centre de données principal. Pour plus d'informations sur ce processus, consultez Installer la fonctionnalité de clustering de basculement. Pour plus d'informations sur la validation de votre infrastructure réseau et la configuration requise, consultez Conditions spécifiques des clusters de basculement.

Oui (coordination des activités entre les rôles)

Oui

2. Examinez les conditions préalables requises et installez les mises à jour logicielles Windows Server requises sur chaque nœud dans le centre de données principal.

Oui

3. Vérifiez que les volumes de stockage partagé désignés pour l'instance FCI du centre de données principal sont formatés et ont une lettre de lecteur.

Nous recommandons que les lettres de lecteur et le chemin d'accès au répertoire correspondants de l'instance FCI de récupération d'urgence correspondent à ceux de l'instance FCI principale. Gardez cela à l'esprit lorsque vous attribuez les lettres de lecteur dans l'instance FCI principale.

Oui

4. Vérifiez que le compte que vous utilisez pour installer et configurer le WSFC est un compte de domaine. Ce compte doit également disposer d'autorisations administratives sur chaque nœud du cluster, et d'autorisations Créer des objets ordinateur et Lire toutes les propriétés pour le conteneur utilisé pour les comptes d'ordinateur de domaine.

Sinon, vous pouvez préconfigurer les comptes d'objet de nom à l'avance, ou utiliser un compte d'administrateur de domaine pour l'installation. Pour plus d'informations sur les autorisations requises et les options de configuration, consultez Guide pas à pas du cluster de basculement : configuration de comptes dans Active Directory.

Oui

17

http://technet.microsoft.com/library/cc731002(WS.10).aspx



http://technet.microsoft.com/library/cc771404.aspx








5. À l'aide du gestionnaire de cluster de basculement, exécutez la validation de cluster des deux nœuds serveurs dans le centre de données principal et dans le stockage partagé qui sera ajouté au WSFC. Exécutez la validation de manière itérative jusqu'à ce qu'il n'existe aucune erreur bloquante.

Même si vous pouvez passer à l'étape suivante en dépit des avertissements existants, il est important de comprendre leur signification pour obtenir une configuration stable. Pour plus d'informations sur l'exécution d'un test de validation, consultez Validation d'une configuration de cluster de basculement.

Oui Oui - Pour tous les problèmes qui peuvent survenir pour la connexion des nœuds

6. À la fin de l'étape de validation de cluster, utilisez le gestionnaire du cluster de basculement pour créer un WSFC à deux nœuds. Pour plus d'informations et une présentation détaillée de ce processus, consultez Créer un cluster de basculement.


7. Vérifiez que les votes sont en nombre impair ; par exemple, vous pouvez obtenir un nombre impair en ajoutant un partage de fichiers ou un nœud supplémentaire, comme expliqué plus haut dans ce document.

Si vous avez choisi Nœud et partage de fichiers majoritaires, avant de modifier la configuration, assurez-vous que vous avez accordé les autorisations en lecture et en écriture sur le partage de fichiers témoin pour le compte de cluster WSFC.

Oui

8. Vérifiez que l'installation utilise un stockage partagé et formaté accessible uniquement aux deux nœuds situés dans le centre de données principal. Ces disques seront utilisés pour SQL Server à l'étape suivante.

Oui

18








9. Installez une instance FCI de SQL Server 2012 Enterprise sur le centre de données principal. Pour plus d'informations, consultez Créer un cluster de basculement SQL Server.

Vous devez procéder à deux installations : l'installation d'un nouveau cluster de basculement SQL Server, qui crée l'instance FCI, et l'ajout d'un nœud à un cluster de basculement SQL Server sur le deuxième nœud dans le centre de données principal.

Oui

10. Après avoir installé la première instance FCI, activez les fonctions du groupe de disponibilité AlwaysOn sur les deux instances de SQL Server.

Pour plus d'informations sur l'utilisation du Gestionnaire de configuration SQL Server ou, éventuellement, de SQL Server PowerShell, consultez Activer et désactiver les groupes de disponibilité AlwaysOn. Notez que lorsque vous activez les groupes de disponibilité AlwaysOn sur l'instance, vous devez redémarrer celle-ci pour que la modification prenne effet.

19




http://msdn.microsoft.com/library/ms179530(v=sql.110).aspx

http://msdn.microsoft.com/library/ms179530(v=sql.110).aspx




11. Après avoir activé la prise en charge des groupes de disponibilité AlwaysOn sur l'instance FCI de récupération d'urgence, sauvegardez vos bases de données utilisateur en production à partir de la topologie héritée, puis restaurez-les dans l'instance FCI du centre de données principal.

Remarque : vous pouvez choisir d'effectuer cette étape une fois que l'instance FCI de récupération d'urgence est disponible et que le groupe de disponibilité peut être configuré avec deux réplicas.

Vous devez également générer le script des autres objets SQL Server dans la topologie héritée, desquels dépendent vos bases de données utilisateur, mais qui ne sont pas contenus dans les bases de données utilisateur restaurées (par exemple, les connexions SQL Server, les autorisations au niveau serveur associées, et les travaux SQL Server Agent).

Ce processus est similaire à celui que vous suivriez pour générer le script des objets dépendants externes sur la base de données mise en miroir, pour un partenariat de mise en miroir de bases de données. Il existe plusieurs méthodes permettant de transférer des objets de base de données et des principes entre des instances de SQL Server. La Tâche de transfert d'objets SQL Server d'Integration Services est l'une de ces méthodes. Une autre méthode, dans laquelle les connexions et les mots de passe sont transférés entre différentes instances, est décrite ici : http://support.microsoft.com/kb/918992/

Tableau 1 : Création d'une solution FCI+AG dans le centre de données principal

20

http://support.microsoft.com/kb/918992/

http://support.microsoft.com/kb/918992/

Configuration de la solution dans le centre de données de récupération d'urgenceCe tableau décrit le flux de travail permettant de configurer le serveur secondaire et les nœuds du centre de données de récupération d'urgence, et de créer le groupe de disponibilité.Étape Administrateur de

base de donnéesWindows Server \ Admini-strateur de cluster

Admini-strateur réseau

1. Ajoutez la fonctionnalité de clustering de basculement à tous les nœuds situés dans le centre de données de récupération d'urgence qui participent à la solution.

Oui (coordination des activités entre les rôles)

Oui

2. Examinez les conditions préalables et installez les mises à jour logicielles Windows Server requises sur chaque nœud dans le centre de données de récupération d'urgence.

Oui

3. Vérifiez que le compte que vous utilisez pour installer et configurer le WSFC est un compte de domaine. Ce compte doit également disposer d'autorisations administratives sur chaque nœud du cluster, et d'autorisations Créer des objets ordinateur et Lire toutes les propriétés pour le conteneur utilisé pour les comptes d'ordinateur de domaine. Si vous utilisez les mêmes comptes que le centre de données principal, ces autorisations sont déjà définies correctement.

Oui

4. À l'aide du gestionnaire de cluster de basculement, exécutez la validation de cluster des deux nœuds serveurs et du stockage partagé qui rejoint le WSFC existant. Si le message d'avertissement concernant le stockage asymétrique « Le disque ayant l’id XYZ est visible ou peut être mis en cluster uniquement à partir d’un sous-ensemble de nœuds » s'affiche, aucune action n'est requise ; cela est prévu et acceptable pour le stockage asymétrique. Exécutez la validation de manière itérative jusqu'à ce qu'il n'existe aucune erreur bloquante.


5. Une fois la validation terminée, utilisez le gestionnaire du cluster de basculement pour ajouter les deux nœuds de récupération d'urgence au WSFC existant.


6. Définissez le NodeWeight des nœuds WSFC du centre de données de récupération d'urgence sur un poids 0 (zéro) (voir la Figure 4 : Solution de haute disponibilité et de récupération d'urgence FCI+AG avec attributions de

Oui

21


Windows Server \ Admini-strateur de cluster


vote de nœud pour un exemple).7. Cette installation devrait utiliser un

stockage partagé et formaté accessible uniquement aux deux nœuds situés dans le centre de données de récupération d'urgence. Ces disques seront utilisés pour SQL Server à l'étape suivante.

Conservez la lettre de lecteur et le mappage pour simplifier le déploiement du groupe de disponibilité dans les étapes suivantes, et pour que les opérations de base de données ne nécessitent aucune intervention manuelle, ni l'arrêt de la session du groupe de disponibilité.

Oui

8. Déplacez le stockage disponible sur l'un des nœuds du centre de données de récupération d'urgence, afin de l'utiliser dans l'étape suivante.

Oui

9. Installez une instance FCI de SQL Server 2012 Enterprise sur le centre de données de récupération d'urgence. Vous devez appliquer l'option d'installation d'un nouveau cluster de basculement SQL Server sur l'un des nœuds, pour créer l'instance FCI, puis l'option d'ajout d'un nœud à un cluster de basculement SQL Server sur le deuxième nœud dans le centre de données de récupération d'urgence.

Oui Oui - Pour coordonner les adresses IP (si vous utilisez des adresses IP statiques) et les ports

10. Après l'installation des deux instances FCI, l'étape suivante consiste à activer les fonctionnalités du groupe de disponibilité AlwaysOn sur l'instance SQL Server du centre de données de récupération d'urgence.

Pour les étapes d'utilisation détaillées du Gestionnaire de configuration SQL Server ou, éventuellement, de PowerShell, consultez Activer et désactiver les groupes de disponibilité AlwaysOn. Notez que vous devez redémarrer l'instance pour que l'activation du groupe de disponibilité AlwaysOn prenne effet.

Oui

22




Windows Server \ Admini-strateur de cluster


11. Générez le script des autres objets SQL Server dans la topologie héritée, desquels dépendent vos bases de données utilisateur, mais qui ne sont pas contenus dans les bases de données utilisateur restaurées (par exemple, les connexions SQL Server, les autorisations au niveau serveur associées, et les travaux SQL Server Agent).

Ce sont les mêmes objets que vous avez déjà écrits et copiés vers l'instance FCI du centre de données principal.

Oui

12. Vérifiez que les propriétaires possibles des deux instances FCI sont définis correctement : pour INST_A les propriétaires possibles doivent être PRIMARYNODE1, PRIMARYNODE2 ; pour INST_B les propriétaires possibles doivent être DRNODE1, DRNODE2.

13. Créez un groupe de disponibilité (cette phase implique l'instance FCI principale et l'instance FCI de récupération d'urgence). Vous pouvez utiliser le mode de disponibilité asynchrone ou synchrone, en fonction des caractéristiques de la charge de travail et du réseau de votre environnement. Sélectionnez le basculement manuel pour les groupes de disponibilité. Dans une solution FCI+AG, le basculement FCI est automatique, et le basculement du groupe de disponibilité est manuel. Pour plus d'informations sur la configuration du basculement pour cette solution, consultez Création et configuration des groupes de disponibilité.

Oui Oui - Pour vérifier que les ports de point de terminaison sont ouverts et pour résoudre les erreurs, le cas échéant

14. Créez l'écouteur de groupe de disponibilité. Cette étape n'est pas nécessaire si vous avez déjà configuré ce paramètre lors de la création du groupe de disponibilité. Vous pouvez créer l'écouteur du groupe de disponibilité à l'aide de Transact-SQL, SQL Server PowerShell ou d'un assistant dans SQL Server Management Studio. Pour plus d'informations sur les différentes méthodes, consultez Créer ou configurer un écouteur de groupe de disponibilité.

Oui Oui Oui - Pour coordonner les adresses IP et les ports

23




http://msdn.microsoft.com/library/ff878265.aspx



Tableau 2 : Création d'une solution FCI+AG dans le centre de données de récupération d'urgence

Après avoir terminé les étapes, dans le gestionnaire du cluster de basculement Windows, un nouveau groupe apparaît sous Services et applications, portant le même nom que le groupe de disponibilité. Dans ce groupe, vous trouverez également la ressource d'écouteur de groupe de disponibilité et les adresses IP associées à l'écouteur (voir la Figure 5).

Figure 7 : Après la configuration de l'instance FCI pour la solution de haute disponibilité et de récupération d'urgence utilisant les groupes de disponibilité

La Figure 7 illustre la vue WSFC du déploiement. Notez qu'à titre d'illustration, l'écouteur de groupe de disponibilité de la figure présente une seule adresse IP associée ; toutefois, il est courant d'utiliser deux adresses IP dans les topologies à plusieurs centres de données.

Remarque : lorsque le groupe de disponibilité apparaît en tant que ressource dans le WSFC, vous ne devez pas tenter de le gérer à l'aide du gestionnaire du cluster de basculement ou d'interfaces d'étendue WSFC. Gérez plutôt le groupe de disponibilité dans le contexte de l'instance SQL Server via SQL Server Management Studio, Transact-SQL, ou Windows PowerShell. Pour comprendre pourquoi vous ne devez pas utiliser le gestionnaire du cluster de basculement ou d'autres interfaces d'étendue WSFC, consultez la publication de blog N'utilisez pas le gestionnaire du cluster de basculement pour basculer des groupes de disponibilité.

La Figure 8 illustre le déploiement de SQL Server Management Studio. La vue affiche l'une des instances FCI dans l'Explorateur d'objets, avec le dossier « AlwaysOn High Availability » ouvert. Dans cet exemple, l'instance FCI de récupération d'urgence est le réplica secondaire, et l'autre instance FCI est le réplica principal. Les trois bases de données de disponibilité qui participent au groupe apparaissent, ainsi que le nom de l'écouteur du groupe de disponibilité.

24



Figure 8 : Post-configuration de l'instance FCI pour la solution de haute disponibilité et de récupération d'urgence utilisant les groupes de disponibilité dans SQL Server Management Studio

Éléments à prendre en considération pour l'analyseLa migration d'une topologie utilisant une instance FCI et la mise en miroir de bases de données vers une solution utilisant une instance FCI et les groupes de disponibilité requiert de nouvelles méthodes d'analyse. Les méthodes et les outils que vous pouvez utiliser pour surveiller l'infrastructure du groupe de disponibilité comprennent le tableau de bord AlwaysOn dans SQL Server Management Studio, les informations d'état de l'Explorateur d'objets, les stratégies de Gestion basée sur des stratégies, les nouveaux compteurs de performances de groupe de disponibilité, les affichages catalogue, les vues de gestion dynamique, une session d'événements étendus qui suit les exécutions récentes des instructions liées aux DDL AlwaysOn, les problèmes de connectivité WSFC, les événements de basculement, les changements d'état et les événements de blocage de thread de restauration.

Le tableau de bord AlwaysOn est l'outil privilégié pour consulter rapidement l'intégrité d'un groupe de disponibilité spécifique. Il vous permet de voir l'emplacement de l'instance principale, le mode de basculement, l'état de synchronisation et la disponibilité de basculement des différents réplicas. Vous pouvez également accéder à la session d'événements étendus d'intégrité AlwaysOn directement à partir du tableau de bord pour afficher l'activité du groupe de disponibilité, les changements d'état et les événements les plus récents.

25

Figure 9 : Tableau de bord AlwaysOn

De plus, vous pouvez créer des alertes SQL Server Agent et des réponses à un travail en fonction des seuils du compteur de performances et des changements d'état du groupe de disponibilité. Pour plus d'informations et des instructions sur la manière de surveiller un environnement de groupe de disponibilité, consultez Surveillance des groupes de disponibilité.

Récupération après sinistreCette section détaille les étapes du flux de travail que vous devez suivre en cas de panne du réplica principal dans le centre de données principal. Elle couvre également les étapes requises pour restaurer la disponibilité du réplica principal depuis le centre de données de récupération d'urgence. Les causes d'une panne du réplica principal peuvent être les suivantes :

Échec de tous les nœuds FCI du centre de données principal Échec du stockage FCI du centre de données principal Échec ou panne de réseau ayant un impact sur l'ensemble du centre de données principal

Dans l'un de ces scénarios, un certain nombre d'actions doivent être effectuées au niveau du centre de données de récupération d'urgence afin de rétablir le service SQL Server pour les applications.

La Figure 10 illustre la fenêtre Informations de quorum de cluster pour ce scénario (ces informations sont accessibles à partir du tableau de bord AlwaysOn et du lien Afficher des informations de quorum de cluster ). Elle représente le quorum avant l'incident, où les deux nœuds de récupération d'urgence ont zéro vote.

26


Figure 10 : État précédant des votes de quorum du cluster

Le flux de travail suivant présente les étapes nécessaires pour restaurer un groupe de disponibilité dans le centre de données de récupération d'urgence en cas de panne du centre de données principal :

1. Forcez le quorum sur l'un des nœuds de récupération d'urgence, et vérifiez que les nœuds du centre de données principal ne forment pas leur propre quorum.

Le gestionnaire du cluster de basculement exécuté sur un nœud de récupération d'urgence ne fournira probablement pas d'emblée des informations utiles sur l'état du WSFC car le cluster n'a plus le quorum.

Figure 11 : Gestionnaire du cluster de basculement après un problème grave et avant la récupération

Étant donné que les instances FCI dépendent d'un WSFC opérationnel, elles sont accessibles à moins qu'un quorum du cluster et le service de cluster soient en cours d'exécution à la fois. Pour un scénario où l'état du centre de données principal est incertain et le service doit être restauré à partir du centre de données de récupération d'urgence secondaire pour répondre aux objectifs de récupération de l'entreprise, vous devez forcer le quorum sur l'un des nœuds de récupération d'urgence.

27

La commande Windows PowerShell suivante montre comment forcer un quorum sur l'un des nœuds de récupération d'urgence.

Start-ClusterNode –Name "DRNODE1" –FixQuorum

Après avoir exécuté cette commande, vous devriez voir un affichage semblable au suivant.

Name State------- --------drnode1 Joining

Remarque : si le service de cluster est toujours sur « DRNODE1 », vous pouvez utiliser la commande suivante dans Windows PowerShell pour arrêter le service avant de redémarrer le service de cluster avec un quorum forcé :

Stop-ClusterNode –Name "DRNODE1"

Pour connaître les autres outils que vous pouvez utiliser pour forcer un quorum, comme cluster.exe ou le gestionnaire du cluster de basculement, consultez Forcer un cluster WSFC à démarrer sans quorum.

2. Ouvrez le gestionnaire du cluster de basculement pour afficher l'état du cluster Windows. À ce stade, le cluster Windows doit avoir l'état de quorum forcé, et l'instance FCI secondaire doit fonctionner. L'instance FCI du centre de données principal restera hors connexion, tout comme les ressources du groupe de disponibilité.

Figure 12 : Gestionnaire du cluster de basculement après avoir forcé le quorum

3. Mettez le groupe de disponibilité en ligne sur l'instance FCI de récupération d'urgence.

Attention : si le réplica est configuré en mode asynchrone, la restauration du service peut entraîner une perte de données pour tous les enregistrements de journal non envoyés. Vous devez comprendre parfaitement les conséquences de cette opération.

Pour plus d'informations sur la procédure à suivre avant, pendant et après ce type de basculement manuel, consultez Effectuer un basculement manuel forcé d'un groupe de disponibilité.

28




Connectez-vous à l'instance FCI dans le centre de données de récupération d'urgence à l'aide de SQL Server Management Studio. SQL Server Management Studio doit indiquer que les bases de données de disponibilité sont dans un état non synchronisé (« Not synchronizing »). L'instance FCI de récupération d'urgence doit également indiquer un état de résolution (« Resolving ») comme dans la Figure 13.

Figure 13 : Explorateur d'objets SQL Server Management Studio après avoir forcé le quorum

Notez que dans la Figure 13 l'autre réplica, dans cet exemple « SQLFCIPrimary\INST_A », n'indique aucun état dans l'Explorateur d'objets sous le dossier « Availability Replicas » de AG1. Il s'agit de l'instance FCI du centre de données principal qui n'est plus accessible en raison de la panne.

Si le risque de perte de données est acceptable et le service doit être restauré sur le centre de données, exécutez la syntaxe Transact-SQL suivante sur l'instance FCI de récupération d'urgence afin de forcer le basculement.

ALTER AVAILABILITY GROUP [AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS;

À ce stade, les bases de données de votre groupe de disponibilité doivent être disponibles. Reportez-vous à la Figure 14 pour un exemple de l'état du basculement après le forçage.

29

Figure 14 : Explorateur d'objets après un basculement forcé

Après la remise en ligne, les nouvelles connexions à l'écouteur du groupe de disponibilité sont acheminées automatiquement sur le réplica principal actuel, qui est maintenant hébergé par l'instance FCI de récupération d'urgence.

Notez également que des messages d'avertissement peuvent s'afficher pour signaler que les nœuds du centre de données principal sont indisponibles dans SQL Server Management Studio. La Figure 15 illustre ce type de message.

30

Figure 15 : Tableau de bord AlwaysOn après un basculement forcé

4. À partir d'un nœud WSFC de récupération d'urgence, supprimez les votes des nœuds du centre de données principal et attribuez des votes aux nœuds du centre de données de récupération d'urgence. Les votes peuvent est supprimés même si les nœuds du centre de données principal ne sont pas disponibles. Les deux nœuds avec un poids de « 1 » sont les nœuds WSFC de récupération d'urgence.



(Get-ClusterNode "PrimaryNode1").NodeWeight=0

(Get-ClusterNode "PrimaryNode2").NodeWeight=0

Remarque : si le site de récupération d'urgence est voué à être utilisé pour une longue période, il est recommandé que des membres de vote supplémentaires (nœud ou partage de fichiers WSFC) soient ajoutés.

Avant de continuer, vérifiez que les votes de nœud ont été modifiés comme prévu à l'aide de la commande Windows PowerShell suivante.

Get-ClusterNode | fl NodeName, NodeWeight

Comme mentionné plus haut dans ce document, la plupart des entreprises de grande taille répartissent les fonctions entre les rôles d'administrateur de base de données, d'administrateur Windows Server (ou cluster) et d'administrateur réseau. Le tableau suivant récapitule le flux de travail de récupération d'urgence décrit précédemment et indique les fonctions habituellement prises en charge par les différents rôles d'entreprise, à des fins de planification.

31


Windows Server \ administrateur de cluster


1. Vérifiez l'état actuel du centre de données principal et des nœuds de récupération d'urgence WSFC restants, et coordonnez les tâches.

Oui Oui Oui

2. Forcez le quorum sur l'un des nœuds du site de récupération d'urgence pour accéder à l'instance FCI de récupération d'urgence.

Oui

3. Forcez le basculement du groupe de disponibilité sur l'instance FCI de récupération d'urgence.

Oui

4. Ajoutez des votes aux nœuds de récupération d'urgence et supprimez les votes sur les nœuds principaux.

Oui

Tableau 3 : Récupération après sinistre par rôle de travail

Rebasculer sur le centre de données principalLe service étant restauré sur le centre de données de récupération d'urgence, le scénario illustré dans ce document est supposé temporaire et viable tant que les problèmes du centre de données principal ne sont pas résolus. Il existe de nombreux scénario de panne différents et, par conséquent, de nombreux types de récupération. Dans le scénario décrit ci-après, les serveurs du centre de données principal sont arrêtés pendant une longue période.

Une fois les problèmes du centre de données principal résolus, et les nœuds du centre de données principal de nouveau opérationnels, les nœuds tentent de se connecter au WSFC. Après la reconnexion au WSFC et la reprise des services de cluster, les poids des nœuds affectés au nœud de récupération d'urgence devraient être actifs. De plus, ce scénario suppose que les installations SQL Server d'origine et les bases de données associées sont intactes.

Le réplica sur l'instance FCI du centre de données principal précédemment en échec est dans un état non synchronisé (« Not synchronizing ») (reportez-vous à la Figure 16).

32

Figure 16 : SQL Server Management Studio après la récupération de l'instance FCI principale mais avant la reprise du groupe de disponibilité

L'instance SQL Server du site de récupération d'urgence (dans notre exemple « SQLFCIDR\DC2 ») est toujours le réplica principal. Notez également le symbole « pause » en regard de chaque base de données de disponibilité dans le dossier Availability Databases.

À ce stade, vous devez choisir entre sauver les données (autrement dit, les modifications apportées aux données dans le réplica principal d'origine qui n'ont pas été envoyées au réplica de récupération d'urgence juste avant l'incident) ou passer au rétablissement des sessions de réplica.

Attention : reprendre les réplicas du groupe de disponibilité à ce stade peut entraîner une perte de données ; si la perte de données n'est pas acceptable, les données doivent être enregistrées avant que leur déplacement soit repris. En revanche, la non reprise du groupe de disponibilité entraîne l'augmentation de la taille des fichiers du journal des transactions sur les bases de données du réplica de récupération d'urgence.

Pour cela, vous pouvez créer un instantané de base de données sur les bases de données secondaires interrompues (qui étaient auparavant les bases de données principales) afin d'extraire les données appropriées requises pour la resynchronisation avec la version du réplica de récupération d'urgence des bases de données de disponibilité. L'exemple suivant montre comment créer un instantané de base de données sur une base de données de disponibilité non synchronisée.

-- Create the database snapshotCREATE DATABASE AppDB_A1 ON( NAME = AppDB, FILENAME = 'R:\MSSQL11.MSSQLSERVER\MSSQL\Data\AppDB_A1.ss' )AS SNAPSHOT OF AppDB;GO

33

Les données requises peuvent maintenant être extraites de l'instantané de base de données et insérées correctement dans le réplica principal actuel, avant de reprendre le déplacement des données.

Remarque : pour plus d'informations sur les risques liés au basculement forcé et pour réduire la perte de données, consultez Basculement et modes de basculement.

Une fois le risque de perte de données écarté, vous pouvez restaurer le service sur le centre de données principal. L'étape suivante consiste à replacer le rôle de réplica principal sur le centre de données principal, de manière contrôlée :

1. Commencez par migrer de façon contrôlée sur le centre de données principal en rajoutant les votes de quorum aux deux nœuds du centre de données principal. Après cela, vérifiez de nouveau que tous les nœuds du WSFC ont un vote.

2. Pour reprendre chaque base de données participant au groupe de disponibilité, exécutez les commandes Transact-SQL ALTER DATABASE sur l'instance FCI du centre de données principal. Ceci est un exemple.

ALTER DATABASE AppDB SET HADR RESUME;GOALTER DATABASE ConfigDB SET HADR RESUME;GOALTER DATABASE ReportDB SET HADR RESUME;GO

3. Pour synchroniser avant le basculement, modifiez le groupe de disponibilité sur l'instance FCI de récupération d'urgence afin d'utiliser temporairement le mode de disponibilité avec validation synchrone. Idéalement, le paramètre de validation synchrone doit être appliqué au cours d'une période de faible activité de l'application, afin de réduire l'impact de la latence des transactions sur les utilisateurs.

Voici un exemple de la commande Transact-SQL (exécutée sur l'instance FCI principale actuelle dans le centre de données de récupération d'urgence). Ici, AG1 est le groupe de disponibilité et le réplica du centre de données principal est SQLFCIPrimary\INST_A.

USE [master]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);GO

Au cours de la même session SQL Server Management Studio, exécutez la commande suivante pour définir la validation synchrone également sur le réplica de récupération d'urgence.

34

http://technet.microsoft.com/library/hh213151.aspx

USE [master]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);GO

4. Vérifiez l'état de synchronisation entre les deux emplacements (les deux états de réplica doivent indiquer « healthy » avant de passer à l'étape suivante, ce qui signifie que les deux réplicas de validation synchrone sont synchronisés).

SELECT role_desc,synchronization_health_desc

FROM sys.dm_hadr_availability_replica_states;

5. Pour basculer de l'instance FCI du centre de données de récupération d'urgence sur l'instance FCI de l'ancien centre de données principal, connectez et exécutez le script suivant sur l'instance FCI du centre de données principal, qui deviendra le nouveau réplica principal.

ALTER AVAILABILITY GROUP [AG1] FAILOVER;

6. Si votre topologie utilise le mode hautes performances, comme indiqué précédemment, définissez la validation asynchrone sur le nœud du réplica FCI de récupération d'urgence. Exécutez le code Transact-SQL suivant sur le réplica principal.

USE [master]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);GO

USE [master]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);GO

7. Supprimez les votes de quorum des nœuds de récupération d'urgence.

35

Le tableau suivant récapitule le flux de travail de récupération d'urgence décrit précédemment et indique les fonctions habituellement prises en charge par les différents rôles d'entreprise, à des fins de planification.


Windows Server \ administrateur de cluster


1. Une fois le service du centre de données principal, les nœuds et

l'instance FCI restaurés, rajoutez les votes de quorum sur les nœuds principaux d'origine.

Oui

2. Rétablissez les sessions des bases de données de disponibilité sur chaque réplica secondaire.

Oui

3. Définissez la validation synchrone sur le réplica FCI de récupération d'urgence et sur le réplica FCI du centre de données principal.

Oui

4. Vérifiez l'état de synchronisation entre les deux emplacements (les deux états de réplica doivent indiquer « healthy » avant de passer à l'étape suivante).

Oui

5. Basculez sur le réplica FCI du centre de données principal.

Oui

6. Rétablissez la validation asynchrone sur le réplica de récupération d'urgence (conformément à la configuration d'origine).

Oui

7. Supprimez les votes des nœuds WSFC de récupération d'urgence.

Oui

Tableau 4 : Rebasculer sur le centre de données principal

ConclusionLes groupes de disponibilité SQL Server 2012 AlwaysOn peuvent remplacer la mise en miroir de bases de données dans les topologies qui utilisent des instances FCI pour la haute disponibilité et la mise en miroir de bases de données pour la récupération d'urgence. Ce modèle de conception étend les fonctionnalités au-delà de ce qui a été proposé dans les versions antérieures, autorisant une unité de basculement à plusieurs bases de données, des réplicas en lecture seule, et bien plus encore. La finalité de ce livre blanc est de présenter une solution de haute disponibilité et de récupération d'urgence utilisant des instances FCI AlwaysOn et des groupes de disponibilité AlwaysOn pour remplacer l'architecture héritée.

Le déploiement réussi d'une telle solution HA/DR sollicite non seulement l'équipe d'administrateurs de base de données, mais implique également une collaboration étroite entre ces derniers, l'équipe

36

d'administration Windows Server, et l'équipe de gestion du réseau au sein du service informatique. Les compétences transversales sont d'une aide précieuse lorsque vous déployez la solution HA/DR.

Références Modèles de conception pour la haute disponibilité et la récupération d'urgence SQL Server 2012

AlwaysOn (http://go.microsoft.com/fwlink/?LinkId=255048) Guide de solutions Microsoft SQL Server AlwaysOn pour la haute disponibilité et la récupération

d'urgence (http://msdn.microsoft.com/library/hh781257.aspx) Instances de cluster de basculement AlwaysOn

(http://technet.microsoft.com/library/ms189134.aspx) Présentation des groupes de disponibilité AlwaysOn

(http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx) Clustering de basculement et groupes de disponibilité AlwaysOn

(http://technet.microsoft.com/library/ff929171.aspx) Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité

AlwaysOn (http://technet.microsoft.com/library/ff878487(v=sql.110).aspx) Guide pas à pas du cluster de basculement : configuration du quorum dans un cluster de

basculement (http://technet.microsoft.com/library/cc770620(v=WS.10).aspx) Correctif logiciel Windows Server pour les votes de quorum

(http://support.microsoft.com/kb/2494036) Windows PowerShell (http://technet.microsoft.com/library/bb978526) Mappage des commandes Cluster.exe aux applets de commande Windows PowerShell pour les

clusters de basculement (http://technet.microsoft.com/library/ee619744(v=WS.10).aspx) Windows PowerShell Survival Guide

(http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survival-guide-en-us.aspx)

Applets de commande de cluster de basculement dans Windows PowerShell (http://technet.microsoft.com/library/ee461009.aspx)

SQL Server PowerShell (http://msdn.microsoft.com/fr-fr/library/hh245198.aspx)

Pour plus d'informations :

Site Web SQL Server (http://www.microsoft.com/sqlserver/)

TechCenter SQL Server (http://technet.microsoft.com/sqlserver/)

Centre de développement SQL Server (http://msdn.microsoft.com/sqlserver/)

Avez-vous trouvé ce document utile ? Nous apprécions vos commentaires. Sur une échelle de 1 (faible) à 5 (excellent), quelle note donneriez-vous à ce document ? Expliquez pourquoi. Par exemple :

Avez-vous attribué une bonne note car le document fournit de bons exemples, contient des captures d'écran très utiles, est clairement rédigé, ou pour d'autres raisons ?

Avez-vous attribué une mauvaise note car le document fournit de mauvais exemples, contient des captures d'écran pas claires ou est mal rédigé ?

37

http://msdn.microsoft.com/sqlserver/

http://technet.microsoft.com/sqlserver/

http://www.microsoft.com/sqlserver/

http://msdn.microsoft.com/fr-fr/library/hh245198.aspx

http://technet.microsoft.com/library/ee461009.aspx

http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survival-guide-en-us.aspx

http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survival-guide-en-us.aspx

http://technet.microsoft.com/library/ee619744(v=WS.10).aspx

http://technet.microsoft.com/library/bb978526



http://technet.microsoft.com/library/ff878487(v=sql.110).aspx

http://technet.microsoft.com/library/ff929171.aspx

http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx

http://technet.microsoft.com/library/ms189134.aspx



Vos commentaires nous aident à améliorer la qualité des livres blancs que nous publions.

Envoyez vos commentaires

38

mailto:[email protected]?subject=White%20Paper%20Feedback:%20Guide%20de%20l'architecture%20AlwaysOn%A0:%20cr%E9ation%20d'une%20solution%20de%20haute%20disponibilit%E9%20et%20de%20r%E9cup%E9ration%20d'urgence%20en%20utilisant%20des%20instances%20de%20cluster%20de%20basculement%20et%20des%20groupes%20de%20disponibilit%E9

AlwaysOn Architecture Guide - Building a High...

Documents

Transcript of AlwaysOn Architecture Guide - Building a High...