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

Должно ли в этом сценарии произойти аварийное переключение HA?

Я запускаю vSphere 5 в кластере высокой доступности на двух хостах (vsphereA и vsphereB). У меня есть кластер высокой доступности, настроенный для мониторинга хоста и мониторинга пульса хранилища данных с отключенным контролем допуска (надеюсь, я правильно понимаю, что мониторинг пульса хранилища данных предотвращает непреднамеренное и нежелательное переключение на резерв HA из-за изоляции сети управления). Каждый хост имеет одно подключение к выделенной сети iSCSI и цели iSCSI (без MPIO). Все vmdk для всех виртуальных машин существуют в хранилище данных iSCSI. В качестве теста высокой доступности я отключил соединение iSCSI на vsphereB и был удивлен, увидев, что работающие виртуальные машины на vsphereB продолжали работать на vsphereB. Выключенные виртуальные машины отображались как недоступные (что я ожидал из-за того, что они не работали и соединение от vsphereB к цели iSCSI было прервано), но работающие виртуальные машины продолжали работать и продолжали «принадлежать» vsphereB . Я ожидал, что для этих виртуальных машин произойдет переключение HA, и ожидал, что они будут «принадлежать» vsphereA после аварийного переключения HA (чего не произошло). Я не понимаю, почему для этих виртуальных машин не произошло переключения HA. Я неправильно понимаю, в каких случаях должно происходить аварийное переключение HA?

Кажется, вы путаете vMotion и HA, которые представляют собой разные функции, выполняющие разные функции.

vMotion - это функция, которая позволяет переносить виртуальные машины с одного физического хоста на другой без простоев и минимальных (миллисекунд) перерывов в обслуживании. Сделано заранее, авансом обслуживания и требует, чтобы виртуальная машина и исходный и целевой хосты уже находились в работоспособном состоянии. HA - это функция, которая перезапускает неисправные виртуальные машины (или недоступные виртуальные машины, если настроена изоляция хоста) и действительно приводит к простою виртуальной машины, поскольку вся виртуальная машина выключается и перезапускается.

Важный вывод: vMotion - это не аварийное переключение HA. Отработка отказа HA - это отработка отказа HA.

vMotions запускаются следующими причинами:

  1. Пользователь инициирует vMotion
  2. DRS инициирует vMotion в ответ на условия нагрузки (пороговые значения, установленные настройкой агрессивности DRS), нарушения правил привязки или обновления узла, запускаемые через VUM

Отработка отказов HA вызывается следующими причинами:

  1. Хост в вашем кластере высокой доступности обнаружил, что другой хост в кластере вышел из строя и не отвечает на контрольные сигналы высокой доступности, используя настроенные сети управления или хранилища контрольных сигналов.
  2. Ответ на изоляцию настроен на завершение работы или отключение питания виртуальных машин, и хост больше не может разговаривать с большинством узлов кластера, вызывая отключение виртуальной машины и последующее обнаружение сбоя высокой доступности из оставшейся части кластера (если таковой имеется, одна из опасностей реакции изоляции)
  3. Кластер / виртуальная машина настроены для мониторинга виртуальных машин с помощью инструментов VMware, гипервизор не получал пульс в течение определенного времени, а дисковая или сетевая активность не наблюдалась в течение 120 секунд.

Итог: vMotions происходит из-за событий производительности, а отработка отказов HA происходит из-за событий доступности.

Что вы сделали, так это вытащили диск из-под работающей виртуальной машины. Стандартное поведение vSphere и большинства гипервизоров в этом случае - оставить виртуальную машину в покое и позволить ей решать свои собственные проблемы с диском. Для этого есть несколько веских причин:

  1. Некоторые операционные системы / дистрибутивы (например, pfSense) будут работать нормально, если базовый диск перестанет отвечать.
  2. Несколько десятков виртуальных машин запускаются одновременно, как правило, создают проблему "гремящего стада" - делать это в хранилище, которое уже вызывает сомнения, может оказаться не лучшей идеей.
  3. Как и свопинг, операционная система (и приложения) обычно лучше справляется с проблемами хранения, чем гипервизор.
  4. Иногда хранилище просто зависает - это наиболее подверженный сбоям компонент в большинстве виртуализированных сред. Лучше всего попытаться обнаружить это и предупредить об этом, и позволить администратору выяснить, что с ним делать, прежде чем вы начнете перебивать всю среду

С другой стороны, для многих рабочих нагрузок (на ум приходят базы данных) рекомендуется завершить работу, как только появится вероятность повреждения или потери транзакций. Однако в лучшем случае, поскольку вы не можете полностью заморозить базу данных без диска, вы, вероятно, все равно окажетесь в несогласованном состоянии.

В конечном итоге: есть несколько хороших вариантов использования для того, чтобы HA реагировала на ненадежное хранилище, но сегодня этого не происходит, и поведение, которое вы видите, совершенно нормальное.