none
DFSR перестала работать RRS feed

  • Вопрос

  • Доброго времени суток.

    Дано:

    Было 2 сервера,

    FS1 с расшаренной папкой FOLDER1

    FS2(read-only member) с нерасшаренной FOLDER1

    между которыми работала репликация папки FOLDER1 (200+ тысяч файлов, общим объемом 400+ гигабайт).

    В какой-то момент в офисе, где стоит FS1 пропало питание. Сервер FS1, судя по логам, корректно завершил работу.

    Я спокойно зашел на FS2, перевел его в read-write, расшарил FOLDER1 и пользователи спокойно продолжили работать. Одновременно с этим FS1 был переведен в (read-only), чтобы при его возвращении в работу, он сразу перешел в этот режим.

    После восстановления работы офиса FS1, на него не реплицируются файлы с FS2. В логах с FS2 debug\dfsrxxxxxx.log вижу ошибки вида:

    20190718 11:31:39.425 5208 SRTR   971 [WARN] SERVER_EstablishSession Failed to establish a replicated folder session. connId:{E49163CC-FF65-4F86-BEE2-819D4C8323ED} csId:{B6DC1F9D-C039-4423-8C23-062016C01637} Error:
    + [Error:9051(0x235b) UpstreamTransport::EstablishSession upstreamtransport.cpp:803 5208 C The content set is not ready]
    + [Error:9051(0x235b) OutConnection::TransportEstablishSession outconnection.cpp:510 5208 C The content set is not ready]
    + [Error:9051(0x235b) OutConnection::TransportEstablishSession outconnection.cpp:449 5208 C The content set is not ready]

    В событиях всё красиво:

    FS2:The DFS Replication service successfully established an inbound connection with partner FS1 for replication group FOLDER1. 

    FS1: The DFS Replication service successfully established an inbound connection with partner FS2 for replication group FOLDER1. 

    Размер Staging на обоих серверах устанавливался "с запасом" исходя из суммарного объема 10-ти самых больших файлов в FOLDER1,  ConflictAndDeleted так же, с запасом.

    Всё, что удалось найти в интернетах- это совет "удалить репликацию в консоли, остановить и отключить сервис и грохнуть в system volume information\DFSR", после чего заново настроить репликацию. Как я понимаю, это убьет и другие репликации с этого диска. Есть какие-то менее радикальные способы вернуть реплику к жизни ?


    • Изменено Alex_Zlobin 18 июля 2019 г. 12:15
    18 июля 2019 г. 11:07

Все ответы

  • 1. Перестартовать службу DFSR на обеих нодах

    2. Проверяйте правильно ли определен PrimaryMember

    DFSRADMIN membership list /rgname:fileserver /attr:MemName,RFName,IsPrimary

    3. Если на обоих нодах Primary=0, то надо задать

     DFSRADMIN membership set /RGName:fileserver /RFName:"Shared Folders" /MemName:FS2 /IsPrimary:TRUE

    4. Пнём репикацию чтобы не ждать

    DFSRDIAG Pollad /Member:fs01

    DFSRDIAG Pollad /Member:fs02

    https://wiki.it-kb.ru/microsoft-windows/windows-server-2012-r2/file-and-storage-services/dfsr-this-member-is-waiting-for-initial-replication-for-replicated-folder

    18 июля 2019 г. 11:33
  • 1.Делалось и не раз уже.

    2....4 Разве PrimaryMember нужен после первоначальной репликации? Во всех статьях по репликации встречалось что праймари нужен "for initial replication"

    • Изменено Alex_Zlobin 18 июля 2019 г. 12:07
    18 июля 2019 г. 12:04
  • А у вас есть события с Intial replication?

    Что сейчас с DFSR BACKLOG, он не уменьшается?

    18 июля 2019 г. 13:54
  • А у вас есть события с Intial replication?

    Что сейчас с DFSR BACKLOG, он не уменьшается?

    Новых событий нет, одно единственное на дату первичной репликации.

    Размер backlog смотрел вчера (первый), так, по-памяти- не изменился 

     /SendingMember:FS2 /ReceivingMember:FS1

    Member <fs1> Backlog File Count: 243784

    /SendingMember:FS1/ReceivingMember:FS2 

    Member <fs2> Backlog File Count: 241974

    Точно смогу завтра сказать, но исхожу из того, что не изменился.

    P.S. count у них должен так отличаться, если пользователи сейчас работают на fs2 ?
    18 июля 2019 г. 14:26
  • Вам надо смотреть тот backlog, где отправляющий FS2, а принимающий FS1. Не исключаю, что сейчас идёт валидация БД DFSR - поищите в логе соответствующие события.

    Если ничего не поменяется, то попробуйте сделать Primary.

    Если и это не поможет, то проще всего будет заново создать группу репликации, за 1,5 дня она уже успешно должна завершиться.

    P.S. Для сравнения у меня этот процесс занял 2,5 дня - общий объём данных более 3 ТБ, кол-во файлов более 2 млн, но предварительно ещё делал экспорт/импорт БД DFSR. Сейчас смотрю на Storage Replica, которая работает гораздо лучше и продуктивнее.

    18 июля 2019 г. 16:10
  • Назначил праймари, вроде, какой-то процесс пошел, размер backlog на обоих серверах уменьшается, буду наблюдать.

    Я правильно понимаю, что сейчас по-сути заново запустился процесс первичной репликации и по её окончании флаг Primary с FS2 будет снят? Или его надо будет снимать "руками"?

    В events на primary только:

     

    The DFS Replication service initialized the replicated folder at local path f:\хххххххх. This member is the designated primary member for this replicated folder.

    Как понять, что репликация данных завершена и можно пользователей возвращать на fs1, No "Backlog - member <fs1> is in sync with partner <fs2> " - вот на это можно ориентироваться ? Сейчас так для тестовой папки на тех же серверах.


    • Изменено Alex_Zlobin 19 июля 2019 г. 8:09
    19 июля 2019 г. 7:59
  • Primary снимать руками не надо, один раз задали и всё.

    Если backlog уменьшается, то это победа - процесс пошёл. Да, на это сообщение можете ориентироваться (бэклог должен быть равен 0, также можете тестовый файл положить и убедиться, что он успешно отреплицировался).

    19 июля 2019 г. 8:17
  • Primary снимать руками не надо, один раз задали и всё.

    Если backlog уменьшается, то это победа - процесс пошёл. Да, на это сообщение можете ориентироваться (бэклог должен быть равен 0, также можете тестовый файл положить и убедиться, что он успешно отреплицировался).

    Мне надо будет по окончании процесса репликации "рабочим" для пользователей сделать fs1, а fs2 (который я назначил праймари) перевести в read-only member. Не будет ли у меня потом каких-либо конфликтов, если оставить fs2 праймари ?
    19 июля 2019 г. 8:22
  • Вы когда переключать будете, то он там сам флаг должен сбросить.
    19 июля 2019 г. 8:23
  • Надеюсь, так всё и будет, ибо переключать надо будет ночью, а утром "всё уже должно работать" и разбираться, что пошло не так, времени не будет ((

    Спасибо вам за помощь, о результатах отпишусь.

    19 июля 2019 г. 8:27
  • Ну что же, данные успешно реплицировались с fs2 на fs1, после чего я переключил их режимы, read-write - read-only. Именно в таком порядке, сначала выдал разрешение писать (в результате оба стали r-w), потом запретил писать на том, кто должен остаться r-o.

    После переключения DFSR захотел сделать initial replication (зачем-то), и снова отказался работать с тем же симптомом, The content set is not ready c "передающего". Вылечил так же (назначил праймари принудительно).

    Сейчас все данные синхронны и новые изменения реплика отрабатывает сразу, но вопросы остались. Это же не нормальное поведение dfsr? Боюсь, если доведется опять переключать сервера, вылезет такая же байда и снова "ручками" придется лезть, что не есть хорошо.



    • Изменено Alex_Zlobin 22 июля 2019 г. 14:18
    22 июля 2019 г. 14:09
  • Алексей, с DFSR всегда были проблемы (можете на хабре посмотреть - там куча статей на эту тему), поэтому ждать особых чудес от устаревающей технологии не стоит. Ставьте WS16 Datacenter/WS19 Standard и переходите на Storage Replica. Тем более дальше развивать и поддерживать DFSR MS не будет (ИМХО) и подобных проблем меньше не станет.
    23 июля 2019 г. 6:36