А, сейчас дошло.
Проблема в том, что фэйловер ресурсов действительно срабатывает только в случае сбоя узла кластера. При этом четкого определения понятия "сбой" я найти так и не сумел, и, видимо, недоступность сети через публичный
сетевой интерфейс к таковым не относится (и это логично - см. ниже). Так что это by design.
В данном случае есть очень простое решение.
Начиная с Windows Server 2012 рекомендация использовать выделенный сетевой интерфейс для внутрикластерных коммуникайций утратила силу (линк). Так что следует
просто отключить выделенный интерфейс для внутрикластерных коммуникаций и использовать один и тот же сетевой интерфейс и для внутрикластерных, и для клиентских связей. Если в качестве кворума используется кластерный диск, то следует
заменить его на файловую шару на внешнем сревере. Если что-то случается с сетью в такой конфигурации кластера, heartbeats и доступ к кворуму пропадают, и узел автоматически становится
сбойным.
Однако следует понимать, что такого рода конфигурация является крайне опасной с точки зрения устойчивости работы. Даже самая короткая преходящая недоступность сети может обернуться принудительной остановкой кластерных ресурсов на соответствующем
узле и их запуском в режиме холодного старта на альтернативном сервере. Для виртуальных машин и SQL Server это аналог аппаратного резета, что чревато проблемами в гостевых ОС, утратой данных в Сиквеле и т.п. Оно вам
надо только из-за того, что вы случайно патч-корд к серверу зацепили локтем? Не проще настроить мониторинг доступности узлов кластера из сети и реагировать на уведомления?
Ну, или еще один вариант. Регулярно запускайте на каждом узле скрипт, который будет мониторить сеть и при ее недоступности выполнять остановку хоста с помощью Stop-ClusterNode или миграцию ресурсов с помощью Move-ClisterXXX.
Но это нетривиально и из разряда "из пушки по воробьям". На вашем месте я бы остановился на варианте с внешним мониторингом.
Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging
