• Articles
• admin

Le 9 juillet 2019, la prise en charge de SQL Server 2008 et 2008 R2 prendra fin. Cela signifie la fin des mises à jour de sécurité régulières. Cependant, si vous déplacez ces instances SQL Server vers Azure ou Azure Stack (je vais simplement appeler les deux Azure pour le reste du guide), Microsoft vous offrira trois ans de mises à jour de sécurité étendues sans frais supplémentaires. Si vous utilisez actuellement SQL Server 2008/2008 R2 et que vous ne parvenez pas à mettre à jour une version ultérieure de SQL Server avant la date limite du 9 juillet, vous voudrez profiter de cette offre plutôt que de courir le risque de faire face à une faille de sécurité future. Une instance non corrigée de SQL Server peut entraîner une perte de données, des temps d’arrêt ou une violation dévastatrice des données.

L’un des défis auxquels vous serez confronté lors de l’exécution de SQL Server 2008/2008 R2 dans Azure consiste à garantir une haute disponibilité. Sur site, vous exécutez peut-être une instance de cluster de basculement SQL Server (FCI) pour une haute disponibilité, ou peut-être que vous exécutez SQL Server sur une machine virtuelle et que vous comptez sur VMware HA ou un cluster Hyper-V pour la disponibilité. Lors du passage à Azure, aucune de ces options n’est disponible. Les temps d’arrêt dans Azure sont une possibilité très réelle que vous devez prendre des mesures pour atténuer.

Afin d’atténuer la possibilité de temps d’arrêt et de bénéficier du 99,95% ou 99 d’Azure.99% SLA, vous devez tirer parti de SIOS DataKeeper. DataKeeper comble le manque de stockage partagé d’Azure et vous permet de créer un FCI SQL Server dans Azure qui exploite le stockage attaché localement sur chaque instance. SIOS DataKeeper prend non seulement en charge SQL Server 2008 R2 et Windows Server 2008 R2, comme indiqué dans ce guide, mais prend également en charge n’importe quelle version de Windows Server, de 2008 R2 à Windows Server 2019 et n’importe quelle version de SQL Server à partir de SQL Server 2008 à SQL Server 2019.

Ce guide décrit le processus de création d’une instance de cluster de basculement SQL Server 2008 R2 à deux nœuds (FCI) dans Azure, s’exécutant sur Windows Server 2008 R2. Bien que SIOS DataKeeper prenne également en charge des clusters couvrant des Zones ou des régions de disponibilité, ce guide suppose que chaque nœud réside dans la même région Azure, mais dans des domaines de défaut différents. SIOS DataKeeper sera utilisé à la place du stockage partagé normalement nécessaire pour créer un SQL Server 2008 R2 FCI.

Pré-requis

Active Directory
Ce guide suppose que vous disposez d’un domaine Active Directory existant. Vous pouvez gérer vos propres contrôleurs de domaine ou utiliser les services de domaine Azure Active Directory. Pour ce tutoriel, nous allons nous connecter à un domaine appelé contoso.local. Bien sûr, vous vous connecterez à votre propre domaine en suivant ce tutoriel.

Ouvrez les ports du pare-feu – Gardez à l’esprit que si vous avez une sécurité basée sur le réseau en place qui bloque les ports entre les nœuds du cluster, vous devrez également tenir compte de ces ports.

Compte de service DataKeeper
Créez un compte de domaine. Nous spécifierons ce compte lors de l’installation de DataKeeper. Ce compte devra être ajouté au groupe Administrateurs locaux sur chaque nœud du cluster.

Créer la première instance SQL Server dans Azure

Ce guide exploitera l’image SQL Server 2008R2SP3 sur Windows Server 2008R2 publiée sur le marché Azure.

Lorsque vous provisionnez la première instance, vous devrez créer un nouvel ensemble de disponibilité. Au cours de ce processus, assurez-vous d’augmenter le nombre de domaines de défaut à 3. Cela permet aux deux nœuds de cluster et au témoin de partage de fichiers de résider chacun dans leur propre domaine de défaut.

Si vous n’avez pas encore configuré de réseau virtuel, autorisez l’assistant de création à en créer un nouveau pour vous.

Une fois l’instance créée, accédez aux configurations IP et rendez l’adresse IP privée statique. Ceci est requis pour SIOS DataKeeper et constitue la meilleure pratique pour les instances en cluster.

Assurez-vous que votre réseau virtuel est configuré pour que le serveur DNS soit un contrôleur Windows AD local afin de vous assurer que vous pourrez rejoindre le domaine à une étape ultérieure.

Une fois les machines virtuelles provisionnées, ajoutez au moins deux disques supplémentaires à chaque instance. Les SSD Premium ou Ultra sont recommandés. Désactivez la mise en cache sur les disques utilisés pour les fichiers journaux SQL. Activez la mise en cache en lecture seule sur le disque utilisé pour les fichiers de données SQL. Reportez-vous aux directives de performance pour SQL Server dans les machines virtuelles Azure pour plus d’informations sur les meilleures pratiques de stockage.

Créez la 2ème instance SQL Server dans Azure

Suivez les mêmes étapes que ci-dessus, sauf assurez-vous de placer cette instance dans le même ensemble de réseau virtuel et de disponibilité que vous avez créé avec la 1ère instance.

Créer une instance de témoin de partage de fichiers (FSW)

Pour que le cluster de basculement de Windows Server (WSFC) fonctionne de manière optimale, vous devez créer une autre instance de Windows Server et la placer dans le même ensemble de disponibilité que les instances SQL Server. En le plaçant dans le même ensemble de disponibilité, vous vous assurez que chaque nœud de cluster et le FSW résident dans des domaines de défaut différents, ce qui garantit que votre cluster reste en ligne si un domaine de défaut entier est hors ligne. Cette instance ne nécessite pas SQL Server, il peut s’agir d’un simple serveur Windows car il suffit d’héberger un simple partage de fichiers.

Cette instance hébergera le témoin de partage de fichiers requis par WSFC. Cette instance n’a pas besoin d’avoir la même taille, ni de disques supplémentaires à attacher. Son seul but est d’héberger un simple partage de fichiers. Il peut en effet être utilisé à d’autres fins. Dans mon environnement de laboratoire, mon FSW est également mon contrôleur de domaine.

Désinstallez SQL Server 2008 R2

Chacune des deux instances SQL Server provisionnées a déjà SQL Server 2008 R2 installé sur elles. Cependant, elles sont installées en tant qu’instances SQL Server autonomes et non en cluster. SQL Server doit être désinstallé de chacune de ces instances avant de pouvoir installer l’instance de cluster. La façon la plus simple de le faire est d’exécuter la configuration SQL comme indiqué ci-dessous.

Lorsque vous exécutez setup.exe /Action-RunDiscovery vous verrez tout ce qui est préinstallé

setup.exe /Action=RunDiscovery

Configuration en cours d’exécution.exe/Action=Uninstall/FEATURES=SQL, AS, RS, IS, Tools/INSTANCENAME=MSSQLSERVER lance le processus de désinstallation

setup.exe /Action=Uninstall /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME=MSSQLSERVER

Configuration en cours d’exécution.exe/Action – RunDiscovery confirme la désinstallation terminée

setup.exe /Action-RunDiscovery

Exécutez à nouveau ce processus de désinstallation sur la 2ème instance.

Ajouter des instances au domaine

Ces trois instances devront être ajoutées à un domaine Windows. Comme mentionné dans la section Prérequis, vous devez avoir accès pour rejoindre un répertoire actif Windows existant. Dans notre cas, nous rejoignons un domaine appelé contoso.local.

Ajout d’une fonctionnalité de Clustering de basculement Windows

La fonctionnalité de Clustering de basculement doit être ajoutée aux deux instances SQL Server

Add-WindowsFeature Failover-Clustering

Installez la mise à jour de cumul pratique pour Windows Server 2008 R2 SP1

Une mise à jour critique (kb2854082) est requise pour configurer une instance Windows Server 2008 R2 dans Azure. Cette mise à jour et bien d’autres sont incluses dans la mise à jour de cumul pratique pour Windows Server 2008 R2 SP1. Installez cette mise à jour sur chacune des deux instances SQL Server.

Formater le stockage

Les disques supplémentaires qui étaient attachés lorsque les deux instances SQL Server ont été provisionnées doivent être formatés. Procédez comme suit pour chaque volume sur chaque instance.

Les meilleures pratiques de Microsoft indiquent ce qui suit…

« Taille de l’unité d’allocation NTFS: Lors du formatage du disque de données, il est recommandé d’utiliser une taille d’unité d’allocation de 64 Ko pour les fichiers de données et les fichiers journaux ainsi que TempDB. »

Exécutez la validation de cluster

Exécutez la validation de cluster pour vous assurer que tout est prêt à être mis en cluster.

Import-Module FailoverClustersTest-Cluster -Node "SQL1", "SQL2"

Votre rapport contiendra des AVERTISSEMENTS sur le stockage et la mise en réseau. Vous pouvez ignorer ces avertissements car nous savons qu’il n’y a pas de disques partagés et qu’une seule connexion réseau existe entre les serveurs. Vous pouvez également recevoir un avertissement concernant l’ordre de liaison réseau qui peut également être ignoré. Si vous rencontrez des ERREURS, vous devez les corriger avant de continuer.

Erreur lors de l’exécution de la validation du cluster ?

J’ai rencontré cette erreur à quelques reprises et j’essaie toujours de déterminer dans quelles conditions cela se produit. De temps en temps, vous constaterez que le cluster de tests ne s’exécute pas comme décrit dans le post du forum.

Test-ClusterUnable to Validate a Cluster Configuration. The operation has failed. The action validate a configuration did not completeThere is an error in XML document (5, 73). Attempt by methodMicrosoft.Xml.Serialzation.GeneratedAssembly.XmlSerialzationReaderClusterPrep.Config.Read4_As...Bolean) to access methodMS.Internal.ServerClusters.Validation.TestAssemblyCollection.Add(MS.Internal.ServerClusters.V....Failed

Si cela vous arrive, j’ai trouvé que le correctif suivant recommandé dans le post du forum fonctionne pour moi.

Inside C:\Windows\System32\WindowsPowerShell\v1.0 make a copy of powershell_ise.exe.config file (make a copy inside C:\Windows\System32\WindowsPowerShell\v1.0)- rename it to powershell.exe.configOpen it with notepad- delete current config line and paste:<?xml version="1.0" encoding="utf-8" ?><configuration> <system.xml.serialization> <xmlSerializer useLegacySerializerGeneration="true"/> </system.xml.serialization></configuration>- save and run test-cluster

Bien que ce correctif vous permette d’exécuter un cluster de tests à partir de Powershell, j’ai constaté que l’exécution de Validate via l’interface graphique génère toujours une erreur, même avec ce correctif. J’ai une requête à Microsoft pour voir s’ils ont une solution, mais pour l’instant si vous devez exécuter la validation du cluster, vous devrez peut-être utiliser Test-Cluster dans Powershell.

Créer le cluster

Les meilleures pratiques pour créer un cluster dans Azure consisteraient à utiliser Powershell pour créer un cluster, en spécifiant une adresse IP statique. Powershell nous permet de spécifier une adresse IP statique, contrairement à la méthode GUI. Malheureusement, l’implémentation de DHCP par Azure ne fonctionne pas bien avec WSFC, donc si vous utilisez la méthode GUI, vous vous retrouverez avec une adresse IP en double comme adresse IP du cluster qui devra être corrigée avant que le cluster ne soit utilisable.

Cependant, ce que j’ai trouvé, c’est que la commande powershell New-Cluster typique avec la commande -StaticAddress ne fonctionne pas. Pour éviter le problème de l’adresse IP en double, nous devons recourir au cluster.utilitaire exe et exécutez la commande suivante.

cluster /cluster:cluster1 /create /nodes:"sql1 sql2" /ipaddress:10.0.0.100/255.255.255.0

Ajoutez le Témoin de partage de fichiers

Ensuite, nous devons ajouter le témoin de partage de fichiers. Sur le 3ème serveur que nous avons provisionné en tant que FSW, créez un dossier et partagez-le comme indiqué ci-dessous. Vous devrez accorder des autorisations de lecture/écriture à l’Objet Nom de cluster (CNO) aux niveaux de partage et de sécurité, comme indiqué ci-dessous.

Une fois le partage créé, exécutez l’assistant Configurer le Quorum du cluster sur l’un des nœuds du cluster et suivez les étapes illustrées ci-dessous.

Installez DataKeeper

Installez DataKeeper sur chacun des deux nœuds de cluster SQL Server, comme indiqué ci-dessous.

C’est là que nous spécifierons le compte de domaine que nous avons ajouté à chacun des groupes d’administrateurs de domaine locaux.

Configurez DataKeeper

Une fois que DataKeeper est installé sur chacun des deux nœuds de cluster, vous êtes prêt à configurer DataKeeper.

REMARQUE – L’erreur la plus courante rencontrée dans les étapes suivantes est liée à la sécurité, le plus souvent par des groupes de sécurité Azure préexistants bloquant les ports requis. Veuillez vous référer à la documentation SIOS pour vous assurer que les serveurs peuvent communiquer sur les ports requis.

Vous devez d’abord vous connecter à chacun des deux nœuds.

Si tout est configuré correctement, vous devriez alors voir ce qui suit dans le rapport d’aperçu du serveur.

Ensuite, créez une nouvelle tâche et suivez les étapes illustrées ci-dessous

Choisissez Oui ici pour enregistrer la ressource de volume DataKeeper dans le stockage disponible

Suivez les étapes ci-dessus pour chacun des volumes. Une fois que vous avez terminé, vous devriez voir ce qui suit dans l’interface utilisateur WSFC.

Vous êtes maintenant prêt à installer SQL Server dans le cluster.

REMARQUE – À ce stade, le volume répliqué n’est accessible que sur le nœud qui héberge actuellement le stockage disponible. C’est prévu, alors ne vous inquiétez pas!

Installez SQL Server sur le premier nœud

Si vous souhaitez écrire l’installation par script, j’ai inclus l’exemple ci-dessous d’une installation de cluster par script de SQL Server 2008 R2 dans le premier nœud du cluster. Le script pour ajouter un nœud au cluster existant se trouve plus bas dans le guide.

Bien sûr, ajustez-vous à votre environnement.

c:\SQLServerFull\setup.exe /q /ACTION=InstallFailoverCluster /FEATURES=SQL /INSTANCENAME="MSSQLSERVER" /INSTANCEDIR="C:\Program Files\Microsoft SQL Server" /INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxxx" /SQLDOMAINGROUP="contoso\SQLAdmins" /AGTDOMAINGROUP="contoso\SQLAdmins" /SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS" /FAILOVERCLUSTERGROUP="SQL Server 2008 R2 Group" /FAILOVERCLUSTERDISKS="DataKeeper Volume E" "DataKeeper Volume F" /FAILOVERCLUSTERIPADDRESSES="IPv4;10.0.0.101;Cluster Network 1;255.255.255.0" /FAILOVERCLUSTERNETWORKNAME="SQL2008Cluster" /SQLSYSADMINACCOUNTS="contoso\admin" /SQLUSERDBLOGDIR="E:\MSSQL10.MSSQLSERVER\MSSQL\Log" /SQLTEMPDBLOGDIR="F:\MSSQL10.MSSQLSERVER\MSSQL\Log" /INSTALLSQLDATADIR="F:\MSSQL10.MSSQLSERVER\MSSQLSERVER" /IAcceptSQLServerLicenseTerms

Si vous préférez utiliser l’interface graphique, suivez simplement les captures d’écran ci-dessous.

Sur le premier nœud, exécutez la configuration de SQL Server.

Choisissez Nouvelle installation de cluster de basculement SQL Server et suivez les étapes illustrées.

Choisissez uniquement les options dont vous avez besoin.

Veuillez noter que ce document suppose que vous utilisez l’instance par défaut de SQL Server. Si vous utilisez une instance nommée, vous devez vous assurer de verrouiller le port sur lequel elle écoute et d’utiliser ce port ultérieurement lorsque vous configurez l’équilibreur de charge. Vous devrez également créer une règle d’équilibrage de charge pour le service de navigateur SQL Server (UDP 1434) afin de vous connecter à une instance nommée. Aucune de ces deux exigences n’est couverte dans ce guide, mais si vous avez besoin d’une instance nommée, cela fonctionnera si vous effectuez ces deux étapes supplémentaires.

Ici, vous devrez spécifier une adresse IP inutilisée

Accédez à l’onglet Répertoires de données et déplacez les fichiers de données et les fichiers journaux. À la fin de ce guide, nous parlons de déplacer tempdb vers un volume DataKeeper non reflété pour des performances optimales. Pour l’instant, conservez-le simplement sur l’un des disques en cluster.

Installez SQL Server sur le deuxième nœud

Voici un exemple de commande que vous pouvez exécuter pour ajouter un nœud SQL Server 2008 R2 supplémentaire dans un cluster existant.

c:\SQLServerFull\setup.exe /q /ACTION=AddNode /INSTANCENAME="MSSQLSERVER" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxx" /IAcceptSQLServerLicenseTerms

Si vous préférez utiliser l’interface graphique, suivez les captures d’écran suivantes.

Exécutez à nouveau la configuration de SQL Server sur le deuxième nœud et choisissez Ajouter un nœud à un cluster de basculement SQL Server.

Congratulations , vous avez presque terminé! Cependant, en raison du manque de prise en charge d’Azure pour l’ARP gratuit, nous devrons configurer un équilibreur de charge interne (ILB) pour aider à la redirection du client, comme indiqué dans les étapes suivantes.

Mettre à jour l’adresse IP du cluster SQL

Pour que l’ILB fonctionne correctement, vous devez exécuter la commande suivante à partir de l’un des nœuds du cluster. Il SQL Cluster IP permet à l’adresse IP du cluster SQL de répondre à la sonde de santé ILB tout en définissant également le masque de sous-réseau sur 255.255.255.255 afin d’éviter les conflits d’adresse IP avec la sonde de santé.

cluster res <IPResourceName> /priv enabledhcp=0 address=<ILBIP> probeport=59999 subnetmask=255.255.255.255

REMARQUE – Je ne sais pas si c’est un coup de chance, mais à l’occasion, j’ai exécuté cette commande et il semble qu’elle s’exécute, mais elle ne termine pas le travail et je dois l’exécuter à nouveau. La façon dont je peux savoir si cela a fonctionné est en regardant le masque de sous-réseau de la ressource IP SQL Server, si ce n’est pas 255.255.255.255, vous savez qu’il n’a pas fonctionné avec succès. Il peut s’agir simplement d’un problème d’actualisation de l’interface graphique, vous pouvez donc également essayer de redémarrer l’interface graphique du cluster pour vérifier que le masque de sous-réseau a été mis à jour.

Après son exécution réussie, mettez la ressource hors ligne et remettez-la en ligne pour que les modifications prennent effet.

Créer l’équilibreur de charge

La dernière étape consiste à créer l’équilibreur de charge. Dans ce cas, nous supposons que vous exécutez l’instance par défaut de SQL Server, à l’écoute sur le port 1433.

L’adresse IP privée que vous définissez lorsque vous créez l’équilibreur de charge sera exactement la même adresse que votre SQL Server FCI utilise.

Ajoutez uniquement les deux instances SQL Server au pool d’arrière-plan. N’ajoutez PAS le FSW au pool d’arrière-plan.

Dans cette règle d’équilibrage de charge, vous devez activer l’IP flottante

Validez le cluster

Avant de continuer, exécutez la validation du cluster une fois de plus. Le rapport de validation de cluster doit renvoyer les mêmes avertissements réseau et de stockage que la première fois que vous l’avez exécuté. En supposant qu’il n’y ait pas de nouvelles erreurs ou avertissements, votre cluster est configuré correctement.

Modifier sqlserv.fichier de configuration exe

Dans le répertoire C:\Program Fichiers (x86) \ Microsoft SQL Server \ 100\Tools\Binn nous avons créé un sqlps.EXE.fichier de configuration et sqlservr.EXE.configuration avec les lignes suivantes dans le fichier de configuration:

<configuration> <startup> <supportedRuntime version="v2.0.50727"/> </startup></configuration>

Ces fichiers, par défaut, n’existeront pas et pourront être créés. Si ce ou ces fichiers existent déjà pour votre installation, la ligne <supportedRuntime version= »v2.0.50727″/> doit simplement être placée avec la sous-section <startup>…</startup> de la section <configuration >…</configuration >. Cela devrait être fait sur les deux serveurs.

Testez le cluster

Le test le plus simple consiste à ouvrir SQL Server Management Studio sur le nœud passif et à se connecter au cluster. Si vous êtes capable de vous connecter, félicitations, vous avez tout fait correctement! Si vous ne pouvez pas vous connecter, ne craignez rien, vous ne seriez pas la première personne à faire une erreur. J’ai écrit un article de blog pour aider à résoudre le problème. La gestion du cluster est exactement la même que la gestion d’un cluster de stockage partagé traditionnel. Tout est contrôlé via le gestionnaire de cluster de basculement.

Facultatif – Déplacer la Tempdb

Pour des performances optimales, il serait conseillé de déplacer la tempdb vers le SSD local non répliqué. Cependant, SQL Server 2008 R2 nécessite que tempdb soit sur un disque en cluster. SIOS a une solution appelée Ressource de volume non en miroir qui résout ce problème. Il serait conseillé de créer une ressource de volume non en miroir du disque SSD local et d’y déplacer tempdb. Cependant, le disque SSD local n’est pas persistant, vous devez donc veiller à ce que le dossier contenant tempdb et les autorisations sur ce dossier soient recréés à chaque redémarrage du serveur.