Привет, Хабр! Меня зовут Павел Князькин, я системный архитектор в команде платформы виртуализации zVirt в Orion soft. Отказоустойчивость — важнейшая характеристика системы виртуализации, поэтому мы регулярно проверяем ее, имитируя различные кейсы отключения оборудования. Сегодня мы протестируем:

• Поведение системы и ВМ при разрыве соединения между сервером и менеджером управления при различных настройках ВМ;

• Срабатывание функциональности HA при отсутствии коммуникации с хранилищем;

• Отказ одного из сетевых адаптеров сервера;

 — и все это на примере 7 различных настроек ВМ.

Немного теории

В zVirt предусмотрены механизмы обеспечения отказоустойчивости для хостов виртуализации, которые позволяют минимизировать простой ВМ в случае аппаратных сбоев. 

В zVirt можно объединять несколько физических серверов в кластер, что позволяет:

• Автоматически перезапускать ВМ на другом хосте при сбое текущего;

• Использовать live migration (живую миграцию ВМ) для балансировки нагрузки.

Как это работает: если один из хостов выходит из строя, ВМ автоматически запускаются на других узлах кластера.

Минимально для инсталляции достаточно одного хоста. Для организации отказоустойчивости необходимо наличие двух серверов, настроенного модуля управления питанием и общего хранилища. Отказоустойчивость обеспечивают правильно настроенные устройства управления питанием на всех хостах в среде. Процесс настройки управления питанием описан по ссылке, возможности по управлению питанием указаны в руководстве.

Но как именно будут вести себя ВМ в различных ситуациях отключения оборудования? Несколько таких кейсов я разберу в этой статье. 

Для проведения тестирования мы подготовили физические серверы — «srv1» и «srv2».

В данный момент хост «srv1» является «Хостом с золотой короной», на котором запущена ВМ «Hosted Engine». Хост «srv2», имеющий статус «Хоста с серебряной короной», может принять на себя запуск «Hosted Engine» в случае отказа основного хоста или при его плановой миграции. 

В качестве общего хранилища мы используем FC. 

Настройки ВМ

Для нашего тестирования мы создали группу виртуальных машин. 

Устанавливаем для ВМ №1 режим высокой доступности. Домен хранения подключен  по FC, и диск виртуальной машины расположен именно в этом домене хранения (FC_1TB_3). Целевой домен для хранения аренды ВМ — FC_1TB_3. Также в свойствах ВМ на вкладке «Хост» — для запуска выбран только «srv1».

В параметрах ВМ №2 видно, что высокая доступность отключена. То есть мы предполагаем, что эта ВМ не перезапустится на других серверах при выходе из строя основных.

ВМ №3 также запущена со включенным режимом высокой доступности, выбран корректный домен для хранения аренды ВМ (FC_1TB_3 — физическое расположение загрузочного диска данной ВМ). Однако в действиях указан параметр «принудительно завершить». Как она себя поведет, увидим в тесте.

Для ВМ №4 в свойствах высокой доступности ВМ, на вкладке «Целевой домен для хранения аренды ВМ» выбран другой домен хранения (hosted_storage), на котором не расположен диск этой ВМ (физическое расположение загрузочного диска ВМ — FC_1TB_3).

На виртуальной машине №5 активирован режим высокой доступности, но домен хранения вообще не выбран. В реальности такое может быть, если люди просто забыли это сделать. Мы же поставили такую настройку специально, чтобы проверить, как поведет себя ВМ в ходе краш-теста.

Для виртуальной машины №6 в свойствах высокой доступности ВМ, на вкладке «Целевой домен для хранения аренды ВМ» не выбран домен хранения, а в качестве действия выбрано «Оставить на паузе»

А для ВМ №7 в свойствах высокой доступности ВМ, на вкладке «Целевой домен для хранения аренды ВМ» не выбран домен хранения, а в качестве действия выбрано «Принудительно завершить».

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

Таким образом, мы подготовили 7 ВМ с различными настройками. Для удобства тестирования все ВМ запущены на «srv2», а «Hosted Engine» — на «srv1», чтобы было видно, как именно перезапускаются машины. 

Дальше мы будем принудительно выключать хост по питанию, отключать порты на коммутаторе, и посмотрим, что будет происходить в ВМ.

Краш-тест №1: обрыв связи между сервером «srv2» и «Hosted Engine»

Исходные данные: два хоста в кластере, каждый хост добавлен в менеджере управления с помощью модуля управления питанием хоста. Все ВМ (кроме «Hosted Engine») запущены на «srv2».  

Состав теста: разрыв связи между «srv2» и «Hosted Engine» со стороны коммутатора.

В этом тесте мы хотим увидеть, что случится, есть сервер управления не будет знать, что происходит с хостом по сети. Прервем связь между «srv2» и «Hosted Engine» на коммутаторе. При этом доступ с нашего рабочего места до «srv2» останется.

При обрыве связи между «Hosted Engine» и «srv2» менеджер управления пытается проверить состояние сервера, производит попытки подключиться к серверу. ВМ на хосте «srv2» тем временем продолжат работать. В интерфейсе «Hosted Engine» мы видим, что наши виртуальные машины перешли в статус «?» — то есть менеджеру неизвестно их состояние.

Если подключиться по SSH к «srv2» и выполнить команду virsh -r list, то мы увидим, что все ВМ продолжают работать на сервере. Мы также можем успешно подключиться к любой из этих ВМ по SSH.

Тем временем менеджер управления безуспешно пытается выяснить статус хоста по сети. Так как мы заранее настроили управление питанием для двух хостов, менеджер произведет опрос fence-агента и поймет, что хост находится в состоянии «UP» (по питанию). Через некоторое время менеджер управления попытается перезапустить хост, используя прокси-сервер и модуль управления питанием.

Важно отметить, что у хоста «srv2» имеется доступ к хранилищу (мы не прерывали этот доступ). ВМ, запущенные на этом хосте, продолжают обновлять свою «lease». 

Но что будет в итоге с ВМ после перезапуска хоста?

После попыток подключиться по сети к «srv2» менеджер управления принимает решение о перезапуске хоста по питанию и старте ВМ на хосте «srv1». 

Итог данного теста:

1. Все ВМ, кроме «a_vm_02», перезапускаются на «srv1». «a_vm_02» не запускается на хосте «srv1» т. к. у нее отключено свойство высокой доступности. При необходимости мы можем стартовать ВМ «a_vm_02» вручную;

2. ВМ «a_vm_01» также перезапустилась на хосте «srv1», несмотря на то что в свойства выбран хост для запуска — только «srv2». Свойство высокой доступности ВМ имеет приоритет перед выбором конкретного хоста для запуска. То есть ВМ со свойством высокой доступности важнее запуститься на любом хосте, чем не запуститься вовсе.

Краш-тест №2: отказ одного из сетевых адаптеров в сервере

Исходные данные: два хоста в кластере, каждый хост добавлен в менеджере управления, настроен модуль управления питания хостов. На каждом из хостов создан «bond0» из двух адаптеров (сеть «ovirtmgmt»).

Состав теста: На сетевом оборудовании производим выключение одного из портов, входящих в «bond0» — «srv1».  

Выключаем один из портов и запускаем команду «ping», чтобы посмотреть, какими будут потери (и будут ли они вообще).

Отключаем один из адаптеров в «bond0» на «srv1». Запускаем ping c «srv2» на «srv1». Команда ping -s 8000 -f 10.255.201.81.

Теория:

-s 8000 → Установить размер полезной нагрузки в 8000 байт

-f → Flood-пинг — Отправлять пакеты максимально быстро, создавая высокую нагрузку на сеть

10.255.201.81 → Целевой IP-адрес, к которому идет тест

Итог: мы потеряли 3 из 89399 пакетов (потери составили 0.00335574%). Если же не прерывать процесс нажатием Ctrl+C, а задать количество пакетов (например, 20К), то будет потерян только 1 пакет.

Краш-тест №3: разрываем связь между «srv2» и СХД

Исходные данные: два хоста в кластере, каждый хост добавлен в менеджере управления с помощью модуля управления питанием хоста, на каждом хосте настроен multipath. Все ВМ (кроме «Hosted Engine») запущены на «srv2».  

Состав теста: обрыв связи между «srv2» и СХД.

Выполним тест: на FC-коммутаторе отключим порт в сторону «srv2» . В выводе «multipath -ll» пути постепенно переходят в состояние «Failed».

Мы видим, что на хосте остались доступны пути только по iSCSI и локальный диск SSD. 

Что же происходит с нашими ВМ? Ведь для них были указаны разные свойства. Менеджер управления, в соответствии с настроенными свойствами для каждой ВМ, выполняет то, что было указано в настройках. 

Итог:

• «a_vm_01» — перезапустилась на «srv1». Несмотря на то что в свойства выбран хост для запуска — только «srv2». Свойство высокой доступности ВМ имеет приоритет перед выбором конкретного хоста для запуска. Т. е. ВМ со свойством высокой доступности важнее запуститься на любом хосте, чем не запуститься вовсе;

• «a_vm_02» — не запускается на хосте «srv1», так как у нее отключено свойство высокой доступности;

• «a_vm_03» — перезапустилась на «srv1»;

• «a_vm_04» — перезапустилась на «srv1»;

• «a_vm_05» — ВМ приостановлена из-за ошибки ввода-вывода хранилища. Если мы восстановим связь между хранилищем и «srv2», то ВМ самостоятельно, без ручного вмешательства, продолжит работу без перезапуска на другом хосте;

• «a_vm_06» — ВМ приостановлена из-за ошибки ввода-вывода хранилища. Если мы восстановим связь между хранилищем и «srv2», то ВМ останется на паузе и будет ожидать действия со стороны администратора; 

• «a_vm_07» — перезапустилась на «srv1».

После возвращения связи между «srv2» c СХД пути становятся «active/enabled». ВМ «a_vm_05» — продолжает работу в автоматическом режиме, «a_vm_06» — ожидает действия со стороны администратора.

В следующей статье мы проверим:

• поведение системы при отключении модуля управления питанием;

• поведение системы при размещении диска и его целевого домена для хранения аренды ВМ в разных доменах хранения.

А пока буду рад ответить на вопросы в комментариях, если они появились.