Сценарий:
Кластер с тремя узлами (без общего доступа) в Windows Server 2012. Два узла в основном центре обработки данных, оба с голосами (вес узла = 1) и файловый ресурс-свидетель. Третий узел находится в удаленном центре обработки данных и не имеет голосов (вес узла равен 0).
Проблема: один узел кластера (которому принадлежало имя кластера) отключился для автоматического обновления. Имя кластера не соответствует удаленному узлу центра обработки данных, и удаленный узел смог получить блокировку файла-свидетеля общего файлового ресурса. В этот момент наш VPN-туннель упал. Один узел, который был включен в основном центре обработки данных (и имел запущенные службы), заметил, что удаленный узел кластера не работает, и попытался перевести имя кластера в оперативный режим. Файл-свидетель файлового ресурса по-прежнему был заблокирован удаленным узлом, а один видимый работающий узел кластера в первичном центре обработки данных не смог перевести имя кластера в оперативный режим, и он отключил службу кластера на себе.
Предостережения: брандмауэр общего файлового ресурса с удаленного узла не является вариантом из-за других процессов, которые его используют.
Я рассматривал попытку удалить удаленный узел кластера из числа возможных владельцев имени кластера, но я не делал и не тестировал этого раньше, и я не хочу взорвать свой производственный кластер. Можно ли удалить узел кластера у возможных владельцев по имени кластера? Если нам приходится отказывать в обслуживании удаленного центра обработки данных, необходимо координировать ряд движущихся частей, поэтому мне не нужно «автоматическое» переключение обслуживания при отказе в удаленном центре обработки данных. Причина, по которой удаленный узел вообще находится в кластере, заключается в том, что группы доступности SQL Server управляют репликацией на удаленный узел.
Я также рассмотрел возможность удаления свидетеля файлового ресурса и предоставления удаленному узлу права голоса. Новый динамический кворум «должен» поддерживать кластер в оперативном режиме, если один узел выходит из строя из-за перезагрузки и сетевое подключение к удаленному центру обработки данных теряется.
Учитывая мой сценарий, какой вариант (или другие альтернативы) даст мне максимальную доступность.
На самом деле мне нравится давать голосование удаленному узлу, потому что это значительно упростит запланированное переключение на другой ресурс. Вы можете перенести базы данных и ресурсы в удаленный центр обработки данных, а затем постепенно отключать узлы в основном центре обработки данных, и вам не придется обезьянничать с голосованием, чтобы заставить его работать. Кроме того, вас не беспокоит высокая доступность файлового ресурса.
Так что я здесь с Брентом. Я никогда не был сторонником удаления узла в качестве избирателя, если вы не на 100% уверены, что вам это не важно. Единственное, к чему вы должны стремиться, - это сохранить группу кластеров WSFC там, где ваша первичная реплика, как мы надеемся, избежать разделения мозга.
Удаление узла кластера как возможного владельца из WSFC - плохая идея. Если вам нужно это сделать, удалите узел из кластера. Плохое, плохое моджо.
В Windows Server 2012 у вас также есть динамический кворум, поэтому, если все ваши сбои не были одновременными, вы можете в значительной степени перейти к последнему выжившему (конечно, с предупреждениями).
Также решу любые проблемы с сетью. Как вы понимаете, они будут убийцами в географически разрозненной ситуации.