Архив за месяц: Ноябрь 2017

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