vSMP Fault Tolerance

For a long time VMware Fault Tolerance was only supported on a single vCPU VM. Today we witnessed a change: During the BCO2874 session we got a first look on the prototype of the SMP enabled Fault Tolerance. Cool!

Что такое FT?

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

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

Everything is amazing, but nobody's happy.

Не успела VMware выпустить vSphere с технологией FT, сразу же появились недовольные. Почему всего для одного процессора? Непорядок! Срочно бежать и делать FT для SMP!

Ответ сотрудника VMware на форуме: "Для решения проблему синхронизации двух (однопроцессорных) ВМ потребовались сотни и тысячи рабочих часов самых опытных инженеров и ведущих разработчиков. Решение данной задачи для многопроцессорных машин потребует значительно большего количества времени и, возможно, даже иного подхода."

В тему этого всего (на английский языке):



"Как мир успел ему задолжать что-то, о существовании чего он сам узнал лишь 10 секунд назад?!"

FT & Split Brain

Dave Lawrence (VMware) рассказал как именно FT борется со Split Brain.

Что делает Fault Tolerance для предотвращения Split Brain ситуаций, когда первичная и теневая ВМ становятся изолированными?

Fault Tolerance (FT) использует файл на диске с номером поколения ВМ. При создании FT машины (включении FT) создается файл на разделяемом хранилище с именем generation.N, где N - счетчик. При подключении теневой машины к первичной, первичная сообщает теневой текущий номер поколения. Как только первичная или теневая машина обнаруживает сбой во второй половине, она пытается переименовать файл в generation.N+1. При успехе машина переключается в режим первичной (или остается первичной) и дает команду на построение теневой машины, чтобы остаться защищенной от сбоев. Если же переименование файла не удалось, значит его уже переименовала вторая машина в паре и эта машина выключается.

Таким образом дисковая система служит для предовращения переключения обеих машин в режим первичной и соотв. Split Brain ситуаций.

FT & Snapshots

В качестве ответа на вопрос на сегодняшнем вебинаре по FT & HA.

Fault Tolerance не совместим со снапшотами и соотв. их не поддерживает.

Required

Virtual Machines: Ensure that there is no user requirement to have
virtual machine snapshots since these are not supported for VMware
FT. Delete snapshots from existing virtual machines before protecting
with VMware FT.

http://www.vmware.com/files/pdf/vsphere-migration-prerequisites-checklist.pdf

Почему они несовместимы? Для FT обязательным требованием является thick диск, и даже не просто thick, а eagerzeroedthick, поскольку FT очень чувствительно относится к изменению метаданных. А снапшот виртуального диска представляет собой сам диск и растущий дельта файл, который как раз метаданные изменяет ровно так же, как и thin диск.

Поскольку прозвучал вопрос и про eagerzeroedthick - напомню разницу между ним и просто thick. Thick при создании полностью выделяет место в объеме самого диска, и при первом обращении к каждому блоку сначала его очищает. На практике это моментальное создание, а затем некоторое время низкая дисковая производительность (пока не будет обращений к большинству блоков). Eagerzeroedthick очищает весь диск при создании, поэтому создается такой диск довольно долго, но сразу же после создания выдает максимальные IOPS.

Microsoft и Fault Tolerance

Microsoft, по словам Zane Adam (Senior Director of Virtualization Product Management and Marketing), не видит востребованности в Fault Tolerance и соотв. можно не ждать этого в Hyper-V 2.0.

We don't see this [fault-tolerance software for Hyper-V] as an area of high demand right now, but we are watching this closely.

Собственно, выглядит это ровно так же, как и в ситуации с Live Migration - у всех ключевых игроков в обасти виртуализации x86 есть, кроме Microsoft, а сл-но "это просто реально нужно очень небольшому количеству конечных пользователей" (с) некий сотрудник Microsoft.
Что можно перевести на простой русский язык как: "Мы очень хотим, но никак не успеваем этого сделать в разумный срок". А потом, когда таки будет ответ от инженеров, что они смогут это релизовать, Microsoft радостно заявит о прорыве, новой супертехнологии, которую они выпустят через год-полтора, оставив за кадром, что это есть уже у всех несколько лет как.