Отказоустойчивая виртуализация на базе Ovirt 3.5

Добрый день.

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

Многие из нас знакомы с понятием High Availability в разрезе Microsoft Failover Cluster Services или VMWare HA - в Ovirt данный механизм так же существует.

Думаю, он понимаем достаточно легко, так же как и балансировка виртуальных машин, в зависимости от нагрузки (DRS в терминах VMWare и Dynamic Optimization в терминах Microsoft), существуют и Affinity Groups. Детально с реализацией механизмов можно ознакомиться в Admin Guide продукта, поэтому мы не будем детально обсуждать этот вопрос.

Отдельного упоминания заслуживают способы отработки отказа сервера-узла кластера виртуализации. Таких механизмов всего три:

• Fencing (переводится как фехтование). Данный термин используется в отношении физических узлов виртуализации с поддержкой удалённого управления;
• Soft fencing over SSH для сервиса агента VDSM;
• Sanlock Fencing (с использованием общего хранилища).

Кластеры Ovirt, которые мы создаем в системе управления, так же используют единое и разделяемое хранилище данных (NFS, iSCSI, FC и прочие), так же должны иметь выделенные сети для производственной нагрузки и управления, а вот дальше начинаются нюансы.

Host High Availability или Fencing

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

Ovirt 3.5.x поддерживает только ограниченный набор интерфейсов управления серверной платформой, которые могут быть использованы для реализации функционала:

• Power Management  и управление энергосбережением (аналог Power Optimization в SCVMM 2012);
• Динамического распределения нагрузки в кластере (DRS в терминах VMWare или PROTips и Dynamic Optimization в терминах Microsoft);
• Политики высокой доступности виртуальных машин (Microsoft High Available VMs или vSphere HA).

Поддерживаемые интерфейсы:

• apc - APC MasterSwitch network power switch. Not for use with APC 5.x power switch devices.
• apc_snmp - Use with APC 5.x power switch devices.
• bladecenter - IBM Bladecentre Remote Supervisor Adapter.
• cisco_ucs - Cisco Unified Computing System.
• drac5 - Dell Remote Access Controller for Dell computers.
• drac7 - Dell Remote Access Controller for Dell computers.
• eps - ePowerSwitch 8M+ network power switch.
• hpblade - HP BladeSystem.
• ilo, ilo2, ilo3, ilo4 - HP Integrated Lights-Out.
• ipmilan - Intelligent Platform Management Interface and Sun Integrated Lights Out Management devices.
• rsa - IBM Remote Supervisor Adaptor.
• rsb - Fujitsu-Siemens RSB management interface.
• wti - WTI Network PowerSwitch.

Это налагает определённые ограничения на выбор аппаратной платформы виртуализации.

 

 

 

oVirt использует механизм Fencing для поддержки узлов кластера в активном работающем состоянии. Узел кластера, который находится в статусе "Non Responsive" отличается от узла в статусе "Non Operational" тем, что узел со статусом Non Operational доступен для oVirt по сети управления, но к примеру имеет неверную конфигурацию логических сетей.

"Non Responsive" - это узел с которым oVirt не может коммуницировать. Если oVirt теряет коммуникацию с узлом, то он может быть перезагружен (fenced) с портала администратора, либо автоматически в зависимости от состояния параметров управления питанием. В этом случае все  виртуальные машины  на сбойном узле будут остановлены, а высокодоступные виртуальные машины запущены на другом узле кластера.

Если сбойный узел кластера не вернулся к статусу активный, после команды перезагрузки, то он остаётся в положении Non-Responsive до устранения проблемы.

Все операции управления питанием выполняются через проксирующий узел, в отличии от операций, которые выполняются напрямую oVirt. Требуется минимум 2 узла в кластере для поддержки функционала fencing и работающего Power Management.

Soft-Fencing Hosts
Иногда узел кластера переходит в статус "Non Responsive" в виду внезапной проблемы и агент VDSM не будет отвечать на запросы, хотя виртуальные машины, зависимые от VDSM, будут продолжать работать и быть доступными.

В этом случае, перезагрузка VDSM агента может решить проблему. В oVirt 3.3 появился дополнительный механизм, называемый Soft-Fencing. Идея в том, что сервер управления oVirt  будет пытаться перезагрузить  агент VDSM узла кластера, подключившись по SSH. Данную операцию будет выполнять внешний fencing-агент, если он сконфигурирован.

Эта операция так же требует наличие прокси-узла в датацентре.

Запуск процедуры Soft-Fencing происходит по тайм-ауту соединения между сервером управления и хостом виртуализации.

Работает это следующим образом:

• При первом сетевом сбое устанавливается статус "Connecting"
• oVirt предпринимает 3 попытки подключения к VDSM для получения статуса и ожидает ответ интервал времени, который определяется загрузкой узла. Формула следующая:
•  TimeoutToResetVdsInSeconds (the default is 60 seconds) + [DelayResetPerVmInSeconds (the default is 0.5 seconds)]*(the count of running vms on host) + [DelayResetForSpmInSeconds (the default is 20 seconds)] * 1 (if host runs as SPM) or 0 (if the host does not run as SPM).

ПРИМЕЧАНИЕ! The Storage Pool Manager  или  SPM - это роль, которая выдаётся oVirt конкретному узлу в Datacenter  для управления хранилищами. SPM контролирует доступ к хранилищам, координируя  метаданные для Storage Domains. Это включает операции: создания, удаления, манипулирования виртуальными дисками, снапшотами и шаблонами, выделением хранилищ SAN и отвечает за целостность данных.

• Для того, чтобы дать VDSM максимальное кол-во времени на ответ, oVirt выбирает самое длинное значение, полученное с помощью формулы, приведённой выше.
• Если узел не ответил за отведённое время вызывается процедура vdsm restart по SSH
• Если vdsm restart не привёл к установлению соединения между узлом и сервером управления oVirt , то узел переходит в состояние "Non Responsive".
• Далее, если сконфигурировано управления питанием управление будет передано внешнему fencing-агенту.

ПРИМЕЧАНИЕ! Soft-fencing over SSH может быть выполнено на узле, которые не имеет функционала Power Management. 

Sanlock Fencing

Данный механизм - Sanlock Daemon, включен в продукт с Ovirt 3.1 для получение хостами аренды области с данными на общем хранилище. Sanlock Fencing использует возможности shared storage (NFS, Glusterfs, FCP и т.д.) и эффективен в тех случаях, когда хост стал недоступен через обычные средства коммуникации: Power Management или сетевые интерфейсы. В этом случае узел-прокси пошлет команду на демон недоступного узла, а тот отправит узел кластера в перезагрузку.

Основной проблемой данного механизма является то, что при сбое аппаратного обеспечения, потере электропитания или kernel panics, недоступности общего хранилища, узел перестаёт обновлять свою аренду. Так как мы не имеет данных о состоянии узла,  мы предполагаем, что  узел может начать писать на СХД в любой момент.  Как следствие, мы не можем перезапустить узел используя sanlock, чтобы предотвратить запись в одни и те же области СХД, получив потерю данных. Нам потребуется в ручную перезагрузить узел.

Детально о Sanlock Fencing можно прочитать тут



В следующей статье мы затронем интеграцию с Microsoft Active Directory.

Предыдущие статьи цикла

Установка Ovirt 3.5 в доменной среде IPA на базе RELS 6.6