Вход|Регистрация

Fusion Sphere testing. Part 2

Пятница, 26 июня 2015, 20:38
Disclaimer: в данной статье приводится исключительно личное мнение автора данного блога. Оно может не совпадать с официальной позицией его работодателя и/или компаний-партнёров.
<----------------------------------------------->
Функции непрерывности и отказоустойчивости, реализованные во Fusion Compute.

1. vMotion.

Среда виртуализации позволяет мигрировать ВМ без остановки работы. Трафик данных памяти ВМ передаётся по сети через выделенный порт управления гипервизора (либо через дефолтный управляющий порт, если выделенный порт не сконфигурирован).

Условия миграции из официальной документации:

В целом, технология миграции находится на уровне vSphere 4.x. Нет распараллеливания потоков по нескольким аплинкам и аналогов Long Distance vMotion.

2. Storage vMotion

В среде виртуализации Fusion Compute все хранилища делятся на два типа:

  • virtualized -- позволяет работать с основными функциями дисковой подсистемы (снапшоты, горячая миграция, репликация и т.п.), но создаёт дополнительный оверхед;
  • non-virtualized -- обеспечивает высокую производительность без дополнительных задержек на уровне гипервизора и рекомендованы вендором для высоконагруженных систем.

Различия двух типов заложены где-то в файловой системе среды виртуализации и никак не зависят от типа подключения СХД и протоколов доступа к нему (FC SAN, iSCSI, NAS, local HDD).

“Горячий” перенос дисков ВМ между хранилищами возможен только для хранилищ типа “virtualized”. При этом, весьма неприятным моментом для нас стало то, что "родной" для платформы тип распределённого хранилища Fusion Storage, отдаёт разделы, которые в имевшемся у нас релизе не могли быть размечены как virtualized.

3. High Availability

Для каждого кластера среда виртуализации позволяет использовать один из двух механизмов высокой доступности:

  • VRM-dependent
  • VRM-independent

В первом случае сервис VRM отслеживает доступность хостов виртуализации по сети и, при необходимости, перезапускает ВМ, работавшие на отказавшем хосте. При выходе из строя самого VRM (или хоста с ним), роль арбитра берёт на себя пассивная нода VRM. Если вас сильно не повезло (например отказал Power Domain в блейд-шасси), обе упавшие ноды VRM уже не будут перезапущены.

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

Логика работы VRM-independent механизма высокой доступности в общих чертах схожа с реализацией VMware HA. Главное ограничение, заключается в том, что все датасторы в кластере (включая локальные!) должны быть подключены в режиме “virtualized”.

Настройка резервирования ресурсов кластера для ВМ с отказавшего хоста производится практически идентично с реализацией в VMware vSphere.

Помимо описанных выше механизмов повышения доступности виртуальных машин, среда виртуализации позволяет определять состояние BSOD и выполнять перезапуск ВМ на том же, либо другом хосте в зависимости от выбранных настроек.

4. Distributed Resource Scheduler

В решении FusionCompute реализован механизм ручной и автоматической балансировки нагрузки между хостами виртуализации, объединёнными в единый кластер. Балансировка обеспечивается выбором хоста при запуске ВМ и горячей миграцией ВМ между хостами при превышении порогового значения использования ресурсов процессора и памяти:

Существует три режима учёта дисбаланса ресурсов:

  • только учёт потребления процессорных ресурсов хоста,
  • только учёт потребления ресурсов памяти хоста,
  • одновременный учёт нагрузки на ресурсы процессора и памяти.

Интенсивность миграции и задержку реакции системы на "случайные" пики нагрузки можно регулировать в графическом интерфейсе от уровня Conservative до Radical с дискретностью один час. Такая маска допустимой балансировки может быть применена к каждому дню, к определённым дням недели, либо к конкретным числам каждого месяца.

Интегральное значение состояния кластера и его целевое значение доступно в графическом интерфейсе.

5. Maintenance Mode

Среда виртуализации имеет возможность перевести хост виртуализации в режим обслуживания. Логика работы данного механизма отличается от реализации VMware:

  • на первом шаге хост помечается как вошедший в режим обслуживания;
  • на втором шаге (опционально) с хоста виртуализации мигрируют все ВМ.

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

Комментариев нет