Почему зависают RDSH в ферме удаленных рабочих столов?

Question

[Сергей]

Коллеги, ситуация завела меня в тупик. Имеется ферма терминалов на базе Win Srv 2012R2 с брокером подключений в режиме высокой доступности.
Ферма состоит из:
7 RDSH серверов,
2-х кластеризованных Hyper-V виртуалок с доменными службами,
2-х таких же виртуалок с брокерами подключений,
Роли MFC "Файловый сервер" из двух нод
Кластера MFC MS SQL из двух нод.

Перемещаемые профили и перенаправленные папки (а точнее пути к ним) добавлены в пространство имен DFS и расположены на кластерной роли "Файловый сервер" с диском SCSI. Почему сделал акцент на этом: проблема заключается в том, что примерно раз в день (реже 2) все 7 серверов RDSH просто наглухо зависают и перестают отвечать на какой-либо инпут. Если при этом пользователь логинится/завершает сеанс, он видит в расширенном виде сообщение "Работает служба профилей пользователей". Это может длиться достаточно долго, пока не пройдет тупняк. У тех же, кто имеет активную сессию падают приложения, которые прямо или косвенно обращаются к файлам пользователя по сети, например проводник или мессенджер, который сохраняет полученные файлы в сетевую перенаправленную папку Загрузки.

В журналах при этом нет ошибок кроме упомянутых выше упавших приложений, а так же что та или иная служба не ответила за отведенное время. Можно было бы однозначно грешить на вышеупомянутую роль кластера, но при попытке открыть её с другого хоста в сети - все открывается и копируется/удаляется. Да и бывает, что на серверы RDSH при таких тупняках не удается зайти по mstsc /admin.

Собственно, взываю к людям с богатым опытом развертывания подобных ферм. В журналах чисто, все службы работают, но на протяжении недели вижу одну и ту же картину примерно в одно и тоже время (ночь, в диапазоне то 1 до 3 часов, никаких бекапов в это время нет). Может как-то не корректно развернута роль файлового сервера в кластере? Может вообще нельзя её использовать для хранения перемещаемых профилей и Folder Redirection? У меня тупо не осталось вариантов, хотел бы погуглить, да не знаю что. Сегодня вот в момент такого затыка перенес роль кластера файлового сервера на другую ноду кластера. И это было подозрительно долго (примерно секунд 30). Может потому что дело в ней, а может потому что при этом был этот тупняк и я пытался зайти на серверы RDSH 7-мью тестовыми аккаунтами одновременно. После переноса роли вроде как все прожевало. Но такое решение проблемы не устраивает при пустых журналах на нодах кластера. Подскажите, в какие журналы подсмотреть? В каком месте подебажить?

Comments

[Сергей]

После ручного переноса кластерной роли "Файловый сервер" на другую ноду, проблема уже второй день не наблюдается. Но это как-то не веет стабильностью

[Sasha Odarchuk]

Сергей, так вы перенесли роль на другую ноду и дефрагментация перестала "ложить" хосты ??

[Сергей]

Sasha Odarchuk, ответ написан ниже. Перенос роли помогал только в момент проявления проблемы. Но каждую ночь она снова повторялась.

Answer 1

[Сергей]

Для тех, кто подписан, и просто для истории. Причина найдена, а об устранении буду еще размышлять.

Регулярность проявления (каждый день между часом и 2-мя ночи) натолкнула на мысль, что происходит это по планировщику. Итак:

Get-ScheduledTask | Get-ScheduledTaskInfo | ? {$_.LastRunTime -gt ((Get-Date).AddHours(-2))}

вывело заинтересовавшую меня:

LastRunTime        : 16.10.2016 1:00:00
LastTaskResult     : 0
NextRunTime        : 17.10.2016 1:00:00
NumberOfMissedRuns : 0
TaskName           : Storage Tiers Optimization
TaskPath           : \Microsoft\Windows\Storage Tiers Management\
PSComputerName     :

В действиях которой значилось:
%systemdir%/system32/defrag.exe -c -h -g -#
Ни что иное как дефрагментация с высоким приоритетом. Принудительный запуск этой задачи продемонстрировал все вышеуказанные проблемы. Из-за медленной дисковой подсистемы на файловом сервере ПО пользователей и службы профилей пользователей просто крайне долго отрабатывали I/O операции и если их при этом еще многократно тыркали мышкой - вовсе зависали.

В свойствах задачи сказано, что изменять и удалять её не рекомендуется. Нашел по этой теме инфо на течнете, буду думать, что с этим делать. Для любознательных ссылка:
https://technet.microsoft.com/ru-ru/library/dn7891...