Дункан Эппинг написал интересную заметку о максимальных настройках виртуальных машин, защищенных средствами кластера непрерывной доступности VMware Fault Tolerance.

Некоторые из вас знают, что у Fault Tolerance есть ограничения как по числу одновременно защищенных виртуальных машин на хосте, так и по числу виртуальных процессоров (vCPU) на один хост ESXi. Напомним, что эти ограничения были улучшены в VMware vSphere 6.0, теперь можно с помощью FT защищать машины с четырьмя vCPU, а всего таких машин может быть до четырех штук. Но при этом заявлено, что для FT не может быть более 8 vCPU на хосте (то есть 4 машины по 4 vCPU в каждой поддерживать не получиться).

Но это, оказывается, только в дефолтной конфигурации. Для регулирования этих параметров есть две расширенные настройки (Advanced Settings) кластера HA/DRS:

• das.maxftvmsperhost - максимальное число защищенных ВМ на хост (4).
• das.maxFtVCpusPerHost - максимальное число защищенных vCPU на хост (8).

Они по умолчанию равны значениям, описанным выше, но вы можете выставить свои значения - и это будет работать. Тогда откуда они взялись? Очень просто - инженеры взяли типовые нагрузки, посадили их на адаптер 10G и получили, что хост потянет где-то 8 vCPU для Fault Tolerance (4 машины по 2 vCPU). Это условие выполняется при старте машин пользователем, миграциях vMotion, а также механизмом DRS при расчете рекомендаций.

Но у вас своя инфраструктура (может уже и адаптеры 40 Gbps), поэтому вы можете использовать какие захотите разумные значения. Кстати, если вы поставите значение 0, то кластер VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.

Но помните, что со стороны VMware превышение указанных значений не будет официально поддерживаемой конфигурацией.

Как вы знаете, в VMware vSphere 6.0 функции кластеров непрерывной доступности Fault Tolerance были существенно улучшены. Например, в издании Standard/Enterprise стало возможным использовать виртуальные машины с двумя виртуальными процессорами (2 vCPU), а для издания Enterprise Plus можно сделать FT-машину с четырьмя vCPU (но не более 8 vCPU на один хост).

Между тем, Fault Tolerance предъявляет довольно существенные требования к серверам, сетям и хранилищам для функционирования такого кластера. Они изложены в документе vSphere Availability Guide в секции "Fault Tolerance Requirements, Limits, and Licensing".

Немногие знают, что на сайте VMware есть удобная утилита-плагин к VMware vSphere C# Client под названием SiteSurvey, которая позволяет проверить хосты VMware ESXi на возможность создания на них FT-кластеров из виртуальных машин. Вот результат ее работы:

Как мы видим, галочками и крестиками отмечаются категории, в которых хост ESXi проходит или не проходит тест на совместимость с кластером Fault Tolerance. К сожалению, пока утилита доступна только для "толстого" клиента vSphere Client, но для следующего релиза vSphere, скорее всего, ее доработают и как плагин для Web Client.

Скачать SiteSurvey для Windows можно по этой ссылке. Помимо этого, вам будет полезно ознакомиться с KB 1013428 на тему основных вопросов по Fault Tolerance.

Как вы знаете, в последней версии платформы VMware vSphere 6.0 технология кластеров непрерывной доступности VMware Fault Tolerance была существенно улучшена (напомним, что добавили поддержку до 4 vCPU и до 64 ГБ памяти). Также в этом году мы писали о тестах производительности технологии FT, которые показали небольшие издержки на поддержание работы таких кластеров (их проводила сама VMware).

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

Так вот, посмотрим на результаты тестов, которые были сделаны с помощью бенчмарк-утилиты DVDstore. В качестве приложения для тестов использовался MS SQL Server (8GB памяти, адаптер VMXNET3 NIC и контроллер VMware paravirtual SCSI) а также машина с клиентом DVDstore. Между хостами ESXi, на которых были FT-машины, был организован 10-гигабитный линк.

В качестве команды для тестирования нагрузки на MS SQL Server была использована следующая:

ds2sqlserverdriver.exe –target=192.168.150 –run_time=15 –db_size=20GB –n_threads=25 –ramp_rate=5 –pct_newcustomers=10 –warmup_time=0 –think_time=0.085

Ну и, собственно, сами результаты:

Основной показатель теста OPM (Orders per Minute) - это оранжевые столбцы. Как видим, добавление новых vCPU не сильно повышает производительность системы, а вот включение Fault Tolerance прямо-таки обрушивает параметр OPM практически в 2 раза (на 47%, если быть точным). Результаты в таблице:

Ну и зеленые столбики показывают, как линейно росло использование полосы пропускания с ростом количества виртуальных процессоров (vCPU) для FT. При этом самое большое CPU Latency наблюдалось для одного vCPU.

В итоге, мы видим, что производительность при включении VMware Fault Tolerance вполне себе существенно падает, по крайней мере, при некоторых видах рабочих нагрузок. Поэтому тут главный совет - тестировать технологию в своей инфраструктуре перед тем, как планировать использовать ее в производственной среде.

Как вы знаете, вчера компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, но нас больше всего заинтересовала технология непрерывной доступности VMware Fault Tolerance.

Ранее никто не воспринимал технологию Fault Tolerance всерьез, поскольку она была доступна только для виртуальных машин с одним vCPU, а такие машины, как правило, не делаются для бизнес-критичных приложений, для которых, собственно, технология Fault Tolerance и создавалась.

Теперь VMware Fault Tolerance в VMware vSphere 6.0 полноценно доступна для виртуальных машин с четырьмя vCPU и 64 ГБ оперативной памяти. И все это поддерживается в производственной среде.

Какие преимущества дает VMware FT в vSphere 6.0:

• Непрерывная доступность и полное сохранение данных ВМ в случае отказа хоста ESXi.
• При отказе не разрывается TCP-соединение.
• Срабатывание Fault Tolerance полностью прозрачно для гостевой системы.
• При сбое хоста происходит переключение на новую первичную ВМ, при этом на другом хосте автоматически поднимается новая резервная ВМ.

Что нового в Fault Tolerance 6.0:

• Теперь технология непрерывной доступности VMware Fault Tolerance поддерживает виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
• Fast Check-Pointing - новая технология, предназначенная для поддержания исходного и резервного узла в синхронном состоянии, пришедшая на смену технологии "Record-Replay".
• Поддержка технологии горячей миграции как для Primary, так и для Secondary-узла.
• Возможность резервного копирования виртуальных машин, защищенных с помощью FT, технологией vStorage APIs for Data Protection. То есть, для таких ВМ теперь работет Veeam Backup and Replication.
• FT в vSphere 6.0 поддерживает новые типы дисков, такие как EZT, Thick или Thin Provisioned. Для vSphere 5.5 и более ранних поддерживаются только диски типа Eager Zeroed Thick.
• Возможность создания снапшотов виртуальных машин, защищенных FT.
• Новая версия FT поддерживает отдельные копии файлов ВМ (.vmx и .vmdk) для каждой машины, чтобы защитить машину не только от сбоев хоста, но и от сбоев хранилища, которые могут произойти одновременно со сбоем хоста. Файлы Primary и Secondary VM могут быть на разных виртуальных хранилищах.

Но по-прежнему, для Fault Tolerance остаются следующие ограничения:

• На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
• Обязательно потребуется адаптер 10 Gb. Его можно разделять между различными типами трафика средствами NetIOC.
• Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
• Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
• Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.

Как и раньше, технология VMware HA полностью поддерживается:

Для наглядности есть вот такая табличка, описывающая отличия от предыдущей версии FT:

Надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.

Ну и помните, что VMware Fault Tolerance на защитит от сбоя на уровне приложения - если он произойдет в основной ВМ, то будет и в резервной ВМ, поскольку машины синхронизированы на уровне исполнения инструкций в процессорах.

Мы уже писали о продукте VMware vSphere Storage Appliance, который позволяет организовать отказоустойчивую инфраструктуру хранилищ на базе локальных дисков хост-серверов VMware ESXi, которые реализуют общее хранилище за счет зеркалирования томов и экспорта хранилищ хостам по протоколу NFS. Узлы ESXi с использованием VSA могут образовывать двух- или трехузловой кластер:

В случае, например, использования двухузлового кластера VSA совместно с технологией VMware Fault Tolerance, может возникнуть такая ситуация - когда Primary VM находится на хосте ESXi и использует основную копию тома с его локальных дисков. В случае сбоя этого хоста возникает двойной отказ - и виртуальной машины, которая на нем исполняется, и ее хранилища, так как оно находилось на дисках хоста. В этом случае возникает неизбежный простой ВМ до того момента, как подхватится хранилище с другого хоста и Secondary VM сможет его использовать.

В такой ситуации VMware рекомендует поступать так:

А именно: размещать хранилище защищенной FT виртуальной машины (ее виртуальные диски и файлы) на хосте, отличном от того, на котором она исполняется, т.е. на том хосте ESXi, где исполняется Secondary VM. В этом случае при любом отказе двойного сбоя не будет - всегда выживет или исполняющаяся ВМ или ее хранилище, которое подхватится Secondary VM.

В случае трехузловой конфигурации VSA можно пойти дальше: разместить Primary VM на одном узле, Secondary VM на другом, а файлы этой ВМ на третьем узле кластера VSA.

На проходящих сейчас по всему миру мероприятиях VMware Partner Exchange On Tour (PEX) сотрудники VMware все больше рассказывают о возможностях новой версии платформы виртуализации серверов VMware vSphere 5.1. Во-первых, стало известно, что vSphere 5.1 будет анонсирована на предстоящем VMworld, который пройдет в Сан-Франциско с 27 по 30 августа этого года.

Во-вторых, во всяких твиттерах появилось описание некоторых новых возможностей VMware vSphere 5.1, которые мы увидим осенью этого года, а именно:

• Поддержка технологии кластеров непрерывной доступности Fault Tolerance для виртуальных машин с несколькими виртуальными процессорами (vCPU).
• Загрузка хостов через адаптеры Fiber Channel over Ethernet (FCoE).
• Поддержка виртуализованных контроллеров домена Active Directory. Windows Server 8, который исполняется в виртуальной машине, на самом деле в курсе, что он работает в ВМ. Это означает, что создание и удаление снапшота такой машины не приведет к проблемам с AD, возникающих с номером последовательного обновления (Update Sequence Number, USN) контроллера. Ранее при восстановлении из снапшота из-за проблем с USN могла остановиться репликация данных каталога. Теперь Microsoft добавила технологию Generation ID, которая позволяет виртуальному контроллеру домена знать, последняя ли версия каталога им используется. За счет этого решаются проблемы с репликацией при откате к снапшоту, а также появляется возможность клонирования виртуальных машин с контроллерами домена. Соответственно, такую возможность и будет поддерживать vSphere 5.1.

Что касается технологии Fault Tolerance для ВМ с несколькими vCPU, то, как пишут наши коллеги на vMind.ru, эта технология будет требовать соединения 10 GigE для работы механизма "SMP Protocol", который придет на смену технологии vLockstep. При этом работать она сможет вообще без общего хранилища для виртуальных машин, которые могут быть разнесены по разным датасторам и хостам:

Безусловно, это не все новые возможности, которые следует ожидать в VMware vSphere 5.1, поэтому мы будем держать вас в курсе новых подробностей по мере их поступления.

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

Поскольку у ВМ может быть только 1 vCPU, это делает неприменым технологию Fault Tolerance в большинстве случаев. Главная сложность задачи реализации нескольких виртуальных процессоров и их синхронизации - математическая.

Но, кажется VMware решила эту проблему, поскольку на VMworld 2011 будет сессия - "vSphere High Availability 5.0 and SMP Fault Tolerance - Technical Overview":

То есть нас ждет не только рассказ, но и живая демонстрация технологии в действии. Вот это уже будет полезно.

Но, как вы уже прочитали, в VMware vSphere 5 этой возможности еще не будет. Появится поддержка нескольких виртуальных процессоров для Fault Tolerance, скорее всего, в версии VMware vSphere 5.1.

Как вы знаете, в механизме высокой доступности VMware High Availability (HA) есть такая настройка как Isolation Responce, которая определяет, какое событие следует выполнить хосту VMware ESX / ESXi в случае наступления события изоляции для него в кластере (когда он не получает сигналов доступности - Heartbeats - от других хост-серверов).

• Leave powered on
• Power off
• Shutdown

Сделано это для того, чтобы вы могли выбрать наиболее вероятное событие в вашей инфраструктуре:

• Если наиболее вероятно что хост ESX отвалится от общей сети, но сохранит коммуникацию с системой хранения, то лучше выставить Power off или Shutdown, чтобы он мог погасить виртуальную машину, а остальные хосты перезапустили бы его машину с общего хранилища после очистки локов на томе VMFS или NFS (вот кстати, что происходит при отваливании хранища).
• Если вы думаете, что наиболее вероятно, что выйдет из строя сеть сигналов доступности (например, в ней нет избыточности), а сеть виртуальных машин будет функционировать правильно (там несколько адаптеров) - ставьте Leave powered on.

Но есть еще один момент. Как вам известно, VMware HA тесно интегрирована с технологией VMware Fault Tolerance (непрерывная доступность ВМ, даже в случае выхода физического сервера из строя). Суть интеграции такова - если хост с основной виртуальной машиной выходит из строя, то резервный хост выводит работающую резервную ВМ на себе "из тени" (она становится основной), а VMware HA презапускает копию этой машины на одном из оставшихся хостов, которая становится резервной.

Так вот настройка Isolation Responce не применяется к машинам, защищенным с помощью Fault Tolearance. То есть, если хост VMware ESX с такой машиной становится изолированным, при настройке Power off или Shutdown он такую машину не гасит, а всегда оставляет включенной.

Рекомендация - иметь network redundancy для сети heartbeats. Не должен хост себя чувствовать изолированным, если он весь не сломался.

Часто задаваемый вопрос: можно ли осуществлять резервное копирование виртуальных машин на ESX, работающих в кластере постоянной доступности VMware Fault Tolerance. Ответ прост - согласно ограничениям технологии FT, бэкап таких работающих виртуальных машин делать нельзя, поскольку для них нельзя сделать мгновенный снимок (снапшот).

А ведь, зачастую, пользователям нужна не только высокая доступность сервиса в виртуальной машине на случай аварии или других неприятностей, но и резервное копирование на случай утери критичных данных. Кстати говоря, VMware обещала сделать поддержку одного снапшота для FT-машин в целях резервного копирования, но так и не сделала этого в версии VMware vSphere 4.1. А делать бэкап надо - поэтому придется все делать самим.

Очевидных пути выхода из положения два:

1. Делать резервное копирование данных виртуальной машины средствами гостевой ОС (копирование на уровне файлов) либо средствами SAN (снапшоты).

2. На период бэкапа (например, средствами Veeam Backup) выключать защиту Fault Tolerance для виртуальной машины вручную или с помощью скрипта по расписанию. Этот способ подходит не всем, поскольку на время резервного копирования машина оказывается незащищенной.

О первом способе вы и так знаете, поэтому поговорим о втором:

Для автоматизации этого процесса с помощью интерфейса vSphere CLI добрые люди написали соответствующий скрипт, который можно использовать, например, на сервере резервного копирования Veeam Backup and Replication 5. Сначала нужно скачать и установить VMware vSphere CLI:

Затем минут за 10-15 до запуска задачи резервного копирования отключаем Fault Tolerance для машины командой (ее можно добавить в bat-файл и запускать планировщиком):

ftCLI2.pl --server vcenter.domain.local --passthroughauth --operation stop --vmname MyTestFTvm

Затем запускаем задачу резервного копирования Veeam Backup, в настройках которой есть замечательный параметр для выполнения скрипта после завершения задачи:

А вот в этом батнике мы уже снова включаем Fault Tolerance командой вроде этой:

ftCLI2.pl --server vcenter.domain.local --passthroughauth --operation create --vmname MyTestFTvm

Понятное дело, что данный способ является костылем, и скорее всего данная особенность будет исправлена в следующей версии vSphere, но пока приходится делать вот так.

Как вы знаете, в VMware vSphere 4.1 механизм VMware DRS, осуществляющий балансировку нагрузки на хост-серверы ESX, теперь интегрирован с технологией непрерывной доступности VMware Faut Tolerance.

То есть DRS автоматически распределяет по хост-серверам и FT-машины, однако тут есть небольшой нюанс. В соответствии с рекомендациями Fault Tolerance, число таких машин на хосте должно быть не больше 4-х в целях оптимального быстродействия. Если вы попробуете смигрировать пятую виртуальную машину с включенной технологией FT на хост, вы получите вот такое сообщение:

Host already has the recommended number of 4 Fault Tolerance VMs running on it

То есть DRS не смигрирует и не сделает Initial Placement для FT-машин на хосты VMware ESX, где уже работают 4 таких ВМ. Однако, есть возможность увеличить это количество. Для этого необходимо в расширенных настройках (Advanced Settings) кластера VMware HA/DRS добавить параметр:

das.maxftvmsperhost

со значением, например, 6. Если вы поставите значение 0, то VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.

Компания VMware выпустила отличный документ "The Design and Evaluation of a Practical System for Fault-Tolerant Virtual Machines", где описаны ключевые аспекты работы технологии непрерывной доступности виртуальных машин Fault Tolerance (FT).

В частности интересна формула, отражающая требования к пропускной способности FT-канала между серверами VMware ESX:

FT logging bandwidth = 1 Mbit/s + 1.2 * (average disk read throughput [Mbits/s] + average network receives [Mbits/s])

Также интересно описание работы FT-протокола, результаты экспериментального тестирования и анализ различных подходов к непрерывной доступности виртуальных машин, в том числе с раздельным хранилищем для виртуальных дисков основной и резервной ВМ (здесь, кстати, интересна конфигурация FT + StarWind - как средство отказоустойчивости на уровне хранилищ + серверов).

С процессорами семейства Intel Nehalem технология Hyperthreading снова вернулась в нашу жизнь, демонстрируя в некоторых тестах до 20%-30% прироста производительности по сравнению с тем, когда она отключена. Ранее в документации VMware vSphere для технологии непрерывной доступности виртуальных машин Fault Tolerance требовалось, чтобы Hyperthreading был disabled.

Теперь компания VMware прояснила пользователям, что это требование неактуально. Hyperthreading в состоянии enabled полностью поддерживается технологией Fault Tolerance. Цитата из VMware KB1013428:

Does Fault Tolerance support Intel Hyper-Threading Technology?
Yes, Fault Tolerance does support Intel Hyper-Technology on systems that have it enabled. Enabling or disabling Hyper-Threading has no impact on Fault Tolerance.

А знаете ли вы, что в VMware vSphere есть не только режим обслуживания (Maintenance Mode) для DRS, но и для High Availability (HA). Режим vSphere HA Maintenance Mode нужен для проведения регламентных работ в сети или устранения неполадок, чтобы механизм VMware HA не срабатывал почем зря и не вызывал действие, указанное в Isolation Responce (например, выключение виртуальных машин).

Для включения режима обслуживания VMware HA нужно просто снять переключатель "Enable Host Monitoring" в настройках кластера VMware HA:

Многие из вас уже, должно быть, начинают думать о начале проекта по виртуализации серверов на базе платформы VMware vSphere, которая стала вполне доступной для сектора SMB (издания VMware vSphere Essentials). Кроме того, пакеты VMware vSphere Acceleration Kits со скидками для приобретающих впервые - никто не отменял (скидки 20-30% при покупке лицензий на 3-4 сервера). Но сегодня не о ценах, а о том, как правильно спланировать виртуальную инфраструктуру VMware vSphere с учетом появившихся новых технологий и возможностей VMware.

Итак, если начать планировать по этапам, вот так выглядят составляющие инфраструктуры при проектировании решения VMware vSphere 4...
Таги: VMware, vSphere, ESX, Fault Tolerance, vNetwork, DRS, Backup, ESXi, VMFS, vCenter, PowerShell