Création de partages de fichiers et d'imprimantes hautement disponibles avec le service de cluster de Windows 2000

Article
01/18/2008

Sur cette page

Création de partages de fichiers et d'imprimantes hautement disponibles avec le service de cluster de Windows 2000
Introduction
Termes et concepts fondamentaux
Conventions d'affectation de noms
Architecture de type "Shared-Nothing"
Ressources
Dépendances
Groupes Groupes
Basculement et restauration automatique
Serveur virtuel
Création d'un serveur virtuel
Partages de fichiers
Introduction : les partages de fichiers dans le service de cluster Windows 2000 Introduction : les partages de fichiers dans le service de cluster Windows 2000
Création d'un partage de fichiers
Configuration des paramètres propres aux ressources
Un mot sur les autorisations
Partages de fichiers normaux
Sécurité
Consolidation du serveur : scénario 1 Consolidation du serveur : scénario 1
Partages de sous-répertoires de partage
Sécurité
Consolidation du serveur : scénario 2
Partages DFS
Sécurité
Scénario
Partages d'imprimantes
Introduction
Création d'une ressource spouleur
Ajout d'imprimantes
Ajout de pilotes supplémentaires
Scénario
Implémentation
Présentation de la procédure
Conclusion
Pour en savoir plus
Annexe Annexe
Configuration d'un cluster
Remarques relatives à l'installation
Création d'un serveur virtuel
Assistant Application en cluster
Ressource par ressource
Création d'une ressource de partage de fichiers
Imprimantes
Création d'une ressource spouleur d'impression à l'aide de l'Assistant Application en cluster
Ajout d'une imprimante
Ajout de pilotes à l'autre nœud
Configuration de la restauration automatique

Création de partages de fichiers et d'imprimantes hautement disponibles avec le service de cluster de Windows 2000

Système d'exploitation

Par Richard Sasser
Microsoft Corporation

Collaborateurs : Elden Christensen, Guy Henderson, Mike Lawson, John Marlin, Matt Mucker

Résumé

Ce livre blanc présente les scénarios de création de partages de fichiers et d'imprimantes hautement disponible grâce à la fonctionnalité service de cluster du système d'exploitation Microsoft® Windows® 2000. Bien qu'il ne prétende en aucun cas constituer une liste exhaustive de chaque scénario possible, il offre suffisamment d'exemples pour permettre aux administrateurs d'implémenter le service de cluster afin de répondre au mieux aux besoins des utilisateurs.

Introduction

Les services de fichiers et d'impression comptent parmi les services les plus essentiels du système d'exploitation pour les utilisateurs finaux de n'importe quel réseau informatique. Par conséquent, la fonctionnalité Service de cluster du système d'exploitation Microsoft® Windows® 2000 Advanced Server a pour principal objectif de permettre aux administrateurs de créer des partages de fichiers et d'imprimantes hautement disponibles. Dans la mesure où les clusters sont nouveaux dans Windows et qu'ils nécessitent que les administrateurs oublient leur vision d'un système d'exploitation Windows centré sur l'ordinateur, ce document a été créé pour apporter les bases d'une implémentation correcte du service de cluster de Windows 2000, avec notamment l'architecture "shared-nothing" du service de cluster, la structure en groupes et les serveurs virtuels. Les partages de fichiers et les spouleurs d'impression sont traités par type et l'annexe offre une illustration détaillée de l'installation de clusters dont il est question dans ce document.

Termes et concepts fondamentaux

Cette section étudie les termes et concepts fondamentaux utilisés dans ce document.

Conventions d'affectation de noms

Les débutants en gestion de clusters sous Windows seront peut-être un peu perdus devant la diversité des conventions d'affectation de noms. Lors du développement de la version bêta du service de cluster, le produit était connu sous le nom de Wolfpack. Une fois le produit sorti, le nom "officiel" du produit est devenu le service de cluster Microsoft, parfois appelé MSCS. Différents articles de la Base de connaissances font également référence à cette technologie sous le nom de Cluster Server ou de clusters de serveur. Il s'agit de la même technologie.

Ce type de mise en cluster ne doit pas être confondu avec l'équilibrage de charge réseau ou l'équilibrage de charge des composants.

Architecture de type "Shared-Nothing"

Le service de cluster utilise un modèle de mise en cluster de type "shared-nothing" (rien partagé). Ce modèle n'autorise pas les membres du cluster à accéder aux ressources des autres membres du cluster, comme le ferait un modèle de type "shared-everything" (tout partagé). Il évite également la surcharge et les limites d'évolutivité inhérentes qui seraient imposées par un modèle de type "shared-everything". En termes de partages de fichiers et d'imprimantes, cela signifie qu'un partage de fichiers n'appartient qu'à un seul nœud. Pour fractionner la charge d'un partage de fichiers sur plusieurs serveurs, les partages de fichiers eux-mêmes doivent être fractionnés en plusieurs serveurs virtuels.

Ressources

Une ressource offre un service à un client, comme par exemple un partage de fichiers, une adresse IP (Internet Protocol) ou un nom réseau. Les ressources sont la plus petite unité de gestion du service de cluster. Les ressources peuvent dépendre d'autres ressources et sont organisées en groupes.

Dépendances

Une dépendance est une relation entre ressources, semblable aux dépendances de service. Les dépendances définissent également l'ordre selon lequel les ressources sont mises en ligne et hors ligne, et sont généralement représentées sous forme d'arborescences de dépendances. La figure 1 illustre une arborescence de dépendances standard pour une ressource de partage de fichiers. Dans cette illustration, si un administrateur tente de mettre le disque hors ligne, le partage de fichiers est d'abord mis hors ligne, puis c'est au tour du disque d'être mis hors ligne. Le nom réseau n'est pas mis hors ligne, car il n'existe pas de dépendance directe avec le disque. À l'inverse, si nous tentons ensuite de mettre le partage de fichiers en ligne alors que l'état initial de toutes les ressources est hors ligne, le disque et l'adresse IP sont mis en ligne, puis le nom réseau et enfin le partage de fichiers. Remarquez qu'il n'existe pas de dépendance explicite entre le partage de fichiers et l'adresse IP. Cela est dû au fait que les dépendances sont dites "transitives". Ce terme n'est pas techniquement correct, mais il présente l'avantage d'offrir une bonne description du comportement empirique d'une dépendance.

Arborescence de dépendances standard d'un partage de fichiers

Figure 1 Arborescence de dépendances standard d'un partage de fichiers

Étant donné les informations ci-dessus, il peut sembler qu'une dépendance soit une relation strictement unidirectionnelle. Cela n'est pourtant pas le cas, la meilleure illustration en est la ressource spouleur d'impression. Lors de l'ajout d'une imprimante à un serveur virtuel, il est indispensable d'exécuter l'Assistant à partir du nom réseau avec lequel le spouleur d'impression présente une dépendance. Les applications, les ressources de nom réseau et les services génériques présentent également le même type de comportement.

Groupes

Un groupe est une collection logique de ressources qui doivent toutes s'exécuter sur le même nœud pour fonctionner correctement. Si la banque d'informations et l'agent de transfert des messages de Microsoft Exchange Server devaient s'exécuter sur des serveurs différents, cela poserait à l'évidence certains problèmes. Ce point a également une conséquence très importante : le groupe est l'unité de basculement dans le cluster. Des groupes entiers de ressources se déplacent d'un nœud à l'autre, et non des ressources individuelles. Le moyen le plus simple de construire des groupes concerne le stockage. La plupart des applications et services nécessitent du stockage pour fonctionner, comme dans l'exemple de Exchange. Dans la mesure où les dépendances peuvent uniquement être créées dans le même groupe, chaque application ou ressource qui utilise un disque doit se trouver dans le même groupe que ce disque. Les groupes sont généralement organisés sous forme de serveurs virtuels, bien que plusieurs serveurs virtuels puissent exister dans un groupe.

Basculement et restauration automatique

Le basculement est le processus par lequel un groupe se déplace d'un serveur à un autre. Le basculement peut se produire pour plusieurs raisons :

l'administrateur a déplacé un groupe vers un nouveau serveur ;
une ressource du groupe a dépassé son seuil d'erreur ;
le groupe est configuré pour la restauration automatique et le propriétaire original du groupe est de nouveau en service.

La troisième raison contient la définition de la restauration automatique : le groupe est restauré sur un propriétaire favori, selon la configuration. Les propriétaires favoris sont configurés comme une propriété de groupe. La restauration automatique peut être configurée pour se produire soit immédiatement, soit dans un délai spécifié.

Serveur virtuel

Un serveur virtuel est une combinaison de deux ressources (par exemple, une adresse IP et un nom réseau) qui fonctionnent ensemble pour présenter un espace de noms à un client. La figure 2 illustre les ressources et l'arborescence de dépendances d'un serveur virtuel. Remarquez qu'il n'existe aucune raison pour qu'un groupe ne puisse pas contenir plusieurs serveurs virtuels, mais que cela signifie que tous les serveurs virtuels du groupe peuvent appartenir à un seul nœud à la fois. L'organisation de groupes en serveurs virtuels offre un niveau de granularité plus fin et une meilleure évolutivité, en particulier dans les scénarios dans lesquels des nœuds supplémentaires devront être ajoutés ultérieurement. La figure 3 illustre les espaces de noms qui seront présentés à un client par les nœuds du cluster.

Remarque Les serveurs virtuels sont basés sur NetBIOS et présentent donc certaines limitations.

Arborescence des dépendances d'un serveur virtuel

Figure 2 Arborescence des dépendances d'un serveur virtuel

Espaces de noms présentés aux clients par les nœuds de cluster

Figure 3 Espaces de noms présentés aux clients par les nœuds de cluster

Création d'un serveur virtuel

Il existe deux moyens de construire un serveur virtuel. Bien qu'un serveur virtuel puisse être créé manuellement, la méthode la plus simple consiste à utiliser l'Assistant Application en cluster (voir Annexe). Cet Assistant crée un serveur virtuel avec l'option permettant de configurer une application de serveur de cluster. La création manuelle d'un serveur virtuel nécessite qu'une adresse IP et un nom réseau soient configurés dans le groupe approprié.

Partages de fichiers

Introduction : les partages de fichiers dans le service de cluster Windows 2000

Bien que les partages de fichiers en cluster se comportent exactement comme des partages de fichiers classiques, leur création et leur administration sont quelque peu différentes, car ils s'exécutent sur plusieurs ordinateurs. Les partages de fichiers en cluster doivent être créés dans l'Administrateur de cluster à partir des Outils d'administration. Ils ne peuvent pas être créés sur un lecteur en cluster à partir de l'Explorateur Windows. Selon le type de partage, l'administration des autorisations est un peu plus complexe.

Il existe trois types de partages de fichiers dans le service de cluster : normal, sous-répertoires de partage et racine Microsoft DFS (Distributed File System). Le partage de fichiers normal fonctionne exactement comme un partage classique de blocs de messages serveur. Le partage de sous-répertoires de partage est un type particulier de ressource de cluster, qui peut être utilisé pour créer rapidement et efficacement un grand nombre de partages. Le partage de racine DFS fonctionne exactement comme une racine DFS autonome. L'adressage de chaque partage s'effectue tour à tour.

Création d'un partage de fichiers

La création d'un partage de fichiers est simplement une question de création d'une nouvelle ressource dans le groupe. Le partage de fichiers présente une particularité relative aux dépendances : sauf s'il s'agit d'un partage de type DFS, le partage de fichiers ne nécessite pas de dépendance avec une classe de stockage ou un nom réseau. Si les données doivent être stockées sur un disque partagé, le partage de fichiers doit présenter une arborescence de dépendances semblable à celle de la figure 1 ci-dessus, c'est-à-dire une dépendance d'un nom réseau et de la ressource de stockage où se trouvent les données. La raison en est que ces dépendances ne sont pas nécessaires pour la réplication. Il peut être utile de placer les données répliquées sur des disques locaux et de créer un partage de fichiers qui pointe sur une ressource locale. Dans ce cas particulier, DFS est supérieur et offre plusieurs réplicas sur différents serveurs, avec un jeu de fonctionnalités plus robuste.

Configuration des paramètres propres aux ressources

La figure 4 ci-dessous illustre la boîte de dialogue qui vous permet de configurer les paramètres du partage de fichiers.

Paramètres du partage de fichiers

Figure 4 Paramètres du partage de fichiers

Un partage de fichiers présente les paramètres suivants :

Nom du partage—Le nom du partage sur le réseau.
Chemin—Le chemin d'accès au partage.
Commentaire—Champ de commentaire pour l'exploration.
Nombre limite d'utilisateurs—Limite le nombre d'utilisateurs d'un partage.
Autorisations—Les autorisations de niveau partage sont administrées ici.
Avancés—Les différents types de partages de fichiers sont sélectionnés ici. Le partage par défaut est normal.

Propriétés avancées d'un partage de fichiers

Figure 5 Propriétés avancées d'un partage de fichiers

Un mot sur les autorisations

Deux types de sécurité peuvent être utilisés pour les partages de fichiers de Windows 2000. La sécurité de niveau partage est mise en œuvre par le service LanManServer, lequel est essentiellement un mécanisme d'authentification utilisé par un client pour prouver son identité à un serveur. Tant les partages d'imprimantes que les partages de fichiers sont étroitement liés au service LanManServer, mais le service de cluster offre simplement un mécanisme permettant d'enregistrer de façon dynamique les partages de fichiers et d'imprimantes et de détecter leur état. Cela conduit à une petite incohérence : le service LanManServer n'est pas concerné, de sorte que lorsqu'un nœud de cluster possède un ensemble de ressources, il publie toutes ces ressources sur tous les noms réseau qu'il possède actuellement. Cela signifie que les noms de partage doivent être uniques sur l'ensemble du cluster. Microsoft prévoit de résoudre ce problème dans une prochaine version de Windows.

La sécurité de niveau partage est mise en œuvre par le service LanManServer. Le descripteur de sécurité du partage est stocké dans le Registre sous HKEY_LOCAL_MACHINE\System\Current Control Set\Services\LanManServer\Shares\Security. La connexion en local contourne totalement la sécurité de niveau partage, car elle n'accède pas aux fichiers via le partage. Les autorisations de niveau partage sont administrées à partir de la boîte de dialogue des paramètres du partage de fichiers dans l'Administrateur de cluster.

La sécurité NTFS ou la sécurité du système de fichiers est beaucoup plus robuste, car elle est stockée dans une liste de contrôle d'accès sur le disque lui-même. La sécurité NTFS s'applique, qu'une connexion réseau soit utilisée ou non pour accéder aux données. La sécurité NTFS est administrée à partir de l'Explorateur Windows.

Remarque Le compte du service de cluster doit disposer au moins d'autorisations en lecture sur le répertoire pour créer le partage.

Dernier point important concernant les autorisations sur les partages en cluster : les autorisations ne doivent jamais ****** être affectées à des groupes locaux sur des serveurs membres. Ces autorisations n'auraient aucune signification lors du déplacement du disque en cluster vers un autre serveur. Les autorisations doivent toujours être attribuées à une ressource du domaine. Dans les domaines en mode mixte, cela signifie que des droits doivent être attribués à un groupe global, excepté lorsque les nœuds du cluster sont des contrôleurs de domaine. Si les serveurs sont des contrôleurs de domaine, l'accès aux groupes locaux du domaine offre un moyen plus centralisé d'administrer les autorisations, moyennant une charge supplémentaire sur le service Active Directory™, laquelle n'est pas insignifiante. En outre, pour que cette stratégie soit totalement efficace, tous les nœuds du cluster doivent être des contrôleurs de domaine.

Dans les domaines en mode natif de Windows 2000, la sécurité peut être traitée entièrement à partir de groupes universels, lesquels sont nettement plus robustes.

Dans la plupart des cas, la méthode recommandée pour appliquer la sécurité consiste à utiliser la sécurité de niveau NTFS et à laisser ouverte la sécurité de niveau partage. L'administration simultanée des deux types de sécurité constitue une perte de temps et peut impliquer des actions de résolution des problèmes. Windows 2000 utilise le type de sécurité le plus restrictif si les deux sont appliqués.

Partages de fichiers normaux

Le partage de fichiers par défaut lors de la création est le partage de fichiers normal. Il ne présente aucune propriété spéciale et est semblable à un partage sur un serveur classique, à ceci près qu'il est accessible par l'intermédiaire du nom réseau virtuel du groupe. Les partages de fichiers normaux ne présentent pas de dépendances obligatoires, mais s'ils se trouvent sur le stockage partagé, ils doivent au moins présenter des dépendances avec le stockage partagé, si possible en complément de dépendances avec le nom réseau et l'adresse IP.

Sécurité

Le partage de fichiers normal est le plus simple pour générer un modèle de sécurité, en raison de son absence de comportement spécial. Les autorisations de niveau partage sont administrées à partir de l'Administrateur de cluster. Les autorisations NTFS sont administrées à partir de l'Explorateur Windows.

Consolidation du serveur : scénario 1

Dans ce scénario, reskit.com dispose de trois serveurs qui vont être migrés vers le cluster. Les serveurs et leurs partages sont répertoriés dans le tableau 1 ci-dessous.

Tableau 1 Consolidation du serveur : scénario 1

Nom du serveur	Département	Partages
SEA-NA-FILE-01	Development	Code Specs
SEA-NA-FILE-02	Support	Proposals Contracts
SEA-NA-FILE-03	Management	Accounts Proposals Group

L'analyse des performances indique que les serveurs 01 et 02 connaissent un trafic élevé, mais que le serveur 03 présente un trafic relativement faible.

Un problème possible Le serveur "support" et le serveur "management" possèdent tous deux des partages "Proposals". Ces partages doivent être uniques sur le cluster (voir la section ci-dessus, "Un mot sur les autorisations"), de sorte qu'ils seront renommés "SupProposals" et "ManProposals".

Implémentation

Chaque serveur sera recréé sur le cluster en tant que serveur virtuel. Chaque serveur virtuel possède son propre groupe, de sorte que la charge peut être répartie sur plusieurs serveurs. Pour améliorer les performances, les groupes qui contiennent les serveurs à fort trafic (01 et 02) auront chacun une stratégie de basculement qui stipule qu'ils doivent appartenir à des nœuds différents. Le groupe qui contient le serveur 03 sera maintenu en l'état (par défaut) et sera déplacé en fonction des besoins. La restauration automatique sera configurée pour avoir lieu entre 23 heures et minuit.

Présentation de la procédure

Les données des partages de fichiers de SEA-NA-FILE-01 sont migrées vers le lecteur de ressource de classe de stockage X.
L'ancien serveur est renommé ou supprimé du réseau afin d'éviter les conflits de noms.
L'Assistant Application en cluster est utilisé pour construire le serveur virtuel SEA-NA-FILE-01 pour le groupe contenant le lecteur X.
Deux ressources de partage de fichiers sont ajoutées au groupe, correspondant aux partages de fichiers de l'ancien serveur. Dans la mesure où les données se trouvent sur un volume partagé, des dépendances sont sélectionnées pour le nom réseau et le disque.

Pour configurer une stratégie de restauration automatique pour le groupe SEA-NA-FILE-01 :
1. Dans l'Administrateur de cluster, cliquez avec le bouton droit sur le groupe, puis cliquez sur Propriétés.
2. Sous l'onglet Général, cliquez sur Modifier pour ajouter SEA-NA-CLN-01 comme propriétaire favori.
3. Déplacez SEA-NA-CLN-01 vers le côté droit.
4. Sélectionnez l'onglet Restauration automatique, puis cliquez sur Autoriser la restauration automatique.
5. Cliquez sur Restauration automatique, saisissez entre 23 heures et minuit, puis cliquez sur OK.

La figure 6 ci-dessous affiche la configuration du groupe SEA-NA-FILE-01. Les flèches indiquent les dépendances.

Configuration du groupe SEA-NA-FILE-01

Figure 6 Configuration du groupe SEA-NA-FILE-01

SEA-NA-FILE-02 est configuré presque de la même façon sur le lecteur Y, à l'exception des noms et des paramètres du partage de fichiers. La seule différence importante est que le groupe SEA-NA-FILE-02 est configuré avec SEA-NA-CLN-02 comme propriétaire favori.

SEA-NA-FILE-03 est configuré presque de la même façon sur le lecteur Z, à l'exception des noms et des paramètres du partage de fichiers. Aucune stratégie de restauration automatique n'est configurée pour ce groupe.

Implémentation de la sécurité

Reskit.com est un domaine en mode mixte ; ainsi, des groupes globaux sont créés dans chaque domaine dans lequel des utilisateurs peuvent accéder à la ressource. Des autorisations sont affectées à des groupes globaux en fonction des besoins.

Partages de sous-répertoires de partage

Un partage de sous-répertoires de partage fait exactement ceci : il partage des sous-répertoires. Il le fait de façon dynamique ; les nouveaux partages ajoutés au partage racine sont partagés peu de temps après. Considérez par exemple la structure de répertoires suivante :

Exemple de structure de répertoires

Figure 7 Exemple de structure de répertoires

La figure suivante illustre une ressource de partage de fichiers créée pour le répertoire Users. L'option Partager les sous-répertoires est sélectionnée dans la boîte de dialogue Propriétés avancées de partage de fichier.

Ressource de partage de fichiers

Figure 8 Ressource de partage de fichiers

Les partages suivants seront créés :

Users
Guy
John
Martin
Rick
Matt

Remarquez que le répertoire Mystuff n'est pas partagé. L'option Partager les sous-répertoires ne partage pas au-delà d'un niveau de profondeur.

Si un administrateur ajoute plus tard un nouvel utilisateur au répertoire users, comme par exemple T:\Users\Shon, le partage Shon sera ajouté peu de temps après. Si vous examinez de plus près la boîte de dialogue Propriétés avancées de partage de fichier, vous remarquerez la case à cocher Cacher les sous-répertoires partagés. Le fait d'activer cette case à cocher ajoute immédiatement un $ au nom de chaque sous-répertoire, ce qui a pour effet de cacher le partage. Cette option étant sélectionnée, les partages créés seraient :

Users
Guy$
John$

Le répertoire users ne serait pas caché, car le signe $ n'est ajouté qu'aux sous-partages. Pour cacher le répertoire users, ajoutez simplement un $ au nom de son partage dans la boîte de dialogue des paramètres de la ressource.

Sécurité

La sécurité pour ce type de partage est très restrictive. Les sous-répertoires créés par la ressource héritent des mêmes autorisations de niveau de partage que le parent. Sauf s'il s'agit du comportement souhaité, les autorisations de niveau partage doivent être conservées par défaut et la sécurité de niveau NTFS doit être utilisée. Le service de cluster doit disposer d'autorisations de lecture de niveau NTFS sur les sous-répertoires pour créer le partage.

Consolidation du serveur : scénario 2

Dans ce scénario, le cluster de reskit.com présente des performances nettement supérieures aux performances attendues. Il apparaît que l'un des serveurs peut facilement traiter les trois serveurs virtuels. Il est temps de remplacer le serveur qui traite les répertoires de base des utilisateurs par un plus gros serveur, et reskit.com décide donc de migrer également les partages utilisateur vers le cluster. SEA-NA-FILE-04 traite tous les partages utilisateur de noam.reskit.com.

Implémentation

SEA-NA-FILE-04 est migré vers le cluster en tant que serveur virtuel. Le lecteur T est choisi pour héberger le répertoire utilisateur. Tous les répertoires de base des utilisateurs sont copiés dans le sous-dossier users sur le lecteur T et un fichier de sous-répertoires de partage de fichiers est créé dans le groupe SEA-NA-FILE-04.

Présentation de la procédure

Sous le répertoire Users, les données utilisateur sont migrées vers le lecteur de ressource de classe de stockage T.
L'ancien serveur est renommé ou supprimé du réseau afin d'éviter les conflits de noms.
Un serveur virtuel, SEA-NA-FILE-04, est créé dans le même groupe de ressources que le lecteur T.
Une ressource de partage de fichiers est créée pour T:\Users avec le nom de partage Users$. L'option Partager les sous-répertoires est sélectionnée dans la boîte de dialogue Propriétés avancées de partage de fichier. Dans la mesure où les données se trouvent sur un volume partagé, des dépendances sont sélectionnées pour le nom réseau et le disque.
Les stratégies de restauration automatique existantes sont conservées telles quelles. Aucune stratégie de restauration automatique n'est configurée pour le groupe SEA-NA-FILE-04.

Mise en œuvre de la sécurité

Des autorisations de contrôle total NTFS sont attribuées à chacun des utilisateurs pour leurs répertoires de base respectifs. Des autorisations de lecture sont attribuées au service de cluster sur tous les dossiers, de sorte qu'il puisse créer le partage.

Partages DFS

L'option Racine DFS de la boîte de dialogue Propriétés avancées de partage de fichier crée des partages DFS en cluster. Il ne peut y avoir qu'une seule racine DFS par cluster. La racine DFS créée par le service de cluster n'est pas une racine DFS Active Directory. Le tableau suivant illustre les différences entre une racine DFS Active Directory et une racine DFS en cluster.

Tableau 2 Partages DFS

Attribut	DFS Active Directory	DFS en cluster
Disponibilité	Pour N contrôleurs de domaine	Pour N nœuds de cluster
Surcharge de réplication	Oui	Non
Redondance de données	Oui	Non
Plusieurs niveaux de liaisons	Oui	Non
Préférence de site	Oui	Non
Publie les informations dans Active Directory	Oui	Non
Peut disposer de cibles de niveau racine	Oui	Non

Une racine DFS basée sur un domaine et possédant des réplicas peut constituer un meilleur choix pour offrir une disponibilité élevée pour les données essentiellement lues. Si les données changent fréquemment, la réplication n'est généralement pas souhaitable et le DFS du service de cluster est préférable.

L'arborescence des dépendances de la figure 1 est nécessaire ****** dans une ressource DFS. Cela signifie que les données d'un partage DFS doivent se trouver sur un stockage en cluster.

Pour administrer le serveur DFS, utilisez le composant logiciel enfichable Administration DFS pour vous connecter au serveur virtuel dont dépend le partage. Pour plus d'informations sur DFS, reportez-vous à l'aide en ligne de Windows 2000.

Sécurité

Les racines DFS et les liaisons DFS peuvent être contrôlées par la sécurité NTFS ou par la sécurité de niveau partage. L'administration d'une arborescence DFS peut impliquer une certaine surcharge ; il est donc conseillé d'administrer les autorisations NTFS sur les serveurs sur lesquels se trouvent les données et de laisser ouvertes les autorisations de niveau partage.

Les liaisons DFS peuvent toutefois pointer sur des données de volumes FAT ; il peut donc être nécessaire d'utiliser des autorisations de niveau partage.

Scénario

Reskit.com possède plusieurs serveurs qui hébergent plusieurs partages qui ne peuvent actuellement pas être migrés vers le cluster. Cependant, les utilisateurs souhaitent pouvoir accéder à ces partages via un espace de noms unique.

Implémentation

L'hébergement de la racine DFS sur le cluster offre un niveau plus élevé de disponibilité qu'un simple serveur ; une liaison hébergée sur un simple serveur peut subir une défaillance, empêchant ainsi les utilisateurs qui dépendent de cet espace de noms d'accéder à leurs données. Une racine DFS est créée sous un serveur virtuel, SEA-NA-FILE-05. Les liaisons DFS dirigent les clients vers les serveurs appropriés.

Présentation de la procédure

L'Assistant Application en cluster s'exécute et le serveur virtuel SEA-NA-FILE-05 est créé.
Un répertoire destiné à l'hébergement du partage DFS est créé sur le stockage partagé dans le groupe SEA-NA-FILE-05.
Une ressource de partage de fichiers est créée avec une dépendance sur le nom réseau et la ressource de classe de stockage dans le groupe SEA-NA-FILE-05. L'option Racine DFS est sélectionnée dans la boîte de dialogue Propriétés avancées de partage de fichier.
À l'aide du composant logiciel enfichable Administration DFS, une connexion est établie avec le serveur virtuel SEA-NA-FILE-05 et des liaisons DFS sont ajoutées.