none
Failover Cluster 2012 R2 RRS feed

  • Вопрос

  • Имеем кластер из 2х узлов. 2 сетевых интерфейса(public, hearthbeat), witness диск. На активном узле кластера произошел сбой неизвестного происхождения сетевого интерфеса публичной сети. В результате кластер продолжил работу (кворум не потерян, hearthbeat работает) на сбойном узле. В итоге кластер работает, но ресурсы его из сети не доступны.

    Какие есть варианты для исключений такой ситуации в дальнейшем?

    4 февраля 2016 г. 8:43

Ответы

  • Обратите внимание на данную тему.

    Приведённые выше советы насчёт утраты силы рекомендаций исполььзования одних и тех же интерфейсов для кластерных нужд не совсем верно интерпретированы из документации. Разделять служебный, публичный и пульсовый трафик нужно. Только делать это нужно на уровне Converged Virtual Switch.

    9 февраля 2016 г. 7:34
    Отвечающий
  • Разделять служебный, публичный и пульсовый трафик нужно. Только делать это нужно на уровне Converged Virtual Switch.

    ...или на уровне VLAN, или еще как-то. Но я говорил про аппаратный уровень сетевых интерфейсов, а не вышележащие.

    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    9 февраля 2016 г. 7:46

Все ответы

  • Я не совсем понял вашу проблему. У вас отпал публичный интерфейс на интерфейсе одного узла, и ресурсы кластера оказались недоступны и на другом узле тоже? Или у вас от сети отпали сразу оба узла? Или ресурсы не мигрировали автоматически со сбойного узла на здоровый? Или что?

    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    5 февраля 2016 г. 7:53
  • Автор имеет ввиду, что отпадает внешний сетевой интерфейс и у него не произошел переезд на другую ноду кластера.  Потому как кластер считает что все в порядке, ведь он видит партнера по другой сети.

    8 февраля 2016 г. 9:46
  • А, сейчас дошло.

    Проблема в том, что фэйловер ресурсов действительно срабатывает только в случае сбоя узла кластера. При этом четкого определения понятия "сбой" я найти так и не сумел, и, видимо, недоступность сети через публичный сетевой интерфейс к таковым не относится (и это логично - см. ниже). Так что это by design.

    В данном случае есть очень простое решение. Начиная с Windows Server 2012 рекомендация использовать выделенный сетевой интерфейс для внутрикластерных коммуникайций утратила силу (линк). Так что следует просто отключить выделенный интерфейс для внутрикластерных коммуникаций и использовать один и тот же сетевой интерфейс и для внутрикластерных, и для клиентских связей. Если в качестве кворума используется кластерный диск, то следует заменить его на файловую шару на внешнем сревере. Если что-то случается с сетью в такой конфигурации кластера, heartbeats и доступ к кворуму пропадают, и узел автоматически становится сбойным.

    Однако следует понимать, что такого рода конфигурация является крайне опасной с точки зрения устойчивости работы. Даже самая короткая преходящая недоступность сети может обернуться принудительной остановкой кластерных ресурсов на соответствующем узле и их запуском в режиме холодного старта на альтернативном сервере. Для виртуальных машин и SQL Server это аналог аппаратного резета, что чревато проблемами в гостевых ОС, утратой данных в Сиквеле и т.п. Оно вам надо только из-за того, что вы случайно патч-корд к серверу зацепили локтем? Не проще настроить мониторинг доступности узлов кластера из сети и реагировать на уведомления?

    Ну, или еще один вариант. Регулярно запускайте на каждом узле скрипт, который будет мониторить сеть и при ее недоступности выполнять остановку хоста с помощью Stop-ClusterNode или миграцию ресурсов с помощью Move-ClisterXXX. Но это нетривиально и из разряда "из пушки по воробьям". На вашем месте я бы остановился на варианте с внешним мониторингом.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging


    9 февраля 2016 г. 5:31
  • Обратите внимание на данную тему.

    Приведённые выше советы насчёт утраты силы рекомендаций исполььзования одних и тех же интерфейсов для кластерных нужд не совсем верно интерпретированы из документации. Разделять служебный, публичный и пульсовый трафик нужно. Только делать это нужно на уровне Converged Virtual Switch.

    9 февраля 2016 г. 7:34
    Отвечающий
  • Разделять служебный, публичный и пульсовый трафик нужно. Только делать это нужно на уровне Converged Virtual Switch.

    ...или на уровне VLAN, или еще как-то. Но я говорил про аппаратный уровень сетевых интерфейсов, а не вышележащие.

    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    9 февраля 2016 г. 7:46