Суть в том, что мы делаем копию ВМ на другом хосте. Эта копия делается, фактически, с помощью процесса vMotion. Но если при миграции vMotion у нас исходная ВМ удаляется, и остается только перенесенная, то в случае настройки FT для ВМ остаются обе. Т.е.
- Шаг 1 - сделать копию работающей ВМ(де факто - содержимое оперативки) на другом хосте.
- Шаг 2 - непрерывно синхронизируются процессорные инструкции. Т.е. наша ВМ работает, на процессоре что то там делается - и эти инструкции по сети передаются на другой хост, на копию этой ВМ. Таким образом, она все все повторяет за оригинальной виртуалкой.
- Шаг 3 - в случае аппаратного сбоя сервера с оригиналом, в сеть выпускается копия(до того она, разумеется, к сети доступа не имеет). (можем, кстати, такой перенос инициировать ручками, по желанию - тогда ВМ просто меняются ролями)
И все.
Ограничения, условия и особенности:
- ВМ не защищена от программного сбоя. BSOD в оригинальной ВМ передатся и воспроизведется в копии.
- Никаких условий или модификации для гостевых ОС и ПО.
- Работает на стандратном x86 железе. Есть условие на процессоры в связке с гостевыми ОС:
см. статью в KB Processors and guest operating systems that support VMware Fault Tolerance .
- Нельзя использовать vSMP в виртуальной машине - в ВМ может быть только 1 vCPU
- ВМ не может иметь снапшотов
- Диски ВМ не могут быть «тонкими» или RDM-дисками в режиме "physical compatibility"
- Должны отсутствовать присоединенные устройства VMDirectPath
- Нельзя использовать Storage VMotion
- Нельзя добавлять ресурсы во время работы (hot add)
- Нет поддержки Nested Page Tables/Extended Page Tables (NPT/EPT)
- Нет поддержки NPIV
- Виртуальные машины не могут быть кластеризованы средствами MSCS\MFC
- Гостевая ОС не должна быть с паравиртуализованным ядром
Более полный список тут - VMware Fault Tolerance Requirements and Limitations.
Рекомендации по использованию VMware Fault Tolerance в VMare vSphere.
- После сбоя сервера возможно автоматическое возвращение в отказоустойчивое состояние -
- оригинальная ВМ умерла
- ведущей стала копия
- для нее создается копия на каком то другом из работающих хостов - притом с учетом пожеланий HA\DRS
- vLockstep Technology - так называется технология, позволяющая исполнять одну и ту же последовательность инструкций на двух хостах.
картинка из whitepaper
-
- VMware тесно сотрудничала с Intel и AMD для реализации vLokstep - технологии передачи по сети и воспроизведении процессорных инструкций, на которой основывается FT.
- Оба "узла FT кластера" можно представить в виде двух шестеренок на одной цепи - если какое то из них будет крутиться медленнее - второе тоже замедлится. Если резервной ВМ будет не хватать ресурсов для работы - оригинальная замедлится.
- Поддержка многопроцессорных ВМ будет в следующих релизах.
- FT требует процессоров определенных поколений в силу того, что это не чисто программное решение, а тесно завязанное на технологиях процессоров.
- Сейчас жестким является условие одинаковости версий ESX, на которых работает одна пара FT защищенных машин. Одной парой хостов могу быть ESX и ESXi, но их билд должен быть одинаков. Возможно, в следующих версиях это условие будет снято.
- Для FT защищенных машин поддерживается, но не для обеих из пары сразу. Storage VMotion не поддерживается. DRS не будет мигрировать ВМ, защищенную FT. Возможно, это будет реализовано позднее.
- FT может защитить ВМ с vCenter - если у нее один vCPU.
- Нет ограничений на количество хостов в кластере с FT. Но пара FT защищенных ВМ не может быть распределена между кластерами. Возможно, это будет реализовано в следующих версиях.
- Есть APIm с помощью которых можно скриптовать операции типа вкл\выкл FT через PowerShell.
- Выделение гигабитного канала под трафик FT не является жестким требованием, однако является рекомендуемым. Ограничение в 4 защищенных FT ВМ на хост не является жестким - но рекомендуемым.
- Текущая версия FT предполагается к использованию между хостами одного ЦОДа, без WAN соединений между ними. Однако, есть вероятность, что в будущих версиях это будет реализовано.
|
|
