Noms multiples pour un ordinateur – Consolidez vos serveurs de fichiers SMB sans casser les chemins UNC – Blog de Jose Barreto – Bien choisir son serveur d impression

Vue d'ensemble

Ce billet de blog couvre plusieurs manières différentes de consolider plusieurs serveurs de fichiers SMB et de continuer à exposer les partages de fichiers consolidés sous les anciens chemins de partage.

Scénario

Supposons que vous ayez actuellement 3 serveurs de fichiers nommés fichier1.contoso.local, fichier2.contoso.local et fichier3.contoso.local et que vous souhaitiez les consolider sur un seul ordinateur Windows Server appelé cfile.contoso.local. Il est assez simple d’utiliser un outil tel que ROBOCOPY ou l’outil de migration de serveur de fichiers (FSMT) pour copier vos partages et vos fichiers dans la nouvelle boîte.

Vous pouvez obtenir des informations supplémentaires sur FSMT sur la page Web du Kit de migration du serveur de fichiers Microsoft.. Vous pouvez également consulter mon article de blog: Microsoft File Server Migration Toolkit 1.2 disponible en téléchargement gratuit.

Le problème ici est que les utilisateurs et les applications ne pourront pas utiliser les anciens noms de serveur, tels que \ fichier1 ordres ordre1.doc. Après la consolidation, ce chemin doit être modifié pour utiliser le nouveau nom du serveur, comme \ cfile Orders Order1.doc. Toutefois, il existe des moyens d'éviter ce problème et d'afficher les partages sous les anciens noms, permettant ainsi aux anciens chemins UNC de continuer à fonctionner sans modification.

Option 1: entrées statiques dans le DNS

Si vous utilisez des entrées DNS statiques pour vos serveurs de fichiers, il suffit de mettre à jour simplement les entrées DNS des anciens serveurs de fichiers (une fois que vos anciens serveurs ont été supprimés), en indiquant l’adresse IP du nouveau serveur.Cela signifie que vous disposerez de plusieurs enregistrements DNS «A» (A correspond à l'adresse) et pointent tous vers la même adresse IP, qui pointe vers le nouveau serveur.

C'est une solution assez simple si vous utilisez des entrées DNS statiques. Vous pouvez utiliser la console MMC Gestion DNS pour modifier la zone ou utiliser l'outil de ligne de commande DNSCMD. Par exemple, en supposant que votre serveur DNS est à l'adresse dc1.contoso.local et que l'adresse IP de l'ordinateur cfile.contoso.local est 192.168.1.11, vous pouvez utiliser:

DNSCMD dc1.contoso.local / RecordAdd contoso.local Fichier1 A 192.168.1.11
DNSCMD dc1.contoso.local / RecordAdd contoso.local Fichier2 A 192.168.1.11
DNSCMD dc1.contoso.local / RecordAdd contoso.local File3 A 192.168.1.11

Vous trouverez plus d'informations à ce sujet sur la page TechNet relative à l'ajout d'un enregistrement de ressource hôte (A ou AAAA) à une zone.

Veuillez noter que cette option ne fonctionnera pas avec l'authentification Kerberos. Cette solution n'est donc pas recommandée.

Option 2: Noms d'ordinateur alternatifs et DNS dynamique

Si vous utilisez Windows Server, vous pouvez également ajouter d'autres noms d'ordinateurs à votre nouveau serveur (une fois vos anciens serveurs retirés). Cela peut être fait facilement en utilisant la commande NETDOM COMPUTERNAME.

Cette commande, qui fonctionne uniquement pour Windows Server, vous permet d’ajouter plus de noms à un ordinateur, en plus de ses noms principaux. Vous pouvez voir des détails sur l'utilisation de la commande sur la page TechNet à propos de Netdom Computername.

Par exemple, si le domaine de l'exemple de scénario est contoso.local et que le nom de domaine complet du serveur de fichiers était CFILE.contoso.local, vous pouvez ajouter les autres noms suivants:

NETDOM COMPUTERNAME cfile / ADD fichier1.contoso.local
NETDOM COMPUTERNAME cfile / ADD fichier2.contoso.local
NETDOM COMPUTERNAME cfile / ADD fichier2.contoso.local
IPCONFIG / registerdns

La dernière commande permet de s’assurer que les noms alternatifs sont correctement enregistrés sur votre serveur DNS, où les autres ordinateurs du domaine le trouveront. Pour vérifier tous les noms de l'ordinateur, principal et secondaire, vous pouvez utiliser la commande:

NETDOM COMPUTERNAME cfile / ENUM

Les informations sur les noms d’ordinateur alternatifs sont conservées dans le registre, comme indiqué sur la page TechNet sur les entrées de registre DNS.

Option 3: Racines de consolidation DFS

Bien que ces deux premières options permettent de conserver les anciens chemins UNC, elles modifient le comportement d'origine des 3 serveurs de fichiers. Auparavant, chacun des 3 avait un ensemble spécifique de partages de fichiers, mais le serveur de fichiers consolidé résultant et chacun des trois autres noms avaient un seul jeu qui fusionnait tous les partages d'origine.

Cela peut en fait être un effet secondaire que vous souhaitez ou que vous pouvez au moins tolérer, mais vous devez peut-être conserver le comportement original exact, chacun des noms d'origine indiquant un sous-ensemble précis des actions. Cela pourrait être particulièrement gênant s'il existait des partages différents du même nom sur les trois serveurs d'origine. Leur fusion peut entraîner des problèmes supplémentaires, voire des chemins de fichiers en conflit.

Vous pouvez résoudre ce problème en utilisant une fonctionnalité appelée DFS appelée racines de consolidation. Cette fonctionnalité de DFS-Namespaces vous permet de mapper chacun des nombreux noms de serveur vers des espaces de nom spécifiques. De cette façon, vous pouvez configurer exactement quels partages doivent apparaître sous chaque ancien nom. Dans notre cas, en plus d’avoir le point DNS fichier1, fichier2 et fichier3 à l’adresse de cfile, vous créez trois espaces de noms appelés \ cfile # fichier1, \ cfile # fichier2 et \ cfile # fichier3 et les peupler avec les bons liens vers l'emplacement de vos partages.

La FSMT comprend un assistant de racine de consolidation qui facilite la création de ces types spéciaux d’espaces de nom autonomes. Vous pouvez obtenir la boîte à outils à partir de la page de téléchargement de Microsoft File Server Migration Toolkit 1.2. Vous pouvez également apprendre à créer manuellement les racines de consolidation sur la page de support relative à la mise à jour du système de fichiers distribué afin de prendre en charge les racines de consolidation dans Windows Server 2003.

Option 4: machines virtuelles

Une autre méthode de plus en plus utilisée consiste à utiliser la virtualisation pour consolider vos serveurs de fichiers. Au lieu d'utiliser un nouveau serveur de fichiers, vous créez un nouveau serveur exécutant Hyper-V avec 3 ordinateurs virtuels exécutant chacun un serveur de fichiers. Dans ce cas, vous pouvez conserver les noms d'origine (et même les mêmes adresses IP) sans avoir à conserver l'ancien matériel. Bien que cela puisse entraîner plus de machines à gérer, cela simplifiera beaucoup votre migration.

Le Gestionnaire de machines virtuelles System Center inclut les outils permettant de migrer vos machines physiques vers des machines virtuelles (communément appelé P2V). Pour plus d'informations, voir la page TechNet sur P2V: Conversion d'ordinateurs physiques en machines virtuelles dans VMM. Vous pouvez également ajouter un clustering avec basculement pour rendre vos machines virtuelles hautement disponibles.

Option 5: Clusters de basculement

En parlant de haute disponibilité, vous avez une autre option en utilisant les clusters de basculement Windows Server. Les serveurs de fichiers consolidés peuvent généralement utiliser la disponibilité supplémentaire, puisque vous vous retrouvez avec «de nombreux œufs dans le même panier». Le processus a été grandement simplifié dans Windows Server 2008 et les versions suivantes, et vous pouvez trouver dans Technet un guide pas à pas de cluster de basculement: Configuration d'un cluster de basculement de serveur de fichiers à deux nœuds

Les serveurs de fichiers en cluster sont créés de manière à attribuer un nom et une adresse IP spécifiques à chaque service de fichiers ou groupe de clusters. Vous pouvez utiliser cette possibilité pour créer plusieurs noms, chacun avec un ensemble spécifique de partages, imitant potentiellement la configuration d'origine de vos anciens serveurs de fichiers.

À partir de Windows Server 2008, les partages de fichiers sont affectés à un nom spécifique. Vous obtenez donc naturellement les différents ensembles de partages associés à leur nom spécifique, même s'ils sont hébergés sur le même nœud de cluster. Ceci est expliqué en détail dans ce billet de blog à propos du partage du fichier 'Portée' dans les clusters de basculement Windows Server 2008.

Option 6: Actions Scoped

S'agissant des partages scoped, ils constituent un autre moyen de résoudre le problème de partage de partages en fonction du nom utilisé pour accéder au serveur de fichiers. Ceux-ci fonctionneraient sur un serveur de fichiers autonome (pas en cluster). Cependant, il n'existe aucun outil de ligne de commande ou d'interface graphique permettant de créer des partages étendus sur un serveur de fichiers autonome.

Si vous êtes développeur, vous voudrez peut-être essayer de créer vous-même ces partages étendus en appelant la fonction NetShareAdd. Dans ce cas, vous devez utiliser le niveau 503. Voir les remarques sur le lien pour plus d'informations, y compris sur la nécessité d'utiliser la fonction NetServerTransportAddEx.

Conclusion

J'espère que cet article vous a aidé à comprendre vos options pour consolider vos serveurs de fichiers et à conserver vos anciens chemins UNC dans le processus. Comme d'habitude, vous devez tester toutes les procédures dans un environnement de test avant de le déployer en production. Commençons maintenant avec la planification de ces projets de consolidation.