Groupes de disponibilité AlwaysOn pour la haute
publicité
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. 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 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 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. 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. 4 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 : 5 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. Les groupes de disponibilité et l'écouteur de groupe de disponibilité associé prennent en charge la redirection cliente automatique sur le réplica principal ou la redirection aux serveurs secondaires lisibles disponibles. Les écouteurs du groupe de disponibilité évitent de désigner un partenaire de basculement dans la chaîne de connexion du client. La Figure 2 illustre la solution de haute disponibilité et de récupération d'urgence utilisant des groupes de disponibilité. Centre de données de récupération d'urgence Centre de données principal Cluster de basculement Windows Server (un cluster WSFC réparti dans deux centres de données) SQL Server SQL Server Principal SQL Server Secondaire Secondaire Synchrone Asynchrone Groupe de disponibilité Figure 2 : Utilisation des groupes de disponibilité pour la haute disponibilité et la récupération d'urgence Comme l'illustre la Figure 2, les trois nœuds, chacun exécutant une instance de SQL Server, participent à un cluster de basculement Windows Server (WSFC) unique qui s'étend sur deux centres de données. En outre, il est important de noter qu'il s'agit d'une solution non partagée, et que les nœuds ne partagent pas de stockage avec un autre nœud. Chaque nœud exécute une instance de SQL Server et possède sa propre copie des données. Remarque : la figure 2 illustre un scénario simple avec deux centres de données : le centre de données principal héberge deux réplicas, et le centre de données de récupération d'urgence héberge un réplica. L'architecture permet des variantes de cette topologie, avec plusieurs centres de données ainsi que plusieurs réplicas (jusqu'à cinq). 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. L'une des ces variantes, avec trois centres de données, est présentée à l'annexe A. Planification du déploiement et éléments à prendre en compte Les deux sections suivantes décrivent les éléments clés, les contraintes et les conditions préalables à prendre en compte lorsque vous planifiez le déploiement des groupes de disponibilité pour la haute disponibilité et la récupération d'urgence. Conditions préalables pour la topologie Il est important de comprendre les conditions préalables et les restrictions avant de concevoir une solution de haute disponibilité et de récupération d'urgence utilisant des groupes de disponibilité. Pour plus d'informations sur les conditions préalables et les restrictions applicables à l'utilisation des groupes de disponibilité, consultez Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server). 6 Unité de basculement Dans cette solution de haute disponibilité et de récupération d'urgence, l'unité de basculement est le groupe de disponibilité (un groupe de bases de données utilisateur). Les travaux de SQL Server Agent, les connexions, les serveurs liés, ainsi que d'autres objets stockés hors des bases de données de disponibilité ne basculent pas avec le groupe de disponibilité. Envisagez l'utilisation de bases de données à relation contenant-contenu pour contenir les connexions qui basculent entre les réplicas de disponibilité. Pour les autres objets extérieurs à la base de données utilisateur tels que les travaux SQL Server Agent, les serveurs liés et les packages SQL Server Integration Services, vous devez effectuer une synchronisation supplémentaire entre les instances de SQL Server. Éléments à prendre en compte pour remplacer la copie des journaux de transaction Si vous remplacez une solution antérieure impliquant la copie des journaux de transaction, par les groupes de disponibilité, gardez à l'esprit les points suivants : Si vous supprimez la copie des journaux de transaction, aucune « application différée » ne sera possible sur les réplicas secondaires. Les enregistrements du journal du réplica du groupe de disponibilité sont appliqués immédiatement, et l'application différée fournie par la copie des journaux de transaction n'est pas disponible pour les groupes de disponibilité. Si cette fonctionnalité était requise dans le cadre de votre solution héritée, vous devez envisager une alternative ou utiliser la copie des journaux de transaction conjointement aux groupes de disponibilité. De plus, si vous supprimez la copie des journaux de transaction, le travail standard de sauvegarde des journaux est aussi supprimé. Les groupes de disponibilité ne remplacent pas une stratégie de sauvegarde et de restauration. Vous devrez planifier des sauvegardes régulières des fichiers journaux dans un processus distinct, afin d'assurer la gestion essentielle du journal des transactions pour chaque base de données de disponibilité du groupe de disponibilité. Modèle de quorum et votes de nœud Remarque : le quorum et les sujets associés abordés dans ce livre blanc s'appliquent à une solution exécutée sur les systèmes d'exploitation Windows Server 2008 et Windows Server 2008 R2, avec les mises à jour logicielles appropriées. Étant donné que l'infrastructure sous-jacente d'un groupe de disponibilité est un WSFC, il est important de déterminer le modèle de quorum adéquat pour le WSFC. La configuration du quorum est gérée au niveau du WSFC, quel que soit le nombre de réplicas et le nombre de groupes de disponibilité hébergés dans le WSFC. WSFC prend en charge quatre modèles de quorum. Toutefois, certains modèles de quorum ne sont pas pertinents pour la solution de stockage non partagé telle que décrite dans ce livre blanc. Par conséquent, les modèles de quorum sur disque partagé (Nœud et disque majoritaire, Aucune majorité - Disque uniquement) ne sont pas applicables. Cela laisse deux modèles de quorum pour l'architecture de solution visée : Nœud et partage de fichiers majoritaires ou Nœud majoritaire. Pour plus d'informations sur les quatre modèles de quorum, consultez Guide pas à pas du cluster de basculement : configuration du quorum dans un cluster de basculement. 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 WSFC 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, car cela dépend des nœuds de distribution dans le centre de données principal et de récupération d'urgence. Un correctif logiciel Windows Server est disponible (http://support.microsoft.com/kb/2494036) et vous permet d'attribuer 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. 7 Les recommandations générales pour le vote de quorum d'une solution de haute disponibilité et de récupération d'urgence AlwaysOn sont fournies dans la section Réglages recommandés pour le vote de quorum de la rubrique Modes de quorum WSFC et configuration de vote dans 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 compte ces instructions pour la solution de haute disponibilité et de récupération d'urgence des groupes de disponibilité présentée à la figure 2, le schéma de vote est le suivant : Un vote sur chaque nœud dans le centre de données principal Zéro vote sur le nœud dans le centre de données de récupération d'urgence Cette attribution de vote permet de garantir que le quorum des nœuds dans le centre de données principal ne sera pas affecté en cas de pannes dans le centre de données de récupération d'urgence ou de perte de connectivité entre les deux centres de données. Si vous avez un nombre impair de nœuds votants, le modèle de quorum avec nœud majoritaire est le meilleur choix. Étant donné que la topologie décrite dans ce livre blanc possède un nombre pair de nœuds votants (les deux nœuds du centre de données principal), vous pouvez choisir librement l'une des deux options suivantes : Ajouter un nœud votant supplémentaire au WSFC dans le centre de données principal, puis utiliser le modèle de quorum Nœud majoritaire. Ce nœud supplémentaire ne requiert pas l'installation de SQL Server, et n'est pas nécessairement un réplica du groupe de disponibilité. Cette configuration, avec les votes de nœud appropriés, est illustrée à la Figure 3 (la procédure d'affectation des votes de nœud est abordée plus loin dans le livre blanc). Centre de données de récupération d'urgence Centre de données principal Cluster de basculement Windows Server (un cluster WSFC réparti dans deux centres de données) SQL Server SQL Server VOTE VOTE AUCUNE VOTE Secondaire Principal SQL Server Secondaire Synchrone Asynchrone Groupe de disponibilité VOTE Serveur supplémentaire pour le modèle de quorum Nœud majoritaire Figure 3 : Affectation des votes de nœud pour le déploiement d'un groupe de disponibilité pour la haute disponibilité et la récupération d'urgence avec le modèle de quorum Nœud majoritaire 8 Utilisez le modèle de quorum Nœud et partage de fichiers majoritaires avec un témoin de partage de fichier protégé. Le partage de fichiers fournit un vote supplémentaire pour établir un quorum, il ne contient pas de données SQL Server. Cette configuration avec les votes de nœud appropriés est illustrée dans la Figure 4. Centre de données de récupération d'urgence Centre de données principal Cluster de basculement Windows Server (un cluster WSFC réparti dans deux centres de données) SQL Server SQL Server VOTE VOTE AUCUNE VOTE Secondaire Secondaire Principal SQL Server Synchrone Asynchrone Groupe de disponibilité VOTE Partage de fichiers Figure 4 : Affectation des votes de nœud pour le déploiement d'un groupe de disponibilité pour la haute disponibilité et la récupération d'urgence avec le modèle de quorum Nœud et partage de fichiers majoritaires Notez que le témoin de partage de fichiers est en dehors du WSFC qui héberge le groupe de disponibilité. Un partage de fichiers donné peut servir de témoin à un ou plusieurs WSFC. Le témoin de partage de fichiers, s'il est utilisé, a toujours un vote. Vous ne pouvez pas affecter 0 vote à un témoin de partage de fichiers. Le modèle de quorum et les affectations de vote présentés à la figure 3 et à la figure 4 supposent que vous avez trois réplicas (un réplica principal et deux secondaires) du groupe de disponibilité (deux réplicas dans le centre de données principal, et un réplica dans le centre de données de récupération d'urgence). Si vous avez un nombre de nœuds et de réplicas différent, les affectations de vote peuvent différer légèrement, mais les principes de base restent les mêmes. Par exemple, si vous avez un réplica supplémentaire dans le centre de données principal (pour réduire la charge de lecture ou de sauvegarde), vous aurez un total de trois nœuds dans le centre de données principal et vous pourrez par conséquent utiliser le modèle de quorum Nœud majoritaire sans besoin de nœud supplémentaire (comme illustré dans la figure 3) ni de témoin de partage de fichiers (comme illustré dans la figure 4). Dans ce scénario, vous affectez un vote sur chaque nœud dans le centre de données principal, et zéro vote au nœud du centre de données de récupération d'urgence. Le modèle de quorum et les affectations de vote présentés à la figure 3 et à la figure 4 supposent également que la solution s'étend sur deux centres 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 ou modifier le modèle de quorum et les votes de nœud Il existe plusieurs façons de consulter et de modifier le modèle de quorum du cluster et les votes de quorum. Les tableaux suivants répertorient les différents outils permettant d'effectuer ces tâches. 9 Pour afficher le modèle de quorum Gestionnaire du cluster de basculement Windows Windows PowerShell Cluster.exe Vues de gestion dynamique (DMV) SQL Server Tableau de bord AlwaysOn dans SQL Server Management Studio Pour modifier le modèle de quorum Gestionnaire du cluster de basculement Windows Windows PowerShell Cluster.exe Pour afficher les votes de nœud Windows PowerShell Cluster.exe Vues de gestion dynamique (DMV) de SQL Server Tableau de bord AlwaysOn Pour modifier les votes de nœud Windows PowerShell Cluster.exe Configurer le mode de quorum WSFC Voici des exemples d'utilisation de Windows PowerShell via la ligne de commande pour afficher le modèle actuel du quorum, ainsi que 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 \\EMU-DC\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é en tant que 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 une logique intégrée pour ajouter ces autorisations au témoin de partage de fichiers, à condition que le compte d'administrateur qui modifie le modèle de quorum dispose des autorisations appropriées sur le partage de fichiers. Utilisation des vues de gestion dynamique (DMV) et du tableau de bord AlwaysOn pour afficher les informations de quorum Bien 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 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. 10 SELECT FROM cluster_name, quorum_type_desc, quorum_state_desc sys.dm_hadr_cluster; Lorsque cette requête est exécutée dans l'exemple d'environnement abordé dans ce livre blanc, elle retourne les valeurs suivantes. cluster_name -----------EMU-AGClstr quorum_type_desc ---------------NODE_AND_FILE_SHARE_MAJORITY quorum_state_desc ----------------NORMAL_QUORUM Pour afficher les votes de nœud, interrogez la vue de gestion dynamique sys.dm_hadr_cluster_members. SELECT FROM member_name, number_of_quorum_votes sys.dm_hadr_cluster_members; Lorsque cette requête est exécutée dans l'exemple d'environnement abordé 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 ----------- ---------------------EMU-SQL1 1 EMU-SQL2 1 EMU-SQL3 0 FSWitness 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). Figure 5 : Affichage des votes de quorum et de l'état du cluster dans le tableau de bord AlwaysOn pour le modèle de quorum Nœud majoritaire 11 Bien que la colonne Votes 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 semblable à 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œud La 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, EMU-SQL3 représente un nœud WSFC spécifique situé dans le centre de données secondaire. 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 "EMU-SQL3").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. 12 Connectivité client Cette section décrit brièvement les problèmes de connectivité client lorsque vous adoptez une solution de groupe de disponibilité. 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). Chaînes de connexion pour la mise en miroir de bases de données héritée Si vous migrez vos connexions d'une solution héritée de mise en miroir de bases de données qui contient l'attribut de partenaire de basculement, vous pouvez continuer à utiliser votre chaîne de connexion de mise en miroir de bases de données uniquement si le groupe de disponibilité est configuré avec un seul réplica secondaire. Le réplica secondaire ne peut pas être activé pour l'activité en lecture seule. Vous pouvez indiquer le nom du serveur partenaire initial et, éventuellement, le nom du partenaire de basculement. Gardez à l'esprit qu'il ne s'agit pas d'une solution recommandée à long terme et que ce contournement ne s'applique pas à la solution de déploiement utilisée dans ce livre blanc, car cette conception spécifique exige trois réplicas au minimum (un réplica principal et deux réplicas secondaires). Écouteur de groupe de disponibilité Pour les groupes de disponibilité, vous pouvez indiquer un nom d'écouteur de groupe de disponibilité pour l'attribut de serveur. L'écouteur de groupe de disponibilité est un nom de réseau virtuel (VNN) que vous créez pour l'utiliser avec un groupe de disponibilité spécifique. Ce nom est lié à une ou plusieurs adresses TCP/IP et ports d'écoute, et est utilisé pour se connecter automatiquement au réplica principal, où qu'il soit hébergé. Le VNN évite de spécifier un attribut de partenaire de basculement et permet une topologie mise à l'échelle pouvant comporter jusqu'à cinq emplacements de réplica de disponibilité. Par exemple, si un groupe de disponibilité bascule sur Node2 à partir de Node1, les nouvelles connexions à l'écouteur de groupe de disponibilité se connectent automatiquement au réplica qui héberge actuellement le réplica principal. De plus, l'écouteur de groupe de disponibilité peut également être utilisé pour router automatiquement l'activité en lecture seule vers les réplicas en lecture seule secondaires. Pour plus d'informations sur cette fonctionnalité, consultez Configurer le routage en lecture seule pour un groupe de disponibilité (SQL Server). Prise en charge des connexions à plusieurs sous-réseaux Concernant les autres attributs de connexion liés aux groupes de disponibilité, nous recommandons que les chaînes de connexion du groupe de disponibilité spécifient l'attribut MultiSubnetFailover pour les topologies de sous-réseau simple et de sous-réseaux multiples à la fois, lorsqu'elles référencent un nom d'écouteur de groupe de disponibilité. Lorsque cet attribut de chaîne de connexion est activé, 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 de groupe de disponibilité en parallèle. Si vous utilisez d'anciennes bibliothèques clientes qui ne prennent pas en charge l'attribut MultiSubnetFailover, vous devez envisager d'augmenter le délai de connexion du client dans la chaîne de connexion de l'application pour tenir compte de la latence de connectivité potentielle dans une topologie à plusieurs sous-réseaux. Le paramètre de délai d'expiration doit refléter une valeur supérieure au temps de basculement moyen du groupe de disponibilité, selon l'environnement spécifique. Pour plus d'informations sur la prise en charge du client, consultez Prise en charge des fonctionnalités de récupération d'urgence, haute disponibilité par SQL Server Native Client. 13 Générer la solution de groupe de disponibilité Cette section présente les étapes et le flux de travail requis pour créer un groupe de disponibilité afin de mettre en œuvre une solution de haute disponibilité locale et de récupération d'urgence distante. Ce document décrit la création d'un nouvel environnement similaire à la topologie illustrée dans la figure 4 et dans les figures précédentes. N'oubliez pas que ce modèle de conception spécifique suppose qu'un stockage non partagé est utilisé pour chaque instance de SQL Server. La configuration minimale requise pour SQL Server 2012 exige Windows Server 2008 R2 avec Service Pack 1 (SP1) ou Windows Server 2008 avec SP2. Les instructions suivantes supposent que Windows Server 2008 R2 SP1 Enterprise est le système d'exploitation du nœud du serveur. Le tableau 1 décrit les étapes requises pour créer un groupe de disponibilité pour la haute disponibilité locale et la récupération d'urgence distante. Bien que chaque étape ne soit pas reprise ici de façon détaillée, l'objectif de cette section est d'aider à clarifier la séquence du flux de travail parmi les nombreuses étapes d'implémentation et les nombreux rôles de travail participants. La documentation afférente est référencée le cas échéant. Les étapes suivantes sont détaillé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 important de mettre en place une communication efficace et de coordonner les activités entre les rôles. Étape Administrateur de base de données Windows Server \ administrateur de cluster 1. Démarrez le processus en ajoutant la fonctionnalité de clustering de basculement aux deux nœuds récemment, configurés situés dans le centre de données principal, et au troisième nœud récemment configuré qui se trouve dans le centre de données secondaire. Pour plus d'informations sur ce processus, consultez Installer la fonctionnalité de clustering de basculement et Conditions spécifiques des clusters de basculement. Oui - Pour la coordination des activités entre les rôles Oui 14 Administrateur réseau Étape 2. 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 Active Directory à 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, ainsi que des instructions détaillées, consultez Guide pas à pas du cluster de basculement : configuration de comptes dans Active Directory. 3. À l'aide du gestionnaire de cluster de basculement, exécutez la validation de cluster des trois nœuds serveurs entre les deux centres de données qui rejoindront le WSFC. Étant donné que le modèle de conception que nous abordons dans ce document n'utilise pas le stockage partagé, les tests de stockage partagé ne sont pas effectués pendant la validation. Après avoir exécuté la validation de cluster, vérifiez qu'aucune erreur matérielle n'est détectée avant de créer le WSFC. Même si vous pouvez passer à l'étape suivante en dépit des avertissements, il est important de pousser davantage l'analyse afin de garantir une configuration stable. Pour plus d'informations, notamment des instructions pour effectuer un test de validation, consultez Validation d'une configuration de cluster de basculement. 15 Administrateur de base de données Windows Server \ administrateur de cluster Administrateur réseau Oui Oui Oui - Pour tous les problèmes qui peuvent survenir pour la connexion des nœuds Étape 4. Après avoir terminé la validation, utilisez le gestionnaire de cluster de basculement pour créer un WSFC à trois nœuds. Pour plus d'informations sur ce processus, consultez Créer un cluster de basculement. En supposant qu'il existe trois nœuds dans votre WSFC, la configuration par défaut du mode de quorum sera Nœud majoritaire à ce stade. Vous pouvez modifier le modèle de quorum ultérieurement en Nœud et partage de fichiers majoritaires, si vous le souhaitez, ou vous pouvez ajouter un autre nœud en tant que nœud de vote seul, sans besoin d'installer SQL Server. 5. Pour empêcher que le nœud du centre de données de récupération d'urgence affecte la disponibilité des nœuds du centre de données principal, installez le correctif détaillé dans l'article 2494036 de la base de connaissances Un correctif logiciel est disponible pour vous permettre de configurer un nœud de cluster qui n'a pas de votes de quorum dans Windows Server 2008 et Windows Server 2008 R2. Après avoir installé ce correctif sur chaque nœud WSFC, suivez les étapes détaillées dans la section Configurer les votes de nœud de ce document pour affecter au paramètre NodeWeight du nœud WSFC du centre de données de récupération d'urgence la valeur 0 (zéro) poids. Cela signifie que seuls les deux nœuds du centre de données principal et le témoin de partage de fichiers, que vous configurerez à l'étape suivante, ont des votes. Ce flux de travail suppose que vous avez choisi un témoin de partage de fichiers au lieu d'un serveur supplémentaire pour la majorité des nœuds. Si vous aviez sélectionné un serveur supplémentaire pour fournir un vote, les mêmes considérations sur le vote de quorum seraient applicables. 16 Administrateur de base de données Windows Server \ administrateur de cluster Administrateur réseau Oui Oui - Pour tous les problèmes qui peuvent survenir pour la connexion des nœuds Oui Étape Administrateur de base de données 6. Puisque le troisième nœud est dans un centre de données différent et n'a plus de vote, vous devez modifier ce modèle de quorum en Nœud et partage de fichiers majoritaires. Créez un partage de fichiers dans le centre de données principal sur un nœud serveur qui ne participera pas au WSFC. Ce partage de fichiers se comportera comme le témoin de partage de fichiers. Après avoir créé le partage de fichiers, suivez les instructions décrites plus haut dans ce document pour modifier la configuration du quorum en Nœud et partage de fichiers majoritaires. Avant de modifier la configuration, assurezvous d'avoir accordé les autorisations en lecture et en écriture sur le partage de fichiers témoin au compte de cluster WSFC. 7. Installez une instance autonome de SQL Server 2012 Enterprise sur chacun des trois nœuds WSFC. Chaque nœud doit avoir accès à son propre stockage local et non partagé pour être utilisé par SQL Server. Pour chaque nœud WSFC, installez le moteur de base de données SQL Server 2012 Enterprise (avec les autres fonctionnalités facultatives utilisées dans votre environnement), en suivant les mêmes étapes que vous suivriez pour installer une instance autonome de SQL Server. Bien qu'il s'agisse d'un processus autonome classique, vous devez vous assurer que toutes les instances de SQL Server que vous installez utilisent le même classement SQL Server pour héberger les réplicas du groupe de disponibilité (de plus, vous devez faire en sorte qu'elles correspondent au classement de votre environnement de mise en miroir de bases de données et de copie de journaux de transaction existant). Il est également recommandé d'utiliser des chemins d'accès de fichier identiques sur chaque nœud. 17 Windows Server \ administrateur de cluster Oui Oui Administrateur réseau Étape Administrateur de base de données 8. Activez les fonctionnalités du groupe de disponibilité AlwaysOn pour chaque service SQL Server. Pour plus d'informations et pour obtenir les étapes détaillées d'utilisation du Gestionnaire de configuration SQL Server ou de Windows PowerShell, consultez Activer et désactiver les groupes de disponibilité AlwaysOn. 9. Après avoir activé les trois instances de SQL Server pour prendre en charge les groupes de disponibilité AlwaysOn, et après vous être assuré que les bases de données qui appartiendront au groupe de disponibilité sont configurées en mode de récupération FULL, sauvegardez vos bases de données utilisateur en production depuis la topologie héritée, puis restaurez-les dans un nœud du centre de données principal dans le WSFC. Oui Cette rubrique suppose que vous migrez une ou plusieurs bases de données utilisateur vers une instance de SQL Server dans le centre de données principal. Le second nœud du centre de données principal est ensuite utilisé comme réplica secondaire en mode synchrone. 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 (tels que 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 pour transférer des objets de base de données 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. 18 Oui Windows Server \ administrateur de cluster Administrateur réseau Étape Administrateur de base de données 10. Créez un groupe de disponibilité à l'aide de l'Assistant de SQL Server Management Studio (Utiliser l'Assistant Nouveau groupe de disponibilité), Transact-SQL ou Windows PowerShell. Oui Windows Server \ administrateur de cluster Pour plus d'informations sur l'utilisation de Transact-SQL ou SQL Server PowerShell, consultez Créer un groupe de disponibilité (Transact-SQL) ou Créer un groupe de disponibilité (SQL Server PowerShell). 11. Créez l'écouteur du groupe de disponibilité Oui (sauf si vous l'avez déjà créé à l'étape précédente). Vous pouvez créer l'écouteur du groupe de disponibilité à l'aide d'un Assistant SQL Server Management Studio, Transact-SQL ou SQL Server PowerShell. Pour plus d'informations sur les différentes méthodes, consultez Créer ou configurer un écouteur de groupe de disponibilité (SQL Server). Oui - Pour coordonner tous les paramètres du pare-feu pour les adresses IP sélectionnées Administrateur réseau Oui - Pour vérifier que le port de l'écouteur que vous désignez pour le point de terminaison du groupe de disponibilité est ouvert pour chacune des instances participantes de SQL Server Oui - Pour coordonner les adresses IP et les ports Tableau 1 : Générer la solution de groupes de disponibilité par rôle de travail À titre de référence, pendant l'installation du groupe de disponibilité, consultez le tableau 2 pour une description des configurations de réplica qui s'appliquent à la conception spécifique abordée dans ce document. N'oubliez pas que vous pouvez également choisir d'utiliser les serveurs secondaires en tant que serveurs lisibles. Il s'agit d'un choix viable qui n'a pas d'impact sur la conception de haute disponibilité et de récupération d'urgence globale, et qui, de ce fait, n'a pas été inclus dans le tableau. Centre de données Centre de données principal Centre de données principal Centre de données de récupération d'urgence Réplica Rôle Mode de disponibilité Mode de basculement Automatique Nœud 1 Principal Validation synchrone Nœud 2 Secondaire Validation synchrone Automatique Nœud 3 Secondaire Validation asynchrone (mais un réplica secondaire synchrone est autorisé ; tenez compte de la latence du réseau entre les centres de données, et de son impact sur les performances de l'application) Manuel Tableau 2 : Paramètres de réplica Une fois les étapes du tableau 1 terminées, dans le gestionnaire du cluster de basculement, vous pouvez observer qu'un groupe de ressources a été créé pour le groupe de disponibilité. Au sein de ce groupe de ressources, vous trouverez également la ressource d'écouteur de groupe de disponibilité, les adresses IP de l'écouteur, et la ressource du groupe de disponibilité. La Figure 7 donne un exemple de l'affichage dans le gestionnaire du cluster de basculement. 19 Figure 7 : Gestionnaire du cluster de basculement Windows Server : groupe de disponibilité pour la solution de haute disponibilité et de récupération d'urgence Éléments à prendre en considération pour l'analyse Lorsque vous migrez d'une topologie de mise en miroir de bases de données et de copie des journaux de transaction vers une solution de conception utilisant un groupe de disponibilité, vous devez modifier votre approche pour analyser la topologie. Les méthodes et les outils disponibles pour surveiller l'infrastructure du groupe de disponibilité sont les suivants : Tableau de bord de groupe AlwaysOn dans SQL Server Management Studio Informations d'état de l'Explorateur d'objets Compteurs de performances associés au nouveau groupe de disponibilité Affichages catalogue Vues de gestion dynamique (DMV) Une session d'événements étendus qui surveille les exécutions des instructions DDL AlwaysOn les plus récentes, 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 de groupe AlwaysOn permet d'identifier efficacement et rapidement l'intégrité d'un groupe de disponibilité spécifique. À partir du tableau de bord, vous pouvez identifier l'emplacement de l'instance principale, le mode de basculement des réplicas, leur état de synchronisation et la disponibilité de basculement des différents réplicas (en d'autres termes, le risque de perte de données d'un réplica spécifique). Vous pouvez également consulter les données de 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. 20 Vous pouvez aussi 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 sur la manière de surveiller un environnement de groupe de disponibilité, consultez Surveillance des groupes de disponibilité. Récupération après sinistre Cette section détaille le flux de travail que vous devez suivre en cas de panne des nœuds WSFC dans le centre de données principal. Ce scénario spécifique suppose que les nœuds dans le centre de données principal ne sont pas disponibles. Il suppose également que le seul nœud disponible dans le WSFC se trouve dans le centre de données de récupération d'urgence secondaire. Notez qu'un véritable sinistre peut impliquer une grande variété de pannes. Les conseils fournis ici sont adaptés à un scénario où les nœuds du centre de données principal ne sont pas disponibles. Comme indiqué précédemment, on suppose que le nœud restant n'a pas (initialement) un vote de quorum et que seuls les nœuds avec des votes ont été placés dans le centre de données principal (figure 4). Pour récupérer un groupe de disponibilité en cas de panne du centre de données principal, procédez comme suit : 1. Le gestionnaire du cluster de basculement exécuté sur le 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. En outre, le tableau de bord de groupe AlwaysOn sur le nœud de récupération d'urgence est susceptible de signaler le mode de basculement comme étant inconnu (« unknown ») et les réplicas de disponibilité comme étant en cours de résolution (« resolving state ») (seul l'état du réplica local est susceptible d'être affiché lors d'une panne). Les bases de données de disponibilité peuvent ne pas être visibles dans l'arborescence de l'Explorateur d'objets de SQL Server Management Studio sur le nœud de récupération d'urgence (reportez-vous à la Figure 8 pour un exemple de vue). Figure 8 : Sur le second centre de données, lors d'une panne du centre de données principal 2. 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, la seule option consiste à démarrer le cluster Windows après avoir forcé le quorum sur le nœud du centre de données de récupération d'urgence. Le quorum forcé doit être utilisé en dernier ressort, lorsque le centre de données principal est susceptible d'être arrêté pour une longue période. Lorsque vous forcez le quorum, vérifiez que les nœuds dans le centre de données principal ne forment pas leur propre quorum. 21 L'exemple Windows PowerShell suivant illustre le forçage du quorum sur le nœud du centre de données de récupération d'urgence. Pour commencer, assurez-vous que le service de cluster n'est pas déjà sur le nœud de récupération d'urgence. Stop-ClusterNode –Name "EMU-SQL3" Ensuite, démarrez le service de cluster en forçant le quorum. Start-ClusterNode –Name "EMU-SQL3" –FixQuorum Pour plus d'informations sur le forçage du quorum, consultez : Forcer un cluster WSFC à démarrer sans quorum. 3. À ce stade, le modèle de quorum du cluster est toujours Nœud et partage de fichiers majoritaires. Get-ClusterQuorum Cluster ------EMU-AGClstr QuorumResource -------------File Share Witness QuorumType ---------NodeAndFileShareMajority Étant donné que le cluster est exécuté sur le nœud de récupération d'urgence dans un état de quorum forcé, vous devez modifier en conséquence le modèle de quorum et les votes de nœud. Étant donné qu'il y a un seul nœud dans le centre de données de récupération d'urgence (dans cet exemple de topologie), modifiez le modèle de quorum en Nœud majoritaire (dans ce cas, la majorité d'un seul nœud) et affectez un seul vote au nœud de récupération d'urgence et zéro vote aux nœuds du centre de données principal. Pour définir le modèle de quorum sur Nœud majoritaire, tapez la commande suivante. Set-ClusterQuorum -NodeMajority En modifiant le modèle de quorum, vous rétablissez l'état par défaut des votes de nœud (un vote sur chaque nœud). Maintenant, modifiez les votes de nœud. (Get-ClusterNode "EMU-SQL3").NodeWeight=1 (Get-ClusterNode "EMU-SQL1").NodeWeight=0 (Get-ClusterNode "EMU-SQL2").NodeWeight=0 À ce stade, l'environnement a un nœud et un vote, et, par conséquent, un seul point de défaillance. 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 22 Si vous avez modifié les propriétaires « Cluster Group » du WSFC de sorte qu'ils soient contraints uniquement aux nœuds du centre de données principal, vous devez également modifier les propriétaires « Cluster Group » du WSFC pour inclure à la place le nœud de récupération d'urgence. 4. Mettez le groupe de disponibilité en ligne sur l'instance SQL Server du nœud de récupération d'urgence. Attention : si le réplica est configuré en mode asynchrone, la restauration du service peut entraîner la perte de tous les enregistrements de journal non envoyés. Vous devez comprendre parfaitement les conséquences de cette opération avant de restaurer le service. Pour plus d'informations sur les risques de restauration du service sur les réplicas configurés en mode asynchrone, consultez Effectuer un basculement manuel forcé d'un groupe de disponibilité. Si le risque de perte de données est compensé par la possibilité d'atteindre l'objectif de temps de récupération (RTO) et de restaurer le service sur le centre de données, exécutez la syntaxe Transact-SQL suivante sur l'instance SQL Server de récupération d'urgence afin de forcer le basculement (dans cet exemple, EMU-AG1 est le nom du groupe de disponibilité). ALTER AVAILABILITY GROUP [EMU-AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS; À ce stade, les bases de données de votre groupe de disponibilité doivent être disponibles. Vous devez obligatoirement vous assurer que toutes les connexions d'application entrantes sont déconnectées de l'ancien réplica principal, ou qu'elles sont totalement déconnectées. Les nouvelles connexions vers l'écouteur du groupe de disponibilité (qui devrait être de nouveau opérationnel) doivent être automatiquement acheminées vers l'instance de récupération d'urgence. Vous devez également vous assurer que les connexions d'application ne tentent de se connecter au centre de données principal, pour éviter une situation de « partition réseau ». Notez aussi que même après avoir rétabli le quorum au niveau du centre de données de récupération d'urgence, vous verrez toujours différents messages d'avertissement signalant que les nœuds du centre de données principal ne sont pas disponibles dans SQL Server Management Studio. La Figure 9 illustre un exemple de ces avertissements, et comprend une vue de l'Explorateur d'objets et du tableau de bord de groupe AlwaysOn. 23 Figure 9 : SQL Server Management Studio après un basculement forcé Comme indiqué précédemment, dans les entreprises de grande taille, les fonctions sont généralement réparties entre les rôles d'administrateur de base de données, d'administrateur Windows Server (ou cluster) et d'administrateur réseau. Le Tableau 3 récapitule le flux de travail de récupération d'urgence décrit précédemment et indique les secteurs habituellement pris en charge par les différents rôles d'entreprise à des fins de planification. Étape Administrateur de base de données Vérifiez l'état actuel du centre de données principal et du nœud de récupération d'urgence WSFC restant, et coordonnez les tâches. Forcez le service de quorum sur le nœud de récupération d'urgence. Supprimez les votes des nœuds principaux et ajoutez un vote au nœud de récupération d'urgence. Forcez le basculement du groupe de disponibilité sur l'instance SQL Server de récupération d'urgence. Oui Oui Oui Oui Tableau 3 : Récupération après sinistre par rôle de travail 24 Windows Server \ administrateur de cluster Oui Administrateur réseau Oui Rebasculer sur le centre de données principal Le scénario ci-après suppose que le service restauré sur le site de récupération d'urgence est uniquement destiné à exécuter la charge de travail pendant le sinistre, et qu'il est souhaitable de rebasculer la charge de production sur le site principal dès qu'il est capable de l'assumer. 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 ses nœuds de nouveau opérationnels, ces derniers 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, le scénario suppose que l'instance SQL Server d'origine est installée et que les bases de données associées sont intactes. À ce stade, vous devez choisir entre sauver toutes 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 de toutes les sessions de réplica. Les réplicas sur les nœuds en échec seront dans un état « non synchronisé » après un basculement forcé et le réplica de récupération d'urgence, dans un état « synchronisé » comme indiqué dans la Figure 10. 25 Figure 10 État des bases de données entre les réplicas avant que le système rebascule sur le centre de données principal Pour sauvegarder les données du réplica principal d'origine, vous pouvez créer un instantané de base de données sur la base de données secondaire interrompue (à l'origine, la base de données principale) 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 snapshot CREATE DATABASE AppDB_A1 ON (NAME = AppDB, FILENAME = 'S:\Data\AppDB_A1.ss' ) AS SNAPSHOT OF AppDB; GO Étant donné que le scénario d'origine utilise le mode asynchrone pour la base de données de récupération d'urgence, on suppose que l'objectif de point de récupération (RPO) tolère la perte de données. Les étapes suivantes supposent que le service sera restauré à l'aide des réplicas du centre de données principal existants : 1. Relancez la migration contrôlée sur le centre de données principal en modifiant correctement le modèle de quorum (dans ce cas, utilisez Nœud et partage de fichiers majoritaires), puis rajustez les votes. 2. Après vous être assuré que les instances de serveur SQL du centre de données principal ont démarré, sur chaque instance de SQL Server dans le centre de données principal, exécutez le code Transact-SQL suivant à partir du contexte de la base de données master pour reprendre chaque base de données qui participe au groupe de disponibilité. USE [master] GO ALTER DATABASE AppDB SET HADR RESUME; GO ALTER DATABASE ConfigDB SET HADR RESUME; GO ALTER DATABASE SecurityDB SET HADR RESUME; GO 3. Modifiez le groupe de disponibilité pour utiliser temporairement le mode de disponibilité avec validation synchrone, afin d'effectuer une synchronisation avant le basculement. La commande Transact-SQL est la suivante (exécutée sur le réplica principal actuel dans le centre de données de récupération d'urgence, où EMU-AG1 est notre groupe de disponibilité et EMU-SQL3 est le réplica du centre de données de récupération d'urgence). 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. 26 USE [master] GO ALTER AVAILABILITY GROUP [EMU-AG1] MODIFY REPLICA ON N'EMU-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); GO 4. Vérifiez l'état de synchronisation entre les deux emplacements (tous les états de réplica doivent indiquer « healthy » avant de passer à l'étape suivante, ce qui signifie que les réplicas sont synchronisés). SELECT role_desc, synchronization_health_desc FROM sys.dm_hadr_availability_replica_states; 5. Basculez le groupe de disponibilité du nœud du centre de données de récupération d'urgence sur le nœud du centre de données principal (c'est-à-dire, connectez et exécutez le script suivant sur le nœud du centre de données principal, qui deviendra le nouveau réplica principal). ALTER AVAILABILITY GROUP [EMU-AG1] FAILOVER; 6. Pour respecter le déploiement d'origine, rétablissez la validation asynchrone sur le nœud du réplica de récupération d'urgence. Exécutez le code Transact-SQL suivant sur le nouveau réplica principal, où EMU-SQL3 est le nom du réplica de récupération d'urgence et EMU-AG1 est le nom du groupe de disponibilité. USE [master] GO ALTER AVAILABILITY GROUP [EMU-AG1] MODIFY REPLICA ON N'EMU-SQL3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT); GO 7. Supprimez le vote de quorum du nœud WSFC dans le centre de données de récupération d'urgence. Le tableau suivant récapitule le flux de travail de récupération d'urgence décrit précédemment et indique les secteurs habituellement pris en charge par les différents rôles d'entreprise à des fins de planification. 27 Étape 1. Après avoir restauré le service du centre de données principal, modifiez le modèle de quorum de la façon appropriée. Rajoutez ensuite les votes de quorum aux nœuds du centre de données principal. 2. Rétablissez les sessions des bases de données de disponibilité sur chaque réplica secondaire. 3. Appliquez la validation synchrone sur le réplica de récupération d'urgence. 4. Vérifiez l'état de synchronisation entre les deux emplacements (tous les états de réplica doivent indiquer « healthy » avant de passer à l'étape suivante). 5. Basculez sur un réplica dans le centre de données principal. 6. Rétablissez la validation asynchrone sur le réplica de récupération d'urgence (conformément à la configuration d'origine). 7. Supprimez le vote de quorum du nœud dans le centre de données de récupération d'urgence. Administrateur Windows Server \ de base de administrateur données de cluster Administrateur réseau Oui Oui Oui Oui Oui Oui Oui Tableau 4 : Rebasculer sur le centre de données principal Conclusion SQL Server 2012 AlwaysOn fournit plusieurs options pour générer une solution de haute disponibilité (HA) et de récupération d'urgence (DR) pour votre application. Ce livre blanc décrit une solution qui utilise les groupes de disponibilité pour la haute disponibilité et la récupération d'urgence. C'est purement une solution de 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. Vous pouvez utiliser cette solution pour remplacer les topologies héritées qui utilisent la mise en miroir de bases de données et la copie des journaux de transaction. 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 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 28 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) Présentation des groupes de disponibilité AlwaysOn (http://technet.microsoft.com/library/ff877884(v=SQL.110).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-survivalguide-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) Annexe A : Exemple de groupes de disponibilité HA/DR à 3 centres de données L'architecture décrite dans ce livre blanc repose sur deux centres de données, ce qui est une topologie de déploiement courante. Toutefois, occasionnellement, certains clients utilisent un troisième centre de données pour le déploiement. Dans la plupart des cas, la raison d'un tel choix est qu'il permet le basculement automatique du groupe de disponibilité entre les centres de données principal et de récupération d'urgence. Pour y parvenir, vous pouvez, par exemple, déployer les deux réplicas dans ces deux centres de données et un témoin de partage de fichiers dans le troisième centre de données, comme le montre la figure 11. Troisième centre de données VOTE Centre de données principal SQL Server Partage de fichiers Cluster de basculement Windows Server VOTE Centre de données de récupération d'urgence VOTE SQL Server Secondaire Principal Synchrone Groupe de disponibilité Figure 11 : Solution de groupes de disponibilité HA/DR utilisant trois centres de données 29 Pour plus d'informations : http://www.microsoft.com/sqlserver/ : Site Web SQL Server http://technet.microsoft.com/fr-fr/sqlserver/ : TechCenter SQL Server http://msdn.microsoft.com/fr-fr/sqlserver/ : Centre de développement SQL Server 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é ? Vos commentaires nous aident à améliorer la qualité des livres blancs que nous publions. Envoyez vos commentaires 30
