Общие объемы кластера отключены при чрезмерном использовании
Я пытаюсь понять (и в идеале исправить) особенно раздражающее явление, которое я заметил в Failover Clustering и Cluster Shared Volume в сочетании с Hyper-V. Похоже, что при высокой нагрузке, когда серверное хранилище CSV отвечает на все запросы со значительной задержкой (>3 секунд) для всех подключенных узлов кластера, возникает условие "не отвечает", и происходит удержание процесса Resource Hosting Subsystem (RHS), удерживающего процесс. ресурс, таким образом также отключая соответствующий CSV на короткий период времени (до тех пор, пока процесс RHS не будет перезапущен).
Журнал содержит записи из RHS с событием 2051 "Физический диск [RES]: проверка работоспособности IsAlive завершилась неудачно!, ожидание ввода-вывода завершено со статусом 170". сопровождаемый рядом записей, указывающих, что CSV принудительно удален и повторно присоединен.
Поскольку CSV используются для размещения гостевого хранилища Hyper-V, Hyper-V впоследствии устанавливает метку "невозможно подключиться к хранилищу конфигурации виртуальной машины" на виртуальных машинах, хранящихся в уязвимом CSV, и впоследствии отключает их. Даже если это не было достаточно быстро для отключения каждого уязвимого гостя, запросы доступа к диску гостя будут возвращать ошибки на время простоя, делая гостей непригодными для использования до следующего перезапуска.
Теперь, поскольку это происходит только в пограничных условиях и не может быть легко воспроизведено, у меня не так много случаев, чтобы проверить возможные решения. После прочтения этого и того, что я разработал гипотезу, что некоторый запрос на операцию ввода-вывода CSV (возможно, но не обязательно резервирование - я понимаю, резервирования используются только для записей метаданных FS, которые не должны быть настолько распространенными) сбой из-за тайм-аута, который впоследствии ставит весь ресурс в состояние сбоя. Но это оставляет меня с некоторыми вопросами:
Действительно ли Hyper-V должен выключать виртуальные машины, для которых он не может получить доступ к хранилищу? Или ответ с ошибками на гостевые запросы на доступ к хранилищу? Разве это не может просто заморозить выполнение, пока хранилище не вернется?
Как я могу настроить проверки RHS, чтобы они не проваливались из-за простого состояния перегрузки внутреннего хранилища?