Баг с переименование NIC при клониковании или разворачивании из темплейта

При  клонировании или разворачивании из темплейта виртуальной машины с гостевой ОС Windows 2008 R2 и сетевой картой vmxnet3 изменяется имя сетевого соединения в ОС (например, было "Local Area Connection", стало "Local Area Connection 2"), в Device Manager также меняется имя устройства сетевой карты (VMXNET Device 2). Этот баг лечится установкой на исходную виртуальную машину хотфикса от Microsoft:

• 2344941 для гостевых ОС Windows 2008 R2, Windows 7 без SP1,
• 2550978  для гостевых ОС Windows 2008 R2, Windows 7 с SP1.

Процедура "лечения" исходной виртуальной машины:

1. Удалить из конфигурации виртуальной машины сетевую карту.
2. Включить виртуальную машину.
3. Установить хотфикс, перезагрузить виртуальную машину.
4. Выключить виртуальную машину.
5. Добавить в конфигурацию сетевую карту.

Источник KB1020078.

Как работает 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