X-Ray 2.2

В релиз вышла новая версия нашего открытого теста-бенчмарка гиперконвергентных сред — X-Ray v2.2
Мы планируем выпускать новую версию каждые два месяца, так что следующая запланирована на январь-февраль 2018.

В текущей версии к Nutanix и VSAN добавлен также ScaleIO как платформа, на которой можно запустить наши тесты и проанализировать производительность.
Появилась возможность к предустановленным workloads создавать свои собственные.
Добавлена возможность использовать Linked Clones для тестов VDI.

В будущем мы планируем расширить X-Ray на поддержку наших совместных с IBM платформ на Power8.

Взять новую версию можно как обычно:
QCOW2 (AHV) — http://download.nutanix.com/x-ray/2.2.0/xray-2.2.qcow2
OVA (ESXi) — http://download.nutanix.com/x-ray/2.2.0/xray-2.2.ova

Не забывайте прочитать документацию по настройке и использованию. Хэппи бенчмаркинг!

Конфигурация «1-Node» Nutanix

Как вы уже наверное слышали, у Nutanix появляется особый класс систем, которые я в целом затрудняюсь называть «кластер». Это однонодовые системы, которые, подобно тому, что вы уже, возможно, видели в Community Edition, могут работать как «кластер, состоящий из одной ноды». Раньше мы такое позволяли использовать в качестве Backup Target, а вот теперь, хорошо подумав, разрешили использовать и для запуска VM. Но подумали мы и правда тщательно, и вот ниже я перечислю все моменты, о которых вам будет нужно знать, прежде чем вы будете интересоваться предметно таким «сверхдешевым» Nutanix.

Пункт номер ноль. Это НЕ SMB решение. Это решение для рынка так называемого ROBO (Remote Office/Branch Office). Поэтому минимальная закупка таких 1-Node Nutanix — 10 штук.
То есть если у вас структура компании с множеством (десятком и более) небольших удаленных филиалов, и вы выбрали Nutanix в качестве решения для основной инфраструктуры, и при этом вам нужно оснастить Nutanix-ами филиалы и удаленные офисы, на которых практически нет вычислительной задачи, а данные для защиты все равно реплицируются на «большой» Nutanix в головной компании, то вот тогда это то, что вам нужно. В филиалы тогда идут недорогие однонодовые Nutanix, управляемые из Prism Central головного офиса. И в целом вы решаете задачу защиты данных через их репликацию в центральную систему, минимальная локальная защита у вас будет (об этом ниже). При этом типовая задача у вас для такого офиса — держать «AD, DHCP, DNS, Firewall, VPN до «головы», пять VDI операционистов, почту и файлопомойку» — то с этим вот сюда. Получается такой «филиальный допофис-ин-э-бокс», заливаемый за 30 минут и готовый к использованию «просто включи в сеть».

1. Пока мы подготовили две специальные модели для этого направления, это NX-1175S-G5 (1N1U) и NX-1155-G5 (1N2U). Обратите внимание, 1175S означает single socket, 1 pCPU. Модель 1155 уже была доступна, это 1-Node Backup Target, теперь на ней разрешено запускать Guest VMs.

Конфигурация NX-1175S-G5:
CPU: 1x 2620v4 (8-core) or 1x 2650v4 (12-core)
Memory: 64G or 96G or 128G or 256G
Hybrid:
SSD: 2x 480G or 2x 960G or 2x 1.9TB
HDD: 2x 2TB or 2x 4TB or 2x 6TB
All-Flash:
SSD: 4x 480G or 4x 960G or 4x 1.9TB
Network: 2x1GbE LOM (built-in) + Add-on NIC (Optional) : 2x1GbE or 2x10GbE (SFP+ or Base-T)
Power Supply: 1 (only!)

Сетевая конфигурация, доступная для NX-1155-G5:
4x1GbE, Add-on NIC (Optional): Dual-Port 10 GbE SFP+, Dual-Port 10 GbE BASE-T, or Quad-Port 10 GbE SFP+

2. «Расширение кластера» для 1-Node нет и не планируется. То есть, купить и установить 1-Node, потом докупить еще две и расширить на них, сделав «полный» кластер нельзя.
Однако можно собрать «большой» Nutanix Cluster из трех и более NX-1175S, но только НЕ расширением 1-Node, а переинсталляцией, с нуля. Дальше такой 1375S можно скейлить обычным для Nutanix способом, это будет обычный трех- и более нодовый кластер Nutanix из 1U Single CPU нод 1175S.

3. CVM на такой системе занимает 6 vCPU и 20GB RAM

4. Так как наша архитектура подразумевает репликацию блоков, то даже на 1-Node она будет, просто две копии блока будут храниться локально. Это не защитит от отказа контроллера или ноды целиком, но отказ одного HDD это может помочь пережить без потери данных. Отказоустойчивость предполагается решать репликацией на main cluster и локальными бэкапами, например с помощью Comtrade HYCU на сторонний NAS.
Так что репликация RF=2 будет, и usable space все равно будет ~50% от raw физических дисков.

5. Нет: дедупликации, ABS и AFS, Erasure Coding, Capacity Analysis на Prism Central.

6. Async DR (репликация на Nutanix в другом DC) — минимальный цикл 6 часов (RPO). Metro Availability конечно же нет тоже.

7. Отказ ноды — ожидаемо offline всего на ней содержащегося.

8. Отказ SSD (одного из двух) — переход хранилища в read only.

9. Гипервизоры: для 1175S — AHV и ESXi, для 1155 — только AHV. Hyper-V нет ни для одной модели.

10. Минимальная версия AOS — 5.5

Чуть позже, как только они будут объявлены, я расскажу и про вариант перечисленного, который будет носить название «2-Node».

AHV Turbo Mode — первые результаты

Интересные результаты показали наши разработчики для AHV Turbo Mode (AKA Frodo).

Напомню, AHV Turbo Mode, как внутренний project codename называвшийся Frodo, это новый способ работать с дисковым хранилищем в Nutanix AHV, оптимизация пути передачи данных и более высокая параллельность обработки очередей, которые теперь могут обрабатываться большим числом ядер CPU на хост-машине, чем было до того в vanilla QEMU. Он появился впервые в AOS 5.5, вышедшем на прошлой неделе.
Это улучшение особенно важно для AllFlash и NVMe машин, выходящих у нас в свет следующем году.
Как вы видите из графика, на обычной VM рост производительности ввода-вывода при увеличении числа параллельных операций практически останавливается в районе 30-40 Outstanding Requests, при этом с использованием AHV Turbo Mode он продолжает свой рост вплоть до 128. Это отличный потенциал для роста производительности для новых AllFlash, так как проявляется эта новая возможность прежде всего на них.

Acropolis OS 5.5 goes wild

Итак, долгожданный AOS 5.5 вышел в релиз.
Если у кого все работает, не спешите обновляться, дайте пару недель «постоять» все же. А я пока перечислю самое важное, что в новом релизе появляется.

1. Calm. Или вот даже так: CALM!!
Столько мы о нем говорили, и вот он есть.

2. Микросегментация и политики микросегментации сети в Prism Central.
Это позволяет гибко создавать «сетевые сегменты» для приложений, задавать их политиками, и наследовать эти политики даже при миграции VM. Наш ответ NSX-у.
Пока в Tech Preview, релиз весной.

3. Async DR с Nearsync репликацией.

4. Программное шифрование.
Раньше только с помощью SED disks, а теперь — программно, на любой системе. По прежнему непонятен статус этой фичи для России по известным причинам. Этой фичи не будет в версии для России (по известным причинам), в других странах будет.

5. Scaleout Prism Central.
В отличие от Prism Elements, встроенного, наш Prism Central был одной VM, с понятными проблемами с масштабируемостью и доступностью. Так как теперь PC стал все более и более важным компонентом системы, этот недостаток устранен, теперь он тоже распределенный.

6. AHV Turbo Data Path.
Я уже кратко упоминал это. Новый метод работы с быстрыми дисками, позволяет обойти узкое место в гипервизоре. Особенно актуально для NVMe.

7. Поддеживается vNUMA в AHV.

8. vGPU в AHV.
Долгое время это была проблема, использовать 3DGPU в VDI с AHV. Теперь есть поддержка vGPU.

9. Поддерживается Windows Server 2016 и Hyper-V 2016.

10. Появилась официально возможность запускать VM на «Single Node Cluster».
Single Node cluster знаком вам по CE, в этом году он появился как Backup Target, и вот, после всестороннего тестирования, появиась эта возможность и для запуска VM на такой системе. Вариант для extremely low-end, понимающего, что он делает.

11. Сетевая сегментация.
Было некоторое количество критики на тему, почему у Nutanix все сетевые трафики, служебные, пользовательские, и все остальное, загнаны в одну сеть. Теперь их можно ранести по интерфейсам.

AOS 5.5 пока не вышел в 1-Click Upgrade, но на тестовых системах уже можно начинать смотреть.

Куда и кому продавать Nutanix?

Кому продавать Nutanix (и более широко — гиперконвергенцию вообще). Заметки для памяти.
Очень часто, рассказывая новым партнерам Nutanix о продукте, я слышу вопрос: «Ну а куда нам стоит попробовать продавать Nutanix в первую очередь?», куда его будет новичку продать проще и удобнее всего, куда «зацепиться» в аккаунте, в какой проект?
И вот, у меня родился такой текст, в помощь начинающему продавать Nutanix, и, в общем случае, кстати, гиперконвергенцию вообще.
Я решил представить себе (и вам)несколько кейсов, увидев которые начинающий продавать Nutanix должен удвоить усилия, и попытаться продать туда именно гиперконвергенцию, а не что-то еще, вроде «классики». Просто потому, что приведенные ниже области — хороший вариант показать лицом все основные преимущества HCI и Nutanix.

1. Если компания развертывает инфраструктуру виртуальных десктопов, VDI. (Особенно на Citrix XenDesktop, и особенно — с vGPU). Сегодня объем VDI, когда-то первого направления компании, совсем не так велик (вопреки популярному «заблуждению» на этот счет от наших конкурентов). Всего около четверти всех клиентов компании, по опубликованным результатам прошедшего года, это VDI. Сегодня мы гораздо больше работаем в «тяжелом энтерпрайзе» и БД (около 50% клиентов). Тем не менее, если стоит задача объяснить «с нуля» то, «в чем цимес» гиперконвергентности в инфраструктуре, то сделать это на задаче VDI нет ничего проще. Такие задачи состоят обычно из множества сравнительно однотипных VM. Задача, требующая быстрого масштабирования, растущая как вширь, так и «вглубь», от десятков и сотен, и порой до тысяч рабочих мест. Ничего нет лучше для этой задачи чем гиперконвергенция.
С 2015 года мы сотрудничаем с Citrix, для которого наша платформа виртуализации под их лидирующий в энтерпрайзе VDI брокер XenDesktop (XD) — идеальное дополнение, позволяющее легко конкурировать, и прежде всего по цене, с VMware Horizon. Своя платформа виртуализации у Citrix (это Xen Server) довольно быстро теряет позиции, отставая во многих решающих областях, поэтому эффективный, бесплатный, современный гипервизор для брокера Xen Desktop (и при этом чтобы НЕ ESXi!) Citrix-у насущно необходим. Так что неудивительно, что Citrix и Nutanix вот уже более 2 лет — технологические партнеры, а Xen Desktop на AHV это взаимно поддерживаемое и валидированное решение. В том числе и для использования GPU-powered десктопов с использованием графических карт NVIDIA Tesla M10 и M60.

2. Если компания собирается «в облака». Это, обычно, значит, что у нее уже все готово в инфраструктуре к такому переходу. Им не нужно будет объяснять преимущества перехода к облачной модели использования ресурсов, чуть ли не самому сложному, из того, что мне приходится объяснять среди преимуществ использования гиперконвергентного подхода. Значительная часть этих преимуществ находится именно тут. Они этот путь прошли, и все эти достоинства для себя уже сформулировали. Теперь вам просто надо прийти и сказать: «Вот смотрите, вместо того, чтобы отдавать свои данные на сторону, компании, которую вы пока не знаете (и еще и платить за это узнавание будете!) вы можете оставить все ваши данные и приложения у себя, и использовать Nutanix как платформу для «частного», или «гибридного облака», интегрированного как с вашими бизнес-задачами, так и с предложениями публичного облачного оператора. Да, «облако», но — у себя!». Nutanix Сalm, Kubernetes, AWS, Azure, Google Cloud. Гибко, быстро, удобно, безопасно.

3. Если компания хочет отказаться от vSphere. Причин может быть множество. Ищут альтернативу (а их сегодня, увы, немного. Кроме Hyper-V (и AHV), можно сказать, практически и нет). Не обновились на 6.х вовремя, или не хотят обновляться на «шестерку» в принципе, а дата окончания поддержки для vSphere 5.5 — сентябрь следующего, 2018 года, и уже припекает — так припекает. Просто разочаровались в VMware как таковой, продукте или компании в целом, и хотят «соскочить» с минимумом проблем с регулярных выплат «на техподдержку» и необходимости платы за расширение инфраструктуры с оплатой «за сокет». Если компания размышляет о миграции с VMware, и миграция на Hyper-V при этом по разным причинам не рассматривается, то это прекрасный случай поговорить о возможности уйти со всем хабаром на Acropolis Hypervisor (AHV), причем использовать наши средства миграции инфраструктуры для облегчения этого процесса. А они у нас есть.

4. Если компании интересно направление Big Data. Если вы еще никогда не слышали о Big Data, или слышали только краем уха, то вам стоит узнать о том, что это направление сегодня растет опережающими рынок темпами. Сегодня объем рынка по этому направлению составляет около 33 миллиардов долларов, и через 5 лет — более чем удвоится (72 миллиарда). Этим уже вовсю занимаются, в том числе в России, ритейл, банки, сотовые и интернет-операторы, и интерес тут, у нас в стране, растет вслед за мировыми трендами. Big Data, название может ввести в заблуждение, это не о размерах или количестве данных, это о методике работы с данными любого объема, не обязательно огромного (хотя часто — довольно большого). Big Data Analysis требует использования специальных средств. Если вы слышите в разговоре с клиентом слова Big Data, Hadoop, Splunk — навострите уши. Сюда есть куда продать Nutanix, мы много и успешно работаем в области интеграции с big data продуктами и у нас есть хороший опыт, в том числе в России.

5. Если компания занимается микросервисами, распределенными системами, контейнеризацией приложений, разработкой в вебе, Kubernetes, Docker, etc-etc.
Ну тут все очевидно. Как и в случае перехода в «облака» компания уже сделала важный шаг, перешла в новую парадигму, или сразу в ней родилась, жила и развивалась (что характерно для веб-ориентированных компаний). Им не нужно объяснять, чем хороши discretization, distributed apps, микросервисы, контейнеризация. Показывайте Calm, интеграцию с Docker, Kubernetes, публичными облаками, методы построения гибридного облака через оркестрацию в Calm, возможно — интеграцию с OpenStack. Это все скажет само за себя.

6. Если компания работает в области здравохранения и вообще медицины. Медицинский софт — это отдельный мир, со своими протоколами доступа к данным, форматами файлов, разнообразными специализированными сертификациями. В Nutanix работа с healthcare-вертикалью — большой сегмент бизнеса. Мы умеем работать с этим направлением, поддерживаем разное специализированное ПО, и у нас есть что предложить в этой области. Привлекайте наших экспертов к разговору. У нас есть опыт в том числе и в России.

Итак, остановимся на шести. Конечно же, число наших клиентов показывает, что Nutanix востребован и используется очень широко. Но иногда, для сейла, чтобы начать продавать, нужно «зацепиться». И, как мне кажется, перечисленные области, это то, где «зацепиться» начинающему бывает проще всего.

Если у кого есть дельные мысли по поводу того, какие очевидные и легкие области продать Nutanix я выше пропустил — делитесь в комментах.

Обновление платформы: G6!

Тем временем подоспели новости, о которых я начну рассказывать с этой недели.
Как вы уже, наверное, слышали, к семье наших OEM-ов (DellEMC и Lenovo) добавляется Fujitsu. Пока это только анонс, и из трех заявленных моделей у Fujitsu доступна в первом квартале будет только одна.

Так что, когда они раскачаются, тогда я об этом и напишу подробно, а пока достаточно этого короткого анонса, потому что дальше — о нас самих.

Да, действительно, Nutanix постепенно идет в направлении software-only модели, но это будет не в следующем году точно. В следующем году нас ждет обновление линейки платформ native Nutanix, связанной с плановым обновлением процессорного ряда Intel, и, соответственно, обновлением наших ODM-партнеров, Supermicro.
Заверешен цикл тестирования, и мы официально объявляем выход поколения Generation 6, на процессорах Intel Skylake.

Вот, что будет в деталях нового и интересного.

Платформы NX-3060 первыми получат обновление до G6.
Мы будеи использовать шасси Supermicro SYS-2029BT-HNC0R-NI22 с материнской платой BigTwin X11DPT-B, на логике Intel C621 PCH (Lewisburg) и процессорами Intel Xeon Silver 4108, 4114 , 4116 и Intel Xeon Gold 5120 ,6130, 6138, 6126. Как вы должно быть знаете, Intel в очередной раз перелопатил номенклатуру процессоров Xeon, и теперь процессоры у них называются «металлами» по семейству и номерами по моделям в семействе. Bronze мы использовать, понятное дело, не будем, а Silver и Gold семейства, используемые в следующем поколении платформ, перечислены выше.
Повышается тактовая частота памяти DDR4, с 2400 до 2666 MHz. Максимальный объем памяти — 768GB на ноду G6 (все конфигурации по памяти — сбалансированные). Пока не поддерживаются 64GB DDR4 DIMM, из-за ограничений платформы по тепловыделению, поэтому максимальная емкость памяти на ноду ограничена на 768GB.

Сразу со старта заявлена поддержка NVMe (на 1.6TB). Разумеется остались SSD (960GB, 1.92TB, 3.84TB) и HDD (2TB только).

Из интересного «под капотом»: в Supermicro (и мы, следовательно, тоже), отказываются от использования SATADOM, SATA Disk-on-Module, внутреннего flash-диска на SATA-шине, с которого у нас грузится baremetal hypervisor. С ним было одно время достаточно проблем, связанных с производительностью и ресурсом. Например, проблемы вызывала Windows Server 2012R2, поставленная на него как хост Hyper-V. Оказалось, она непрерывно пишет неотключаемые логи, и это приводило к скорому выходу из строя SATADOM flash той модели, которую мы использовали примерно пару лет назад. Тогда это потребовало множества гарантийных замен на работающих системах у пользователя. Теперь эта проблема кардинально решена, платформа переходит на пару устройств 240GB SATA 2280FF M.2 в software RAID-1. Декларируется 1 DWPD, так что, как мы ожидаем, названные выше проблемы ушли в прошлое.

Расширяется номенклатура сетевых карт. К уже известным 2port 10G SFP+, 4port 10G SFP+, 2port 10GBaseT добавятся 2port 40G QSFP28 и 2port 25G SFP+, причем до двух карт на ноду! Новый конструктив корпуса дает возможность поставить ДВЕ карты на каждой ноде, и это не считая пары 10GbaseT, встроенных в платформу (на SIOM, Supermicro IO Module).
Так что 40G и 25G будут доступны теперь и на 3000-series. Это вызвано растущей производительностью ноды. Если раньше на midrange-нодах использование таких производительных интерфейсов выглядело сомнительным, так как чтобы загрузить такую полосу ввода-вывода нужна очень солидная производительность CPU и памяти, то теперь, с новыми CPU и, в особенности, с NVMe, это уже становится важным и необходимым.

Энергопотребление 4 нод под нагрузкой — в районе 1700W, рассчитанный worst case — 2080W, среднее тепловыделение 4 нод — 5800 BTU/h, блоки питания при «нашем» вольтаже поддерживают полную redundancy (блок из 4 нод продолжает работу при выходе из строя одного PSU).

Доступность всех перечисленных фич ожидается к концу декабря.

Странные движения вокруг Microsoft Storage Spaces Direct (S2D)

А еще тут у нас странная история произошла со Microsoft Storage Spaces Direct. Это, кто не знал, такая «гиперконвергенция», встроенная в Windows Server 2016 (ну, она теперь у всех, вот и Microsoft оскоромился). Или, вернее, была встроена, потому что в новом обновлении 1709 его из Windows Server 2016 удалили. По этому поводу есть некоторое количество запутанных объяснений, но, откровенно говоря, выглядит как временное удаление до исправления каких-то серьезных проблем. Обещают вернуть в следующем semi-annual update. Но пока пускать ли такое в продакшн — я бы поостерегся.

Пишу, потому что у нас в стране есть некоторое ненулевое количество пользователей и фанатов технологий Microsoft, и мне уже несколько раз приходилось сталкиваться с вопросами про S2D как потенциального конкурента. Ну, вот такой он у нас конкурент. То есть, то нет.

Переход на Nutanix для компании — реальный кейс

Кстати, вот вам реальный кейс одного из клиентов компании, взятый из свежего отчета по проекту миграции.

Поэтому когда мы рассказываем про то, что, мол, «продали один нутаникс на четыре ноды», это не оттого, что не можем больше. Это оттого, что клиенту, зачастую, больше нечего в него положить! Семь стоек, 56 серверов и сопутствующего хабара 19 информационных систем переехало на Nutanix и уместилось в компании в 10U одной стойки, при этом с двукратным ростом по памяти и ядрам, и пятикратным по дисковой емкости.

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 еще никогда не был для пользователя настолько простым.