SQL Server

Astuces pour les clusters SQL Server

Tom Moreau, PhD

Vue d'ensemble:

• Exécution de SQL Server sur un cluster
• Exigences matérielles et logicielles
• Clustering d’un nœud
• Options rentables

Un cluster de serveurs vous permet de connecter un certain nombre de serveurs physiques (ou nœuds) jouant le rôle de partenaires de basculement les uns envers les autres. La redondance offerte par un cluster permet de bénéficier d’une plus grande disponibilité pour vos opérations

critiques. J’ai mis en œuvre beaucoup de clusters au cours de mes 13 années de travail avec SQL Server™, et chacun avait ses problèmes spécifiques. Cette expérience m’a permis de rassembler un certain nombre d’astuces qui pourront vous aider.

Les clusters de serveurs tirent parti des capacités de clustering intégrées à la famille des éditions d’entreprise de Windows Server®. En fait, concernant le clustering, Windows Server 2003 est bien plus pratique que Windows 2000 Advanced Server. Pour maximiser les avantages que vous tirerez du clustering, vous avez besoin du matériel adéquat, et cela implique quelques dépenses. Rassembler deux serveurs via un disque partagé ne suffit pas, et vous ne pouvez pas compter sur le fait que les composants matériels individuels se trouveront peut-être dans le Catalogue Windows® (anciennement connu sous le nom de Liste de certification matérielle). Il faut que le système dans son intégralité se trouve dans le Catalogue de Windows. Toutefois, pas d’inquiétude : il existe des solutions plus économiques et approuvées. La figure 1 affiche une configuration de cluster typique.

Figure 1** Cluster typique **(Cliquer sur l'image pour l'agrandir)

Bien sûr, le clustering ne se limite pas au matériel, il faut également que vous choisissiez la bonne édition de SQL Server 2005. L’édition d’entreprise permet le clustering et compte d’autres fonctionnalités utiles, telles que la capacité d’exploiter davantage d’unités centrales, des affichages partitionnés distribués qui peuvent être mis à jour, l’envoi de journaux intégrés et l’utilisation automatique d’affichages indexés. Si vous avez déjà une licence d’édition d’entreprise, je vous conseille de considérer le clustering, que vous disposiez ou non des deux à huit serveurs nécessaires pour former un cluster traditionnel (nous allons parler des clusters à un nœud dans quelques instants). Si vous disposez de SQL Server 2005 Standard Edition, vous pouvez installer un cluster à deux nœuds.

Les éditions Windows Server 2003 Enterprise et Datacenter sont fournies avec un clustering intégré. Il vous suffit d’exécuter l’Administrateur de cluster pour configurer votre cluster. Vous pouvez ajouter tous les nœuds en même temps, ou les ajouter un par un. De même, lorsque vous installez SQL Server, vous pouvez choisir une installation sur un serveur individuel sans cluster ou l’installation d’une instance virtuelle sur un cluster. Si vous choisissez d’installer une instance virtuelle, vous pouvez procéder à une installation sur tous les nœuds du cluster, certains nœuds uniquement ou même un seul nœud.

Enfin, pour atteindre le véritable objectif du clustering (la haute disponibilité), vous aurez besoin de personnel qualifié et de procédures éprouvées en cas de problème. Bien que le clustering constitue une bonne assurance contre les échecs matériels, il n’empêche pas les erreurs d’utilisateurs (comme la suppression d’une table critique par un administrateur de base de données épuisé, au beau milieu de la nuit).

Clusters à un nœud

Même si tout ce dont vous avez besoin est un serveur unique, considérez la création d’un cluster à un nœud. Ceci vous donne la possibilité de passer à un cluster ultérieurement et donc d’éviter une reconstruction. Assurez-vous juste que le matériel choisi se trouve sur la portion de cluster du Catalogue de Windows.

Ce n’est pas uniquement pour une question de disponibilité élevée que l’option d’ajouter un nœud ultérieurement peut s’avérer utile. Imaginez ce qui arrive si vous vous rendez compte que votre serveur n’a tout simplement pas la capacité nécessaire. Une migration est alors inévitable, avec le temps et les efforts associés. Si vous avez un cluster d’un nœud, la migration est plus facile et l’interruption bien moins longue. Vous ajoutez le nouveau nœud au groupe, les binaires SQL Server et les service packs au nouveau nœud, puis vous basculez vers le nouveau mode. Ensuite, vous ajoutez les mises à jour de service packs post-service, le cas échéant, et enfin, vous vous débarrassez de l’ancien nœud. Le temps d’interruption est limité au temps nécessaire au basculement et à l’ajout des mises à jour (le cas échéant).

Ajout de nœuds

Étant donné que tous les nœuds d’un cluster doivent être identiques, il est conseillé de récupérer ce nœud supplémentaire le plus vite possible. Si vous attendez trop longtemps, le nœud ne sera peut-être plus produit. Sur un projet, j’ai eu à reconstruire un nœud dans un cluster SQL Server 2000. J’ai demandé à l’administrateur système d’exploitation/réseau de gérer la construction de base, puis j’ai rajouté celle-ci au cluster et je l’ai préparée au fonctionnement en tant que nœud SQL Server. Tout s’est bien passé, jusqu’au basculement vers le nouveau nœud. À mon grand désarroi, il est repassé immédiatement à l’ancien. Pour résumer, j’avais préparé un document détaillé sur la construction d’un nouveau cluster, y compris l’addition du service de cluster et des comptes de service SQL Server aux deux nœuds, mais celui-ci n’avait pas été suivi explicitement. L’administrateur n’avait pas ajouté les comptes de service au nœud reconstruit, et les privilèges dont ils disposaient avant la reconstruction n’existaient donc plus.

J’ai mis du temps à comprendre ce qui s’était passé. Un jour, j’ai songé à examiner les appartenances de groupes locaux. Une fois les deux comptes ajoutés, le basculement s’est fait sans problème. Et puis j’ai réfléchi. La reconstruction d’un nœud, ce n’est pas quelque chose que l’on fait fréquemment ; c’est quelque chose que l’on fait dans l’urgence. J’avais un document, mais il n’avait pas été utilisé. Nous aurions pu automatiser la partie sécurité en écrivant un script bref pour ajouter ces deux comptes et apporter les autres personnalisations nécessaires. Heureusement, les choses se sont améliorées dans SQL Server 2005. Le programme d’installation vous demande de configurer des groupes niveau domaine pour les comptes de service SQL Server.

Bien sûr, ceci m’a fait réfléchir encore plus. Vous pouvez créer des scripts invoquant CLUSTER.EXE pour ajouter le nœud à votre cluster Microsoft® Cluster Server (MSCS). Tout ce que vous avez à faire, c’est de fournir au script le nom du nœud, il s’occupe du reste. En cas d’urgence, l’automatisation est votre meilleure amie.

Clusters N + 1

Parfois, ce n’est pas parce que vous remplacez un nœud que vous ajoutez un nœud à un cluster. Vous pourriez par exemple être en train d’ajouter des instances SQL Server à votre cluster, chaque instance ayant besoin de ressources de disque séparées. Bien que des instances multiples puissent s’exécuter sur un nœud unique, elles partageraient l’unité centrale et la RAM, ce qui pourrait engendrer des performances médiocres. L’idéal est qu’une seule instance s’exécute sur un seul nœud. Comment garantir ceci lorsque vous procédez au basculement ? La réponse est simple : il y a un nœud sur lequel ne s’exécutent aucun services, tandis que les autres exécutent chacun une instance de SQL Server. En fait, il s’agit là de la définition d’un cluster N + 1 : N instances s’exécutant sur N + 1 nœuds. Le nœud supplémentaire est la sauvegarde.

Mise à niveau de SQL Server

La mise à niveau d’une instance clusterisée de SQL Server n’est pas une mince affaire, car il est clusterisé pour une raison : vous avez besoin de disponibilité. Toutefois, SQL Server 2005 offre un certain nombre d’améliorations très intéressantes ; si vous décidez donc de procéder à la mise à niveau, le temps d’interruption ne sera pas important.

Quelles sont vos options ? Regardons tout d’abord la solution la plus chère : la création d’un nouveau cluster, ce qui signifie de nouveaux serveurs et peut-être un nouveau réseau de stockage SAN (storage area network). Vous pourrez probablement conserver les commutateurs de réseau existant, mais c’est à peu près tout. Évidemment, cette approche n’est pas très économique, mais elle présente des avantages. Le nouveau matériel fonctionne généralement beaucoup mieux que l’ancien, la capacité de disque et la vitesse augmentant en permanence. Ainsi, le matériel lui-même vous permet déjà d’obtenir de meilleures performances. Vous choisirez même peut-être de louer votre équipement afin d’être toujours à la pointe du progrès.

Une fois le matériel en place, vous pouvez créer votre nouveau SQL Server virtuel sur cette installation, y copier vos bases de données de production et lancer le nouveau système, ce qui vous laisse le temps nécessaire pour vous débarrasser des bogues avant le changement définitif. N’oubliez pas de scripter les connexions à partir de votre serveur existant. (Voir support.microsoft.com/kb/246133. Je vous conseille également de mettre à jour votre script de génération de connexion en cas de défaillance catastrophique).

Pour réduire au maximum le temps d’interruption, vous devrez probablement utiliser l’envoi de journaux, à moins que vos bases de données ne soient assez petites et que vous disposiez d’une période pendant laquelle aucun utilisateur n’est connecté. Vous pouvez procéder à l’envoi de journaux juste avant le changement définitif. Ensuite, chassez les utilisateurs, envoyez le journal final, puis pointez l’application vers la nouvelle instance. (Consultez la section sur la mise en miroir de la base de données, ci-dessous, pour obtenir une alternative intéressante à l’envoi de journaux). Si vous utilisez des alias DNS, vous n’aurez sans doute même pas besoin de pointer les applications vers la nouvelle instance. Contentez-vous de mettre à jour l’alias DNS. Cette approche présente un avantage : si vous vous lancez dans une migration et que vous devez revenir à l’original en cours de route, vous avez l’original.

Vous pouvez choisir une voie moins coûteuse, mais cela requiert une planification préalable plus approfondie. Un cluster peut prendre en charge plusieurs instances de SQL Server, mais chaque instance doit disposer de ses propres ressources disque. Lorsque vous configurez votre SAN, mettez un LUN de côté pour une mise à niveau future. Pour exécuter la mise à niveau, installez les binaires SQL Server sur cette ressource disque. Vous pouvez exercer le système et, lorsque vous êtes prêt, arrêter le SQL Server actuel, déplacer les ressources disque de l’ancien groupe SQL Server, mettre à jour les dépendances, et mettre en ligne la nouvelle instance de SQL Server. Attachez les bases de données à partir de l’ancienne instance, et vous y êtes. (Vous avez effectué des copies de sauvegarde auparavant, n’est-ce pas ?)

Il s’agit là de l’approche la moins coûteuse, mais elle comporte quelque risques. En cas de problème, vous ne pouvez pas détacher les bases de données de la nouvelle instance et les remettre. Vous serez alors réduit à restaurer des copies de sauvegarde, ce qui peut impliquer un temps d’interruption important.

Vous pouvez également placer deux instances de SQL Server sur votre SAN, si vous disposez de suffisamment d’espace. Vous restaurez les sauvegardes de production (et l’envoi de journaux) sur la nouvelle instance, et procédez comme indiqué plus tôt. Vous disposez cependant à présent de ressources de secours. Une fois la migration terminée, vous pouvez libérer les ressources SAN de l’ancienne instance. Cela vous coûtera uniquement le prix des disques supplémentaires.

Équilibrage de la charge

Commençons par éliminer une idée fausse très courante. Vous utilisez le clustering MSCS pour obtenir une disponibilité élevée, pas pour l’équilibrage de la charge. En outre, SQL Server ne dispose pas de capacité d’équilibrage de la charge intégrée. Vous devez équilibrer la charge via la conception physique de votre application. Qu’est-ce que cela signifie ?

À mesure qu’un tableau grandit, vous risquez de voir des dégradations des performances, particulièrement lorsque des analyses de tableaux sont impliquées. Lorsqu’il y a des millions, voire des milliards de lignes, la solution traditionnelle consiste généralement à utiliser des affichages partitionnés, constitués de tableaux aux schémas identiques rassemblés avec UNION ALL’s. En outre, des contraintes CHECK sont mises à sa place pour différencier les tableaux membres, et ceci empêche la duplication des données sur l’affichage partitionné. Si la colonne qui est utilisée dans la contrainte CHECK fait également partie de la clé principale, il est possible de mettre l’affichage à jour.

Si les tableaux membres se trouvent dans leurs propres groupes de fichiers, vous obtiendrez peut-être de meilleures performances de disque si les fichiers de ces groupes sont sur des lecteurs physiques séparés. Les tableaux peuvent même se trouver dans des bases de données séparées. Dans SQL Server 2005, cependant, tant que toutes les données se trouvent dans la même base de données, vous pouvez utiliser le partitionnement de tableau, bien plus facile à mettre en œuvre.

Mais imaginons que vous ayez essayé le partitionnement de tableau ou les affichages partitionnés (locaux), et que le fonctionnement soit toujours lent. Si vous avez SQL Server 2000 ou SQL Server 2005, vous pouvez utiliser des affichages partitionnés distribués. La différence majeure est que les tableaux membres peuvent résider sur différentes instances de SQL Server et que ces instances peuvent être installées sur un cluster N + 1. En quoi cela est-il une bonne idée ? Si un tableau membre se retrouve hors ligne dans un affichage partitionné, l’intégralité de l’affichage passe hors ligne. En intégrant ces membres à un cluster, vous disposez de la fiabilité dont vous avez besoin pour les performances et l’équilibrage de la charge.

Avez-vous vraiment besoin d’un cluster ?

Il est possible que vous disposiez de serveurs supplémentaires, mais qu’ils ne se trouvent pas dans le Catalogue Windows pour les clusters. Il serait dommage d’acheter de nouveaux serveurs pour prendre en charge un cluster lorsque ces serveurs sont disponibles.

Dans ce cas, la mise en miroir de la base de données peut constituer une alternative intéressante au clustering. La mise en miroir implique trois éléments : l’instance hébergeant la base de données miroir est l’instance principale ; le serveur de sauvegarde est le miroir, et si vous voulez un basculement automatique, un troisième serveur (témoin) est requis. Brièvement, une transaction dans une base de données sur l’instance principale est de nouveau exécutée sur le miroir. Si l’instance principale a un problème, la base de données peut basculer sur le miroir, de façon automatique si vous avez un témoin. Vous devrez configurer la mise en miroir pour chacune de vos bases de données d’applications, et vous ne pouvez pas mettre en miroir les bases de données système.

Le miroir est une instance séparée de SQL Server, ce qui n’est pas le cas dans un cluster, et peut être situé à des milliers de kilomètres de là. Ses mémoires cache sont remplies par l’activité de mise à jour résultant des transactions dupliquées à partir de l’instance principale. Nous partons bien sûr du principe qu’il n’y a pas d’activités sur le miroir autres que la réception des transactions reflétées à partir de l’instance principale. Le basculement est généralement plus rapide que dans un cluster, puisque SQL Server s’exécute déjà sur le miroir. Étant donné que les mémoires cache sont au moins partiellement amorcées, les performances initiales ne sont pas aussi lentes qu’elles pourraient l’être avec un cluster. En outre, lorsqu’une base de données miroir bascule, les rôles de l’instance principale et du miroir sont inversés.

L’inconvénient de la mise en miroir de base de données est qu’elle nécessite deux fois plus de capacité de disque que si vous choisissez le scénario avec le cluster. Vous aurez également besoin de davantage d’UC si vous choisissez un mode synchrone sans perte de données. Je le répète, la haute disponibilité n’est pas bon marché.

Une approche combinée

Puisqu’un miroir peut être situé assez loin de l’instance principale, il s’agit là d’un bon candidat pour les plans de récupération après incident. Votre cluster peut constituer votre première ligne de défense, mais que se passe-t-il si vous utilisez à la fois un cluster et une mise en miroir ? Dans un basculement sur cluster, si vous disposez d’un témoin dans votre configuration de mise en miroir, le miroir deviendra l’instance principale pendant que le SQL Server en cluster se met en ligne. Cependant, le basculement de la nouvelle instance principale vers le nouveau miroir (en cluster) n’est pas automatique. Par conséquent, il vaut mieux ne pas activer le basculement automatique pour vos bases de données en miroir lorsqu’elles sont utilisées conjointement à un cluster.

Les plans de récupération après incident ne sont pas la seule raison pour laquelle vous pourriez utiliser une mise en miroir ; celle-ci s’avère également utile si vous avez à appliquer un service pack ou un correctif à votre instance principale, auquel cas vous pouvez basculer manuellement vers votre miroir. Pendant que vous appliquez le service pack ou le correctif, l’ancien serveur principal se retrouve temporairement hors ligne et les transactions validées survenant sur la nouvelle instance principale sont mises en file d’attente, avant d’être renvoyées au nouveau miroir (ancienne instance principale). Une fois l’installation du service pack ou du correctif terminée, la synchronisation a lieu et les deux serveurs se trouvent alors complètement synchronisés. Maintenant, vous pouvez échanger les rôles d’instance principale et de miroir. Le temps d’interruption est limité aux quelques secondes nécessaires pour les deux basculements. Vous pouvez utiliser cette approche pour migrer votre SQL Server vers une autre boîte. Ne rebasculez pas ensuite, c’est tout.

Un serveur virtuel permet de bénéficier de davantage de flexibilité

La virtualisation vous permet d’exécuter un ou plusieurs systèmes d’exploitation simultanément sur un serveur physique unique. Le logiciel de virtualisation rajoute une couche de capacités au concept de cluster, car vous pouvez clusteriser le logiciel. Par conséquent, si le serveur sur lequel l’hôte exécute échoue, ce serveur (et ses systèmes d’exploitation invités) basculent vers un nœud de sauvegarde. Ceci peut permettre de migrer un serveur invité très facilement. En outre, le système d’exploitation invité n’a pas besoin d’être compatible avec un cluster. Vous pourriez ainsi exécuter SQL Server Workgroup Edition dans un Windows Server 2003 invité, s’exécutant sur Microsoft Virtual Server 2005 sur un cluster. Indirectement, vous avez clusterisé Workgroup Edition (voir la figure 2).

Figure 2** Utilisation d’un serveur virtuel **(Cliquer sur l'image pour l'agrandir)

Responsable

Si vous êtes responsable d’une mise en œuvre SQL Server, il faut que votre serveur soit disponible en continu. Le clustering vous aide à vous en assurer. Cet article contient quelques bons conseils pour vous aider à démarrer, et vous trouverez d’autres informations utiles dans la barre latérale « Ressources de clustering ».

Ressources de clustering

Pour plus d’informations sur les méthodes utilisées ici et les divers produits dont vous avez besoin pour configurer votre cluster SQL Server, reportez-vous aux ressources suivantes :

• SQL Server 2005 Failover Clustering (en anglais)
• SQL Server 2000 Failover Clustering (en anglais)
• Windows Server 2003 R2 Enterprise Edition–Cluster Server (en anglais)
• Microsoft Cluster Server Administrator’s Guide (en anglais)
• Microsoft Virtual Server 2005 R2

Tom Moreau, PhD, BSc, PhD, MCSE, MCDBA, est un consultant indépendant spécialisé dans l’administration, la conception et la mise en œuvre des bases de données SQL Server ; il est basé dans la région de Toronto. Tom utilise SQL Server depuis 1993 et est MVP depuis 2001. Il a rédigé plus de 100 articles et co-écrit un livre sur SQL Server. Merci à Geoff Hiten, MVP SQL Server, pour son aide.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.