Архив метки: vsphere

Nutanix Xtract for VMs: как мигрировать сотни VM из VMware vSphere в AHV и не сойти с ума

Постоянно задают нам пользователи вопрос: «Как мигрировать V2V, например, с vSphere на AHV?» Ладно, если это десяток VM, можно перекорячиться руками. А если их сотни? А если нужна сложная схема взаимосвязанных операций при этом? В общем, руками — не вариант.
И вот теперь у нас появился наш собственный, отличный инструмент для переноса VM из vSphere в AHV — Nutanix Xtract for VMs. Он входит в группу инструментов Xtract, там уже есть, например, инструмент для переноса баз данных, может быть как-нибудь напишу и про него. А пока, про то, как мигрировать VM из vSphere в AHV.
Начнем с того, что Xtract for VMs это виртуальная машина, разворачиваемая на платформе Nutanix AHV. Скачать подготовленную VM в формате QCOW2 можно с нашего портала http://portal.nutanix.com, а затем развернуть ее на имеющемся у вас кластере AHV. Образ имеет размер около гигабайта, так что развертывание занимает немного времени. Можно это сделать вручную, залив скачанный образ в AHV Image Service, и затем создав из него VM. Можно также сделать более автоматизированно, с помощью Xtract CLI. Рекомендуем попробовать именно автоматизированный вариант.

Кроме процедуры развертывания, утилита Xtract CLI может быть использована для некоторых других полезных операций, но все необходимое для миграции можно сделать из графического интерфейса, написанного на HTML 5. Так что после развертывания вы скорее всего будете управлять работой Xtract с помощью этого интерфейса в браузере, введя в него IP-адрес VM с установленным в нем Xtract for VMs. 
После логона в Xtract, вам потребуется добавить исходную и целевую систему для миграции. Исходная система под VMware vSphere подключается указанием адреса ее vCenter и соответствующих логинов-паролей. Система под AHV, аналогично, требует указания на адрес кластера AHV или адрес Prism Central.

После заведения системы-источника и системы, на которую будет произведена миграция, можно создать план миграции. С помощью него мы установим, какие именно VM будут мигрировать из vSphere. На примере ниже мы выбрали группу VM, обеспечивающих работу некоего сервиса, это две VM с фронтендом, сервер приложения и сервер базы данных. Перенесем всю эту группу из vSphere в AHV.

Перед началом миграции выполняются проверки, что на целевой системе есть достаточно ресурсов (например, памяти , дискового пространства и vCPU) для размещения переносимых в заданном плане виртуальных машин. Xtract группирует пригодные и непригодные для миграции машины, и снабжает их комментариями, позволяющими разобраться почему, например, данная VM не может быть перенесена. Это может быть, например, необходимость установки в VM средств Vmware Tools, или несоответствие версии virtual hardware, либо еще какие-то проблемы. Со стороны OS VM, все OS, поддерживаемые в AHV, также поддерживаются и в Xtract for VMs. Полный список всех поддерживаемых OS можно найти на портале.
Xtract использует возможности VMware vStorage API for Data Protection (VADP) для управления процесса репликации данных, поэтому на стороне VM или хоста ESXi нам не нужно устанавливать никаких агентов. Опционально можно разрешить Xtract подключаться в VM для установки в нее драйверов (VirtIO), обеспечивающих работу VM OS в среде AHV, однако это можно сделать и заранее вручную. Если вы хотете сделать это как часть процесса миграции, укажите соответствующие логины и пароли для мигрируемых VM, для всех вместе или для каждой индивидуально. Также настраивается и маппирование сети между ресурсами исходной и целевой сетей. Наконец, вы можете создать расписание миграции, запланировав ее на определенное время.

После настройки всего перечисленного выше, можно начинать миграцию. Как упоминалось выше, мы используем механизмы VADP для переноса содержимого виртуальных дисков VM на кластер AHV. Система создает снэпшот ESXi для каждой VM, а затем перенесет его в заданный контейнер AHV. Запущенную миграцию конечно же можно, при необходимости, поставить на паузу или прервать в любой момент. 

Файлы виртуальных дисков мигрируемых VM запоминаются во временной директории, и поддерживаются актуальными даже в случае изменения исходных данных, с помощью механизма change block tracking (CBT) API и дополнительных снэпшотов.
Когда наступает пора провести cutover, и закончить процесс миграции, Xtract выключает исходные машины, выполняя для них power-off, и отключает их виртуальные NIC. Инкрементально накопившиеся данные синхронизируются с перенесенными на AHV данными VM. Когда данные полностью реплицированы, файлы vmdk конвертируются силами AHV image service в нативный формат RAW, используемый в AHV. Конверсия происходит быстро, так как vmdk и RAW, по сути, идентичные форматы, так что обычно это занимает секунды. Xtract также указывает оценочное время выполнения, так что легко можно определить необходимые на операцию затраты времени и период даунтайма.

Виртуальные машины, согласно вашему плану миграции, могут делать cutover все вместе или индивидуально. Для такой группы связанных VM как на нашем примере, cutover можно начать с базы данных, затем провести его для сервера приложений, а затем для фронтэнда. После завершения миграции, VM включаются и все временные vmdk и конвертированные образы в AHV image service удаляются. Исходные VM остаются в состоянии выключенных, и сохраняются неизменными, на случай, если они вам понадобятся. К каждой мигрированной VM добавляется комментарий, где указывается, что данная VM является мигрированной, указывается дата и время миграции и версия Xtract, которая эту операцию проводила.

Мигрированные VM снабжены ссылкой на их управление в Prism целевой системы, так что прямо из интерфейса Xtract можно перейти в управление VM и проверить, что все работает правильно. Xtract отслеживает то, какие VM вы уже мигрировали, а какие еще остались на исходной системе. Вы можете, не боясь запутаться, создавать дополнительные планы миграции для оставшихся VM и переносит их в нужном порядке.

Вот и все. Процесс миграции с vSphere на AHV еще никогда не был для пользователя настолько простым.

1242 страницы качественной бумаги

Книга, озаглавленная «Storage Design and Implementation in vSphere 6». 1242 страницы. Второе издание. Тысяча двести сорок две, my ass! Только про то, как правильно подключить к серверу и настроить СХД.

Мы, в Nutanix, в конечном счете, работаем в том числе и для того, чтобы такие книги стали, наконец, админу не нужны.

Сетевая диаграмма работы Nutanix с инфраструктурными сервисами vSphere

Хорошую работу проделал наш инженер и блоггер Artur Krzywdzinski. На рисунке ниже — сетевая диаграмма со всеми портами, для работы Nutanix с виртуальной инфраструктурой vSphere.

2016-09-24_20-20-51

Если хочется в PDF, то можно скачать тут: Network Diagram Nutanix vSphere PDF.

В посте автора можно найти и другие диаграммы, в частности для Hyper-V, AHV.

Nutanix OS 4.1.3 — что нового

На прошлой неделе я уже мельком упомянул, в посте про Erasure Coding, о том, что выходит в релиз новая версия Nutanix OS (NOS) версии 4.1.3
Вот что в ней заметного из новостей:

Ну, во-первых, это вот он, Erasure Code. Это есть, работает, можно использовать там, где это нужно, но помните, рекомендации Nutanix пока указывают однозначно: это не для production data. Официальный статус фичи — Tech Preview. Это не означает, что это ненадежно или сломано. Нет, это работает, просто для критичных, продакшн данных мы по прежнему рекомендуем использовать для защиты данных Redundancy Factor (RF), то есть хранение копии (одной — RF=2 или двух — RF=3) блока данных. Erasure Code при выходе из строя диска, может вызывать повышенную нагрузку на CPU, как при любом восстановлении из кода избыточности, а это может негативно сказаться на работающем критичном приложении. Увеличивается время восстановления и нагружается процессор.
Однако отметьте, что при обычной работе Erasure Code не приводит, судя по нашим данным, к существенному влиянию на скорость доступа. Вышесказанное, про повышенную нагрузку, относится только к процессу восстановления.
Erasure Coding можно произволно назначать для контейнера, причем можно будет переключать между RF и EC «на ходу».

Появилась синхронная репликация для гипервизора Hyper-V. Теперь можно использовать это для создания катастрофоусточивых структур контейнеров «растянутых» по площадкам между разными кластерами Nutanix.
Однако обратите внимание, при использовании Syncronous Replication под Hyper-V пока не поддерживается работа VSS.

Теперь в Nutanix OS 4.1.3 поддерживается VMware vSphere 6.0

В Acropolis встроен Image Service, который поможет при миграции из vSphere в KVM, о котором я писал в посте на прошлой неделе. В 4.1.3 все становится еще чуть проще и «однокнопочнее» :)

acro-image-service

В KVM Acropolis появился полноценный HA (High Availability), теперь VM на остановившейся ноде автоматически перезапустится на живой. У HA есь два режима работы, это режимы «Best Effort» и «Reserve Space». Эти режимы призваны решить ситуацию, когда у нас на работающих нодах просто нет места для запуска на них VM с остановившейся ноды (например, у нас есть три ноды с 80% загрузкой, и одна нода встает. На оставшизся просто нет места для всех VM отказавшей, как быть?). Подробный рассказ о этих режимах стоит отдельной заметки, пока только упомяну, что они есть. Статус HA пока — Tech Preview.

В Acropolis теперь есть свой Volume Manager. Эта фича пока также в Tech Preview и не рекомендуется к применению в продакшн.

Пофиксены текушие security vulnerabilities и баги там и сям.

Наконец-то дошли руки сделать возможность отключения разлогинивания консоли PrismUI после 15 минут неактивности в ней. %)