1 votes

DFS-R (2008 et R2) cluster de serveurs à 2 nœuds, tous les écrits de fichiers se terminent en conflit et supprimés

Les deux serveurs d'un cluster à 2 serveurs signalent l'événement 4412 20 000 fois par jour. Si je me trouve dans le dossier conflictAndDetected, je peux observer des fichiers apparaissant et disparaissant. Les utilisateurs signalent que leurs fichiers enregistrés par des pairs au même endroit s'écrasent mutuellement.

La configuration a commencé avec un seul serveur, puis DFS-R a été mis en place en utilisant l'assistant 2008 R2 qui a configuré le partage sur le deuxième serveur. DFSN a été configuré indépendamment. Les utilisateurs Windows ont des lecteurs cartographiés en utilisant un espace de noms basé sur le domaine (\domain.com\partage). Les utilisateurs Mac sont dirigés directement vers le nouveau partage du serveur créé par DFS-R. Ce sont les utilisateurs PC qui signalent la plupart des fichiers perdus, mais il y a eu 2 rapports de utilisateurs Mac sur des fichiers revenant à une version antérieure.

J'ai déjà implémenté DFS-R et l'événement 4412 ne se produisait que lorsque les utilisateurs ouvraient simultanément des fichiers et effectuaient des modifications, ou lors de la réplication initiale. Ici, les deux serveurs sont synchronisés (les arriérés sont vides). Pourquoi DFS-R détecte-t-il que le fichier a été mis à jour sur plusieurs serveurs et pourquoi les fichiers valides conflictAndDeleted sont-ils remplacés par des fichiers non conflictAndDeleted ?

0 votes

Et votre question serait...?

0 votes

Bon point, mais si vous ne pouvez pas voir que le fait d'avoir des fichiers écrasés par des pairs au même emplacement est un problème, je ne m'attends pas à ce que poser une question aide.

0 votes

Encore pas une question, mais au moins nous avons clairement identifié le problème. Alors, maintenant que nous l'avons fait, quelle est votre question spécifique concernant votre problème avec les conflits de réplication DFS?

0voto

Cheekysoft Points 16532

Juste pour clarification, voyez-vous des conflits pour des fichiers que vous êtes sûr à 100% ne sont pas modifiés par un serveur? Je suppose en fonction des 22 000 conflits par jour.

Est-ce que cela arrive uniquement pour un groupe de réplication, et quelle est la taille du dossier cible pour ce groupe? Si le dossier cible n'est pas si grand, vous feriez mieux de recréer le groupe de réplication.

Voici quelques choses que je ferais pour obtenir plus d'informations sur ce qui pourrait se passer :

  • Exécutez un rapport diagnostique DFSR pour votre groupe de réplication, et regardez la section "information" de chaque serveur de réplication. Est-ce que l'un d'entre eux indique que la réplication initiale est toujours en cours?
  • Exécutez : "dfsradmin membership list /rgname:nomdugroupedereplication /attr:memname,rfname,isprimary,objstate" et assurez-vous que tous les membres rapportent Normal et qu'aucun membre n'est primaire

Jetez un coup d'œil au journal de débogage DFSR sur l'un des serveurs membres (%windir%\debug\Dfsr00100.log par défaut), et recherchez le mot "Erreur" pour voir s'il y a quelque chose qui apparaît.

0 votes

Est-ce que l'un d'eux dit que la réplication initiale est toujours en cours? Non. Assurez-vous que tous les membres rapportent Normal et qu'aucun membre n'est primaire => ObjState = Normal IsPrimary = Non (deux fois). L'erreur semble normale pour un verrou => [Erreur: 170(0xaa) InitializeFileTransferAsyncState::ProcessIoCompletion servertransport.cpp:2235436 W La ressource demandée est en cours d'utilisation.] achèvement : 0 ptr : 06D96398 Je pense que MozyPro, un logiciel de sauvegarde, cause à DFS-R de penser que les fichiers ont été modifiés. Il faut toujours redémarrer le serveur pour s'en assurer mais laisser faire la sauvegarde d'abord.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X