Administration de Windows

Présentation du clustering avec basculement Windows Server 2008

Chuck Timon

 

En un coup d'œil :

• Composant logiciel enfichable de gestion de cluster de basculement
• Nouvelles fonctionnalités et améliorations
• Fonctionnalités de sauvegarde et restauration
• Migration depuis Windows Server 2003

Sommaire

Nouvelle interface de gestion
Processus de configuration améliorés
Procédure de validation intégrée
Nouveau modèle de quorum
Composants de sécurité améliorés
Fonctionnalités réseau étendues
Fiabilité améliorée lors de l'interaction avec le stockage
Processus de récupération intégrés
Nouvelle fonctionnalité de sauvegarde et de restauration
Migration depuis les clusters de serveurs Windows Server 2003

Depuis que le clustering a été introduit dans Windows NT 4.0 Enterprise Edition, les utilisateurs se plaignent du fait qu'il est trop compliqué à configurer et encore plus difficile à maintenir. L'administration d'un cluster exigeait de la part d'un

administrateur plus qu'une simple compréhension de l'élément de clustering lui-même : il devait également avoir une connaissance intime des technologies de stockage et de l'interaction du service de cluster avec une variété de solutions de stockage. Les capacités nécessaires pour exécuter une solution de haute disponibilité puis la maintenir n'étaient pas faciles à trouver dans beaucoup d'entreprises.

Le clustering s'est amélioré au cours des années, mais il laissait toujours à désirer lorsque Microsoft a commencé à travailler sur Windows Server® 2008. Consciente de cette situation, l'équipe Microsoft s'est mise à reconcevoir le clustering avec, comme objectif principal, la simplicité. Dans Windows Server 2008, Microsoft® Cluster Services (MSCS) a entièrement été remanié et est maintenant appelé Clustering avec basculement.

Cela ne veut pas dire que la simplicité est la seule chose à être introduite par la nouvelle implémentation du clustering avec basculement. Au fil des années, Microsoft a appris de nombreuses leçons à mesure que les entreprises lui fournissaient des commentaires précieux sur ce qu'elles aimeraient voir dans une bonne solution de clustering. Les nouvelles fonctionnalités du clustering avec basculement résolvent plusieurs des nombreux problèmes soulevés par les utilisateurs et introduisent également de remarquables fonctions qui rendent cet outil irrésistible. Dans cet article, j'aimerais donc vous présenter certaines des remarquables fonctionnalités que vous trouverez dans le clustering avec basculement de Windows Server 2008.

Nouvelle interface de gestion

Après avoir installé le clustering avec basculement, vous pouvez accéder à l'interface de gestion de cluster de basculement dans Outils d'administration ou en exécutant Cluadmin.msc. Le composant logiciel enfichable de gestion de cluster de basculement, à l'instar des autres interfaces de gestion de Windows Server 2008, est une console de gestion Microsoft 3.0. Pour les vétérans des clusters, l'ouverture du composant logiciel enfichable de gestion de cluster de basculement pour la première fois semblera étrange, un peu comme quelqu'un qui est parachuté dans un pays étranger sans aucune carte.

La nouvelle interface est divisée en trois volets distincts, comme le montre la figure 1. Le volet de gauche répertorie tous les clusters de basculement de Windows Server 2008 de votre organisation. Le volet central fournit des détails sur la partie d'une configuration de cluster que vous avez sélectionnée dans le volet de gauche, tandis que le volet de droite vous montre les actions qui peuvent être exécutées.

Figure 1 Composant logiciel enfichable de gestion de cluster de basculement (cliquer sur l'image pour l'agrandir)

Supposons que vous sélectionniez Stockage dans le volet de gauche. Le volet central détaille alors le stockage qui a été configuré dans le cluster et le stockage actuellement disponible, le cas échéant. Comme l'indique la figure 1, le cluster renferme un élément de stockage prenant en charge un disque témoin, le stockage qui a été configuré pour un serveur de fichiers et le stockage disponible. Le volet de droite répertorie des actions pertinentes telles que l'ajout de stockage. Notez que le composant logiciel enfichable de gestion de cluster de basculement ne peut pas être utilisé pour administrer des versions précédentes des services de cluster Microsoft.

Processus de configuration améliorés

La configuration d'un cluster de basculement est très simple. Plusieurs des actions visant à configurer, reconfigurer et maintenir un cluster utilisent des assistants. Grâce à ces assistants, l'administrateur n'a plus à vérifier si les ressources sont correctement configurées ou si elles arriveront en ligne dans le bon ordre.

La figure 2 montre l'Assistant de haute disponibilité. Dans cet exemple particulier, un serveur de fichiers a été configuré. À gauche se trouve la liste des étapes à travers lesquelles l'assistant a guidé l'administrateur. Une fois le processus terminé, une page de résumé est affichée et vous avez accès à un rapport.

Figure 2 Assistant de haute disponibilité (cliquer sur l'image pour l'agrandir)

Procédure de validation intégrée

Pour être considérées comme des solutions de cluster prises en charge dans les versions précédentes de Windows Server, les configurations matérielles devaient être répertoriées comme Solution de cluster dans le catalogue Windows Server. Étaient inclus les clusters à plusieurs sites qui étaient indiqués séparément dans la catégorie Géographiquement dispersé. Pour être répertoriés dans le catalogue, les fournisseurs de matériel devaient exécuter une série de tests WHQL (Windows Hardware Quality Lab) et en envoyer les résultats à Microsoft. Pour le fournisseur, il s'agissait là d'une opération onéreuse et la base de données du catalogue Windows Server était difficile à maintenir.

Dans Windows Server 2008, un processus de validation intégré est inclus dans le clustering avec basculement. Ce processus consiste en une série de tests regroupés dans quatre catégories principales, comme le montre la figure 3.

Figure 3 Catégories de tests de validation de cluster de basculement (cliquer sur l'image pour l'agrandir)

Vous pouvez voir que la catégorie Réseau a été développée pour monter les tests qui sont exécutés. Chaque catégorie contient une série de tests. La catégorie Stockage, qui est peut-être la plus importante parmi les quatre catégories, inclut des tests qui veillent à ce que les solutions de stockage soient conformes aux nouvelles exigences mises en place pour les clusters de basculement de Windows Server 2008.

En particulier, les fournisseurs de matériel doivent désormais utiliser des pilotes basés sur le pilote Storport de Microsoft et ils doivent prendre en charge les réservations persistantes SCSI-3. En outre, les modules spécifiques aux périphériques des logiciels avec plusieurs chemins d’accès, lorsqu'ils sont utilisés, doivent être basés sur la norme Multipath I/O (MPIO) de Microsoft.

Avec l'intégration du processus de validation, le modèle de prise en charge a changé. Tout matériel doit avoir un logo Windows Server 2008 et tous les tests de validation doivent réussir. Les seules exceptions sont les clusters à plusieurs sites qui ont deux clôtures de stockage séparées et distinctes, une à chaque site, et l'implémentation de la réplication continue en cluster Exchange Server 2007 qui n'utilise pas de stockage partagé.

Nouveau modèle de quorum

Le modèle de quorum a également changé dans le clustering avec basculement de Windows Server 2008. Dans les anciens systèmes, lorsqu'un administrateur entendait le mot quorum, il pensait à un disque partagé dans lequel résidaient la configuration de cluster et quelques fichiers répliqués. Il s'agissait d'un point de défaillance unique dans le cluster. Si le disque de quorum connaissait une défaillance, le service de cluster était interrompu et la haute disponibilité était perdue.

Les clusters de serveurs de Windows Server 2003 proposaient un deuxième type de quorum appelé le quorum de jeu de nœud majoritaire. Ce type de quorum a été implémenté dans les clusters multisites et ne nécessitait pas de stockage partagé. Le quorum de jeu de nœud majoritaire consistait en un partage de fichiers qui résidait sur le lecteur système de chaque nœud de cluster. Les connexions à ce type de quorum se faisaient par le biais de connexions SMB. Là aussi, pour que le cluster fonctionne, une majorité de nœuds devait participer.

Ensuite, avec l'introduction de la réplication continue en cluster (CCR) d'Exchange Server 2007, la capacité de Témoin de partage de fichiers a été ajoutée aux clusters de serveurs de Windows Server 2003. Ceci permettait à un seul nœud de cluster de la réplication continue en cluster d'Echange 2007 (ou à n'importe quel cluster multisites) de continuer à fournir des services tant qu'une connexion au Témoin de partage de fichiers permettait d'atteindre une majorité.

Dans le clustering avec basculement de Windows Server 2008, le concept de quorum signifie désormais consensus. Le quorum, ou consensus, est maintenant réalisé lorsqu'il existe suffisamment de votes pour mettre le cluster en service. Ces votes peuvent être obtenus de plusieurs façons, selon la configuration du quorum. Quatre modes de quorum sont disponibles dans un cluster de basculement de Windows Server 2008. Ils sont indiqués à la figure 4. Parmi les quatre modes répertoriés, seuls les deux premiers (Nœud majoritaire et Nœud et disque majoritaires) peuvent être automatiquement sélectionnés durant le processus de création du cluster. La logique suivante devrait être utilisée :

• Si un nombre de nœuds impair est configuré dans le cluster, sélectionnez le mode Nœud majoritaire.
• Si un nombre de nœuds pair est configuré dans le cluster et que le stockage partagé est connecté et accessible, sélectionnez alors Nœud et disque majoritaires.

Figure 4 Modes de quorum dans l'Assistant Configurer le cluster du quorum (cliquer sur l'image pour l'agrandir)

Pour sélectionner un disque témoin du stockage disponible, sélectionnez le premier disque d'une capacité d'au moins 500 Mo et doté d'une partition NTFS configurée. Les modes de quorum restants peuvent être sélectionnés manuellement uniquement en exécutant l'Assistant Configurer le cluster du quorum. L'option Nœud et partage de fichiers majoritaires est généralement utilisée dans une configuration de cluster multisites ou dans un cluster CCR d'Exchange 2007. La dernière option, le mode Pas de majorité : disque uniquement, est équivalent au modèle de quorum partagé dans les clusters hérités. Ceci est un point de défaillance unique et ne devrait généralement pas être utilisé.

Il existe seulement deux types de ressources témoin, un disque physique et un partage de fichiers, qui peuvent être configurés dans le cluster pour aider à atteindre un consensus.

Un disque témoin est un élément de stockage que le service de cluster peut mettre en ligne. Ce disque est situé dans le groupe de ressources principales du cluster, avec le nom de réseau du cluster et les ressources d'adresses IP qui lui sont associées. Lorsque le disque témoin est configuré, un dossier Cluster est placé sur le disque et une copie complète de la configuration du cluster (une ruche de clusters ou réplica) est placée sur le disque.

Un témoin de partage de fichiers est un partage réseau qui est situé, dans l'idéal, sur un serveur, sur le réseau qui ne fait pas partie du cluster. Une connexion SMB au témoin de partage de fichiers est effectuée et le témoin de partage de fichiers maintient une copie du fichier journal témoin qui contient des informations de versions liées à la configuration du cluster.

Une seule ressource témoin peut être configurée dans un cluster. Cette ressource fournit un vote supplémentaire, au cas où le cluster en aurait besoin pour atteindre le quorum. En d'autres termes, si le cluster est à un vote (et donc un nœud) d'un consensus, la ressource témoin est placée en ligne afin que le quorum puisse être atteint. Si le cluster est à plus d'un vote du quorum, la ressource témoin n'est pas touchée et le cluster reste dans un état dormant et attend qu'un autre nœud de cluster se joigne.

Composants de sécurité améliorés

Le cluster de basculement propose de nombreuses améliorations de sécurité. La plus importante réside probablement dans le fait que le compte de service de cluster n'est plus exigé. Dans les versions précédentes du service de cluster Microsoft, un compte d'utilisateur de domaine était nécessité durant le processus de configuration. Ce compte, qui était utilisé pour démarrer le service de cluster, a été ajouté au groupe d'administrateurs locaux sur chaque nœud du cluster et s'est vu attribuer les droits d'utilisateur locaux requis pour permettre au service de cluster de fonctionner correctement. En tant que compte d'utilisateur de domaine, le compte de service de cluster était lié à un certain nombre de stratégies au niveau du domaine qui pourraient être appliquées à des nœuds de cluster. Ces stratégies pouvaient avoir une influence négative sur la haute disponibilité en provoquant l'échec du service de cluster.

Le service de cluster s'exécute désormais sous un compte de système local avec une série de droits spécifique sur le nœud du cluster local qui lui permet de fonctionner correctement. Le contexte de sécurité du cluster est passé à l'objet nom de cluster (CNO) qui est l'objet ordinateur qui est créé, par défaut, dans le conteneur Ordinateurs d'Active Directory® la première fois que le cluster est créé. Une fois un cluster créé et que le CNO existe dans Active Directory, le compte utilisateur qui a été utilisé pour installer et configurer le cluster n'est plus nécessaire.

Les autres objets ordinateur créés dans Active Directory dans le conteneur Ordinateurs sont associés à un cluster de basculement. Ces objets, appelés objets d'ordinateurs virtuels (VCO), correspondent à des ressources de nom de réseau du cluster qui sont créées dans le cadre des points d'accès client (CAP) du cluster. Le CNO, qui est chargé de créer tous les VCO d'un cluster, est ajouté à la liste de contrôle d'accès système (SACL) de l'objet dans Active Directory (voir figure 5).

Figure 5 Sécurité sur un VCO dans Active Directory (cliquer sur l'image pour l'agrandir)

Le CNO est également chargé de synchroniser les mots de passe de domaine de tous les VCO qu'il a créés. Ce processus est accompli conformément à la stratégie de domaine configurée pour la rotation des mots de passe. En outre, puisque le CNO est chargé de créer tous les objets ordinateur associés aux VCO d'un cluster, il doit avoir le droit de niveau de domaine de créer des objets ordinateur sur le conteneur dans lequel sont créés les VCO (par défaut, le conteneur Ordinateurs).

Autre changement, Kerberos est désormais utilisé comme méthode d'authentification par défaut. L'existence de comptes d'ordinateur dans Active Directory permet d'obtenir cette fonctionnalité de sécurité améliorée. Le cluster a, toutefois, la possibilité d'utiliser l'authentification NTLM (NT LAN Manager) si une application qui n'est pas capable d'utiliser Kerberos pour l'authentification venait à avoir besoin d'accéder aux ressources du cluster.

La communication entre les nœuds du cluster qui sont directement liés au processus du cluster est également plus sécurisée. Toutes les communications à l'intérieur du cluster sont signées par défaut. À l'aide de l'interface CLI cluster.exe, vous pouvez modifier la propriété de ce cluster afin que toutes les communications entre les nœuds soient chiffrées pour renforcer la sécurité.

Fonctionnalités réseau étendues

Les nouvelles capacités de mise en réseau dans les clusters de basculement offrent plus de flexibilité dans la conception de solutions de haute disponibilité et de récupération après incident. En même temps, ces améliorations proposent une connectivité plus fiable au sein des nœuds du cluster.

La fonctionnalité cliente la plus demandée a probablement été la capacité à localiser des nœuds de cluster sur des réseaux séparés. Ceci est désormais possible. Le pilote de réseau de cluster a été complètement réécrit et offre une communication extrêmement fiable et à tolérance de panne parmi les nœuds d'un cluster, à condition que chaque nœud soit connecté à au moins deux réseaux séparés et distinctement routés.

Le pilote de réseau de cluster construit sa propre table de routage interne en fonction des informations de connectivité fournies durant le processus de démarrage du cluster. Ceci inclut les informations sur la connectivité locale de même que les informations qui sont fournies dans la base de données de configuration du cluster (ruche du registre de cluster).

Une partie du processus de validation de cluster inclut un processus de découverte de connectivité réseau. La possibilité de repérer des nœuds de clusters sur différents réseaux routés a contribué à minimiser les exigences concernant la mise en réseau des clusters multisites. Les organisations pourront ainsi déployer ces derniers plus facilement et à un coût moindre. En outre, l'utilisation du stockage iSCSI devient une solution de stockage plus attrayante dans les clusters de basculement.

Les nœuds de cluster peuvent également obtenir des informations sur les adresses IP via DHCP (Dynamic Host Configuration Protocol). Ceci peut faciliter la tâche des administrateurs réseau s'ils sont prêts à accepter d'utiliser l'adressage dynamique pour les serveurs de leur environnement.

La configuration des interfaces réseau d'un nœud de cluster détermine les réseaux qui utiliseront des adresses IP statiques ou dynamiques. Même si une ressource d'adresse IP d'un cluster est obtenue d'un serveur DHCP, elle peut être transformée en adresse IP statique dans le composant logiciel enfichable de gestion de cluster de basculement.

Par le passé, les communications de cluster utilisaient toutes la diffusion UDP et quelquefois la multidiffusion. La fonctionnalité de multidiffusion a été interrompue et les communications de cluster utilisent désormais la monodiffusion UDP. (Le port 3343 demeure le port le plus communément utilisé par les clusters Microsoft). De nombreux administrateurs réseau seront très contents d'apprendre que la diffusion n'est plus utilisée. Le vrai avantage d'un cluster, cependant, réside dans les nouveaux processus de messagerie qui sont internes au service de cluster lui-même. (Ceci, toutefois, n'entre pas dans le cadre de cet article). Les communications à l'intérieur du cluster disposent à présent de caractéristiques de communications TCP plus fiables bien qu'UDP soit utilisé comme mécanisme de transport.

Fiabilité améliorée lors de l'interaction avec le stockage

La façon dont les clusters de basculement interagissent avec le stockage est radicalement différente. Le pilote du disque de cluster (clusdisk.sys) a été entièrement réécrit et est maintenant un vrai pilote Plug-and-play. Et la manière dont il interagit avec le stockage a changé.

Dans Windows Server 2003, le pilote du disque de cluster se trouvait dans un chemin direct vers le stockage. Dans Windows Server 2008, toutefois, le pilote du disque de cluster communique avec le pilote du gestionnaire de partition (partmgr.sys) pour interagir avec le stockage. Ces deux approches sont illustrées à la figure 6.

Figure 6 Comment la pile de stockage a changé dans Windows Server 2008 (cliquer sur l'image pour l'agrandir)

Le gestionnaire de partition est chargé de protéger les ressources disque du cluster. Tous les disques se trouvant sur un bus de stockage partagé sont automatiquement placés dans un état hors connexion lorsqu'ils sont mappés à un nœud de cluster pour la première fois. Ceci permet de mapper le stockage simultanément à tous les nœuds d'un cluster avant même que ce cluster ne soit créé. Les nœuds n'ont plus à être lancés l'un après l'autre, les disques préparés sur un nœud puis ce nœud fermé, un autre nœud lancé, la configuration disque vérifiée, et ainsi de suite.

Il y a toujours, cependant, les tests de stockage qui sont exécutés dans le cadre du processus de validation de cluster et nécessitent l'initialisation des disques. Ceci peut être accompli sur l'un des nœuds du cluster avant l'exécution du processus de validation. Une fois le stockage ajouté à un cluster, les disques affichent un état Réservé dans l'interface Gestion des disques et ne sont jamais laissés dans un état non protégé.

Un autre changement concerne les commandes SCSI. Dans Windows Server 2003, les commandes SCSI-2 Reserve\Release ont été utilisées avec le pilote du disque de cluster qui écrivait sur des secteurs du disque lui-même. Dans Windows Server 2008, les commandes SCSI-3 de réservation persistante sont nécessaires. Les nœuds de cluster doivent s'inscrire avant de pouvoir placer une réservation sur le stockage, et les nœuds de cluster défendent périodiquement leurs réservations en utilisant le protocole de réservation et défense.

L'un des tests de stockage du processus de validation vérifie cette fonctionnalité. Si une solution de stockage ne prend pas en charge les commandes SCSI-3 (réservation persistante), elle n'est pas prise en charge dans un cluster de basculement.

Beaucoup d'entreprises utilisent des logiciels à plusieurs chemins d'accès pour la redondance lorsqu'elles se connectent au stockage. Cette opération est prise en charge et même encouragée en tant que méthode recommandée. Cependant, les solutions de logiciel à plusieurs chemins d'accès tierces ou les modules spécifiques aux périphériques doivent être réécrits en utilisant la norme Multi-Path Input\Output de Microsoft qui doit être prise en charge dans un cluster de basculement. Toutes les commandes SCSI-3 PR sont ainsi simultanément envoyées à tous les chemins vers le stockage, que ces chemins soient actifs ou non. Cette fonctionnalité est également vérifiée dans le cadre du processus de validation.

Les autres améliorations du stockage incluent un meilleur processus de disque de vérification (chkdsk.exe), une fonctionnalité de réparation de disque intégrée qui était auparavant la partie de l'utilitaire de récupération de Cluster Server et les disques à réparation automatique. Dans les clusters de basculement, la signature de disque et l'ID du LUN sont tous deux utilisés lors de l'identification d'une ressource disque du cluster. Si l'un ou l'autre change, la configuration de cluster est mise à jour. Les erreurs sont ainsi réduites en raison, tout simplement, d'un changement d'attribut sur une ressource disque physique ayant pour résultat une plus haute disponibilité.

Processus de récupération intégré

La réparation de disque précédemment mentionnée est évidemment l'une des capacités de récupération intégrées. Une autre capacité est la capacité de réparation Active Directory. Si l'objet ordinateur qui représente le CNO est supprimé, vous ne pourrez plus créer d'objets ordinateur associés aux CAP de cluster. Toutefois, le premier problème que vous risquez de rencontrer est lorsque des applications ou utilisateurs hautement disponibles ne peuvent pas accéder aux ressources à l'extérieur du cluster parce qu'un jeton de sécurité ne peut pas être obtenu.

Le processus de récupération d'un CNO supprimé comporte deux étapes. Tout d'abord, vous devez engager un administrateur de domaine pour récupérer l'objet ordinateur supprimé du conteneur DeletedObjects dans Active Directory. Ensuite, une fois l'objet restauré et réactivé, vous devez exécuter le processus de réparation de l'objet Active Directory dans le composant logiciel enfichable de gestion de cluster de basculement.

Dans les clusters de serveurs de Windows Server 2003, il y avait toujours un risque que le fichier de configuration de cluster situé dans le sous-répertoire %systemroot%\cluster pouvait se corrompre et devait alors être remplacé. Dans les clusters de basculement, la capacité de réparation automatique est très utile. Si le service de cluster démarre sur un nœud et que la base de données de configuration est corrompue, un modèle de configuration minimal sera chargé à l'aide des informations contenues dans la clé de registre HKLM\System\CCS\Services\ClusSvc\Parameters. Le nœud tentera de joindre un cluster déjà formé et, si cette tentative réussie, une nouvelle copie de la ruche du registre de cluster sera envoyée au nœud. Si un nœud ne peut pas joindre un cluster, le service de cluster sera interrompu.

Nouvelle fonctionnalité de sauvegarde et restauration

Le clustering avec basculement est fourni avec son propre rédacteur VSS. Il joue un rôle clé dans la sauvegarde et restauration d'une base de données de cluster et des données qui résident sur les ressources disque physiques. La sauvegarde de la configuration de cluster est simple. Tant que l'état du système fait partie d'une sauvegarde, la configuration de cluster peut être restaurée. Notez, toutefois, qu'un cluster ne devrait être sauvegardé que s'il a un quorum. Ceci signifie que la configuration du cluster la plus à jour sera sauvegardée.

Il existe deux types de restauration de cluster distincts : la restauration faisant autorité et la restauration ne faisant pas autorité. Une restauration ne faisant pas autorité utilise la Sauvegarde Windows Server ou une application de sauvegarde tierce pour exécuter une restauration d'une sauvegarde sélectionnée. Une restauration faisant autorité d'un nœud de cluster, d'autre part, ne peut être accomplie qu'à l'aide du CLI de Sauvegarde Windows Server (wbadmin.exe).

Une restauration faisant autorité renvoie essentiellement la configuration de cluster « en arrière », au moment où la sauvegarde a été effectuée. Pour effectuer une restauration faisant autorité, le service de cluster est arrêté sur tous les nœuds, à l'exception de celui sur lequel la restauration est exécutée. Une fois la restauration terminée et le service de cluster démarré sur le nœud restauré, la configuration restaurée du cluster devient la nouvelle configuration de cluster. Ainsi, lorsque le service de cluster est redémarré sur les nœuds restants dans le cluster, la configuration restaurée est transférée durant le processus de jointure.

Ceci peut vous faire économiser du temps et de l'argent dans certains scénarios. Supposons que vous ayez un cluster d'impression qui héberge plusieurs ressources de spouleur d'impression, chacun prenant en charge 1 500 imprimantes et que vous supprimiez accidentellement l'une de ces ressources. De nombreux utilisateurs ne peuvent pas imprimer. Au lieu de rajouter manuellement toutes ces imprimantes dans la configuration de cluster, il serait beaucoup plus facile d'effectuer une restauration faisant autorité de la configuration de cluster. Ceci, suppose, bien sûr, que vous ayez mis en place une solide stratégie de sauvegarde et restauration.

Migration des clusters de serveurs Windows Server 2003

En raison de toutes ces modifications architecturales dans le clustering avec basculement de Windows Server 2008, les mises à niveau existantes ou simultanées de Windows Server 2003 ne sont pas prises en charge. Durant une mise à niveau des clusters de Windows Server 2000 à Windows Server 2003, beaucoup d'organisations choisissent d'expulser systématiquement chaque nœud du cluster, de faire une installation propre du système d'exploitation et de rajouter ensuite le nœud dans le cluster. Cette approche ne peut pas être utilisée pour migrer vers Windows Server 2008, étant donné que les nœuds de cluster de Windows Server 2003 et Windows Server 2008 ne peuvent pas faire partie du même cluster.

Fort heureusement, un processus de migration basé sur un Assistant a été inclus pour faciliter la migration. La migration vers un cluster de basculement Windows Server 2008 nécessite, toutefois, une certaine planification. Il existe trois principaux scénarios de migration :

• la migration qui utilise les mêmes serveurs et le même stockage
• la migration qui utilise les mêmes serveurs mais avec un nouveau stockage
• la migration qui utilise de nouveaux serveurs et un nouveau stockage.

Pour chacun de ces scénarios, vous devez vous assurer que le matériel a été certifié sous le programme de logo de Windows Server 2008 et que le processus de validation du cluster de basculement a été exécuté et que tous les tests ont été positifs. Une fois ces étapes terminées, le processus de migration peut continuer.

Les ressources d'un cluster de serveur Windows Server 2003 ne peuvent pas toutes être migrées. Vous pouvez migrer les noms de réseau, les adresses IP, les disques physiques, les partages de fichiers, les racines DFS, DHCP et WINS. Vous pouvez également migrer, dans une certaine mesure, des services génériques, des applications génériques et des ressources de script génériques.

Les applications telles que Microsoft Exchange et SQL Server®, quant à elles, possèdent leurs propres procédures de migration vers un cluster de basculement. Les imprimantes peuvent être migrées vers Windows Server 2008 en utilisant le composant logiciel enfichable Gestion de l'impression (qui est installé avec le rôle serveur d'impression) pour tout d'abord exporter puis importer des imprimantes vers un serveur d'impression récemment configuré et hautement disponible. Aucun type de ressource tiers ne peut faire l'objet d'une migration.

Le processus de migration ne migre pas de données. Il migre les paramètres de configuration de cluster de Windows Server 2003 à Windows Server 2008.

Toutes les ressources migrées sont initialement placées dans un état hors connexion à la fin du processus de migration. La raison en est que d'autres étapes supplémentaires peuvent s'avérer nécessaires. Il est donc important de consulter le rapport de post-migration pour voir quelles étapes supplémentaires (à l'exclusion de la migration de données si vous migrez vers un nouveau stockage) sont nécessaires avant de mettre le cluster en service. Par exemple, si un serveur DHCP est migré, le rôle de serveur DHCP doit être installé sur tous les nœuds du cluster. Si vous migrez un serveur WINS, ses fonctionnalités doivent être installées sur tous les nœuds du cluster.

Chuck Timon est ingénieur support à Microsoft, spécialisé dans les technologies de cluster et d'installation. Il a écrit le cours de formation au cluster de basculement de Windows Server 2008 et s'occupe, à présent, de la formation Hyper-V.

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