[Remarque traducteur. L'article concerne Windows Server 2003 / 2003R2 / 2008 / 2008R2, mais la plupart des éléments ci-dessus s'appliquent aux versions ultérieures du système d'exploitation.]Bonjour à tous!
Warren est de retour ici, et ce billet de blog est une compilation des problèmes DFSR les plus courants que j'ai rencontrés au cours des dernières années. Le but de ce message est de répertorier les erreurs courantes dans la configuration DFSR qui provoquent ces problèmes et de vous empêcher de faire des erreurs similaires. Savoir ce qui
ne devrait
pas être fait
est tout aussi important que de savoir
quoi faire. Bon nombre des éléments décrits sont liés à d'autres sujets, de sorte que les liens correspondants sont fournis pour une étude approfondie du problème.
Taille du quota trop petite pour le dossier intermédiaire
Avez-vous vu beaucoup d'événements dans le magazine avec les codes 4202 et 4204? Dans ce cas, la taille du dossier intermédiaire n'est pas définie correctement. Une conséquence désagréable de la taille incorrectement définie du dossier intermédiaire est la réduction des performances de réplication, car au lieu de répliquer des fichiers, le service passera du temps à nettoyer le dossier intermédiaire.
Les serveurs DFSR configurés avec une taille de dossier intermédiaire suffisante sont plus efficaces pour au moins deux raisons:
- Il est beaucoup plus efficace de simplement placer le fichier dans un dossier intermédiaire, puis de l'envoyer à tous les partenaires de réplication hôte, que de créer le fichier, de le répliquer, puis de supprimer une copie pour chaque partenaire hôte.
- Si l'édition Enterprise du système d'exploitation est installée sur au moins un membre, les serveurs peuvent utiliser la technologie RDC inter-fichiers [env. traducteur: à partir de Windows Server 2012, cette technologie est également disponible dans l'édition Standard]
Une taille incorrectement configurée pour le dossier intermédiaire peut également provoquer des boucles de réplication. Cela se produit si le fichier répliqué a déjà été copié dans le dossier intermédiaire du serveur de réception, mais que le mécanisme de nettoyage du dossier intermédiaire supprime ce fichier avant de pouvoir le déplacer vers le dossier de destination. Le fichier supprimé sera à nouveau répliqué sur le serveur et sera à nouveau supprimé par ce serveur du dossier intermédiaire, ce qui empêchera le serveur de recevoir le fichier. Ce processus sera répété jusqu'à ce que le serveur accepte le fichier.
N'ignorez pas les événements de journal pour le dossier intermédiaire.
Consultez
cet article qui décrit comment utiliser la méthode pour déterminer la taille minimale d'un dossier intermédiaire.
Voir la section «Augmenter le quota provisoire»
ici .
Pour plus d'informations sur le RDC inter-fichiers, vous pouvez lire l'article "Informations sur la compression différentielle à distance", publié
ici .
Procédure de présélection incorrecte ou non testée
Une procédure de préconfiguration consiste à copier des données qui seront répliquées sur un nouveau serveur membre de réplication avant d'être ajoutées au dossier final de ce serveur, afin de réduire le temps requis pour terminer la réplication principale. La plupart des échecs de la procédure de préconfiguration que j'ai rencontrés étaient dus à trois raisons.
- Incohérence ACL à la source et à la destination.
- Après avoir copié vers un nouveau membre de réplication, des modifications ont été apportées aux fichiers.
- Aucun pré-test n'a été effectué pour vérifier que la procédure de préconfiguration utilisée fonctionnait comme prévu.
En bref, les fichiers doivent être copiés d'une certaine manière, et ils ne peuvent pas être modifiés après avoir été copiés dans le dossier intermédiaire, et l'ensemble du processus doit être prétesté par vous.
Cliquez
ici pour lire le blog de M. Pile sur la façon d'organiser correctement la procédure de préconfiguration pour vos serveurs DFSR.
Grande taille de file d'attente de copie au fil du temps
Outre le fait qu'une grande file d'attente de copie qui existe depuis longtemps signifie que vos données ne sont pas synchronisées, cela peut conduire à une résolution de conflit indésirable lorsqu'un fichier avec un ancien contenu gagne dans un script de résolution de conflit. Le scénario le plus courant dans lequel j'ai rencontré ce comportement est l'ajout massif de nouveaux dossiers de réplication. Au lieu de procéder à un déploiement par phases, certains administrateurs ont ajouté 20 nouveaux dossiers pour la réplication à partir de 20 branches différentes, surchargeant ainsi le serveur hôte. Déployez par étapes afin que la réplication principale se termine dans un délai raisonnable.
DFSR utilisé comme solution de sauvegarde
Croyez-le ou non, certains administrateurs déploient DFSR sans sauvegardes hors ligne des données répliquées. DFSR n'a pas été conçu comme une solution de sauvegarde. L'un des objectifs du développement DFSR est de faire partie d'une stratégie de sauvegarde d'entreprise, car DFSR vous permet de collecter vos données géographiquement distribuées sur un site centralisé pour une sauvegarde, une récupération et un archivage ultérieurs. Plusieurs membres de réplication offrent une protection contre les pannes de serveur, mais cela ne vous protège pas contre les suppressions accidentelles. Pour être entièrement protégé, vous devez sauvegarder vos données.
Réplication unidirectionnelle: son utilisation et les méthodes de réparation incorrectes
Dans le but d'empêcher les mises à jour indésirables d'apparaître sur des serveurs où les données ne changeront jamais (ou s'ils souhaitent empêcher leur modification), de nombreux clients ont configuré la réplication unidirectionnelle en supprimant les connexions sortantes pour les membres de réplication. La réplication unidirectionnelle n'est prise en charge dans aucune version de DFSR antérieure à Windows Server 2008 R2. Windows 2008 R2 prend en charge la réplication unidirectionnelle, ce qui vous permet de configurer des dossiers en lecture seule pour les dossiers répliqués.
L'utilisation de membres de réplication en lecture seule peut atteindre l'objectif de réplication unidirectionnelle, ce qui empêche les modifications indésirables des données en cours de réplication. Si vous souhaitez utiliser la réplication unidirectionnelle à l'aide de DFSR, utilisez Windows 2008 R2 et pour les membres qui ne doivent pas être modifiés, sélectionnez le mode lecture seule.
Cliquez
ici et
ici pour en savoir plus sur la réplication en lecture seule DFSR.
Un autre problème courant se produit lorsque l'administrateur découvre que la réplication unidirectionnelle n'est pas prise en charge et essaie de corriger la situation, mais le fait de la mauvaise manière. La simple activation de la réplication bidirectionnelle peut avoir des résultats indésirables.
Cliquez
ici pour savoir comment corriger la réplication unidirectionnelle.
Serveur de nœuds en tant que point de défaillance unique et serveurs de nœuds surchargés
J'ai vu de nombreux déploiements avec un serveur à nœud unique. Si ce serveur de noeud tombe en panne, l'ensemble du déploiement est menacé. Si vous utilisez Windows Server 2003 ou 2008, vous devez avoir au moins deux serveurs hôtes et si l'un d'eux se bloque, l'autre doit gérer la charge sur le temps de récupération du premier avec un impact minimal sur les utilisateurs finaux. À partir de Windows Server 2008 R2, DFSR peut être déployé sur un cluster de basculement Windows, offrant une haute disponibilité tout en réduisant de moitié les exigences de stockage.
Tôt ou tard, les administrateurs ont une situation où il y a trop de serveurs dans les branches qui sont configurés pour se répliquer avec un serveur à nœud unique. Cela peut entraîner des retards dans la réplication. Pour comprendre combien de serveurs Office Server un serveur à nœud unique peut servir, vous pouvez utiliser le suivi de la file d'attente de copie. Il n'y a pas de formule magique, car chaque environnement est unique et il existe de nombreuses dépendances.
Lisez la section «Configuration de la topologie»
ici pour en savoir plus sur le déploiement de serveurs hôtes.
Cliquez
ici pour savoir comment configurer DFSR sur un cluster de basculement Windows Server 2008.
Trop de dossiers à répliquer dans une seule base de données Jet
DFSR utilise une base de données Jet sur le volume. Par conséquent, le fait de placer tous les dossiers répliqués sur le même volume entraîne qu'ils se trouvent tous dans la même base de données Jet. Si un problème survient dans cette base de données qui doit être réparé ou restauré, la base de données affectera tous les dossiers répliqués sur ce disque.
[Remarque traducteur. ce n'est évidemment pas un disque, mais un volume.] Il serait plus correct d'utiliser autant de disques que possible et de répartir les dossiers répliqués entre eux, garantissant ainsi un temps de disponibilité des données maximal.
Déploiement basé sur les solutions iSCSI budgétaires
J'ai souvent vu des déploiements DFSR utilisant le matériel iSCSI le moins cher. Habituellement, si vous utilisez DFSR, vous le faites pour atteindre des objectifs critiques, tels que la redondance des données, la consolidation des sauvegardes, la livraison planifiée des applications et les mises à jour du système d'exploitation. Se rendre dépendant d'un équipement de mauvaise qualité qui ne bénéficie pas d'une assistance commerciale normale n'est pas une bonne idée. Si les données sont importantes pour votre entreprise, l'équipement sur lequel le système d'exploitation et le mécanisme de réplication fonctionnent sera important pour lui.
Le service DFSR n'installe pas les correctifs actuels
DFSR est activement pris en charge par Microsoft et est mis à jour au besoin. Mettez à jour DFSR s'il existe une nouvelle version pour celui-ci au moment de votre prochain cycle d'installation de mise à jour. Assurez-vous que vos serveurs sont mis à jour conformément aux articles de la base de connaissances répertoriés ci-dessous.
Correctifs DFSR pour Windows 2003 R2Correctifs DFSR pour Windows 2008 et Windows 2008 R2Veuillez noter qu'en plus de DFSR.EXE / DFSRS.EXE, les mises à jour répertoriées concernent également NTFS.SYS et d'autres fichiers. Pour que la réplication fonctionne correctement, vérifiez toujours que les derniers correctifs sont installés au moins pour DFSR et NTFS. Les autres corrections de la liste concernent principalement les problèmes d'interface utilisateur et vous devrez les installer au moins sur les systèmes sur lesquels des tâches de configuration DFSR sont effectuées.
Il est recommandé que les correctifs soient installés à l'avance sur le serveur DFSR, même si tout fonctionne correctement, car plus tard, cela vous aidera à éviter l'apparition de problèmes déjà connus.
Les pilotes de carte réseau ne sont pas pris en charge à jour
DFSR ne pourra fonctionner normalement que si le réseau que vous lui fournissez fonctionne également sans problème. Utiliser des pilotes il y a 5 ans n'est pas la solution la plus intelligente. J'avais de l'expérience dans la communication avec plusieurs clients pour lesquels les problèmes de réplication DFSR ont été résolus en mettant à jour un pilote NIC obsolète.
Surveillance DFSR manquante
Malgré le fait que DFSR est utilisé pour déplacer, en règle générale, des données critiques, de nombreux administrateurs n'ont aucune idée de ce que fait DFSR jusqu'à ce qu'ils rencontrent un problème. Ceux qui sont plus ingénieux créent leurs propres scripts pour surveiller les files d'attente de copie sur leurs serveurs, mais le plus souvent en dépendent. Le pack d'administration pour DFSR est sorti il y a presque un an (et d'autres versions sont apparues plus tôt). Installez-le et utilisez-le - et vous pourrez alors détecter les problèmes et y répondre avant qu'ils ne se transforment en cauchemar. Si vous ne parvenez pas à utiliser le pack d'administration Operations Management pour DFSR, écrivez au moins un script pour surveiller la file d'attente de copie quotidiennement afin de comprendre si les fichiers DFSR se répliquent ou non.
Cliquez
ici pour obtenir des informations sur le pack d'administration d'Operations Management pour DFSR.
Mis à jour le 19 janvier 2011:Apporter des modifications au stockage sur disque sans archiver les premières données
Si le serveur DFSR doit remplacer le disque dur ou en ajouter un nouveau pour augmenter l'espace de stockage, il est extrêmement important d'avoir une sauvegarde des données à jour en cas de problème. Tout peut mal tourner, le plus souvent, des événements de conflit se produisent en raison de modifications inattendues dans le dossier parent ou d'une suppression accidentelle du dossier parent, qui est répliqué sur tous les partenaires. Vous devez sauvegarder vos données avant d'apporter des modifications et les conserver jusqu'à la fin du projet.
Arrêt du service DFSR pour arrêter temporairement la réplication
Parfois, vous devez arrêter temporairement la réplication. La bonne façon de procéder consiste à désactiver la réplication pour le groupe souhaité à l'aide d'une planification. Le service DFSR doit être en cours d'exécution pour pouvoir lire les mises à jour dans le journal USN. N'arrêtez pas le service DFSR pendant une longue période (jours, semaines), car cela peut entraîner un débordement de journal (si de nombreux fichiers ont été modifiés, ajoutés ou supprimés pendant cette période). DFSR se rétablira des débordements de journaux, mais dans les déploiements importants, cela prendra du temps et la réplication ne fonctionnera pas ou sera très lente pendant la récupération des journaux. En outre, vous êtes susceptible d'observer des files d'attente de copie très volumineuses jusqu'à la fin de la récupération du journal.
J'espère que cette liste vous aidera. Bonne réplication!
Warren «large net» Williams
[Remarque traducteur. S'il y a de l'intérêt des lecteurs, j'essaierai plus tard de traduire les articles postés sur les liens indiqués dans le texte, ainsi que d'autres articles de l'auteur d'origine