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

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

Спасибо

1
задан 25 October 2016 в 22:45
2 ответа

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

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

3
ответ дан 3 December 2019 в 18:32

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

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

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

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

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

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

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

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

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

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

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

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

Итак, чтобы «протестировать» «автоматическое аварийное переключение», нам нужно понять, что на самом деле делает этот тест «IsAlive / LooksAlive». 1234] Нам нужно убедиться, что у нас есть хотя бы ресурс «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-адресом, вы успешно протестируете аварийное переключение.

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

0
ответ дан 3 December 2019 в 18:32

Теги

Похожие вопросы