Technologies d'organisation en clusters pour Windows : architecture du service de cluster
Sur cette page
.gif){kind=icon}
Technologies d'organisation en clusters pour Windows : architecture du service de cluster
Résumé
Introduction
Contexte de développement
Terminologie de l'organisation en clusters
Clusters de serveurs
Serveurs virtuels
Groupe de ressources
Architecture du service de cluster
Composants de cluster
Gestionnaire de noeuds
Gestionnaire de la base de données de configuration
Gestionnaire de journal
Gestionnaire des points de vérification
Gestionnaire de ressources
Gestionnaire de basculement
Processeur d'événements
Gestionnaire de communications
Gestionnaire de mise à jour globale
Moniteurs de ressources
Ressources du cluster
Administration d'un cluster
Formation et fonctionnement d'un cluster
Création d'un cluster
Participation à un cluster
Formation d'un cluster
Abandon d'un cluster
Perspectives d'avenir
Pour en savoir plus
Manuels
Technologies d'organisation en clusters pour Windows : architecture du service de cluster
Résumé
Le service de cluster est l'une des deux technologies d'organisation en clusters utilisées par la famille de produits serveurs Microsoft Windows 2000 et Microsoft Windows NT. Les serveurs Windows 2000 et Windows NT utilisant le service de cluster prennent en charge le basculement pour les applications principales et les services pour lesquels haute disponibilité et intégrité des données sont prioritaires. Ces applications principales sont des applications professionnelles du type bases de données, serveurs de fichiers, ERP (Enterprise Resource Planning) et systèmes de messagerie. Ce livre blanc traite principalement de l'architecture et des fonctions du service de cluster et décrit la terminologie, les concepts, les objectifs, les composants principaux et les perspectives d'avenir de ce service.
Introduction
Initialement conçu pour le système d'exploitation Windows NT Server 4.0, le service de cluster a été amélioré et est actuellement parfaitement adapté à Windows 2000 Server. Le service de cluster permet de connecter plusieurs serveurs en cluster pour atteindre une haute disponibilité et une gestion simplifiée des données et des programmes. Le service de cluster présente trois avantages essentiels en matière d'organisation en clusters :
Accroissement de la disponibilité : les services et les applications du cluster continuent de fonctionner en cas de défaillance matérielle ou logicielle ou pendant les opérations de maintenance programmée.
Forte évolutivité : grâce à la prise en charge de serveurs acceptant plusieurs processeurs (jusqu'à quatre processeurs).
Simplification de la gestion : les administrateurs peuvent gérer les périphériques et les ressources du cluster comme s'il s'agissait d'un seul ordinateur.
Le service de cluster est l'une des deux technologies complémentaires d'organisation en clusters pour Windows qui sont proposées comme extensions des versions Windows 2000 et Windows NT standard. La seconde technologie d'organisation en clusters, l'équilibrage de charge réseau (Network Load Balancing), complète le service de cluster en prenant en charge les clusters hautement disponibles et évolutifs pour des applications frontales et des services tels que les sites Internet ou intranet, les applications conçues pour le Web et les services MTS (Microsoft Terminal Services).
Ce livre blanc traite uniquement de l'architecture et des fonctions du service de cluster ; il en décrit la terminologie, les concepts, les objectifs, les principaux composants et les perspectives d'avenir. La rubrique "Pour en savoir plus" figurant en fin de document, donne une liste de références sur le service de cluster et la technologie d'équilibrage de charge réseau.
Contexte de développement
Les clusters d'ordinateurs sont utilisés depuis plus de dix ans. Un des pionniers de la technologie d'organisation en clusters, G. Pfister, définit un cluster comme un "système parallèle ou distribué composé d'un ensemble d'ordinateurs interconnectés, utilisé comme ressource unique homogène".
Le fait de regrouper plusieurs ordinateurs en un seul cluster homogène permet de partager une charge sans que les utilisateurs ou les administrateurs se rendent compte que plusieurs serveurs sont impliqués. En cas de panne d'un des composants du cluster, ce dernier utilise le composant d'un autre serveur et continue de fonctionner normalement pour les utilisateurs. Ceci s'applique aussi bien aux composants matériels que logiciels.
Les utilisateurs connectés au cluster peuvent éventuellement constater une baisse temporaire des performances mais ils ne perdent pas complètement accès au service. Si les administrateurs doivent augmenter la puissance de traitement, ils peuvent ajouter de nouveaux composants par mises à niveau successives. Au cours de ce processus, l'ensemble du cluster demeure connecté et disponible aux utilisateurs, mais ses performances s'améliorent après la mise à niveau.
Les besoins des utilisateurs et des entreprises en matière d'organisation en clusters ont inspiré la conception et le développement du service de cluster. Dès le début, le principal objectif était de développer un service de système d'exploitation adapté aux besoins en organisation en clusters d'une grande variété d'entreprises et de marchés plutôt qu'à ceux de secteurs spécifiques.
Les études de marché conduites par Microsoft dans les petites et moyennes entreprises ont révélé un besoin important et sans cesse croissant de systèmes à haute disponibilité, dès l'instant où les bases de données et le courrier électronique devenaient des éléments essentiels des tâches quotidiennes. La simplicité d'installation et de gestion sont des points clés car les petites et moyennes entreprises comptent généralement peu d'informaticiens parmi leur personnel. Parallèlement, les études de Microsoft menées dans les grandes entreprises, très exigeantes en matière de performances et de disponibilité, ont montré une demande croissante pour les serveurs utilisant Windows.
Les résultats des études de marché ont été pris en compte dans la conception du service de cluster ; le service a été développé en tant qu'extension intégrée aux systèmes d'exploitation Windows 2000 et Windows NT standard. Il permet de réunir les composants de stockage de données et les composants de plusieurs serveurs en une seule unité facile à gérer, le cluster de serveurs. Les clusters de serveurs permettent aux petites, moyennes et grandes entreprises de posséder des systèmes à haute disponibilité, simples à gérer et utilisant des applications conçues pour Windows 2000 et Windows NT. Le service de cluster fournit également les interfaces et les outils logiciels nécessaires au développement de nouvelles applications prenant en charge les clusters.
Terminologie de l'organisation en clusters
Le service de cluster est l'appellation Windows 2000 de la technologie Microsoft initialement appelée Microsoft Clustering Server (MSCS) sous Windows NT Server 4.0, Edition Entreprise. Lorsqu'un ordinateur appartient à un cluster, il est appelé noeud ou système. Le service de cluster fait référence à l'ensemble des composants clés présents sur chaque noeud qui exécutent une activité spécifique au cluster, tandis que les ressources sont les composants matériels et logiciels du cluster qui sont gérés par le service de cluster. Une ressource est dite connectée lorsqu'elle est disponible et qu'elle fonctionne normalement dans le cluster.
Les ressources peuvent être des périphériques tels que des lecteurs de disques ou des cartes réseau ou bien des éléments logiques comme des adresses Internet (IP), des applications ou des bases de données d'applications. Un groupe de ressources est un ensemble de ressources gérées par le service de cluster comme une seule unité logique. Il contient tous les éléments nécessaires au serveur et au client d'une application spécifique pour que celle-ci soit correctement utilisée. Lorsqu'une opération du service de cluster est exécutée sur un groupe de ressources, l'opération affecte toutes les ressources constituant ce groupe.
Clusters de serveurs
Le modèle utilisé pour la conception du service de cluster s'appuie sur l'architecture de cluster dite aucun partage. Ce modèle qualifie un mode de gestion et d'utilisation du système local, des périphériques et des ressources d'un cluster par les serveurs de ce cluster. Dans le cluster dit aucun partage, chaque serveur possède et gère ses propres périphériques locaux. Les périphériques communs au cluster, un lecteur de disques partagé par exemple et les connecteurs, sont, à un instant donné, la propriété d'un seul serveur qui les gère.
Le modèle dit aucun partage simplifie la gestion des périphériques de disques et des applications standard. Ce modèle ne nécessite aucun câblage ni aucune application spécifique et permet au service de cluster de prendre en charge les applications et les périphériques de stockage sur disque conçus pour Windows 2000 et Windows NT.
Le service de cluster prend en charge les pilotes Windows 2000 et Windows NT Server standard pour les périphériques de stockage et les connexions de médias sur serveurs locaux. Les périphériques de stockage externes, partagés sur le cluster, requièrent toutefois des périphériques SCSI. Le service de cluster prend en charge les connexions SCSI PCI standard, y compris SCSI sur Fibre Channel et bus SCSI à multidéclencheur. En fait, ceci ne change pas fondamentalement la façon dont le service de cluster utilise les connexions des médias et des périphériques. Les connexions optiques sont des périphériques SCSI hébergés sur un bus optique au lieu d'un bus SCSI. En théorie, la technologie Fibre Channel intègre les commandes SCSI dans le câble optique et les commandes SCSI utilisées par le service de cluster telles que Réserver/ Libérer et Réinitialisation du bus. Ces commandes fonctionnent comme en SCSI standard (non optique).
La figure suivante représente les composants d'un cluster à deux noeuds avec des serveurs éventuellement exécutant Windows 2000 Advanced Server ou Windows NT Server 4.0 Edition Entreprise, avec des connexions de périphériques de stockage partagées et compatibles SCSI ou SCSI sur Fibre Channel.
.gif)
Figure 1 Cluster à deux noeuds exécutant Windows 2000 Advanced Server ou Windows NT Server 4.0, Edition Entreprise
Windows 2000 Datacenter Server prend en charge les clusters à quatre noeuds et les connexions de périphériques utilisant des commutateurs Fibre Channel. La figure suivante représente les composants d'un cluster à quatre noeuds.
Figure 2 Cluster à quatre noeuds exécutant Windows 2000 Datacenter Server
Serveurs virtuels
Les applications et les services qui s'exécutent sur un noeud du cluster sont, pour les utilisateurs et les stations de travail, des serveurs virtuels. Les utilisateurs et les clients qui se connectent à une application ou à un service s'exécutant sur un cluster ont l'impression de se connecter à un serveur physique unique. En réalité, la connexion s'établit avec un serveur virtuel qui peut être hébergé sur un noeud quelconque du cluster.
Les applications qui s'exécutent sur les différents noeuds d'un cluster sont gérées par le service de cluster et constituent un serveur virtuel unique. Les serveurs virtuels multiples représentant plusieurs applications peuvent être hébergés sur un cluster comme l'indique le schéma suivant.
Figure 3 Représentation physique des serveurs virtuels du service de cluster
Les connexions clientes au serveur virtuel sur un réseau TCP/IP sont établies par une session cliente qui ne connaît que l'adresse IP publiée par le service de cluster comme adresse de serveur virtuel. Le service de cluster gère l'adresse IP comme une ressource appartenant à un groupe de ressources d'applications. Le schéma suivant représente le serveur virtuel tel qu'il est vu par le client.
Figure 4 Représentation des serveurs virtuels du service de cluster pour le client
En cas de défaillance d'une application ou d'un serveur, le service de cluster déplace la totalité du groupe de ressources sur un autre noeud du cluster. Lorsqu'une défaillance se produit, le client détecte la panne pendant l'exécution de l'application et se reconnecte comme il l'a fait initialement. Étant donné que le service de cluster ne fait que réattribuer l'adresse IP du serveur virtuel à un noeud du cluster en état de marche, la session cliente peut rétablir la connexion à l'application sans savoir que celle-ci est maintenant hébergée sur un noeud différent.
Il est important de noter que malgré le taux de disponibilité élevé que ceci confère à l'application ou au service, toutes les informations relatives à la session d'origine sont perdues. En d'autres termes, le service de cluster permet une haute disponibilité mais n'offre pas de fonction de tolérance de panne pour les applications. Pour qu'il y ait tolérance de panne, l'application doit utiliser une logique transactionnelle garantissant que les données clientes sont liées à la base de données du serveur utilisant une sémantique tolérant les pannes.
Groupe de ressources
Les serveurs virtuels du service de cluster sont des groupes de ressources. Un groupe de ressources ne peut appartenir qu'à un seul noeud à la fois et les ressources individuelles d'un groupe doivent être présentes sur le noeud auquel appartient le groupe. À un instant donné, les ressources d'un même groupe ne peuvent pas être possédées simultanément par plusieurs serveurs.
Chaque groupe dispose d'une stratégie de cluster indiquant un serveur privilégié ainsi que le serveur qui devra prendre le relais en cas de défaillance. Chaque groupe a également un nom et une adresse de service réseau permettant aux clients de se lier aux services du groupe de ressources. En cas de panne, les groupes de ressources peuvent être basculés ou déplacés en tant qu'unités composantes du noeud défaillant sur un autre noeud disponible du cluster.
Architecture du service de cluster
Le service de cluster est un ensemble isolé de composants fonctionnant avec le système d'exploitation. Ceci évite d'introduire des dépendances de planification de traitement complexes entre le service de cluster et le système d'exploitation. Il a toutefois été nécessaire d'apporter quelques modifications au système d'exploitation standard pour que les fonctionnalités d'organisation en clusters puissent être implémentées. Parmi celles-ci, on trouve :
Prise en charge de la création et de la suppression dynamiques des noms et adresses réseau
Modification du système de fichiers pour permettre la fermeture des fichiers ouverts pendant le démontage des lecteurs de disques
Modification du sous-système d'Entrée/Sortie pour permettre à plusieurs noeuds de se partager des disques et des ensembles de volumes
Mises à part les modifications évoquées ci-dessus et quelques changements mineurs, les fonctionnalités d'organisation en clusters du service de cluster ont été développées à partir des systèmes d'exploitation Windows 2000 et Windows NT standard.
Composants de cluster
Le service de cluster est constitué de plusieurs composants et processus étroitement liés et fonctionnant ensemble :
Gestionnaire de noeuds : il gère l'appartenance au cluster et contrôle l'intégrité des autres noeuds.
Gestionnaire de la base de données de configuration : il gère la base de données de configuration du cluster.
Gestionnaire de journal : il écrit les modifications du journal de récupération stocké dans la ressource quorum.
Gestionnaire des points de vérification : il enregistre les données dans un fichier journal géré par la ressource quorum.
Gestionnaire de ressources : il prend toutes les décisions relatives à la gestion des ressources et des groupes de ressources et déclenche les actions appropriées : démarrage, redémarrage et basculement.
Gestionnaire de basculement : il collabore avec le gestionnaire de ressources pour la gestion des ressources et des groupes de ressources et pour le déclenchement des opérations de basculement.
Processeur d'événements : il connecte tous les composants du service de cluster, traite les opérations partagées et contrôle l'initialisation du service de cluster.
Gestionnaire de communications : il gère les communications avec tous les autres noeuds du cluster.
Gestionnaire de mise à jour globale : il assure un service de mise à jour globale utilisé par les autres composants du service de cluster.
Moniteur de ressources : il s'exécute séparément et communique avec le service de cluster via des appels de procédure à distance (RPC). Il contrôle l'intégrité de toutes les ressources du cluster en les rappelant.
Gestionnaire de noeuds
Le gestionnaire de noeuds s'exécute sur chaque noeud et gère une liste locale des noeuds appartenant au cluster. À intervalles réguliers, le gestionnaire de noeuds envoie des messages, appelés pulsations, à ses homologues sur les autres noeuds du cluster afin de détecter d'éventuelles défaillances de noeuds. Il est essentiel que tous les noeuds du cluster aient toujours exactement la même liste d'appartenance au cluster.
Si l'un des noeuds détecte une défaillance de communication avec un autre noeud du cluster, il diffuse un message à tout le cluster et tous les membres vérifient leur liste d'appartenance. Ceci porte le nom d'événement de regroupement. Le service de cluster interdit toute opération d'écriture sur les périphériques de disques qui sont partagés par tous les noeuds du cluster tant que la liste d'appartenance n'est pas stabilisée. Si l'un des gestionnaires de noeuds ne répond pas, il est retiré du cluster et ses groupes de ressources actives sont déplacés sur un noeud actif.
Remarque En cas de défaillance du service de cluster et de ses processus, les ressources liées au noeud défaillant sont arrêtées car elles sont supposées redémarrer sur un autre noeud actif disponible.
Gestionnaire de la base de données de configuration
Le gestionnaire de la base de données de configuration met en oeuvre les fonctions requises pour conserver la base de données de configuration du cluster. La base de données de configuration contient des informations sur toutes les entités physiques et logiques d'un cluster. Ces entités sont le cluster lui-même, les listes de noeuds appartenant au cluster, les types de ressources et la description des ressources spécifiques, comme par exemple les disques et les adresses IP.
Les informations permanentes et volatiles stockées dans la base de données de configuration sont utilisées pour le suivi de l'état actuel et de l'état souhaité du cluster. Les gestionnaires de bases de données de configuration de chaque noeud coopèrent afin de maintenir la cohérence des informations de configuration au sein du cluster. Les enregistrements sont effectués en une seule phase pour assurer l'uniformité des copies de la base de données de configuration sur tous les noeuds. Le gestionnaire de la base de données de configuration fournit également une interface à cette base de données, pouvant être utilisée par les autres composants du service de cluster. Cette interface est identique à l'interface de Registre de l'API Win32. La principale différence dans le cas du service de cluster est que les modifications apportées à un noeud sont distribuées de façon atomique par le gestionnaire des points de vérification à tous les noeuds du cluster.
Gestionnaire de journal
Le gestionnaire de journal vérifie régulièrement la copie de la base de données du cluster présente sur chaque noeud pour en assurer l'uniformité. Le gestionnaire de journal et le gestionnaire des points de vérification vérifient que le journal de récupération de la ressource quorum contient les informations les plus récentes sur la base de données.
Gestionnaire des points de vérification
Les applications qui utilisent le cluster stockent des informations dans la base de données de configuration. Il est toutefois possible, pour les applications qui n'utilisent pas le cluster, de stocker des informations dans le registre de noeud. Le gestionnaire des points de vérification conserve les informations du registre de noeud dans le journal de récupération de la ressource quorum. Ces informations portent le nom de point de vérification. Le gestionnaire des points de vérification écrit des points de vérification à partir de la clé de Registre des ressources désignées vers le disque quorum. Ceci garantit que le journal des récupérations de la ressource quorum contient les informations les plus récentes sur la base de données du cluster .
Gestionnaire de ressources
Le gestionnaire de ressources décide de l'arrêt et du démarrage des ressources, gère leurs dépendances et déclenche le basculement des groupes de ressources. Les moniteurs de ressources et le gestionnaire de noeuds lui envoient des informations sur les ressources et l'état du système. Il utilise ces informations pour prendre des décisions concernant les groupes de ressources.
Gestionnaire de basculement
Le gestionnaire de basculement choisit les noeuds auxquels un groupe de ressources doit appartenir. Lorsque l'arbitrage des groupes de ressources est terminé, les noeuds possédant un groupe de ressources individuelles cèdent le contrôle de ces ressources à leur gestionnaire de ressources respectif. Lorsque des défaillances de ressources survenant dans un groupe ne peuvent pas être gérées par le noeud auquel il appartient, les gestionnaires de basculement de chaque noeud du cluster collaborent pour réarbitrer l'appartenance du groupe de ressources.
En cas de défaillance d'une ressource, le gestionnaire de ressources peut la redémarrer ou bien déconnecter cette ressource et ses ressources dépendantes. Si le gestionnaire de ressources déconnecte la ressource défaillante, il indique au gestionnaire de basculement que la propriété de cette ressource doit être déplacée sur un autre noeud et qu'elle doit être redémarrée sous la propriété du nouveau noeud. Cette opération porte le nom de basculement.
Basculement
Un basculement peut s'opérer automatiquement en cas de défaillance du matériel ou d'une application, ou peut être déclenché manuellement par l'administrateur du cluster. L'algorithme est identique dans les deux cas, si ce n'est que les ressources sont fermées de manière appropriée lors d'un basculement manuel, alors qu'elles sont brutalement interrompues en cas de panne.
Lorsqu'un noeud entier est hors service, ses groupes de ressources sont déplacés sur un ou plusieurs autres serveurs disponibles. Le basculement automatique est identique à une réattribution administrative planifiée de la propriété des ressources. Il est toutefois plus compliqué car la phase d'interruption n'est pas exécutée de manière appropriée sur le noeud défaillant.
Pour un basculement automatique, il est nécessaire d'identifier les groupes qui s'exécutaient sur le noeud défaillant ainsi que les noeuds devant prendre possession des différents groupes de ressources. Tous les noeuds du cluster pouvant héberger les groupes de ressources négocient entre eux les propriétés. Cette négociation s'appuie sur la capacité des noeuds, la charge en cours, les commentaires portant sur l'application ou la liste de préférence des noeuds, permettant d'attribuer un groupe de ressources à un noeud. Lorsque la négociation est terminée, tous les noeuds du cluster mettent à jour leur base de données et conservent en mémoire le nom du noeud qui possède le groupe de ressources.
Dans les clusters possédant plus de deux noeuds, la liste de préférence des noeuds pour chaque groupe de ressources peut indiquer un serveur privilégié puis deux alternatives ou plus. Ceci permet de procéder à des basculements en cascade, grâce auxquels un groupe de ressources pourra survivre à plusieurs pannes de serveur, en se déplaçant tour à tour sur les serveurs de la liste de préférence. Les administrateurs de clusters peuvent ainsi établir des listes de préférence pour chaque groupe de ressources d'un serveur pour qu'en cas de panne, les groupes soient réattribués aux serveurs en état de marche.
Une autre possibilité, appelée communément basculement N+1 , consiste à définir les listes de préférence des noeuds de tous les groupes du cluster. La liste de préférence identifie les noeuds du cluster en veille sur lesquels les ressources doivent être déplacées lors de la première panne. Les noeuds en veille sont des serveurs inactifs la plupart du temps ou des serveurs dont la charge de travail peut facilement être anticipée si celle d'un serveur défaillant doit être déplacée vers le noeud en veille.
Lors du choix entre le basculement en cascade et le basculement N+1, les administrateurs doivent prendre en compte l'emplacement de la capacité excédentaire du cluster devant compenser la perte d'un serveur. Dans le cas du basculement en cascade, un serveur sur deux est supposé avoir une capacité excédentaire pour absorber une partie de la charge de travail d'un serveur défaillant. Avec le basculement N+1, le serveur en veille "+1" est censé être l'emplacement principal de la capacité excédentaire.
Restauration automatique
Lorsqu'un noeud est de nouveau connecté, le gestionnaire de basculement peut choisir de replacer certains groupes de ressources sur ce noeud. Cette opération porte le nom de restauration automatique. Il faut avoir défini au préalable un propriétaire privilégié pour les groupes de ressources pour qu'ils puissent être restaurés automatiquement sur un noeud qui a été redémarré ou récupéré. Les groupes de ressources dont le noeud récupéré ou redémarré est le propriétaire privilégié seront déplacés du propriétaire en cours sur ce noeud. Le service de cluster garantit la protection contre la restauration automatique des groupes de ressources pendant les périodes de charge maximale ou contre la restauration vers des noeuds n'ayant pas été correctement récupérés ou redémarrés. Les propriétés de restauration automatique d'un groupe de ressources peuvent préciser les heures pendant lesquelles cette restauration est autorisée ainsi qu'un nombre de tentatives de restauration maximal.
Processeur d'événements
Le processeur d'événements joue le rôle d'un commutateur électronique envoyant des événements entre les applications et les composants du service de cluster qui s'exécutent sur les noeuds du cluster. Le processeur d'événements assure divers services comme l'envoi d'événements signaux à des applications utilisant le cluster ainsi que la conservation d'objets du cluster. Le processeur d'événements est le point d'entrée initial donnant accès à un cluster de serveurs. Lorsque le service de cluster démarre sur un noeud, le statut externe du noeud est déconnecté jusqu'à ce que le processeur d'événements appelle le gestionnaire de noeuds pour démarrer le processus de jonction ou de formation du cluster.
Pour les autres noeuds du cluster et pour les interfaces de gestion du service de cluster, un noeud peut présenter trois états distincts. Ces états sont visibles par les autres noeuds du cluster et sont gérés par le processeur d'événements. Il s'agit des trois états suivants :
Déconnecté. Le noeud n'est pas un membre totalement actif du cluster. Le noeud et son service de cluster peuvent fonctionner ou non.
Connecté. Le noeud est un membre pleinement actif du cluster. Il respecte les mises à jour des bases de données du cluster, il participe aux votes de l'algorithme quorum, il conserve les pulsations et peut posséder et exécuter des groupes de ressources.
En pause. Le noeud est un membre pleinement actif du cluster. Il respecte les mises à jour des bases de données du cluster, il participe aux votes de l'algorithme quorum et conserve les pulsations, mais il ne peut ni posséder, ni exécuter de groupes de ressources. Cet état permet d'exécuter certaines opérations de maintenance. Les états Connecté et En pause sont considérés comme équivalents par la majorité des composants du service de cluster.
Gestionnaire de communications
Le service de cluster de chaque noeud communique en permanence avec le service de cluster s'exécutant sur les autres noeuds. Dans les clusters à 2 ou à 4 noeuds, la communication est intégrale. Cela signifie que chaque noeud est en communication directe avec tous les autres. La communication intra-cluster repose sur des mécanismes RPC qui garantissent une transmission fiable de chaque message exactement 1004246894 de fois.
Gestionnaire de mise à jour globale
Le gestionnaire de base de données de configuration utilise les services de mise à jour assurés par le gestionnaire de mise à jour globale pour dupliquer les modifications apportées à la base de données du cluster de manière uniforme vers tous les noeuds.
Moniteurs de ressources
Les moniteurs de ressources sont des couches de communication passives ne déclenchant aucune opération mais agissant comme intermédiaire entre le service de cluster et les DLL de ressources. Lorsque le service de cluster émet une requête sur une ressource, le moniteur de ressources transfère cette requête à la DLL de ressources appropriée. Lorsqu'une DLL de ressources doit indiquer un état ou notifier le service de cluster d'un événement, le moniteur de ressources vérifie que les informations sont correctement diffusées.
Le moniteur de ressources s'exécute selon un processus distinct du service de cluster afin de le protéger contre toute défaillance de ressources et de pouvoir agir en cas de panne du service de cluster. Le moniteur de ressources détecte les pannes du service de cluster et y répond en déconnectant toutes les ressources et les groupes du noeud affecté.
Chaque noeud de cluster exécute un ou plusieurs moniteurs de ressources. Par défaut, le service de cluster ne démarre qu'un seul moniteur de ressources qui doit intervenir avec toutes les autres ressources hébergées sur le noeud.
Remarque L'administrateur peut modifier le moniteur de ressources par défaut en utilisant soit l'Administrateur de cluster soit une autre application de gestion.
Ressources du cluster
Le service de cluster gère toutes les ressources comme des objets opaques identiques implémentés en tant que bibliothèques de liens dynamiques (DLL). Les ressources ne doivent présenter qu'un nombre restreint d'interfaces et de propriétés simples via une DLL de ressources pour être exécutées sur un cluster de serveurs. Les fichiers DLL de ressources Microsoft sont fournis pour la prise en charge des applications utilisant ou non le cluster.
Le moniteur de ressources charge une DLL de ressources spécifique dans l'espace d'adressage en tant que code privilégié s'exécutant sous le compte système. Le compte système est un compte utilisé uniquement par le système d'exploitation et les services intégrés au système d'exploitation de base. L'utilisation du compte système permet au service de cluster d'effectuer diverses tâches dans le système d'exploitation. Pour plus d'informations sur l'architecture des services système de Windows 2000 et Windows NT, ainsi que sur l'adressage et la sécurité du compte, visitez le site : Microsoft Windows NT, the Foundation .gif)
Toutes les DLL de ressources fournies par Microsoft pour ses applications prenant en charge les clusters, s'exécutent en un seul processus appelé moniteur de ressources. Celles d'autres éditeurs s'exécutent sur un ou plusieurs autres moniteurs de ressources, selon la configuration choisie par l'administrateur du cluster. Les moniteurs de ressources sont créés par le service de cluster en fonction des besoins lors de l'installation ou du démarrage d'une ressource sur un noeud du cluster.
Lorsque l'exécution des ressources dépend de la disponibilité d'autres ressources, ces dépendances peuvent être intégrées à la DLL de ressources. Le service de cluster utilise la DLL de ressources pour connecter les ressources et gérer leur interactivité avec les autres ressources du cluster. Lorsqu'une ressource est dépendante d'autres ressources, elle n'est connectée par le service de cluster qu'une fois que les ressources dont elle dépend sont connectées dans l'ordre approprié.
Les ressources sont déconnectées de la même façon. Le service de cluster déconnecte une ressource après que toutes les ressources dépendantes ont été déconnectées. Ceci évite d'introduire des dépendances circulaires lors du chargement de ressources.
Chaque DLL de ressources peut également définir le type de connexion d'ordinateur et de périphérique nécessaire à la ressource. Une ressource disque, par exemple, peut n'avoir besoin d'appartenir qu'à un seul noeud connecté physiquement au périphérique de disque. Les stratégies de redémarrage local et les actions souhaitées pendant les événements de basculement peuvent également être définies dans la DLL de ressources.
Les DLL de ressources fournies avec Windows NT Server 4.0, Edition Entreprise, permettent au service de cluster de prendre en charge les ressources suivantes :
Partages de fichiers et d'imprimantes
Service ou application générique
Disques physiques
MSDTC (Microsoft Distributed Transaction Coordinator)
IIS (Internet Information Services)
Mise en file d'attente des messages
Adresses et noms de réseau
Windows 2000 Advanced Server et Windows 2000 Datacenter Server possèdent des DLL de ressources pour les services complémentaires suivants :
Système de fichiers distribués (DFS)
Service DHCP (Dynamic Host Configuration Protocol)
Protocole NNTP (Network News Transfer Protocol)
Protocole SMTP (Simple Mail Transfer Protocol)
Service WINS (Windows Internet Service)
Les DLL de ressources créées par d'autres éditeurs permettent au service de cluster de prendre en charge une gamme d'applications plus étendue. L'interface de la DLL de ressources est formellement spécifiée et publiée dans le kit de développement du service de cluster. Cette interface permet aux développeurs d'applications de créer des DLL pour la prise en charge de l'exécution de leurs applications sur des clusters utilisant le service de cluster. Les applications qui fournissent des DLL de ressources au service de cluster sont appelées applications prenant en charge les clusters. Elles garantissent une meilleure évolutivité et offrent des avantages en matière de basculement.
Une application de serveur de base de données peut par exemple fournir une DLL de ressources de base de données pour permettre au service de cluster de basculer vers une base de données individuelle sur un autre noeud. Sans une DLL de ressources de base de données spécifique à l'application, le service de cluster ne peut que basculer intégralement l'application serveur générique (et toutes ses bases de données).
Avec une DLL de ressources de base de données spécifique à l'application, la base de données devient l'unité standard de basculement au lieu du programme serveur. Une fois que l'application serveur n'est plus gérée par le service de cluster, plusieurs serveurs peuvent s'exécuter simultanément sur différents noeuds du cluster, chacun avec ses propres bases de données. Les DLL de ressources d'applications constituent la première étape de l'évolutivité du cluster et sont indispensables aux applications prenant en charge les clusters.
Sans DLL de ressources spécifique à l'application, le service de cluster ne peut qu'utiliser la DLL de ressources générique du serveur fournie avec le service de cluster. Cette DLL de serveur générique effectue le basculement intégral d'une application serveur et de toutes ses bases de données. Sachant qu'une ressource ne peut être active que sur un seul noeud du cluster, ceci limiterait le cluster à une seule variante d'exécution d'un programme serveur d'application ainsi que des fichiers de données associés. Pour connaître la liste des applications de serveur fournissant des DLL de ressources pour le service de cluster, visitez le site
Administration d'un cluster
Le service de cluster fournit une interface d'automatisation pour l'administration des ressources, des noeuds et du cluster lui-même. Les applications et les outils d'administration, comme par exemple l'Administrateur de cluster, peuvent accéder à cette interface par l'intermédiaire des appels de procédure distante, que l'outil s'exécute sur un noeud du cluster ou sur un ordinateur externe. L'interface d'administration compte plusieurs catégories, chacune étant associée à un composant spécifique du cluster : les noeuds, les ressources, les groupes de ressources et le cluster lui-même.
Pour plus d'informations sur l'utilisation de l'interface d'automatisation pour ajouter des outils d'administration au service de cluster, reportez-vous à Base Services dans le kit de développement de la plate-forme :
Pour plus d'informations sur l'utilisation de l'Administrateur de cluster, reportez-vous à l'Aide de Windows 2000 Advanced Server et Windows 2000 Datacenter.
Formation et fonctionnement d'un cluster
Les rubriques qui suivent décrivent brièvement le comportement des noeuds pendant la création et le fonctionnement du cluster. Pour des informations plus détaillées sur l'installation du service de cluster, reportez-vous à l'Aide et aux guides de déploiement de Windows 2000 et Windows NT Server 4.0, Edition Entreprise.
Création d'un cluster
Le service de cluster comporte un utilitaire d'installation permettant aux administrateurs d'installer le logiciel sur un ordinateur et de créer un nouveau cluster. Pour créer un nouveau cluster, l'utilitaire est exécuté sur l'ordinateur sélectionné comme premier membre du cluster. Pour définir le nouveau cluster, il faut lui attribuer un nom et créer sa base de données ainsi que sa liste initiale d'appartenance.
L'étape suivante consiste pour l'administrateur à ajouter les périphériques qui seront partagés par tous les membres du cluster. Le nouveau cluster possède ainsi un noeud unique, ses propres périphériques de stockage local de données et des ressources partagées, généralement des périphériques de stockage de données ou de stockage sur disque et les connecteurs.
La dernière étape consiste à exécuter l'utilitaire d'installation sur chaque ordinateur qui fera partie du cluster. Chaque fois qu'un nouveau noeud est ajouté au cluster, il reçoit automatiquement une copie de la base de données existante à partir du premier membre du cluster.
Participation à un cluster
Le service de cluster est lancé sur chaque noeud par le gestionnaire de services $$de contrôle de Windows 2000 ou Windows NT. Après le démarrage du service de cluster, celui-ci configure et monte ses périphériques locaux non partagés. Pendant le processus de démarrage, le noeud laisse hors connexion les périphériques de l'ensemble du cluster car d'autres noeuds peuvent être en train de les utiliser. Chaque noeud suit un processus de découverte pour détecter les autres membres du cluster. Lorsqu'un noeud découvre un membre du cluster, il exécute une séquence d'authentification.
Le membre initial du cluster tente d'authentifier le nouveau membre et renvoie un message de succès, le cas échéant. Si le nouveau noeud ne peut pas être reconnu comme membre du cluster, ou si le mot de passe du compte est incorrect, la requête de participation au cluster est refusée. Après le succès de l'authentification, la base de données de cluster du nouveau noeud est vérifiée. Si elle n'est pas à jour, le noeud qui effectue l'authentification envoie au nouveau serveur une copie de la base de données à jour. Une fois reçue, cette copie permet de détecter les ressources partagées et de les connecter selon les besoins.
Formation d'un cluster
Dans chaque cluster, une ressource est désignée comme ressource quorum. La ressource quorum maintient l'intégrité des données et l'unité du cluster, et joue un rôle essentiel dans les opérations de cluster. Elle doit être présente pour permettre certaines opérations telles que la formation d'un cluster ou la participation à un cluster existant.
La ressource quorum joue un rôle essentiel lors de la création d'un cluster ou lorsque la communication réseau entre les noeuds d'un cluster échoue temporairement pour éviter la formation de plusieurs clusters par le même groupe de noeuds. Pour former un cluster, un noeud doit posséder la ressource quorum et procéder à son arbitrage. Par exemple, si un noeud ne parvient pas à détecter un cluster pendant le processus de découverte, il tente de former son propre cluster en accédant à la ressource quorum.
Actuellement, le seul type de ressource pouvant être utilisé comme ressource quorum est un disque physique ayant les attributs suivants :
Méthode d'arbitrage permanent permettant à un noeud unique d'obtenir et de garder un contrôle physique sur la ressource quorum. Par exemple, les commandes de disque SCSI, Réserver et Libérer, permettent un arbitrage permanent.
Stockage physique pouvant être accessible par tous les noeuds du cluster.
Capacité d'utiliser NTFS.
Remarque Les autres éditeurs seront bientôt en mesure de créer d'autres types de ressources quorum utilisant le cluster à condition de remplir les conditions répertoriées ci-dessus.
La ressource quorum stocke la dernière version de la base de données de configuration sous la forme de journaux de récupération, stockant les données d'état et de configuration du cluster indépendamment des noeuds. Lorsqu'un noeud forme un cluster ou participe à un cluster, le service de cluster met à jour la copie de la base de données de configuration appartenant à ce noeud. Lorsqu'un noeud participe à un cluster existant, le service de cluster peut récupérer les données à partir des autres noeuds actifs. Mais lorsqu'un noeud est le premier membre d'un cluster, aucun autre noeud n'est disponible.
Le service de cluster utilise les journaux de récupération de la ressource quorum pour effectuer les tâches suivantes :
Garantir qu'un seul groupe de noeuds actifs communiquants soit autorisé à opérer en tant que cluster.
Permettre à un noeud de former un cluster uniquement s'il a le contrôle de la ressource quorum.
Autoriser un noeud à participer ou à demeurer dans un cluster existant seulement s'il peut communiquer avec le noeud contrôlant la ressource quorum.
Abandon d'un cluster
Lorsqu'un noeud quitte un cluster dans le cas d'une fermeture planifiée, il envoie un message du type ClusterExit à tous les autres membres du cluster pour les en avertir. Sans attendre de réponse, le noeud ferme immédiatement ses ressources et arrête toutes les connexions au cluster. Puisqu'ils ont reçu le message d'abandon, les autres noeuds n'effectuent pas le processus de regroupement permettant d'établir les appartenances au cluster qui s'effectue normalement lorsqu'un noeud tombe en panne ou lorsque les communications réseau sont interrompues.
Perspectives d'avenir
Tous les produits utilisant Windows étant en constante évolution, les perspectives d'avenir du service de cluster concernent principalement les points suivants :
Certification et prise en charge d'un plus grand nombre de configurations de cluster à noeuds multiples.
Simplification de l'installation et de la vérification des configurations du cluster, avec prise en charge de nouveaux types de matériels.
Gestion plus simple et plus puissante des applications et des services prenant en charge les clusters, avec une attention particulière portée à la gestion par scripts, à distance et en aveugle.
Extension de la disponibilité et de l'évolutivité de l'organisation en clusters à davantage services système encore.
Intégration plus étroite de l'infrastructure et des interfaces de toutes les technologies d'organisation en clusters sous Windows pour de meilleurs performances, plus de flexibilité et une gestion simplifiée.
Maintient de la prise en charge de produits tiers conçus pour simplifier le développement, l'installation et la prise en charge des applications utilisant l'organisation en clusters, afin d'accroître la disponibilité et l'évolutivité du service de cluster.
Pour en savoir plus
Manuels
Windows NT Microsoft Cluster Server, Richard R. Lee, Osborne McGraw-Hill, 1999.
In Search of Clusters, Gregory F. Pfister, Prentice-Hall, 1998.
Windows NT Cluster Server Guidebook, David Libertone, Prentice Hall, 1998.
Windows NT Backup & Recovery, John McMains et Bob Chronister, Osborne McGraw-Hill, 1998.
Windows NT Clustering Blueprints, Mark A. Sportack, SAMS Publishing, 1997.
Dernière mise à jour le lundi 3 avril 2000
Pour en savoir plus