Modèle de déploiement régional multizone double

Les serveurs virtuels IBM Cloud Windows Server 2019 Standard configurés en tant que nœuds Windows Server Failover Cluster (WSFC) et SQL Server Enterprise edition avec des groupes de disponibilité SQL Server Always On configurés sur chaque nœud constituent la base du modèle de déploiement double Multi-Zone Region (MZR). Cette architecture, associée à MS ADDNS, permet de déployer un SQL Server pour la reprise après sinistre.

Modèle de déploiement MZR double
Modèle de déploiement MZR double

Le modèle de déploiement MZR double illustré s'appuie sur le modèle de zone de disponibilité (AZ) double et l'étend de manière à ce qu'il y ait une copie des bases de données dans une région distante ; par conséquent, ce modèle convient aux bases de données de production qui nécessitent une reprise après sinistre et s'appuie sur les technologies de base suivantes :

  • Un IBM Cloud VPC avec des sous-réseaux dans deux MZR.
  • Les groupes de sécurité sont utilisés pour contrôler les flux de trafic entre les composants.
  • Un ou plusieurs hôtes bastion utilisés pour l'accès administratif aux serveurs.
  • IP flottante (FIP) attachée aux hôtes du bastion pour permettre l'accès à l'Internet.
  • Trois serveurs virtuels Windows Server 2019 Standard, un dans chaque AZ de la ZDM primaire et un troisième dans la ZDM de récupération, qui sont des contrôleurs de domaine Active Directory dans le même domaine forestier.
  • Trois serveurs virtuels Windows Server 2019 Standard, un dans chaque ZA de la ZDM primaire et un troisième dans la ZDM de récupération, qui deviendront des nœuds Windows Server Failover Cluster (WSFC).
  • Les groupes de disponibilité Always On permettent de maintenir un ensemble discret de bases de données hautement disponibles sur un ou plusieurs nœuds de cluster et fonctionnent au niveau de la base de données. Les groupes de disponibilité sont constitués d'une réplique primaire et d'un maximum de huit répliques secondaires, et utilisent la réplication synchrone ou asynchrone des données. Dans ce déploiement :
    • la réplication synchrone est utilisée entre les deux ZA de la ZDM primaire.
    • la réplication asynchrone est utilisée entre les MZR.
  • Distributed Network Names est une ressource de nom dans les groupes de disponibilité WSFC et Always On, utilisée pour la résolution de nom des ressources du cluster.

Un témoin de partage de fichiers n'est pas nécessaire dans ce déploiement car le nombre de nœuds est impair et le mode quorum Majorité des Node sera utilisé

Cluster de basculement de Windows Server

Le déploiement de groupes de disponibilité Always On pour HA sous Windows nécessite un cluster de basculement de serveur Windows (WSFC). Chaque réplique de disponibilité d'un groupe de disponibilité doit résider sur un nœud différent du WSFC. Pour simplifier la configuration de la sécurité des bases de données de disponibilité, il est recommandé que les instances du serveur SQL (les comptes de service) s'exécutent sous un compte de service de domaine.

Windows Server Failover Cluster (WSFC) est une fonctionnalité de Windows Server et chaque serveur qui agit en tant que nœud de cluster doit avoir cette fonctionnalité activée. La FSMF s'appuie sur des votes de quorum pour éviter le syndrome du "cerveau divisé", et il existe un certain nombre de modes de quorum :

  • Majorité des Node- Les nœuds actifs de la grappe déterminent le quorum. Au moins la moitié des votes possibles doivent être positifs pour que le cluster conserve un état sain.
  • Majorité des Node et des partages de fichiers - Un partage de fichiers distant agit comme un témoin de vote pour les nœuds actifs impliqués dans un vote de quorum. Comme dans le cas de la majorité des Node, au moins la moitié des votes possibles doivent être positifs pour que la grappe conserve un état sain.
  • Majorité des Node et des disques - Un disque partagé agit comme un témoin de vote, au même titre que les nœuds actifs impliqués dans un vote de quorum.
  • Disque seul - Un disque partagé sert de témoin et le quorum est déterminé par les nœuds qui peuvent accéder au disque. Aucun nombre minimum de votes possibles n'est requis.

Les recommandations de Microsoft pour le serveur SQL sont les suivantes :

  • Utilisez le mode quorum "majorité des nœuds Node lorsque le nombre de nœuds votants est impair.
  • Utilisez le mode de quorum Majorité de Node et de partages de fichiers lorsque vous disposez d'un nombre pair de nœuds de vote.

Groupes de disponibilité "Always On

Un groupe de disponibilité prend en charge un ensemble de bases de données primaires et jusqu'à huit ensembles de bases de données secondaires. Les bases de données secondaires ne sont pas des sauvegardes. Il est donc essentiel de sauvegarder régulièrement les bases de données et leurs journaux de transactions. Les groupes de disponibilité Always On nécessitent l'une des trois options de type de cluster suivantes : WSFC, EXTERNAL, NONE.

  • WSFC - Utilise Windows Server Failover Cluster (WSFC) pour gérer le basculement du cluster. Il s'agit d'une condition préalable pour les groupes de haute disponibilité sur les serveurs Windows.
  • Externe - Utilise un gestionnaire de cluster externe. Par exemple, le SQL Server sous Linux prend en charge Pacemaker. Les groupes de disponibilité sur les clusters Linux nécessitent au moins deux répliques synchrones pour garantir l'HA, mais au moins trois répliques pour la récupération automatique. Il est donc recommandé de configurer un groupe de disponibilité sur au moins trois nœuds.
  • Aucun - Connu sous le nom de groupe de disponibilité sans cluster ou initialement appelé groupe de disponibilité à échelle de lecture. Toutefois, cette option n'offre qu'un sous-ensemble des fonctionnalités des groupes de disponibilité et n'inclut pas le basculement automatique. Les fonctionnalités comprennent le basculement manuel planifié et forcé, les modes de réplication synchrone et asynchrone, les nœuds secondaires lisibles et les sauvegardes des répliques secondaires. Les groupes de disponibilité sans cluster WSFC peuvent toujours fournir des nœuds secondaires lisibles, un routage en lecture seule et un équilibrage de charge. Le basculement peut être automatisé à l'aide d'outils externes. Une nouvelle fonctionnalité de SQL Server 2019 permet d'atténuer ce problème avec la redirection automatique du trafic, qui assure le routage du trafic de lecture/écriture vers le nœud principal et ne nécessite pas de Listener.

La terminologie suivante est utilisée pour décrire les concepts de groupes de disponibilité :

  • Groupe de disponibilité - prend en charge un environnement répliqué pour un ensemble discret de bases de données d'utilisateurs.
  • Groupe de disponibilité HA - groupe de bases de données qui basculent ensemble.
  • Groupe de disponibilité en lecture - groupe de bases de données copiées sur d'autres instances de SQL Server pour une charge de travail en lecture seule.
  • Réplique primaire - rend les bases de données primaires disponibles pour les connexions en lecture-écriture des clients et envoie les enregistrements du journal des transactions de chaque base de données primaire à chaque base de données secondaire.
  • Réplique secondaire - jusqu'à huit répliques secondaires, chacune hébergeant un ensemble de bases de données secondaires et servant de cibles de basculement potentielles pour le groupe de disponibilité HA.

Modes de synchronisation

Les répliques secondaires du groupe de disponibilité peuvent être configurées avec l'un des modes de synchronisation suivants :

  • Synchrone - Le journal est renforcé (les transactions sont validées dans le journal des transactions) sur chaque réplique secondaire avant que la transaction ne soit validée sur la réplique primaire. Cela garantit une perte de données nulle, avec un impact potentiel sur les performances d'une charge de travail hautement transactionnelle si la latence du réseau est élevée. Vous pouvez avoir deux répliques synchronous-commit par AG. Ce mode convient mieux aux instances d'une même ZA ou d'une même ZIM.
  • Asynchrone - La transaction est considérée comme validée dès qu'elle est durcie dans le journal des transactions de la réplique primaire. Si un problème survient avant que les journaux ne soient renforcés sur toutes les répliques secondaires, une perte de données est possible, et le point de récupération serait la dernière transaction validée qui a réussi sur toutes les répliques secondaires. Ce mode est mieux adapté aux instances situées dans différentes Zones de responsabilité zéro ou entre une zone de responsabilité zéro et une zone de responsabilité zéro.

Modes de basculement

Lorsqu'un groupe de disponibilité bascule, une réplique secondaire devient la nouvelle réplique primaire et la réplique primaire, si elle est disponible, devient une réplique secondaire.

  • Basculement automatique - Les basculements automatiques assurent l'HA et dépendent d'un auditeur et d'objets WSFC correctement configurés pour réussir. Seule une réplique en mode de disponibilité "synchronous-commit" peut être la destination d'un basculement automatique. Vous pouvez configurer les conditions qui déclenchent un basculement automatique sur une échelle de 1 à 5, où 1 indique que seule une panne totale du service SQL Server sur la réplique primaire déclencherait un basculement, et 5 indique un certain nombre d'erreurs SQL Server critiques à moins graves. La valeur par défaut est 3, ce qui entraîne une défaillance automatique en cas de panne ou de réplique primaire ne répondant pas, mais aussi pour certaines conditions de serveur critiques. Ces conditions de "politique de basculement flexible" sont détaillées à la page Configurer une politique de basculement automatique flexible pour un groupe de disponibilité Always On.
  • Basculement planifié - Un basculement planifié ne peut avoir lieu que s'il n'y a pas de risque de perte de données. Plus précisément, cela signifie que le basculement se produit sans utiliser le paramètre FORCE pour acquitter les avertissements dans le code ou dans les boîtes de dialogue SSMS. Un basculement planifié vers une réplique secondaire n'est possible qu'en mode de disponibilité "synchronouscommit". Vous pouvez faire passer un réplica en mode de disponibilité asynchrone-commit à synchrone, attendre l'état SYNCHRONIZED, puis effectuer un basculement planifié sans perte de données. Les basculements planifiés doivent toujours être initiés via SSMS, T-SQL ou PowerShell.
  • Basculement forcé - Un basculement forcé, initié manuellement, ne doit être initié qu'en réponse à des conditions défavorables du cluster, telles que la perte du nœud principal. Lancer à partir des assistants SSMS, des commandes T-SQL ou de PowerShell et, en dernier recours, à partir du gestionnaire de cluster de basculement de Windows Server.
  • Forcer le basculement si le quorum du WSFC est en panne - Vous ne pourrez pas forcer le basculement des groupes de disponibilité basés sur un WSFC si ce dernier n'a pas de quorum. Vous devrez d'abord forcer le quorum dans le gestionnaire de configuration en "truquant" le vote et en modifiant le poids des nœuds. Cette étape ne doit être envisagée qu'en cas d'urgence, par exemple lorsqu'un sinistre a perturbé la majorité des nœuds du cluster. Ceci peut être réalisé à l'aide d'un script PowerShell, pour forcer un nœud en ligne à assumer le rôle principal sans une majorité de votes.

Les basculements ne sont pas dus à des problèmes de base de données tels que la perte d'un fichier de données ou la corruption d'un journal de transactions.

Autres types de groupes de disponibilité

Les groupes de disponibilité suivants ne sont pas utilisés dans ce modèle de déploiement, mais peuvent intéresser les auteurs de solutions qui souhaitent adapter ou étendre ce modèle de déploiement :

  • Groupes de disponibilité de base - Version limitée des groupes de disponibilité et prise en charge uniquement par l'édition standard de SQL Server. La réplique secondaire unique ne peut être lue ou sauvegardée et chaque groupe de disponibilité de base ne peut prendre en charge que deux répliques, mais plusieurs groupes de disponibilité de base peuvent être configurés par serveur. Les groupes de disponibilité de base permettent de bénéficier d'un grand nombre des caractéristiques des groupes de disponibilité, notamment la réplication synchrone ou asynchrone, les basculements manuels ou automatiques.
  • Groupes de disponibilité distribués - Cela permet à un groupe de disponibilité de traiter un autre groupe de disponibilité pour qu'il agisse en tant que réplique secondaire. Les répliques secondaires en lecture seule peuvent être dispersées à l'échelle mondiale, ce qui permet de décharger les charges de travail sur des répliques secondaires régionales en lecture seule. Les deux groupes de disponibilité, chacun avec son propre auditeur, n'ont pas besoin d'être dans le même réseau ou WSFC. Cela permet de mettre en place une HA et une DR géographiquement distantes dans le cadre de déploiements multi-sites. Avec les groupes de disponibilité distribués, un WSFC n'a pas besoin de s'étendre sur plusieurs régions. Il n'y a pas de basculement automatique entre le groupe de disponibilité primaire et le groupe de disponibilité secondaire. Le groupe de disponibilité qui n'est pas primaire ne peut servir que des requêtes en lecture seule, mais il possède lui-même une réplique primaire. La réplique primaire du groupe de disponibilité secondaire est chargée de répliquer les transactions vers les autres répliques secondaires du groupe de disponibilité secondaire. Cette architecture est utile pour les mises à niveau du système d'exploitation et de la version du SQL Server, car vous pouvez avoir différentes versions de Windows Server dans chaque groupe de disponibilité. Bien que chaque groupe de disponibilité dans un scénario distribué ait son propre auditeur, le groupe de disponibilité distribué dans son ensemble n'en a pas. Les applications, éventuellement à l'aide d'alias DNS, se connecteront à chaque groupe de disponibilité directement après un basculement pour tirer parti des répliques secondaires lisibles.

Noms de réseaux distribués

Ce déploiement utilise les noms de réseaux distribués (DNN), qui sont des ressources de noms dans les groupes de disponibilité WSFC et Always On, utilisés pour la résolution de noms des ressources du cluster. Il diffère d'une ressource de nom de réseau standard car il ne nécessite pas d'adresse IP distincte des adresses IP des nœuds et n'exige pas l'utilisation du protocole GARP (Gratuitous Address Resolution Protocol) sur le réseau en cas de basculement. Dans Windows Server 2019, le nom du WSFC, qui est également l'objet de nom de cluster (CNO) dans les services de domaine Active Directory, et l'auditeur de base de données peuvent tous deux être créés avec des DNN.