Les groupes de disponibilité SQL Server AlwaysOn sont la dernière technologie de Microsoft pour répondre aux besoins de haute disponibilité et de reprise après sinistre des organisations utilisant SQL Server. L'un des principaux avantages d'AlwaysOn est la possibilité de traiter à la fois la haute disponibilité et la reprise après sinistre dans une seule implémentation. Les principaux avantages d'AlwaysOn dont nous avons fait l'expérience sont les suivants :
Nous pouvons regrouper les bases de données associées dans un seul groupe de disponibilité et les faire basculer ensemble en cas de besoin. Ceci est particulièrement utile pour les applications qui dépendent de plusieurs bases de données telles que Microsoft Office SharePoint, Microsoft Lync ou Sage.
Par rapport aux instances de cluster de basculement SQL Server, nous constatons que le stockage en tant que point de défaillance unique a été éliminé puisque chaque instance qui constitue une réplique a son propre stockage attribué.
Avec AlwaysOn, il est possible de configurer HA et DR en même temps. Ceci est réalisé en créant des clusters de basculement Windows multi-sites comme base de votre configuration AlwaysOn. Effectuer un changement de rôle lors de l'utilisation d'AlwaysOn est beaucoup plus simple que de le faire lors de l'utilisation de l'envoi du journal des transactions.
La dépendance WSFC
Lorsque vous utilisez SQL Server AlwaysOn AG pour la haute disponibilité et la reprise après sinistre, vous devez d'abord configurer un cluster de basculement Windows. Les AG AlwaysOn dépendent de WFCS pour gérer l'AG AlwaysOn en tant que rôle composé de ressources de cluster telles que le nom du groupe de disponibilité, le nom du partage de fichiers, le nom de l'écouteur et une adresse IP.
Fig. 1 AlwaysOn AG en tant que ressource de cluster
Quorum
Le quorum est le nombre minimum de votes requis pour une majorité dans un cluster de basculement. Le quorum détermine le nombre de pannes de nœud que le cluster peut supporter. Via le réseau privé sur le port 3343, tous les nœuds du cluster communiquent des informations sur l'état de santé et la surveillance des ressources. En cas d'échec, les votes indiquent quels nœuds ont le statut "Up" et sur quels nœuds les ressources doivent être mises en ligne.
Depuis Windows Server 2012, le nombre maximum de nœuds de cluster pris en charge est de seize. Cependant, dans la plupart des environnements que je connais, les clusters à deux nœuds sont courants. Un cluster à deux nœuds pose un petit problème en termes d'atteinte du quorum puisque chaque nœud a un vote et s'il y a un problème de communication entre les deux, chacun peut supposer que l'autre n'est pas sain. C'est ce qu'on appelle un scénario split-brain. Les scénarios de split-brain sont la raison de la configuration d'un bris d'égalité tel qu'un disque ou un partage de fichiers.
Si vous avez un nombre impair de nœuds, il n'est pas nécessaire de configurer un tiebreaker. La configuration dynamique du quorum et le témoin dynamique ont été introduits respectivement dans Windows Server 2012 et Windows Server 2012 R2. Avec l'aide de ces technologies, Windows redistribue automatiquement les votes dans un cluster afin que le nombre de nœuds dans un cluster n'ait pas d'importance dans l'établissement d'un quorum. Le vote d'un nœud de cluster est supprimé en définissant la propriété de cluster "NodeWeight" sur 0. Ces fonctionnalités sont activées par défaut.
Fig. 2 Obtenir toutes les propriétés du cluster à l'aide de PowerShell
Fig. 3 votes attribués dans un cluster à deux nœuds
Utiliser PowerShell
La commande PowerShell Get-Cluster peut être utilisée pour vérifier la configuration du quorum sur un cluster Windows. La figure 4 montre comment vérifier toutes les propriétés de cluster liées au quorum sur un cluster et la figure 5 décrit les propriétés du témoin de partage de fichiers. Il existe de nombreuses autres commandes PowerShell pour vérifier et gérer les clusters Windows.
Get-Cluster | Format-List –Property *Quorum*
Fig. 4 Commande PowerShell pour vérifier les propriétés liées au quorum
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Fig. 5 Commande PowerShell pour vérifier les détails des propriétés du témoin de partage de fichiers
Modes de quorum
Le cluster de basculement Windows Server permet de configurer jusqu'à quatre modes. Les modes de quorum sont essentiellement des options que vous choisissez pour déterminer comment le cluster gérera les pannes de nœud.
1. Majorité de nœud
Ce mode de quorum peut supporter des défaillances jusqu'à (n/2)-1 nœuds. Il est recommandé pour les clusters avec un nombre impair de nœuds. Par exemple, dans un cluster à cinq nœuds, il faudrait une défaillance de deux nœuds pour provoquer une défaillance du cluster.
2. Nœud et disque majoritaires
Peut subir des défaillances jusqu'à la moitié du nombre de nœuds de cluster tant que le témoin de disque (également appelé disque quorum) reste en ligne.
3. Nœud et partage de fichiers majoritaires
Ce mode de quorum peut supporter des défaillances jusqu'à la moitié du nombre de nœuds de cluster tant que le partage de fichiers reste accessible. À partir de Windows Server 2012 R2, Microsoft recommande qu'un témoin (disque ou partage de fichiers) soit toujours configuré lors de la création d'un cluster.
4. Pas de Majorité
Il s'agit d'un mode disque uniquement. Ce mode peut supporter les défaillances de tous les nœuds sauf un tant que le disque est en ligne. Ce mode n'est pas recommandé car le disque devient un point de défaillance unique.
Conseils sur la configuration de la majorité des nœuds et des partages de fichiers
Les groupes de disponibilité AlwaysOn ne prennent en charge que deux de ces modes de quorum :Nœud majoritaire et Nœud et partage de fichiers majoritaires. Lors de la création d'un cluster de groupe de disponibilité SQL Server AlwaysOn, le DBA doit garder à l'esprit quelques points :
1. Utilisation de serveurs physiques
Lors de la configuration d'un cluster à deux nœuds pour AlwaysOn, vos nœuds doivent résider dans des racks physiques différents. Le serveur hébergeant votre partage de fichiers doit résider dans un troisième rack.
2. Utilisation de serveurs virtuels
Lors de la configuration d'un cluster à deux nœuds pour AlwaysOn, vos machines virtuelles doivent résider sur des hôtes distincts. La machine virtuelle hébergeant votre partage de fichiers doit résider sur un troisième hôte.
3. Clustering multi-sites
Lors de la configuration d'un cluster à plusieurs nœuds pour AlwaysOn dans plusieurs centres de données, dans un scénario idéal, le serveur de fichiers hébergeant votre partage de fichiers doit résider dans un troisième centre de données.
4. Autorisations de partage de fichiers
L'objet de nom de cluster doit avoir des autorisations sur le partage de fichiers utilisé comme témoin de quorum. Sans cela, vous rencontrerez généralement des erreurs en tentant de configurer Quorum Witness.
Fig. 6 autorisations sur le partage de fichiers
5. Configuration en ligne
Les modes de quorum peuvent être configurés lorsque le cluster est en ligne. Ainsi, en cas de panne ou de reconfiguration du serveur de partage de fichiers, assurez-vous de reconfigurer rapidement pour garantir qu'il n'y aura pas de pannes inattendues, en particulier sur un cluster à deux nœuds.
Un cas d'utilisation réel
Le schéma de la Fig. 7 représente un véritable cluster AlwaysOn AG multisite. Il s'agit d'un cluster à quatre nœuds avec deux nœuds sur un site et deux autres sur un site DR distant. Le serveur de fichiers hébergeant le partage de fichiers utilisé comme condition de départage est hébergé dans un troisième centre de données. Dans le cas présent, le serveur de fichiers réside dans la même ville que le centre de données principal, mais si vous pouvez vous le permettre, il serait idéal d'avoir le serveur de fichiers dans une autre ville. La communication entre les trois parties doit être de bonne qualité afin d'éviter les faux positifs.
Par exemple, dans notre mise en œuvre initiale de ce cluster, nous avons utilisé la « réplication synchrone avec basculement automatique » sur les sites Live et DR. À plus d'une occasion, nous avons rencontré un problème de communication qui a déclenché un basculement automatique vers le site DR et a révélé une faille dans notre configuration. Cela a entraîné la résolution du nom de l'écouteur vers les adresses IP associées dans le site DR et les clients ne pouvaient plus se connecter car la communication avec cette nouvelle adresse IP n'était pas autorisée sur les pare-feu du réseau. Nous sommes simplement revenus au site principal pour atténuer le problème et avons changé la configuration en « réplication asynchrone avec basculement manuel » pour les nœuds résidant dans les centres de données. Nous prévoyons de couvrir l'aspect de la résolution de noms dans notre prochain article "AlwaysOn".
Fig. 7 Un cas d'utilisation réel
Conclusion
La fonctionnalité Groupes de disponibilité AlwaysOn a été introduite dans SQL Server 2012 et est la dernière technologie de Microsoft pour répondre à la fois aux besoins de haute disponibilité et de reprise après sinistre. La configuration des groupes de disponibilité AlwaysOn dépend fortement du service de cluster de basculement Windows. Les clusters de basculement, à leur tour, dépendent beaucoup de la configuration correcte du quorum. Lors de la création d'AlwaysOn sur des clusters multi-sites, la latence entre vos nœuds dans les différents sites et le partage de fichiers utilisé comme arbitre sont vraiment importants. Assurez-vous que la configuration de votre quorum est toujours optimale pour éviter les comportements inattendus avec les groupes de disponibilité.
Références
Présentation des groupes de disponibilité AlwaysOn
Cluster de basculement Windows avec SQL Server
Documentation PowerShell
Comprendre le quorum du cluster de basculement Windows Server
