Как работает vMotion

Последовательность действий vMotion:

1. На целевом хосте создается теневая виртуальная машина.
2. Копируется каждая страница памяти из источника в целевую виртуальную машину через сеть vMotion. Эта операция называется preCopy.
3. Следующая итерация - это копирование страниц памяти, которые изменились во время выполнения  последней операции preCopy.
4. Итерации preCopy продолжаются до тех пор пока не будет измененных страниц памяти.
5. "Глушится" виртуальная машина на хосте-источнике и разблокируется на целевом хосте.

В большинстве случаев итерации копирования работают прекрасно, при условии если хост передает страницы памяти по сети vMotion быстрее, чем они успевают меняться виртуальной машиной.
Однако, иногда виртуальная машина изменяет страницы памяти быстрее, чем vMotion может передать их, и возможна ситуация, когда итерации preCopy не могут сойтись.
Если preCopy не сходится, vMotion должен решить потерпит миграция неудачу или будет завершена. Решение принимается на основе оценки времени необходимого для копирования оставшихся страниц памяти. По умолчанию, если это время не превышает 100 секунд, то миграция будет завершена. Если время превышает 100 секунд, vMotion завершится ошибкой без воздействия на виртуальную машину.
Если оценка укладывается в 100 секунд, vMotion "заглушит" источник и запустит целевую виртуальную машину. Когда виртуальная машина уже будет работать на целевом хосте, источник еще будет передавать оставшиеся страницы памяти, используя технологию "Quick Resume", которая появилась в vSphere 4.1.
В vSphere 5 подобная технология называется  "Stun During Page Send". Эта технология, "замедляя" vCPU на источнике, управляет скоростью изменения страниц памяти в зависимости от пропускной способности сети vMotion и позволяет завершить миграцию. Также Stun During Page Send делает возможным vMotion при задержках сети до 10 мс (Metro vMotion).
Подчеркнем несколько ключевых моментов:

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

Источники:
VMware Uptime Blog: vMotion - what's going on under the covers?
Yellow Bricks: vSphere 5.0 vMotion Enhancements
+Презентация VMware vMotion in VMware vSphere 5.0: Architecture, Performance and Best Practices

Растянутый HA\DRS кластер vSphere 5

Ранее тема растянутых кластеров vSphere затрагивалась в посте об обеспечении катастрофоустойчивости. С тех пор вышла vSphere 5 и появились новшества, связанные в том числе и с растянутыми кластерами:

• технология vSphere Metro Storage Cluster, которая призвана работать в растянутыми VMware HA кластерами;
• vMotion стал возможен на сетях с большими задержками (для Metro vMotion допустима задержка до 10мс);
• переработана технология VMware HA (нет зависимости от DNS,  нет принципа разделения  хостов на primary / secondary и связанных с ним ограничений, появился datastore heartbeating).

В настоящий момент единственным устройством, которое сертифицировано для  vSphere Metro Storage Cluster является VLEX.
EMC VPLEX - решение виртуализации сети хранения данных.

• VPLEX позволяет  объединить ресурсы различных дисковых массивов (необязательно производства EMC) в единый логический пул внутри одного сайта (VPLEX Local) и между сайтами (VPLEX Metro).
• VPLEX обеспечивает репликацию данных между сайтами синхронную (VPLEX Metro до 150 км) и асинхронную (VPLEX Geo ~ 1000 км).
• VPLEX Metro позволяет осуществлять чтение\запись локально на массивы обоих сайтов, тома которых входят в пул распределенного тома (технология AccessAnywhere).

Защита от split brane распределенного тома в VPLEX Metro осуществляется с помощью компонента VPLEX Cluster Witness и назначения для каждого распределенного виртуального тома prefered site и non-prefered site. При разрыве синхронизации между устройствами VPEX  возможность чтения\записи на распределенный том остается только на prefered site,  а non-prefered site останавливает операции ввода\вывода. Виртуальная машина Cluster Witness располагается на третьем независимом сайте, связывается с VPLEX по IP и координирует обработку сбоев.

Плюсы схемы с растянутым кластером vSphere и VPLEX Metro очевидны:

• Наиболее полное использование кластерных технологий vSphere: DRS, HA, vMotion, Storage DRS, т. е. возможна балансировка нагрузки между сайтами, более гибкая балансировка нагрузки на дисковые массивы, и, конечно же, катастрофоустойчивость.
• Защита от аварий дисковых массивов на сайте.
• Обеспечивается непрерывность доступности сервисов при необходимости обслуживания сайта либо его плановой недоступности (предупреждение отказов).

Моменты, на которые следует обратить внимание при проектировании растянутых HA\DRS кластеров:

• Наличие нескольких адресов изоляции (isolation addresses) поможет более четко определять изоляцию хостов. Это важно при работе на двух сайтах, когда есть вероятность разделения сети.
• На каждом сайте должен быть heartbeat datastore, расположенный на нераспределенном (локальном для сайта) томе.
• С помощью предпочтительных (Should) правил DRS VM-Host Affinity возможно\нужно распределять виртуальные машины по сайтам так, чтобы операции ввода\вывода на распределенный том выполнялись локально на сайте. Такая рекомендация есть в KB2007545, где говорится, что предпочтительно, чтобы виртуальные машины были запущены на стороне prefered site. Это поможет снизить влияние аварий, когда разделяются системы хранения или полностью разделяются сайты. Правда, такое правило ограничит автоматическую балансировку нагрузки между сайтами.
• Для сервисов, состоящих из нескольких виртуальных машин, группировать эти виртуальные машины на одном сайте правилами DRS VM-Host Affinity, т.е не разносить отдельный сервис по сайтам.
• Для vmkernel и виртуальных машин требуется растянутая сеть на уровне L2. Вещь довольно сложная и дорогая.
• В этой схеме есть только один vCenter, и доступность его при аварии сайта нужно как-то обеспечить (располагать на третьем сайте; использовать VMware Heartbeat, и если это виртуальная машина,  не располагать ее на распределенном томе).

Источники:
Yellow Bricks: vSphere 5.0 HA and metro / stretched cluster solutions
Deshifrator's blog: vSphere 5: High Availability - Промежуточные итоги
blog.scottlowe.org: Updated Stretched Cluster Presentation
Vierual Geek: VMworld 2011 content: BCO2479 - Understanding vSphere Stretched Clusters, Disaster Recovery, and Planned Workload Mobility

Оптимизация дисковой производительности с помощью EMC Fast Suite

Оптимизация производительности сервиса с использованием технологий EMC Fast VP (Virtual Pool) и Fast Cache на примере Microsoft SQL Server 2008 R2 (failover cluster и standalone), платформа VMware vSphere 5, дисковый массив EMC VNX5700 (видео от EMCProvenSolutions, короткая версия видео).
UPD. Новая ссылка.

Veeam: восстановление отдельных файлов гостевой ОС для виртуальной машины с vRDM

В официальной документации Veeam Backup&Replication 5 о восстановлении из бэкапа виртуальной машины, у которой есть диски RDM Virtual Compatibility Mode, ничего не говорится. Между тем есть некоторые нюансы.
Например, если пользоваться стандартным визардом для файлового восстановления для гостевых систем Windows, то содержание vRDM-раздела не отображается. Для восстановления отдельных файлов гостевой ОС для виртуальной машины с vRDM используем Multi-OS File Level Restore Wizard:

• Запускаем Multi-OS File Level Restore Wizard (Tools - File Level Restore - Other OS или Restore - Guest files (other OS).
• Выбираем виртуальную машину.
• Выбираем точку восстановления.
• До нажатия кнопки Finish жмем кнопку Customize и настраиваем временные расположение и сетевые настройки для FLR Appliance.
• Жмем кнопку Finish. Получаем вспомогательную виртуальную машину VeeamFLR_<name VM> и окно File Level Restore (подобие Windows-проводника), содержащее состояние файловой структуры виртуальной машины на требуемую точку восстановления.
• Восстанавливаем необходимые файлы. Закрываем окно File Level Restore. Вспомогательная виртуальная машина будет выключена и удалена автоматически.

Если восстанавливать vRDM-раздел не отдельными файлами, а полностью, то он восстанавливается как обычный виртуальный диск на Datastore, а не RDM. Чтобы получить RDM, конвертируем vmdk в RDM (для ESX\ESXi 3.x-4.x см. KB3443266).

Лимиты CPU для виртуальных машин

KB2009408 объясняет, что  и почему мы видим при выборе лимитов CPU в свойствах виртуальных машин.

Максимальные значения CPU лимитов виртуальных машин различны для Standalone хостов и DRS-кластеров.

Для Standalone хоста
maxCPUlimit =  numVMCPUs * GHzPerHostCore.
Пример: на хосте 8 ядер с чатотой 2GHz.

• виртуальная машина с 2 vCPU имеет максимальный лимит CPU 4GHz = 2 vCPU * 2GHz
• виртуальная машина может иметь до 8 vCPU, при этом ее максимальный лимит CPU 16GHz = 8 vCPU * 2GHz

DRS-кластер может состоять из хостов с разными CPU, виртуальные машины могут мигрировать между хостами с разной скоростью ядер CPU. Максимальное значение на движке лимита будет общая кластерная емкость. Это значение указывает, что виртуальная машина может работать на любом хосте в кластере, а ресурсы DRS-кластера абстрагированы от физических хостов в отличии от Standalone хоста.

Т.е. для DRS-кластера

maxCPUlimit =  Сумма (numVMCPUs * GHzPerHostCore) всех хостов.

Пример: в DRS-кластере, состоящем из хоста с 8 ядрами по 2GHz и хоста с 4 ядрами по 2,5GHz, виртуальная машина может иметь 12 vCPU и лимит CPU 26GHz = (8 vCPU * 2GHz) + (4 vCPU * 2.5GHz).

Значение, которое мы видим будет ниже из-за накладных расходов.

Обновление ESX(i) 4.1 до 4.1 Update2

В разделе Support&Download на www.vmware.com нет пакета обновления ESX(i) 4.1 до 4.1 Update2 для VMware vCenter Update Manager.
Пакет можно найти на странице Download Patches.

VMware vSphere 5: лицензирование, цены, пакеты

Обзор VMware vSphere 5: Licensing, Pricing and Packaging. White paper
Редакции Compare vSphere 5.0 Editions
Американские цены Compare VMware vSphere Pricing
Пакеты Compare vSphere 5.0 Kits