Voici un guide, étape par étape, sur l’utilisation du logiciel de cluster de basculement sans réseau de stockage (SAN) pour prendre en charge le cluster de basculement Always On de SQL Server dans le cloud public.
Alors que le cloud continue de gagner en popularité pour de nombreuses applications d’entreprise, voire la plupart, les services informatiques restent réticents à faire confiance aux clouds publics, y compris Google Cloud Platform, concernant les applications critiques de Microsoft SQL Server.
Leur principale préoccupation est le risque et la complexité accrus de l’exécution de Microsoft SQL Server. Et en option, le Cluster de Basculement Windows Server ou WSFC (Windows Server Failover Clustering) dans des environnements où les configurations de clusters haute disponibilité sont souvent moins robustes et plus coûteuses que dans un cloud privé.
Parmi les problèmes rencontrés par SQL Server figure la nécessité d’utiliser le stockage partagé pour les instances de cluster de basculement Always On.
C’est un problème pour deux raisons:
- Tout d’abord, le stockage partagé sous la forme d’un réseau de stockage (SAN) n’est pas disponible dans Google Cloud Platform.
- Deuxièmement, tout ce qui est partagé crée un point de défaillance unique lorsqu’il n’est pas entièrement redondant.
Une façon de surmonter ces limitations consiste à implémenter un logiciel de clustering de basculement tiers dans Google Cloud.
Lorsqu’il est conçu pour prendre en charge SQL Server, le cluster de basculement crée un environnement à haute performance et à haute disponibilité, facile à gérer.
Les limitations sur la haute disponibilité de SQL Server dans Google Cloud
Comme les autres services cloud, Google Cloud Platform offre des fonctionnalités de basculement d’applications pour de nombreuses applications nécessitant une haute disponibilité.
Ces services fonctionnent en répliquant les données de l’instance maître vers une ou plusieurs instances de réplica dans des zones différentes, qui sont normalement situées dans différents centres de données pour se protéger contre les sinistres localisés.
En cas de défaillance de l’instance maître de l’application, les dispositions de haute disponibilité basculent vers une instance de réplica.
Dans Google Cloud, les dispositions standard de haute disponibilité comportent les cinq limitations suivantes :
- Les basculements ne sont normalement déclenchés que par une panne de zone, c’est l’une des raisons pour lesquelles les applications échouent.
- Chaque maître ne peut créer qu’un seul réplica de basculement, créant ainsi un point de défaillance unique.
- Les sauvegardes doivent être effectuées à partir de l’ensemble de données de l’instance maître, ce qui rend inévitable les temps d’arrêt planifiés.
- L’utilisation de journaux d’événements pour répliquer des données crée un « retard de réplication » qui provoque des interruptions temporaires pendant un basculement.
- Le service ne supporte actuellement que MySQL et PostgreSQL, mais pas SQL Server.
Bien que ces limitations puissent être acceptables dans le cadre d’une stratégie de récupération après sinistre pour certaines applications, elles ne sont pas acceptables pour les applications SQL Server stratégiques.
Pour prendre en charge la haute disponibilité dans les clouds publics, privés et hybrides, SQL Server propose sa propre solution avec Always On Availability Groups dans l’Edition Entreprise.
Mais, cette capacité premium est également disponible à un prix supérieur qui ne peut pas être justifié pour de nombreuses applications de base de données.
SQL Server Standard Edition inclut toujours le clustering de basculement, qui exploite le clustering de basculement Windows Server intégré au système d’exploitation.
Bien que cela fonctionne bien dans Google Cloud, il nécessite l’utilisation d’un clustering de basculement sans SAN tiers pour remplacer le SAN et permettre l’utilisation du stockage attaché localement dans un cluster de basculement.
L’ajout d’un cluster de basculement sans SAN au cloud Google
Le logiciel de clustering de basculement sans SAN est spécialement conçu pour créer exactement ce que son nom implique :
Un cluster de serveurs et de stockage agnostiques et aucun partage (shared nothing), avec basculement automatique pour la disponibilité des applications.
En tant que solution à haute disponibilité, les clusters sans SAN sont capables de fonctionner sur les réseaux LAN et WAN dans des clouds privés, publics et hybrides.
Ces clusters sont également extensibles, permettant aux entreprises d’avoir une seule solution universelle à haute disponibilité pour la plupart des applications.
La plupart des logiciels de clustering de basculement sans SAN fournissent:
- Une combinaison de réplication de données en temps réel,
- Surveillance continue des applications et
- Stratégies de reprise par basculement/restauration configurables
Cela est pour protéger les applications stratégiques, y compris celles qui utilisent la fonction de cluster de basculement Always On dans SQL Server Standard Edition.
Certaines des solutions de clustering de basculement sans SAN les plus robustes offrent également des fonctionnalités avancées telles que:
- La facilité de configuration et de fonctionnement avec une interface utilisateur graphique intuitive,
- Un choix de réplication synchrone ou asynchrone,
- L’optimisation WAN pour maximiser les performances,
- Le basculement manuel des affectations de serveur primaire et secondaire pour la maintenance planifiée, et
- L’exécution de sauvegardes régulières sans perturber l’application.
La configuration des instances de cluster de basculement SQL Server dans Google Cloud
Cette section décrit le processus utilisé pour configurer un cluster de basculement simple à deux serveurs sur l’infrastructure à base de zones de Google Cloud Platform.
Les configurations impliquant trois serveurs ou plus sont également possibles en utilisant le même processus de base.
L’exemple utilise SIOS DataKeeper Cluster Edition pour créer le cluster de basculement sans SAN.
SIOS DataKeeper utilise la réplication au niveau du bloc pour garantir que le stockage attaché localement sur chaque instance SQL reste synchronisé. Il s’intègre également au Cluster de Basculement Windows Server via sa propre ressource de classe de stockage appelée DataKeeper Volume, qui remplace la ressource de disque physique.
Dans le cluster, le volume DataKeeper semble être un disque physique, mais au lieu de contrôler les réservations SCSI, il contrôle la direction du miroir, garantissant ainsi que seul le serveur actif écrit sur le disque et que les serveurs passifs reçoivent tous les changements, que ce soit synchrone et asynchrone.
L’architecture d’un cluster de basculement sans SAN
L’architecture d’un cluster de basculement sans SAN configuré en tant que cloud privé virtuel (VPC) est illustrée dans le diagramme ci-dessous.
Il existe deux nœuds SQL Server dans différentes zones (1-A et 1-B) dans la région US-Central.
Le témoin de partage de fichiers, nécessaire pour configurer un quorum dans les clusters Windows, est exécuté par le contrôleur de domaine dans la zone 1-C de US-Central.
Garder chaque instance du quorum dans une zone différente élimine la possibilité de perdre plus d’un vote si une zone entière est déconnectée. Les noms de nœud, les adresses IP et les valeurs de sous-réseau du VPC seront également affichés dans les étapes suivantes.
Les clusters de basculement sont créés dans Google Cloud de la même manière qu’ils sont créés dans un cloud privé, mais avec une différence importante :
Vous ne pouvez pas utiliser un seul sous-réseau avec une seule adresse IP virtuelle qui se déplace entre les nœuds du cluster, en raison du manque de prise en charge par GCP de l’ARP (protocole de résolution d’adresse) gratuit.
Il est possible de contourner cette limitation en suivant les procédures décrites ici qui placent chaque nœud dans un sous-réseau différent, puis créent des routes spécifiques à l’hébergeur pour les adresses IP du cluster.
Supposons que le lecteur connaît le sous-réseau de Google Cloud et de l’adresse IP.
Étape 1 : Créer le réseau VPC et les instances de cluster de basculement
Dans cet exemple, le VPC, nommé WSFCNET, a trois sous-réseaux :
- WSFCSUBNET1,
- WSFCSUBNET2 et
- WSFCSUBNET3
Ils sont localisés dans trois zones différentes (10.0.0.0/24, 10.1.0.0/24 et 10.2.0.0/24) pour SQL1, SQL2 et DC1, respectivement.
À l’aide de la console Google Cloud Platform, chaque nœud recevra initialement une adresse IP statique avec renvoi dans le sous-réseau /24.
Cependant, nous allons remplacer tous les nœuds SQL par un masque de sous-réseau /16 pour prendre en charge le routage spécifique à l’hébergeur.
Cette étape implique également la création de règles de pare-feu pour permettre les communications entre les nœuds VPC.
Voici la commande pour créer WSFCSUBNET1 :
gcloud compute networks subnets create wsfcsubnet1 --network wsfcnet \
--region us-central1 --range 10.0.0.0/24
Les instances de cluster de basculement SQL1 et SQL2 utilisent des images Windows Server 2016 standard avec SQL Server pré-installé. Toutefois, le logiciel SQL Server devra être réinstallé en tant qu’instance en cluster après la création du cluster de base à l’étape 3.
L’instance DC utilise également une image Windows Server 2016 standard.
Étape 2 : Mettre à jour les adresses IP et les routes
Avec DC1 connecté et désigné en tant que contrôleur de domaine, les adresses IP pour les instances SQL Server sont modifiées à l’aide de la commande netsh pour avoir un masque de sous-réseau /16 pour prendre en charge le routage spécifique à l’hébergeur.
La commande netsh est également utilisée pour définir l’adresse DNS. La commande gcloud compute routes create sur la console Google Cloud Platform est ensuite utilisée pour créer quatre routes, avec à la fois une route et un listener de route pour SQL1 et SQL2.
Voici les commandes pour mettre à jour l’adresse pour SQL1 :
netsh interface ip set address name=ethernet static 10.0.0.4 255.255.0.0 10.0.0.1 1
netsh interface ip set dns ethernet static 10.2.0.100
Et voici les commandes pour créer le route et le listener de route pour SQL1 :
gcloud compute routes create cluster-sql1-route --network wsfcnet \
--destination-range 10.0.1.4/32 --next-hop-instance sql1 \
--next-hop-instance-zone us-central1-a --priority 1
gcloud compute routes create cluster-sql1-route-listener
--network wsfcnet \
--destination-range 10.0.1.5/32 --next-hop-instance sql1 \
--next-hop-instance-zone us-central1-a --priority 1
Étape 3 : Créer le cluster
Avec les adresses IP et les routes spécifiées, le cluster est créé en exécutant des commandes PowerShell pour activer le cluster de basculement, ainsi que pour valider et créer le cluster, qui désigne également son nom et ses adresses IP de nœud membre.
Avec le cluster créé, les propriétés de quorum et les autorisations sont modifiées pour créer un partage de fichiers sur DC1 et pour accorder aux nœuds de cluster des autorisations de lecture/écriture au niveau partage et NTFS.
Voici la commande PowerShell permettant d’activer la fonctionnalité de cluster de basculement sur les deux nœuds SQL :
Install-WindowsFeature Failover-Clustering –IncludeManagementTools
Cette commande PowerShell est ensuite utilisée pour valider le cluster :
Test-Cluster -Node sql1, sql2
Enfin, le cluster est créé en exécutant la commande New-Cluster à partir de SQL1 ou SQL2 :
New-Cluster -Name cluster1 –Node sql1,sql2 -NoStorage -StaticAddress 10.0.1.4,10.1.1.4
Après avoir créé le partage de fichiers sur DC1, le témoin de partage de fichiers est ajouté en utilisant la commande PowerShell suivante :
Set-ClusterQuorum -NodeAndFileShareMajority \\dc1\quorum
Étape 4 : Installer les instances SQL Server
La dernière étape consiste à installer le logiciel SQL Server sur les deux nœuds (SQL1 et SQL2) du cluster de basculement.
Cette étape implique également la configuration de SIOS DataKeeper pour répliquer les disques connectés localement entre les instances de serveur et enregistrer une ressource de volume DataKeeper dans le cluster du basculement.
La réplication synchrone est généralement utilisée pour la mise en miroir dans une région Google Cloud Platform, comme c’est le cas dans cet exemple. La mise en miroir avec un troisième nœud dans une région distincte utiliserait la réplication asynchrone.
Les détails complets impliqués dans la configuration d’un Google Cloud VPC pour le cluster de basculement sont au-delà de la portée de cet article.
Des instructions complètes étape par étape, incluant des commandes et des captures d’écran détaillées, sont disponibles dans le livre blanc de SIOS, « Comment créer une instance de cluster de basculement SQL Server sans SAN dans Google Cloud Platform avec SIOS DataKeeper ? ».
Certains paramètres sont spécifiques à SIOS DataKeeper, les exigences de configuration sont entièrement applicables à toute solution de cluster de basculement SQL Server.
