Назад | Перейти на главную страницу

Кластер Windows 2012 R2 - сбой сетевого адаптера

У меня есть кластер Windows (2012 R2) с 2 узлами с ролью общих служб. В случае, когда я выключаю / перезагружаю службы живых узлов на резервном узле, они запускаются автоматически, однако это не сработает, если я имитирую сбой сетевого адаптера, отключив интерфейс. Возможно ли переключение в случае отказа сети? Я не использую Windows Hyper-V, поэтому вариант с защищенной сетью работать не будет.

Спасибо

Самый простой способ - использовать сценарий PowerShell, который перенесет ваши роли на исправный узел в случае сбоя сети.

Обычно, если сетевой адаптер выходит из строя, событие регистрируется в системном журнале сервера Windows. Просто создайте задачу Windows, которая будет запускать сценарий PowerShell и связывать его с этим конкретным событием. Вы можете повторно проверить статус интерфейса из сценария и решить, перемещать роли или нет.

Уже данный ответ - это действительно метод «ручного» перемещения групп в вашем кластере.

Однако чтобы ответить на вопрос:

Возможно ли переключение в случае отказа сети?

Да, это возможно, но позвольте мне объяснить один аспект отказоустойчивой кластеризации.

Отказоустойчивый кластер имеет много «методов обнаружения неисправностей», и один из них реализуется так называемым IsAlive / LooksAlive метод, выполняемый RHS.exe (подсистемой хоста ресурсов) кластера.

Обычно (если значения по умолчанию не были изменены) RHS вызывает «LooksAlive» для каждого ресурса каждые 5 секунд. Это «небольшой» тест для определения того, что Ресурс «выглядит живым».

Если этот тест «LooksAlive» завершился неудачно: он [RHS] запустит тест «IsAlive» для ресурса. Это будет более «тщательный» тест, который в конечном итоге определяет, работает ли ресурс.

Он [RHS] также запускает "IsAlive" каждые 30 секунд, независимо от того, успешно или нет "LooksAlive".

Если «IsAlive» дает сбой, то он [кластер] отправит «Событие 1069» в журнал системных событий, указывая на сбой ресурса.

После сбоя отказоустойчивый кластер примет решение, что делать с отказавшим ресурсом. И это будет основано на нескольких факторах:

  • Каков порог перезапуска ресурса: он может или не может пытаться перезапустить ресурс, чтобы увидеть, переходит ли он в оперативный режим (без переключения)
  • Если он исчерпал порог перезапуска: он определит, должен ли сбой ресурса повлиять на «группу» (по умолчанию это так)
  • Если действительно порог исчерпан, и ресурс влияет на группу, он [кластер] примет решение об отказе (группа переместится на другой узел, если он доступен)

Я оставлю это там, есть много других функциональных областей, которые мы должны обсудить, чтобы полностью понять решения кластеров.

Итак, чтобы «протестировать» «автоматическое переключение на другой ресурс», нам нужно понять, что на самом деле делает этот тест «IsAlive / LooksAlive».

Нам нужно убедиться, что у нас есть хотя бы ресурс «IP-адрес» в группе приложений кластера, чтобы убедиться, что кластер проверяет это, чтобы зафиксировать сбой сети.

Если вы используете «Общие службы», ваша группа должна выглядеть так:

Application-Group
 - Generic Service
   |- Physical disk (only if your app needs it)
   |- Network Name
      |- IP address

"IsAlive / LooksAlive", который "улавливает" сбой сети, находится в "IP-адресе", определение можно увидеть Вот -> эта статья написана для Windows 2003, но в основном по-прежнему верна в том, что касается ее содержания, и даже цитируется в отличном статья об отказоустойчивой кластеризации написано членом группы отказоустойчивых кластеров Microsoft.

Из этого мы знаем, что IsAlive реализован так же, как LooksAlive в отношении ресурса «IP-адрес». Он в основном проверяет, привязан ли IP-адрес к соответствующему сетевому адаптеру в TCP / IP-стеке ОС. (что вы можете увидеть, запустив ipconfig)

Чтобы протестировать такое аварийное переключение, у вас есть несколько вариантов:

  • В диспетчере отказоустойчивого кластера щелкните правой кнопкой мыши ресурс IP-адреса в группе приложений и выберите «Имитировать сбой». Возможно, вам придется сделать это дважды, так как кластер попытается перезапустить ресурс перед принятием решения об отказе (как описано выше).
  • (как вы это сделали) отключите сетевой адаптер в ОС. Просто убедитесь, что IP-адрес («ресурса IP-адреса» фактической группы, содержащей вашу универсальную службу) на самом деле является сетевым адаптером, перед отключением. Вы можете проверить это, запустив ipconfig в командной строке. (кластер попытается перезагрузиться, но перезагрузка не удастся, поскольку сетевая карта отключена)
  • потяните за кабель физического сетевого адаптера. Просто убедитесь, что это действительно сетевая карта, к которой фактически привязан IP-адрес («ресурса IP-адреса» фактической группы, содержащей вашу универсальную службу), перед тем, как тянуть кабель. Вы можете проверить это, запустив ipconfig в командной строке. (кластер попытается перезагрузиться, но перезагрузка не удастся, так как кабель NIC натянут)

Когда у вас есть правильная группа приложений с правильными зависимостями и IP-адресом, вы успешно протестируете аварийное переключение.

Надеюсь, это объясняет вашу ситуацию.