СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

H Nutanix: Project Acropolis — KVM Management Tool в черновиках

image

Наш проект, носящий название Acropolis (др.-греч. ἀκρόπολισf; — верхний город, обычно крепость на вершине холма в греческом городе, контролирующая все окрестности ввиду своего положения) был начат еще в прошлом году, и вскоре уже по-максимуму использовался для внутренних задач компании Nutanix. Лучший способ разработать что-то качественное — самим активно пользоваться своим продуктом. Практически вся внутренняя IT инфраструктура (включая “святая святых” — разработку самого продукта) работает на Acropolis уже весьма продолжительное время.

В течение прошлого года мы уже показывали и немного рассказывали о проекте, вернее о его пред-релизной версии. Например, участвовавшие в конференции HighLoad++ 2014 возможно слышали наш рассказ о том, что это такое и куда планируется развиваться, там же на стенде можно было посмотреть на продукт “вживую” (правда, только CLI управление). И вот, наконец, в январе, в одном из обновлений Nutanix OS (NOS 4.1.1) разработчики компании выпустили первую публичную версию Acropolis (или как он сейчас будет официально называться KVM Management Tool) «в апстрим».


Технически, Acropolis / KVM Management Tool — это служба, работающая внутри наших CVM (Controller VM), как следствие — кластеризованная, распределенная, доступная на всех нодах (серверах) одновременно, линейно масштабируемая вслед за ростом облака система управления, и на данный момент не имеющая прямых аналогов на рынке система управления открытым гипервизором KVM, встроенным в ядро Linux (у нас — CentOS 6).

KVM Management Tool не имеет ахиллесовой пяты практически всех существующих на сегодня средств управления гипервизорами / облаками (включая OpenStack) — а именно использования SQL-серверов для хранения конфигураций VM и кластера, что влечет за собой массу ограничений (например ограничение размера кластера, количества VM в облаке и т.д.) вкупе с проблемами надежности и производительности.
Иначе говоря, вместо выделенных серверов / сервисов управления кластером, каждый нод является равноценным элементом единой системы управления.

Как результат, Acropolis способен без проблем масштабироваться практически безлимитно (что особенно важно для Nutanix, так как масштабируемость, scale-out — наша ключевая фишка решения), обладает крайне высокой скоростью работы (сотни тысяч и миллионы VM — не проблема, включая полный мониторинг и все метрики производительности на каждую VM) и способен выдерживать множественные отказы оборудования.

Например — всего при 5 узлах (серверах, нодах) в кластере — любые два могут отказать одновременно, что является для традиционных решений аналогом одновременного отказа 2-х SQL и управляющих серверов одновременно. Более того — при 12 узлах (3-х блоках) — может отказать целиком один блок (т.е. 4 управляющих сервера).
Другими словами, мы способны выдержать одновременный отказ двух и более “vCenter-аналогов” и БД серверов, причем это встроено и доступно изначально, при этом не требуя никакой дополнительной особой конфигурации.

Не лишним будет напомнить, что подавляющее большинство частных облаков на сегодняшний день обычно имеют только один SQL сервер (vCenter в том числе) ввиду сложности и дороговизны резервирования баз данных (Oracle RAC или IBM DB2 PureScale — обычно речь идет о десятках или сотнях тысяч долларов только на лицензии).

Если вы размышляете о том, что было бы неплохо перейти с крайне охочей до ваших денег vSphere, при всех плюсах оной как продукта, на что-то куда более свободное — посмотрите на Nutanix + KVM + KVM Management Tool.
Особенно это может быть интересно для компаний, рискующих попасть под падающий топор сами знаете чего и всей сопутствующей этому головной боли для IT-отдела.

Версия KVM, которую мы применяем — полностью открыта (в том числе для сертификации в РФ по высшему уровню) и базируется на QEMU из Centos 6.x (в ближайшее время переходим на 7.x), что позволяет говорить об “импортозамещении” — точнее переходе, в значительной степени, на открытый код и полностью открытый (в том числе документированный) формат хранения всех данных (Nutanix — одна из немногих компаний, которая последовательно и открыто публикует подробности внутреннего устройства своего продукта, (смотрите Nutanix Bible), а автор ее — Steven Poitras — один из разработчиков в компании)
Очевидно, что это является крайне ценным прежде всего для государственных органов, корпораций и прочих структур, но в том числе и для многих коммерческих компаний.
Например, наш первый крупный клиент, перешедший на Акрополис — крупная Швейцарская компания, один из лидеров индустрии в DACH регионе, осуществили полную миграцию и крайне довольны результатом.

Переход с ESXi при этом очень прост и фактически является простым копированием VMDK файла с инсталляцией QEMU-tools вместо vmware-tools на ваши VM (что можно сделать до миграции), причем это требуется только для windows машин.

Вы можете скопировать виртуальный диск (или диски) вашей виртуальной машины c ESXi на Nutanix (подмонтировав по NFS на ESXi хосте), непосредственно его использовать для создаваемой VM в KVM, и прямо с такого диска запуститься.
KVM умеет конвертировать VMDK в raw (это делается буквально одной командой — qemu-img).
Процесс этот может быть автоматизирован, и мы собираемся включить полную автоматизацию процесса в скором будущем в наш Prism UI (графический интерфейс администрирования кластера Nutanix).

Таким образом, перенести тысячи VM из VMware в KVM за несколько дней — совершенно не проблема.

В KVM могут работать самые разные OS (не только Linux). — практически все Windows, разумеется Linux, разные *nix (включая FreeBSD и Solaris). Список поддерживаемых OS тут.

Среди важных и удобных встроенных “фишек” — управление сетью (распределенным коммутатором) и встроенный IPAM (IP Address Management).
Фактически у вас есть бесплатный распределенный виртуальный коммутатор (который у других вендоров доступен обычно только в Enterprise-редакциях с соответствующими уровню лицензии ценами), с управлением VLAN, интерфейсами, назначением IP адресов для VM (статических или динамических).

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

После обновления Nutanix OS, внутренней OS кластера и CVM, Controller VM, до версии 4.1.1 (происходит это, кстати, без прерывания доступности ваших VM) сервис KVM Management Tool, при использовании KVM как установленного гипервизора, автоматически запущен и доступен.

Стартовая страница Prism UI, админского интерфейса Nutanix Cluster, выглядит примерно как на скриншоте. В левом верхнем углу мы видим, что используется гипервизор KVM, слева внизу — что работает он на 4-нодовом NX-3460 (2U стойко-места, 1.3kW потребления, его хватает для работы сотни VM).

prism-01

Перейдем в панель управления виртуальными машинами (VM). Справа вверху мы видим две раздела — создание сети (виртуального сетевого коммутатора) и создание VM.

Начнем с настроек распределенного коммутатора (поддерживается Open vSwitch). Создадим VLAN для нашей VM.

acropolis-gui-create-vlan-01

acropolis-gui-create-vlan-02

acropolis-gui-create-vlan-03

Когда сетевой коммутатор и VLAN настроены, можно приступать к созданию VM.

Нажмем на "+ Create VM".

acropolis-gui-clone-vm-01

В простой панели зададим желаемые параметры VM: Число vCPU, памяти, дисков, и сетевых адаптеров. Кроме vCPU и памяти в дальнейшем эти параметры можно поменять «на горячую».

Укажем желаемый VLAN (L2 или L3 в случае managed сети с IPAM) и нужное число дисков и CDROM.

acropolis-gui-create-disk-01

acropolis-gui-create-nic-01

Почти готово. Запускаем на создание.

acropolis-gui-create-vm-03

acropolis-gui-create-vm-04

Наша машина создана и находится в выключенном состоянии. Включим ее.

acropolis-gui-manage-vm-01

Отсюда же можно проделать с VM разные действия. Смигрировать VM на определенный хост, сделать снэпшот, включить-выключить-перезагрузить, а также склонировать данную VM в ее клон-копию.

acropolis-gui-update-vm-01

acropolis-gui-manage-vm-03

acropolis-gui-manage-vm-02

Как получить доступ к консоли нашей VM?
Для этого можно щелкнуть на ссылку Launch Console. При этом запустится VNC viewer под названием noVNC, написанный на чистом HTML5 (не требуются привычные Flash / Java), и работающий прямо в окне браузера. Напомню, мы тут все еще в браузере, в котором открыли Prism UI, никакого стороннего «VM Client» нам не надо, все в простом web-браузере. У меня, как видите, IE11, но конечно работает в любом современном браузере с поддержой HTML5, хоть в Firefox, хоть в Chrome, хоть в Safari на Mac.

Обратите внимание, что соединение криптуется, а также, что достаточно уникально для VNC клиентов, поддерживаются множество расскладок клавиатуры (включая русскую).

Если бы у меня был на VM смонтирован ISO с дистрибутивом, то началась бы установка, а без него…

acropolis-vm-console-01

Кроме этого, в Prism UI есть множество богатых возможностей по мониторингу и алертам, полезным в нашей админской службе.

acropolis-gui-manage-vm-04

acropolis-gui-manage-vm-05

acropolis-gui-manage-storage-01

acropolis-gui-analytics-01

acropolis-gui-alerts-01

acropolis-gui-alerts-02

acropolis-gui-manage-vm-06

Но что делать, если вы олдскул админ, предпочитающий командную строку всей этой «мышиной возне»?
Отличные новости: есть полнофункциональный командлайн интерфейс, вызываемый из консоли любого CVM командой acli.
Неймспейсы, онлайн-подсказки, дополнение по табу — есть. Все возможости управления доступны как из CLI, так и из GUI. Кто-то из клиентов говорит что очень напоминает старый-добрый Cisco IOS, быстро для освоения и весьма удобно.

acropolis-cli-01

acropolis-cli-06

acropolis-cli-05

А если вы планируете встроить KVM с Acropolis в вашу внешнюю систему управления «облаком», то вам пригодится наличие полноценного RESTful API, из которого VM / облаком можно управлять также, как и всем остальным Nutanix.

acropolis-restapi-01

acropolis-restapi-02

acropolis-restapi-03

acropolis-restapi-04

Это все, напоминаю, первая публичная версия. Развитие проекта продолжается, много интересных фич запланировано к выходу в ближайшее время, по мере их появления в релизе будем показывать и рассказывать.

Поскольку я запостил эту заметку в несколько хабов, то, если вы читаете ее не у нас в корпблоге, для ясности коротенький FAQ в заключение:

Q: Вы вообще кто?
A: Мы — компания Nutanix, разработчик и производитель гиперконвергентной платформы (сервер+сторадж) для работы различных гипервизоров, VM и приложений под ними. Пишем тут свой блог по адресу: http://habrahabr.ru/company/nutanix/

Q: Это все работает только на вашей платформе?
A: Это софтверное решение, но пока оно работает только внутри нашего продукта — Nutanix OS

Q: А будет открытое решение, доступное отдельно, для всех желающих?
A: Такая возможность совсем не исключена, как говорят в таких случаях «следите за рекламой».

комментарии (20)

+1
+3 –2
amarao ,  
А как оно с опенстеком? Прямые конкуренты? Multi-tennancy? Изолированные сети с маршрутизацией? Как конфигурируются загружаемые виртуальные машины? Где хранятся снапшоты?
+1
nutanix ,  
OpenStack — существенно больше и объемнее. В него входит куда больше функций. И, как часто получается, когда пытаются сделать комбайн, то на одну отдельную функцию его усилий тратится меньше. Acropolis — это только управлялка VM в KVM, плюс сравнительно небольшой модуль для управления витуальными сетями. Но, часто, именно это — 80% всех используемых функций. То есть вместо мультитула это — только плоскогубцы.
Как я знаю, Nutanix пытался сотрудничать с Mirantis для развития OpenStack, но в итоге быстрее получилось написать нужную нам функциональность самим.

Так что OpenStack конечно не «убивается» как продукт, в целом,, но некоторая часть его функций выполняется Acropolis быстрее и проще.
0
shapa ,  
Чуток добавлю.

«Убивать» никто никого не хочет и не может (рынок — он сам все расставит по местам), мало того сейчас идут проекты по интеграции с OpenStack через Nutanix API — независимые разработчики уже подключились.

Это можно только приветствовать, больше решений по управлению — шире выбор для клиента.

Учитывая что мы полностью сертифицированы для MS Azure Pack, VMware VCloud — добавление OpenStack всячески
приветствуется. Но как абсолютно правильно замечено коллегой, закон Парето работает прекрасно — 80% компаний требуется 20% функционала.

У нас функционала намного больше чем 20% (по ряду «фич» вообще уникальны), но суть остается верной — мы сконцентрировались и отполировали наиболее важный и востребованный.
0
+2 –2
shapa ,  
Давайте объективно.

Опенстак имеет большое количество фундаментальных проблем (основные — централизованное хранение конфигураций в SQL базах) и является по большому счету очередной шумихой и способом сделать деньги, с пачкой несовместимых реализаций на рынке (HP Openstack, Мирантис и прочее).

Мы же стараемся всегда делать лучший в классе продукт со 100% рабочим функционалом.

По поводу изоляции сетей — VLAN дает изоляцию, маршрутизацию мы пока не делаем сами (ключевое слово «пока», ибо мы каждые несколько месяцев выкатываем новые версии ПО) но не скрываем что активно сотрудничаем с Cumulus и Arista Networks :)
Идея в том что мы не хотим делать «ужас-ужас» по управлению сетью (как на Опенстаке), но хотим чтобы было легко, изящно и управлялось одним инженером который разобрался за 2 минуты. В общем — как весь Nutanix.

Вообще автоматизация любая на нас делается через RESTful API, включая multi tenancy и прочее.

В мире есть уже сервис-провайдеры / ДЦ которые начали переходить на Acroplois / Nutanix (см. например www.reseller.co.nz/article/566550/maclean-offers-unique-proposition-kiwi-market-nutanix-powered-iaas-offering/ )

По поводу снапшотов — они хранятся локально и удаленно (на других кластерах Nutanix), это функциональность DR.

Мы хотели сначала в этой же статье это описать, но решили что слишком много материала и это лучше сделать отдельно.



Очень объективно IBM про опенстак пишут:

• OpenStack remains an emerging technology,
• It is not mature yet,
Error handling not robust,
• Understanding the flow of calls and messages is needed,
• Large volume of message based rpc calls,
• Logging is not optimal (either too much or too little),
• You must be willing to look at code,
• Networking (nova-network) is complicated,
• Multiple bridges,
• IPTables configuration not straight forward.
© IBM Corporation
+2
pavelodintsov ,  
Снимаю шляпу! Звучит очень вкусно! А цены? :) Если можно, личкой.
0
shapa ,   * (был изменён)
Скажем так — если подсчитать стоимость серверов + high-end СХД + коммерческого гипервизора (и системы управления оным) — мы будем однозначно дешевле и скорее всего кардинально быстрее.

Но мы не рассчитаны на рынок небольших бизнесов или дешевых хостеров, нам наверное проще будет дать бесплатно.



Кстати сегодня кстати анонос пачки нового железа на Haswell, там теперь на каждый микронод (3000-я серия) до 6.4 терабайт SSD и 8TB SATA, что на 2U дает 25.6 терабайт SSD и 32 терабайта SATA, плюс до 4x10G контроллеров на нод (16x10G сетевых адаптеров на 2 юнита стойко-места :) ) и тд

Производительность еще поднялась, теперь на 2U — 80 тысяч IOPS на запись (random) и 140+ тысяч IOPS на чтение (тоже random).

Если взять 10 блоков, учитывая линейный рост производительности, то будет 800 тысяч на запись и почти полтора миллиона IOPS на чтение :)

p.s. пишите мне на m.shaposhnikov@nutanix.com если есть вопросы.
0
teraflops ,  
А как обстоят дела с sustained rate для случайных чтений? Скажем, на терабайтном промежутке для 2U?
0
shapa ,  
Приведенные цифры (очевидно, для flash уровня) — именно для случайного чтения и записи.

Тестируем честно, FIO. Любой клиент может повторить у себя и получить результаты или такие-же или лучше. Если интересно — могу привести детали, включая конфигурационные файлы FIO.
0
teraflops ,  
А, спасибо, ясно. Каково при этом соотношение иопсов к приложению к сырой иопс-емкости этого массива, с учетом фактора резервирования?
0
shapa ,  
Цифры названы для реальной кластерной ФС (4 нода) и двойным резервированием данных. Для тройного — будет около 12% просадка еще.

Масштабирование строго линейное (никаких чудес — Cassanda NoSQL масштабируется линейно), т.е. 2 блока выдадут ровно в два раза больше.

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

Очевидно, что если считать максимальную производительность (сырую), то она будет в разы выше — каждая SSD способна выдавать около 100.000 IOPS, а у нас их 8 штук на 2U блок.
0
teraflops ,  
Целесообразно сравнить эти параметры с single-instance тестированием у Ceph: yadi.sk/i/tCrzLwPWenEYw. В вашем случае фактор железо-софт равен примерно 8 к 1, у Ceph — примерно 12 к 1, для эталона S3700. Насчет потребления процессора в обоих случаях сложно судить, поскольку эти метрики не приведены, но получается так, что опенсорс буквально дышит в затылок :)
0
shapa ,  
Ceph — отличный проект. Файловая система.

Но не надо путать проект и продукт.

Ceph не может управлять VM / облаком, не может работать с ESXi и HyperV, использует нестандартный протокол (Acropolis — на iSCSI мультипоточном работает), не имеет множества функционала крайне важного для энтерпрайза / госприменений.

Но для ряда задач (например построение крайне недорого облака для сервис-провайдера) — отличный выбор.

В целом — мы только рады что нас пытаются догонять (хотя бы по части функционала) — это в общем-то повод быстро идти вперед.

Именно поэтому наша архитектура на 100% открыта — как говорится берите и копируйте (берут и копируют :)) )

stevenpoitras.com/the-nutanix-bible/
0
teraflops ,  
Хорошо, возьмем опенстек и Сeph, там будет доступен HyperV, ESXi, подключение вольюмов ceph к ним через iscsi и все это практически бесплатно, не считая затрат на деплой и обслуживание. Можно также приготовить их должным образом, наподобие Fuel от Мирантиса, спозиционировать это как OSS клоуд и продавать поддержку/экспертизу для внедрений. Разница в том, что в этом случае продается чуть менее производительная сущность, но с огромной диверсифицированной базой разработки и конечных пользователей, что, скорее, перекроет полуторакратную разницу в скоростях при одинаковых ценах.
0
shapa ,   * (был изменён)
«подключение вольюмов ceph к ним через iscsi» — пардон, но это как-бы не очень серьезно даже обсуждать.

1) Как балансировку / отказоуйсточивость iSCSI будете делать?

2) Производительность такого «реэкспорта» тестировали? Как насчет поддержки ODX и VAAI? И то что iSCSI — однопоточный протокол? (мы обошли это архитектурно, но это возможно только в случае гиперконвергентных решений — у нас на каждую VM / vDisk — отдельный iSCSI поток)

3) Вы готовы выкидывать производительность нодов Ceph (процессоры, память и тд) ибо очевидно что ESXi и HyperV не могут работать на этом же железе?

4) OpenStack, с его централизованным хранением конфигураций в SQL серверах, отсутствием аналога VAAI и прочим — в общем-то это все уже отписывалось.

Еще раз, Ceph — отличная ФС для ряда задач / применений.

Но не стоит ножом пилить дерево и долбить камень — там требуются инструменты другого порядка :)

ОпенСтек от Мирантиса имеет множество проблем (стоит например поговорить с их бывшими работниками — они рассказывают как дела обстоят на самом деле), при том что по деньгам выйдет чрезвычайно недешево — зачастую дороже чем VMware VCloud (если нужна поддержка, а OpenStack без поддержки для серьезных применений — только если у вас есть десятки разработчиков на его поддержку)

Вы реально думаете зря Intel им пообещал 100 миллионов долларов инвестиций? :) Это большой бизнес. Клиенты будут в итоге платить, и очень много.

Именно поэтому мы решили сделать все правильно.

Nutanix (и Acropolis) готовы к эксплуатации за 10 минут (полная инсталляция с нуля под ключ), расширение линейное, в штате компании обычно хватит держать максимум несколько инженеров для обслуживания.
0
shapa ,  
Можно например почитать вот это

wiki.ceph.com/Planning/Blueprints/Hammer/Clustered_SCSI_target_using_RBD

«Current Status
There are many methods to configure LIO's iSCSI target for High Availability (HA). None support active/active, and most open source implementations do not support distributed SCSI Persistent Group Reservations.»

Как только доработают (возможно через пару лет) — можно будет уже реалистичнее обсуждать такие конфигурации.
Если сделают мультпоточную реализацию iSCSI (правда не представляю как это архитектурно возможно для Ceph) — будет еще интереснее.
0
teraflops ,  
There are many methods to configure LIO's iSCSI target for High Availability (HA). None support active/active, and most open source implementations do not support distributed SCSI Persistent Group Reservations


Это и текущий вариант с высокой доступностью — немного разные механизмы, HA в данном ключе нужен для поддержки существующих очень специфичных конфигураций, бывших в режиме мастер-мастер ранее, на «легаси»-устройствах.
0
teraflops ,  
1. Отказоустойчивость и распределенность там не отличается от обычного rbd-вольюма, то есть точка отказа и точка объединения потока данных просто отсутствуют.
2. Производительность на уровне сырого rbd, то есть две трети от ваших цифр, без учета улучшений, которые Ceph обещает в ближайшем мажорном релизе, VAAI там действительно нет, это единственный минус из всего списка.
3. Если рассматривать решение с высокими IOPS, то производительность нод хранилища в любом случае будет потреблена хранилищем, а для небольших нагрузок стоимость железа под хранилище будет меньше или равна удельной стоимости ресурсов, высвобождаемой на лицензируемых вычислительных нодах. В любом случае это вин-вин.
4. На его месте может быть другой *stack, начиная от Proxmox и заканчивая Cloudstack, вопрос пожеланий, равно как и вопрос хранения информации, при масштабе деплоя в несколько тысяч нод, где разница между реляционным и KV хранилищем начнет сказываться, удельная разовая стоимость подобной доработки копеечна.

Суммируя, ваш продукт технологически находится в той же нише, что и его опенсорсные эквиваленты, а плюсом может быть только более низкая стоимость внедрения или владения.
0
shapa ,   * (был изменён)
1),2) — я дал ссылку в комментарии выше. На сегодня iSCSI экспорт с ceph — совершенно несерьезно к обсуждению.

3) " Если рассматривать решение с высокими IOPS, то производительность нод хранилища в любом случае будет потреблена хранилищем" — это абсолютно не так, мы резервируем 2 физических ядра с процессора (все остальные свободны для работы гипервизора / полезных нагрузок) и не имеем никаких проблем с производительностью, скорее даже наоборот.

Тобишь (перефразируя), вы предлагаете иметь в два раза больше «железа» (и соответственно тратить электричества, стойкоместа и прочее) — ceph кластер и кластер гипервизора

Ни о каком линейном масштабировании простым добавлением узлов кластера речи не идет.

4) Proxmox — кластер максимум 16 нодов, копии всех конфигураций на каждом ноде, все еще намного хуже чем OpenStack.
Впрочем, для своих целей (маленьких компаний / облаков) — вполне нормально.

Cloudstack — в общем-то тоже абсолютно не решены проблемы центральных точек отказа (опять-же пресловутые SQL и прочее).



С «суммой» даже нет смысла «не соглашаться», проще показать отчеты IDC и Гартнера например (Нутаникс занял более 50% рынка, который к 2017 году будет исчисляться в десятках миллиардов долларов).

www.theregister.co.uk/2015/01/16/hyperconverged_hype_charted_by_shamans_at_idc/
www.gartner.com/newsroom/id/2675916

Где там ceph и мирантис? :)
0
demon23 ,  
Я правильно понимаю, что вы так же поставляете и свой собственный дистрибутив Linux c KVM?
В таком случаи кто занимается поддержкой в случаи с проблемой внутри гипервизора?
0
shapa ,  
Дистрибутив линукса назвать «нашим» можно с некоторой натяжкой — он базируется на Centos, но безусловно есть исправления и улучшения (особенно для KVM). Все патчи открыты.

Если коротко, то Nutanix занимается полной поддержкой «от и до». Причем мы гарантируем что в течении 5 лет все глобальные апдейты (новые ОС) будут работать на проданном оборудовании, что (другими словами) означает что в течении 5 лет клиенты получают весь новый функционал и улучшения производительности. Большинство других вендоров поддерживают оборудование (в смысле новых ОС и функционала) максимум несколько лет.

Техподдерджка является системой «одного окна».

Начиная с вопросов по оборудованию, заканчивая проблемами работы конкретных приложений на какой-то конкретной ОС и конкретном гипервизоре.

Практически любые типовые задачи — есть Best Practice, включая полные конфиги гостевых ОС и приложений на них — например для Oracle RAC, дизайн MS Exchange на 1.3 миллиона почтовых ящиков, Cisco UCS (так-же как Avaya), MS SQL и т.д.

www.nutanix.com/resources/best-practices-guides/
www.nutanix.com/resources/reference-architecture/

Все три гипервизора (KVM, ESXi, HyperV) поддерживаются идентично и нашими силами (мы фактически собираем лучших инженеров в индустрии, штат компании уже более 1000 человек)

Например, у нас наибольшее количество VCDX в мире среди всех коммерческих компаний после самой VMware (если HP или IBM имеют в глобальном штате всего несколько человек, на всю РФ есть единственный инженер, то у нас их более 15 на сегодняшний день)

www.virtualizetips.com/2013/09/27/vmware-vcdx-numbers/
www.theregister.co.uk/2013/11/15/nutanix_building_elite_squad_of_crack_vmware_designers/

Мы единственные кто предоставили (сами) официальную поддержку MS Exchange на NFS датасторах (самой Microsoft это не поддерживается), ввиду нашего партнерского статуса с MS.

lukaslundell.com/2014/09/nutanix-support-for-exchange-on-nfs/



Фактически, уже доступен Nutanix Российской сборки и «полными парами» идет сертификация.