Можно ли настроить аналог VMware Fault Tolerance на Xen?

Question

[TimurUfa]

Итак, суть - имеется 2 стоечных сервера и 1 АРМ. На сервере установлена виртуальная машина (Windows Server 2008 R2), на которую поступает информация от промышленного контроллера, необходимо собрать систему горячего резервирования, чтобы в случае аппаратного отказа сервера №1, сервер №2 получал управление виртуальной машиной без потерь оперативной памяти и клиентская часть на АРМ даже не замечала изменений (простой <= 5 секунд).
Были проработаны варианты использования технологии VMware Faulr Tolerance, но напоролись на необходимость общей шары для хранения файлов конфигурации ВМ, способы решения свелись к:
- аппаратная система хранения данных (СХД), очень кусачий ценник, т.к. дешевый вариант не купишь, именно СХД в данной ситуации является самой уязвимой частью системы;
- маленький сервер с ОС Windows Server и настройке общей шары NFS в качестве СХД. В итоге безопасность системы идет под хвост, да и негоже так делать.
- виртуальная СХД VMware Storage Appliance, вроде решает вопрос общей шары, но больше не продается.
В итоге, даже если вопрос с СХД решается ценник только пакетов VMware переваливает за $16к, что нецелесообразно.

На данный момент рассматривается резервирование с использованием технологии drbd-зеркала на системе управления виртуализацией Proxmox, ввиду ее бесплатности и наличия наработок. НО это гарантирует только High-Availability, т.е. защиту данных на жестких дисках, в итоге потеря времени приравнивается к времени загрузки ВМ, что непозволительно.

В моем прошлом вопросе меня натолкнули в направлении Xen, пока технология, похожая на Fault Tolerance найдена не была, может кто-то сталкивался и сможет направить в нужную сторону? Пока сам курю мануалы, но срок проекта уже подгорает и ищу помощи везде, где можно. Заранее благодарю.

Comments

[ldv]

wiki.xenproject.org/wiki/Remus

[TimurUfa]

ldv: Огромное спасибо!

Answer 1

[lovecraft]

Fault Tolerance, конечно, красивая штука и, если можно так сказать, - апофеоз виртуализации как технологии "отвязывания" ОС от железа. Но эффективность ее преувеличена. Например, у VMWare есть жесткие ограничения на Fault Tolerance - не более одного vCPU на VM (https://pubs.vmware.com/vsphere-50/index.jsp?topic..., что превращает Fault Tolerance просто в красивую игрушку. Все это происходит от необходимости постоянно синхронизировать состояние двух VM на хостах. Я не знаю, как это делает VMWare, а у Remus на этот счет есть большой документ: https://www.usenix.org/legacy/event/nsdi08/tech/fu...
Вкратце, там описана такая схема - состояние VM передается на резервный хост (делается чекпоинт), после этого весь I/O машины накапливается в специальном буфере до следующего чекпоинта. Когда происходит следующий чекпоинт, весь I/O из буфера "отпускается" наружу и цикл повторяется снова. Естественно, все это катастрофически снижает производительность.
Проблем добавляет и то, что гостевая ОС не в курсе, что с ней постоянно происходит suspend/restart и может выпасть в синий экран. По крайней мере, в KVM в свое время добавили специальный виртуальный таймер (hv_time/hv_relaxed), чтобы Windows не сегфолтилась на больших нагрузках. Отдельный разговор - паравиртуальные драйверы. До недавнего времени для оригинального XEN'a нормальных драйверов не было, а было недоразумение под названием GPLPV. Сейчас драйверы с поддержкой от команды XEN появились, но тестировались ли они совместно с Remus'ом - большой вопрос.
Если проанализировать угрозы для вашего проекта по степени уменшения их вероятности, то получится вот что:
1) Отказ из-за сбоя в софте мониторига
2) Синий экран из-за работы в виртуальном окружении или сбоя в паравиртуальных драйверах
3) Синий экран "просто так" - винда иногда тоже падает )))
4) Сбой оборудования
Из всего этого Remus может защитить только от п. 4

Таким образом, на мой взгляд, сам факт применения "сырого" XEN и "сырых" PV-драйверов создает для ОС намного более вероятную угрозу, чем та, которая может произойти при отказе оборудования. Допиленный же XEN от Citrix и Oracle не поддерживает Fault Tolerance, и думаю, на то есть причины )