Une introduction aux clusters SQL Server avec des diagrammes – Bien choisir son serveur d impression

Les options de haute disponibilité peuvent prêter à confusion. J'ai eu la chance de commencer à travailler avec les clusters SQL Server au début de ma carrière, mais beaucoup de gens ont du mal à trouver des informations simples sur ce que fait un cluster et les problèmes les plus courants lors de la planification d'un cluster.

Aujourd'hui, je vais vous dire ce que sont les clusters, à quoi ils servent et pourquoi j'aime planifier mes clusters de manière très spécifique. Je vais également donner un aperçu de la relation entre le clustering et la fonctionnalité AlwaysOn Availability Groups dans SQL Server 2012, et récapituler les questions fréquemment posées sur le clustering SQL Server.

De quel type de clustering SQL parlons-nous?

Il existe de nombreux types de clusters. Lorsque nous mettons en cluster SQL Server, nous installons une ou plusieurs instances de SQL Server dans un cluster de basculement Windows. Dans cet article, je parle spécifiquement du clustering de SQL Server 2005 ou version ultérieure à l'aide de Windows Server 2008 ou version ultérieure.

Concept clé: Un cluster de basculement Windows utilise un stockage partagé – généralement, ce stockage partagé se trouve sur un SAN. Lorsqu'une instance SQL Server est installée sur le cluster, les bases de données système et utilisateur doivent se trouver sur le stockage partagé. Cela permet au cluster de déplacer l'instance SQL vers n'importe quel serveur (ou «nœud») du cluster chaque fois que vous le demandez, ou si l'un des nœuds rencontre un problème. Il n'y a qu'une seule copie des données, mais le nom de réseau et le service SQL Server pour l'instance peuvent être rendus actifs à partir de n'importe quel nœud de cluster.

Traduction: Un cluster de basculement vous donne essentiellement la possibilité d'avoir toutes les données d'une instance SQL Server installées dans quelque chose comme un partage accessible à partir de différents serveurs. Il aura toujours le même nom d'instance, les travaux de l'Agent SQL, les serveurs liés et les connexions partout où vous le montrez. Vous pouvez même lui faire toujours utiliser la même adresse IP et le même port – afin qu'aucun utilisateur de SQL Server ne doive savoir où il se trouve à un moment donné.

Voici un schéma d'un cluster SQL Server. Le cluster est nommé SQLCLUSTER01. Il possède deux nœuds (serveurs), nommés SQLCLU01NODE01 et SQLCLU01NODE02. Les utilisateurs se connectent à l'instance SQL Server dans SQLCLU01A SQL. L'instance a été configurée sur le port 1433.

Oh non! Il y a eu un échec dans notre environnement!

Voici ce qui s'est passé.

Le serveur SQLCLU01NODE01 s'est arrêté de façon inattendue. Lorsque cela s'est produit, le service de cluster de basculement Windows a constaté qu'il était hors ligne. Il a fait apparaître les services SQL Server sur SQLCLU01NODE02. L'instance SQLCLU01A SQL a démarré et s'est connectée à toutes les mêmes bases de données sur le stockage partagé – il existe une copie des données et elle ne bouge pas. Dans le cadre du démarrage de SQL Server, toutes les transactions en cours et non validées au moment de l'accident ont été annulées.

Pendant ce basculement automatique, les utilisateurs n'ont pas pu se connecter à l'instance SQLCLU01A SQL. Cependant, une fois la sauvegarde terminée, ils ont pu reprendre les opérations comme d'habitude et n'avaient aucune idée qu'un serveur était toujours hors ligne.

Pourquoi vous vous souciez du clustering SQL SERVER

Si vous êtes un propriétaire d'entreprise, un gestionnaire ou un administrateur de base de données, vous vous souciez du clustering, car cela permet de garder vos applications en ligne plus souvent. Lorsqu'il est correctement effectué, il rend votre base de données hautement disponible.

Voici quelques façons dont le clustering vous facilite la vie:

• Les pannes matérielles sont un cauchemar sur les serveurs autonomes. Si un serveur commence à rencontrer des problèmes dans un cluster de basculement, vous pouvez facilement exécuter votre instance SQL Server à partir d'un autre nœud pendant que vous résolvez le problème.
• L'application de correctifs de sécurité sur un serveur autonome peut être très fastidieuse et ennuyeuse pour l'entreprise: SQL Server est hors ligne pendant que vous attendez le redémarrage du serveur. En utilisant le clustering de basculement, vous pouvez appliquer des correctifs avec seulement de brefs temps d'arrêt pour votre application lorsque vous déplacez votre instance SQL Server vers un nœud différent.
• Les clusters de basculement peuvent également vous fournir un outil supplémentaire dans votre boîte à outils de dépannage. Exemple: si vous commencez à voir une latence élevée lors de l'utilisation du stockage et que vous avez exclu tous les candidats immédiats, vous pouvez échouer vers un autre nœud pour essayer d'exclure s'il s'agit d'un problème avec un composant par nœud comme un HBA.
• Le clustering est transparent pour l'application appelante. Beaucoup de choses avec SQL Server fonctionnent simplement avec le clustering, alors qu’elles sont un peu plus difficiles avec d’autres alternatives. Avec le clustering, tout de mes bases de données, de mes connexions, de mes travaux d'agent et de tout ce qui se trouve dans mon instance SQL Server bascule et se rassemble en une seule unité – je n'ai pas besoin de script ou de configurer quoi que ce soit. Je peux également regrouper mon coordinateur de transactions distribuées et le faire basculer avec mon instance également.

Gotchas et notes pour la planification d'un cluster SQL

Savoir ce que le clustering SQL Server ne fait pas

Le premier problème est de savoir ce qu'est un cluster de basculement habitude vous aider avec.

Le clustering n'améliorera pas vos performances, sauf si vous passez à des serveurs plus puissants ou à un stockage plus rapide en même temps que vous implémentez le clustering. Si vous avez été sur le stockage local, ne présumez pas que le passage à un SAN signifie un nirvana de performances. De plus, le clustering ne garantit pas que tout ce qui est impliqué dans votre SAN est redondant! Si votre stockage se déconnecte, votre base de données le devient également.

Le clustering ne vous fait pas économiser d’espace ni d’efforts pour les sauvegardes ou la maintenance. Vous devez toujours faire tout votre entretien normalement.

Le clustering ne vous aidera pas non plus à faire évoluer vos lectures. Bien qu'une instance SQL Server puisse s'exécuter sur n'importe quel nœud du cluster, l'instance n'est démarrée que sur un nœud à la fois. Ce stockage ne peut être lu par personne d'autre sur le cluster.

Enfin, les clusters ne vous donneront pas 100% de disponibilité. Il existe des périodes d'indisponibilité lorsque votre instance SQL Server «bascule» ou se déplace entre les nœuds.

Investir du temps pour déterminer la bonne convention de dénomination

Vous avez beaucoup de noms impliqués dans un cluster: un nom pour le cluster lui-même, des noms pour chacun des serveurs du cluster et des noms pour chaque instance SQL du cluster. Cela peut devenir déroutant car vous pouvez utiliser tout de ces noms plus tard lors de la connexion avec Remote Desktop – donc si vous ne faites pas attention, il peut arriver que vous ne sachiez pas exactement sur quel serveur vous êtes connecté! J'ai deux règles générales pour nommer:

Tout d'abord, assurez-vous que le nom de ce type de composant est évident, qu'il s'agisse d'un cluster, d'un serveur physique, d'une instance SQL Server ou d'un coordinateur de transactions distribuées. Je recommande également d'installer BGINFO pour afficher le nom du serveur sur le bureau pour chaque serveur du cluster.

Ensuite, nommez tout pour que si vous ajoutez ultérieurement d'autres nœuds ou installez une autre instance SQL Server sur le cluster, les noms seront cohérents.

Évitez de placer trop de nœuds dans un cluster SQL

Je préfère n'avoir que deux ou trois nœuds dans un cluster. Par exemple, si j'ai besoin de mettre en cluster cinq instances SQL Server, je les placerais dans deux clusters de basculement.

Cela nécessite globalement quelques noms et adresses IP supplémentaires, mais je préfère cela pour des raisons de gestion. Lorsque vous appliquez des correctifs ou des mises à niveau, vous devez vous assurer que chaque service de votre cluster s'exécute correctement sur chaque nœud après avoir appliqué la modification. Le fait d'avoir un cluster plus petit signifie que vous n'avez pas besoin de faire basculer votre instance autant de fois après un changement.

Ne présumez pas que vos applications se reconnecteront correctement après le basculement

Même si votre instance SQL Server fournira le même nom de réseau et la même adresse IP (si elle n'utilise pas DHCP), de nombreuses applications ne sont pas écrites pour continuer correctement si le serveur de base de données se déconnecte brièvement.

Incluez des tests d'application avec votre migration vers un cluster de basculement. Même si l'application ne sait pas qu'elle parle à un cluster (c'est une chaîne de connexion comme les autres), elle peut ne pas se reconnecter après un basculement. J'ai travaillé avec une application où tout fonctionnait bien après un basculement, sauf que les serveurs Web ont cessé d'écrire leurs données de journal dans une base de données car ils n'étaient pas conçus pour réessayer après un échec de connexion. Les données ont été écrites de manière asynchrone et n'ont provoqué aucune défaillance ayant affecté les utilisateurs, mais le problème n'a pas été immédiatement détecté et a entraîné la perte de certaines données de tendance.

«Active Active» peut être utile

Ma disposition de cluster idéale pour travailler avec est un cluster à deux nœuds avec un matériel identique et deux instances SQL Server dessus. Ceci est communément appelé clustering "Active Active", mais ce terme est techniquement un non-non. Officiellement, cela s'appelle un «cluster de basculement multi-instance». Pas aussi accrocheur, n'est-ce pas?

De nombreuses personnes pensent que la situation idéale consiste à placer leur instance SQL Server la plus importante sur un cluster à deux nœuds et à laisser le deuxième nœud prêt, en attente et inactif. Alors, pourquoi veux-je une deuxième instance SQL Server?

J'aime placer ma base de données de frappeurs lourds et critiques sur l'une de ces instances du cluster. Je veux ensuite prendre quelques bases de données moins critiques et moins occupées et les mettre sur la deuxième instance. Les exemples parfaits sont les bases de données de journalisation. Il y a deux exigences pour ces bases de données: premièrement, elles ne peuvent pas nécessiter une grande quantité de mémoire ou d'utilisation du processeur pour bien fonctionner, car je dois absolument savoir que ces deux instances peuvent fonctionner avec succès à la charge de pointe sur un seul nœud si nécessaire. Deuxièmement, les bases de données sur l'instance «silencieuse» ne devraient pas entraîner la mise hors ligne de l'ensemble de l'application si elles ne sont pas disponibles.

Pourquoi est-ce que j'aime avoir une instance «silencieuse»? Eh bien, chaque fois que j'ai besoin d'appliquer des mises à jour à Windows ou SQL Server, c'est le canari que j'envoie en premier dans la mine de charbon. Vous pouvez effectuer des mises à niveau continues avec des clusters de basculement, ce qui est formidable. Mais il est encore mieux de savoir que la première instance sur laquelle vous basculez sur un nœud mis à niveau ne supprimera pas tout en cas de problème.

Remarques: En raison des coûts de licence, cette option ne sera pas toujours réaliste. Si vous suivez cette voie, vous devez vous assurer que tout peut rester dans le SLA s’il doit fonctionner sur un seul nœud aux heures les plus occupées – ne surchargez pas cette instance «silencieuse»!

Réévaluez vos paramètres de configuration SQL Server

Revoyez vos paramètres de configuration dans le cadre de votre planification. Par exemple, sur un cluster multi-instance, vous utilisez le le minimum paramètre de mémoire pour SQL Server afin de configurer la manière dont vos instances équilibreront leur utilisation de la mémoire si elles se trouvent sur le même nœud.

Dois-je utiliser le clustering pour utiliser des groupes de disponibilité dans SQL Server 2012?

C'est une question intéressante – ne vous laissez pas dérouter. Nous avons une nouvelle fonctionnalité très cool appelée Groupes de disponibilité à venir dans SQL Server 2012, qui Est-ce que offre une fonctionnalité de lecture évolutive impressionnante. Vous lirez à de nombreux endroits qu'il "nécessite un clustering de basculement".

C'est vrai. Pour utiliser la fonctionnalité Groupe de disponibilité dans SQL Server 2012, la fonctionnalité de clustering de basculement doit être activée dans Windows. Si vous utilisez Windows Server 2008 ou une version antérieure, cette fonctionnalité est uniquement disponible dans l'édition Datacenter et Enterprise de Windows Server, de sorte qu'elle n'est pas gratuite. Cette fonctionnalité est désormais incluse dans Windows Server 2012 pour toutes les éditions.

Mais attendez, il y a un hic! Même si vous activez la fonction de cluster de basculement, vous êtes NE PAS requis pour avoir un stockage partagé pour utiliser les groupes de disponibilité. Vous avez la possibilité d'utiliser un cluster de basculement dans un groupe de disponibilité, mais vous pouvez également exécuter vos groupes de disponibilité avec des sous-systèmes de stockage entièrement indépendants si vous le souhaitez. La fonctionnalité est requise car, quoi qu'il en soit, les groupes de disponibilité utiliseront des parties de la fonctionnalité de clustering de basculement pour gérer un nom de réseau virtuel et une adresse IP.

Foire aux questions pour le clustering SQL Server

Q: Puis-je installer chaque composant SQL Server sur mon cluster?
UNE: Nan. SQL Server Integration Services n'est pas «compatible avec les clusters» et ne peut pas échouer dans les deux sens avec votre cluster.

Q: Combien de temps faut-il pour basculer?
UNE: Il y a plusieurs facteurs à considérer dans le temps de basculement. Il est temps pour le service de l'instance SQL Server de descendre sur un nœud, d'être lancé sur un autre nœud et de démarrer. Cette fois, le démarrage et l'arrêt des instances incluent les heures normales de récupération de la base de données. Si vous devez conserver les basculements dans un contrat SLA, vous souhaiterez tester les temps de basculement dans un temps d'arrêt planifié, mais également estimer la durée du basculement. pourrait être si cela arrivait à la charge de pointe.

Q: Puis-je mettre en cluster un serveur virtualisé?
UNE: Oui, vous pouvez créer des clusters de basculement avec des serveurs virtuels avec VMware ou Hyper-V et y installer SQL Server. Je pense que c'est génial pour l'apprentissage et les tests, mais je ne suis pas fou de cela pour les environnements de production. Lisez plus ici.

Q: Pourquoi accordez-vous autant d'importance au stockage partagé?
UNE: Parce que tout le monde ne dispose pas d'un stockage partagé robuste. Vous voulez vous assurer que vous utilisez un stockage partagé doté d'une redondance aux bons endroits, car dans un cluster de basculement, le stockage partagé est un point de défaillance unique, quelle que soit la magie du SAN. Cela signifie également que si vos données sont corrompues, elles le seront quel que soit le nœud à partir duquel vous y accédez.

Q: Quel est le nombre minimum de nœuds dans un cluster de basculement?
UNE: Un. C'est ce qu'on appelle un cluster à nœud unique. Ceci est utile à des fins de test et dans le cas où vous avez un cluster à deux nœuds et devez effectuer un travail sur un nœud. Vous pouvez expulser un nœud sans détruire le cluster.

Q: Puis-je utiliser le géo-clustering pour la reprise après sinistre?
UNE: Oui, mais cela nécessite une configuration sophistiquée. La plupart des clusters SQL Server sont installés dans le même sous-réseau dans un seul centre de données et conviennent à la haute disponibilité. Si vous souhaitez vous pencher sur le clustering multi-sites, le «géo-clustering» est devenu disponible avec SQL Server 2008 et est amélioré dans SQL Server 2012. Remarque: vous aurez besoin de la magie du stockage comme la réplication SAN pour activer votre Geo-cluster. .

Q: Quelle est la version de Windows que j'utilise?
UNE: Oui, ça compte beaucoup. Prévoyez d'installer votre cluster de basculement Windows sur la version la plus récente de Windows Server et vous avez besoin de l'édition Enterprise ou Datacenter. Si vous devez utiliser une ancienne version de Windows, assurez-vous qu'elle est au moins Server 2008 avec les derniers Service Packs installés. Le composant de clustering de basculement de Windows a été réécrit avec Server 2008, donc si vous exécutez sur des versions plus anciennes, vous aurez moins de fonctionnalités et vous serez bloqué à la recherche d'anciens problèmes.

Q: Qu'est-ce que le quorum?
UNE: Le quorum est un décompte des membres votants – un quorum est un moyen de prendre la présence des membres du cluster qui sont présents. Le cluster utilise un quorum pour déterminer qui doit être en ligne. En savoir plus sur le quorum ici.

En savoir plus sur le clustering SQL Server

Consultez notre page de formation sur le clustering SQL Server pour plus d'articles et de vidéos.