Назад | Перейти на главную страницу

DFS-R (2008 и R2) 2-узловой серверный кластер, все операции записи в файлы заканчиваются конфликтом

Оба сервера в кластере из 2 серверов сообщают о событии 4412 20 000 раз в день. Если я сижу в папке конфликтAndDetected, я могу наблюдать, как файлы появляются и исчезают. Пользователи сообщают, что их файлы, сохраненные одноранговыми узлами в одном месте, перекрывают друг друга.

Конфигурация началась с одного сервера, затем была настроена DFS-R с помощью мастера 2008 R2, который настроил общий ресурс на втором сервере. DFSN была создана самостоятельно. У пользователей Windows есть диски, сопоставленные с использованием пространства имен на основе домена (\ domain.com \ share). Пользователи Mac напрямую указывают на новый общий ресурс сервера, созданный DFS-R. Пользователи ПК указывают на большую часть потерянных файлов, но от пользователей Mac было 2 сообщения о возврате файлов.

Я реализовал DFS-R раньше, и событие 4412 происходило только тогда, когда пользователи одновременно открывали файлы и вносили изменения или во время начальной репликации. Здесь два сервера синхронизированы (очереди пустые). Почему DFS-R обнаруживает, что файл был обновлен на нескольких серверах, и почему действительные файлы «конфликтAndDeleted» заменяются файлами, не относящимися к конфликтуAndDeleted?

Просто для пояснения, видите ли вы конфликты файлов, которые, как вы на 100% уверены, не изменяются сервером? Я предполагаю, исходя из 22 000 конфликтов в день.

Это происходит только для одной группы репликации и насколько велика целевая папка для этой группы? Если целевая папка не такая большая, вам может быть лучше просто воссоздать группу репликации.

Вот несколько вещей, которые я бы сделал, чтобы получить больше информации о том, что может происходить:

  • Запустите диагностический отчет DFSR для своей группы репликации и просмотрите раздел «информация» на каждом сервере репликации. Кто-нибудь из них говорит, что начальная репликация все еще происходит?
  • Запустите: «список участников dfsradmin / rgname: replicationgroupname / attr: memname, rfname, isprimary, objstate» и убедитесь, что все участники сообщают о нормальном режиме и что ни один член не является основным.

Взгляните на журнал отладки DFSR на одном из рядовых серверов (по умолчанию% windir% \ debug \ Dfsr00100.log), выполните поиск по слову «Ошибка» и посмотрите, не появится ли что-нибудь.