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