Как дела у Nutanix?

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

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

Но так ли все ужасно, и скоро ли Хьюлет Паккард (вариант: Хуавей) купит Нутаникс на сдачу от продажи десятка Супердомов?

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

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

Здесь легко видеть, что, после короткого и бурного роста сразу после размещения, курс начал падать и падал больше года, до начала 2009. После чего линейно попер вверх в течение двух лет, хотя даже в этом случае он так и не достиг цены акций, полученной в первые недели после размещения. Потом курс рос, снижался, опять рос, опять снижался, и несмотря на это компания VMware — это компания VMware.

Плохо это или хорошо? Да ни плохо, ни хорошо. Такова фондовая биржа, не зря к ней применяют слово «игра». Она давно уже живет не в понятиях, допустим, XIX века, когда если курс акций высокий — хорошо, курс снизился — плохо. Там давно уже все не так просто. Там свои механизмы, которые нам не видны, если вы только не профессиональный биржевой брокер, не зря сейчас на бирже допущены «играть» только они.

Еще пример? Пожалуйста.
Вот так выглядел первый год у еще одной большой и успешной сегодня компании. Как вы видите, в первые полгода курс акций упал более чем вдвое. В третьем и четвертом квартале чуть приподнялся, но все равно, что бы сказали, глядя на этот график уже знакомые вам «финансовые аналитики»? Ну, стали бы рассказывать, что дела плохи, что у компании скоро «кончатся деньги» и их «скоро купит кто-нибудь».

Давайте посмотрим, что произошло дальше, после первого года?

Парадоксально, возможно, но быстрый рост — не всегда хорошо (хотя слукавлю, если скажу что мне, как сотруднику компании, и владельцу shares, как это сегодня принято во многих американских компаниях, не хотелось бы, чтобы акции стоили побольше). Но и резкое падение — совсем не всегда означает обязательный крах, неудачу, скорое разорение и закрытие. Вот вам еще один характерный пример:

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

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

У Twitter в долгосрочной перспективе курс вообще никогда не рос, и практически линейно снижался прямо с самого момента размещения акций на бирже. И вы не живете в Америке, если скажете, что сегодня Twitter — не влиятельная и не успешная компания в глобальном масштабе. И такие примеры существуют еще.

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

Так что, накануне отчета за наш третий квартал, заканчивающийся вот-вот, давайте наберемся терпения, и сперва посмотрим, как закончится наш первый год в статусе публичной компании. И, нет, «не дождетесь» (с). ;)

Nutanix Acropolis Hypervisor best practices — на русском

Мы закончили перевод одного из наших документов серии Best Practices:
Nutanix Acropolis Hypervisor Best Practices (BP-2029) по самой свежей версии AHV, v5.0
Извольте знакомиться и пользоваться в работе.

Nutanix AHV Best Practices BP-2029 v.3 RUS

Nutanix Acropolis AHV BP v3.0 RUS

OCS и ОЛЛИ внедрили решение на Nutanix в автодилере Inchcape

Пресс-релизов вам в ленту. :) На этот раз новость от нашего дистрибутора — OCS, и его партнера «ОЛЛИ Информационные технологии», которые завершили сделку с крупным международным автодилером в России — Inchcape.

http://www.ocs.ru/PressCenter/PressReleases/2709/

«Компания Inchcape, дилер автомобилей BMW, MINI, Rolls-Royce, Volvo, Land Rover, Jaguar,Toyota, Lexus и Audi, переводит свою ИТ-инфраструктуру на гиперконвергентную платформу Nutanix.

Inchcape

В Inchcape длительное время использовалась классическая ИТ-инфраструктура, состоящая из серверов, СХД и сети SAN. Со временем она устарела и перестала устраивать по своей производительности и функционалу. В компании стали готовиться к замене оборудования и внимательно изучили современные альтернативы. Покупка новой СХД и серверов не совсем устраивала руководство ИТ, т.к. это означало высокие финансовые и ресурсные затраты. Требовалось разработать архитектуру решения, заменить все оборудование, обновить  SAN, выполнить миграцию, переобучить персонал и т.д. Для более долгого использования оборудование, пришлось бы выбрать более дорогие модели с запасом по производительности.

Специалисты компании «ОЛЛИ Информационные технологии», ведущего системного интегратора Северо-Запада, в результате консультаций с представителями Inchcape порекомендовали рассмотреть альтернативные варианты и обратить особенное внимание на гиперконвергентные решения. В результате, компанией Inchcape были тщательно изучены несколько конкурирующих систем. Одна из них не проходила по функционалу, другая – по стоимости. Наиболее подходящей была признана система Nutanix, модель NX-1465-G5. Эта модель, состоящая из четырех узлов, образующих единый кластер, включает в себя одновременно серверы, СХД и SAN, и занимает всего 2U в стойке. Поставки оборудования осуществила компания OCS Distribution.

Представители Inchcape отмечают: «Мы теперь можем не думать об устаревании оборудования и ограничениях по росту. Поскольку это программно-определяемое решение, то даже через несколько лет мы сможем получать новый функционал простым обновлением ПО. А сам кластер с нынешних четырех узлов можно масштабировать практически бесконечно. И через 5 лет нам не придется думать о переезде со старой СХД на новую. Мы просто будем добавлять новые узлы по мере необходимости, а физически изношенные выводить из эксплуатации без остановки сервисов. Нам также очень понравилась простота развертывания кластера Nutanix. Очень важный момент, что с момента распаковки оборудования до запуска приложений прошло всего три часа. Это фантастический результат! Виртуальные машины быстро мигрировали на новую инфраструктуру при помощи vMotion. Приложения работают быстро, в два раза сократилось время бэкапа, значительно упали задержки на дисковой подсистеме».

Высокая производительность системы достигается за счет того, что данные хранятся и обрабатываются на одном сервере. Кроме того, каждый узел Nutanix содержит как минимум один SSD, на котором хранятся «горячие» данные. Благодаря этому даже гибридная система работает практически так же быстро, как All-Flash сервер. А для экономии места на дисках возможно включение компрессии и дедупликации данных.

В настоящий момент Inchcape перевел на гиперконвергентную инфраструктуру терминальные сервисы, телефонию и почту. В планах компании на эту платформу и все бизнес приложения – 1С, SAP, базы данных и т.д. Встроенная репликация (как синхронная, так и асинхронная), позволит надежно защитить все критичные данные компании.»

Сколько в мире сегодня «гиперконвергентных решений»?

Наш коллега в своем блоге делает подсчеты и собирает индекс «гиперконвергентных решений», существующих на сегодня. У него получилось 34 (Тридцать Четыре!) продукта, без учета выбывших и «слившихся» с другими.
Конечно, добрая половина там — компании «ниже горизонта», не уверен даже что у них вообще есть хоть какие-то продажи, но сам факт!
В этом списке огромный диапазон компаний, от HP и EMC, до, например, QNAP и Promise. Поистине, сегодня гиперконвергенция — самая горячая тема в IT.

http://bythebell.com/2016/01/hyperconverged-players-index.html

Чем отличается SAN СХД от Nutanix?

После публикации о том, что в самой старшей модели, NX-8150, официально появилась поддержка 40GbE, стали часто задавать вопрос: «А почему нельзя заказать 40GbE и для остальных нод?» И для ответа надо немного более подробно рассказать о том, как именно работает устройство распределенного кластера Nutanix с точки зрения хранения данных, и почему нам не настолько важны «толстые» интерфейсы, особенно на не супермощных нодах-серверах.

Представим себе условную инфраструктуру, состоящую из 6 серверов, и SAN СХД. Допустим, для простоты иллюстрации, что на каждом из шести серверов работает прикладная задача, генерирующая около 2000 IOPS дискового трафика. Все эти серверы включены в SAN, и туда же включена и СХД.

Как мы видим на рисунке выше, это будет означать, что для обеспечения этих 2000 IOPS на каждом сервере, наша СХД будет должна обслужить и выдать 12 тысяч IOPS дискового трафика (без учета RAID penalty!). И чем больше будет становиться подключенных серверов, тем выше будет на нее нагрузка. Для такой СХД разумеется потребуется достаточно «толстый» интерфейс, иначе однажды серверы не смогут «протолкнуть» с СХД необходимый им трафик. В конечном счете производительность серверов будет определяться производительностью интерфейса к СХД и производительностью самой СХД, нагрузка на которую будет расти линейно увеличанию серверов или с ростом дискового трафика задач.

Другая ситуация в случае распределенного кластера хранения на Nutanix.
Представим такую же точно ситуацию, 6 серверов-нод, на каждом по 2000 IOPS. В отличие от «классической» SAN-инфраструктуры, у Nutanix нет единой консолидированной СХД, пространство хранения локально для каждой задачи, плюс каждая нода кластера хранит какую-то часть избыточных блоков. Избыточные блоки пересылаются на другие ноды с помощью канала 10GbE. Но этот канал не используется для доступа к дисковым данным у этого нода-сервера!

Каждый локальный диск отдает свои 2000 IOPS, что для современных SSD, совсем немного, и, при необходимости, может отдать и больше. Причем при увеличении инфраструктуры и добавлении еще серверов-нод, перегрузки какого-то отдельного компонента трафиком не возникает.
Вот здесь и кроется основная особенность распределенного хранилища Nutanix, вот почему нам не нужны на любой ноде сверхтолстые интерфейсы. Мы просто не гоняем по ним (весь) трафик. Да, бывают ситуации, когда толстый интерфейс нужен. Но это означает, не только то, что нода сама по себе высокопроизводительная, но и что задача на ней способна такой канал загрузить (прежде всего извне).

Давайте рассмотрим два крайних случая использования распределенного хранилища на шести нодах, по 2000 IOPS каждая: 100% чтение и 100% запись.
При 100% чтении все блоки данных будут читаться с локального хранилища, и межнодового трафика не будет практически совсем. Каждая нода дает 2000 IOPS и все.
Теперь наихудший с точки зрения межнодового трафика случай, 100% запись. При этом, как вы помните, каждый блок пишется локально, плюс, для избыточности, каждый этот блок записывается рандомно в одной или двух копиях, на одну или две ноды.

При этом вариант каждая нода пишет 2000 IOPS своего трафика, плюс 1/5 или 2/5 (в зависимости от RF=2 или RF=3) от этого трафика операций записи «чужих» блоков с пяти оставшихся нодов. В нашем случае это 2000+400 или +800 IOPS. То есть даже в наихудшем случае 100% рандомной записи, дисковый трафик на каждой ноде кластера не превысит 2400 или 2800 IOPS. Причем, отметьте, при увеличении числа нодов, эта «прибавка» будет падать, так как она будет размазана на все большее число нодов равномерно.
В реальной жизни, где объем трафика записи обычно ниже объема трафика чтения, значение прибавки в «1/5» в данном случае будет даже меньше.

Как совершенно справедливо заметил в комментариях один из читателей, написанный выше расчет относится к варианту, когда из 6 нод только одна делает 100% write, а остальные — read. В случае же, когда ВСЕ ноды делают 100% write (для простоты расчета возьмем, что все ноды делают равное число операций ввода-вывода), то наихудший случай даст нам на ноде 2x local IOPS. 2000 своих, плюс пять оставшихся нод пришлют нам на запись по одной пятой своих копий блоков, итого 4000 IOPS для RF=2 и 6000 для RF=3.

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

Практический пример?
Воспользуемся нашей демо-системой на demo.nutanix.com
Вот как выглядит ее загрузка на дашборде:

Как видите, 70 тысяч дисковых IOPS-ов на 4 нодах и 22 VM
Посмотрим, что делается при этом на сетевых портах нод и коммутаторе. Воспользуемся нашей новой фичей, Network Visualization:
Вот выше пример на одной ноде (на остальных трех ситуация аналогичная, трафикогенерирующие VM разбросаны по ним равномерно). Три-шесть мегаБАЙТА в секунду даже в пике!

А вот — статистика с порта коммутатора, соединяющего ноды вместе в кластер. Тоже семечки для 10GbE коммутатора, меньше миллиона пакетов в пике на порт.

Вот такие вот причины, почему Nutanix не требуется использовать суперинтерфейсы для получения его огромной производительности.

UPD: Поправки, на которые обратил мое внимание в комментариях к посту коллега Nickolay.

SimpliVity теперь в HPE. Что дальше?

Я никак не комментировал эту новость, когда она появилась в январе. Но теперь, когда сделка официально закрыта, и наш конкурент, SimpliVity (SVT) теперь официально стал частью HPE, думаю, стоит сказать несколько слов по этому поводу.
Несмотря на то, что SVT много лет была нашим крупным и важным конкурентом в HCI (Hyperconverged Infrastructure), по крайней мере на американском рынке и в сегменте SME, я старался в этом блоге, когда писал о них, соблюсти нейтральность и минимум предвзятости. Это была компания, вместе с Nutanix начавшая развитие гиперконвергентного рынка простым стартапом, и довольно неплохо державшаяся все это время (собственно та активность, с которой мы в Nutanix их «мочили» иногда, этому основная причина).
Однако, Nutanix вышел на IPO, а SimpliVity куплена «грандом» серверного энтерпрайз рынка, причем куплена, в результате, за сумму существенно меньшую ее оценки, за 650 миллионов $, что почти втрое ниже оценки. Факт этот свидетельствует, что на IPO с такой разницей в оценке и реальной стоимости SimpliVity ничего «не светило».

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

Вообще, HP/HPE компания любящая покупать продукты вместе с компаниями. Однако судьбы разработок таких компаний внутри HP бывают очень разными. Иногда они «расцветают», получая ресурсы такого гиганта, как HP, пример тому — судьба 3Par, который, до покупки в HP прямо скажем «влачил существование», и получил настоящее «второе дыхание» в HP, сменив, наконец, хороший, но безнадежно морально устаревший к моменту покупки midrange enterprise storage HP EVA.
Бывает и по другому, мало кто помнит уже такие имена как IBRIX или PolyServe, компании, разрабатывавшие эти продукты также были в свое время куплены HP, и «канули» словно бы в никуда. Возможно частично какие-то разработки вошли в какие-то другие проекты, но это со стороны не столь очевидно.
Наконец, какие-то продукты ждет стангнация, пример — купленный в 2008 году LeftHand, пару раз переименованный, но так никогда и не заблиставший на рынке, по своему интересный SDS-продукт, так толком за эти уже почти 10 лет и не «распробованный» рынком, и оставшийся в «нише». И даже вся маркетинговая и финансовая мощь HP не смогла его как следует «раскрутить». Даже сегодняшние попытки сделать из StorVirtual «гиперконвергентность» достаточно вялые, вон, у HPE теперь новая большая игрушка, Synergy.

Что суждено SimpliVity, успех, забвение или стагнация сейчас совершенно неясно.

Успех 3Par был обусловлен, как я уже отметил, тем, что он пришел на нужное место в нужное время. Менять в линейке продуктов устаревающую EVA на момент покупки 3Par было надо уже «пожарным порядком», «плана Б» на этот счет у компании просто не было. Polyserve покупался тогда, «чтобы врагам не достался, а дальше придумаем куда». С LeftHand, классическим Software-defined Storage, и на момент разработки весьма пионерским (в хорошем смысле) продуктом, получилось не так. Его, кажется, так и не придумали куда «подоткнуть» в линейку. За ним явно не было какого-то сильного «драйвера» в компании.

SimpliVity, как я уже отмечал в более ранних постах о этой компании и ее продукте, последние год-полтора явно страдала от недостатков ресурсов на разработку. Задержки с выпуском продукта, отсутствие серьезных инноваций от версии к версии, история с поддержкой (читай: ее отсутствием) других гипервизоров, кроме ESXi, явно наталкивали на мысль, что в компании просто заканчиваются ресурсы. Обычно в этом случае компания как раз и идет на публичный рынок, выпуская акции, и собирая нужные для дальнейшего развития деньги таким образом (если она желала бы остаться независимой), либо «продается» большому игроку. До «планки» IPO SimpliVity явно «не дотягивала» (это даже и Nutanix далось нелегко в прошлом году, не зря мы столько «высиживали» этот момент), поэтому покупка «грандом» для SVT был вполне разумный, и объективно необходимый шаг дальнейшего развития.

Однако, если вы следите за ее судьбой, вы знаете, что за последний год SimpliVity очень успешно продавала себя как OEM-решение. Многие серверные вендоры имели с SVT соглашение по выпуску их OmniStack на своем «железе». Cisco, Lenovo, Huawei, даже Dell объявляли о OEM-выпуске SimpliVity на своем серверном железе. Сейчас, очевидно, всем этим продуктам настал EOL. Ясно, что никаких «OEM» HPE на рынке не потерпит. Не для того покупали.
Особо «попали» тут купившие, возможно только вот-вот, такой OEM-SimpliVity клиенты. Они останутся, во-первых, с той версией ПО, которая у них есть, сейчас это 3.5. Во-вторых, вероятно, поддержка таких oem-SVT станет в перечисленных компаниях-бывших партенрах SVT весьма «базовой», как для любого другого EOL-продукта.
В HPE SimpliVity поддерживается только на платформе HPE ProLiant DL380, и пока только на нем. Никаких планов о поддержке «сторонних» вендоров не публиковалось.

Как вы знаете, «интеллектуальное ядро» SimpliVity как продукта — его плата аппаратной дедупликации, вокруг которого, собственно, и «наросла» гиперконвергентность OmniCube как продукта. Однако, почти сразу же за покупкой HPE объявила о том, что намерена отказаться от FPGA-based OmniCube Accelerator Card, и сделать продукт полностью «софтверным».
Это, среди прочего, означает, серьезные изменения в архитектуре, уйдут самые опытные члены инженерной команды SVT, стоявшие у колыбели продукта, бохзнает что еще.
HPE собирается также прекратить разработку и использование основного на сегодня инструмента управления, Simplivity vCenter Management Plug-In, и перейти на HP OneView. Кроме того, есть признаки того, что HPE вообще скептически и без особого понимания смотрит на HCI как таковой, и не исключено, что речь идет о переделке SimpliVity в просто еще один SDS для их новой дорогостоящей разработки — HPE Synergy. «…including tight integration with HPE’s OneView management platform. HPE also plans to integrate the SimpliVity software with HPE Synergy and 3Par.»
Явно в HPE сейчас идет сложная политическая игра между несколькими «партиями», и от того, кто выиграет, «пргрессисты» или «традиционалисты-консерваторы» будет зависеть судьба продукта в компании. Пример медленной стагнации в нише и на периферии интересов у нас уже есть, как я показал выше.

При этом надо также понимать, что внутри HPE уже есть как минимум целых два собственных продукта того же класса, это разработанные самой HPE HC250 и HC380, которые, что интересно, будут продолжать предлагаться, по крайней мере пока: «For current HPE customers and partners, we will continue to offer our existing hyperconverged products, the Hyper Converged 380 and the Hyper Converged 250 and provide a pathway to the SimpliVity based-offerings.» по меньшей мере еще квартал.
Не исключено, что «новичку» в компании придется столкнуться еще и с «внутренней конкуренцией». Синдром «Придумано не нами» (NIH, Not Invented Here) может ударить по продукту в HPE довольно болезненно.

Ясно одно, даже в идеальном случае, дальнейшая разработка продукта задержится минимум на год, а то и меньше, на время слияния и организационных «утрясаний». А в нашей области, где год-два это целое поколение продуктов, и с учетом того, что SVT уже и без этого начинала отставать, это может быть катастрофой.

Таким образом, у приобретения HPE есть и некоторые плюсы, и существенные минусы. Ситуация с SimpliVity как продуктом в компании мне видится крайне неустойчивой и неясной. Думаю, что следуюший квартал-два раставит все по местам, и позволит понять, какая судьба ждет SVT в составе их нового «дома».

UPD: Из свежих новостей: HPE купил еще и Nimble Storage, вошел во вкус. ;)

Результаты первого полугода «публичности» в Nutanix

Итак, закончился второй квартал, для нас, как для публичной компании, это время (и обязанность) опубликовать отчеты о проделанной работе. Делать Nutanix это будет теперь регулярно. Вот так выглядит текущее состояние компании сегодня:

17q2 nutanix results

О пользе точной настройки перед проведением performance tests на Nutanix

Немного интересного о том, насколько важно для получения хорошего результата правильно и грамотно конфигурировать систему (а не просто поставить ее потыкав Enter и «Далее»), руководствуясь нашими Best Practices.

Нак коллега из Германии поделился своим опытом:

«Доброе утро. Хочу с вами поделиться результатами тестирования, которые хорошо иллюстрируют важность использования наших best practices.

Я запускал бенчмарк на MSSQL с использованием HammerDB. Использовался AOS 5 на AHV на 3x NX-3175-G4. CPU на 2.6 Ghz (2x 10 core) и каждая нода имела 692 GB RAM. Диски: 2x 1.5 TB SSD и 2x 2TB HDDs.

Все VM были созданы из шаблона Windows 2012 R2 x64 со всеми сежими патчами, VM имела 1 сокет и 8 виртуальных ядер, а также 64GB vRAM.

Я создал VM с SQL Server установленным по умолчанию (просто приняты все значения установки по умолчанию, просто жал «next» всегда), и база была поставлена на виртуальный диск, размером 1TB в контейнере по умолчанию.

Я также создал одну VM с SQL установленным и настроенным в соответствии с нашими best practices. Контейнер имел включенную inline compression, для базы созданы несколько виртуальных дисков, настроены параметры SQL Server, установлены trace flags, large pages, database memory allocation, и так далее.

Затем я установил HammerDB и выполнил транзакционный тест (TPC-C) с 40 пользователями и 254 warehouses, что, в общем, довольно невысокое число последних.

Так выглядел запуск теста на неоптимизированном сервере SQL. Мы получили примерно 90K transactions per minute, и уперлись в CPU.

А это тест на оптимизированной VM с SQL. Мы получили тут более миллиона транзакций в минуту, и все еще не уперлись в CPU.

В обоих случаях, OS и базовая конфигурация VM были идентичны, различалась только конфигурация контейнера, были добавлены дополнительные диски в VM, и были сделаны настройки базы данных. Подсистема хранения не была слишком нагружена, она выдавала всего около 4800 IOs или 290 MB/s.

Мне показалось, что вам будет интересно посмотреть на результаты. Возможно это также будет полезно показать пользователям, если заходит разговор о производительности базы данных на Nutanix.»

Итак, просто за счет более правильной настройки VM для работы в Nutanix, получен двенадцатикратный прирост ее производительности.

Nutanix в новостях: ГК Ангара

Я всегда стараюсь отлавливать публикации о внедрениях Nutanix, появляющиеся в российской компьютерной прессе. Увы, на десяток внедрений нам удается едва ли одну компанию уговорить опубликовать новость об этом. И вот — один из примеров публичной новости. В компании Ангара работает кластер из 4 нод модели NX-6155.

http://www.cnews.ru/news/line/2017-02-07_angara_priobrela_giperkonvergentnoe_webscale

www.angaratech.ru

Интеграция Nutanix AHV в vRealize Automation 7.x

Интересное видео, показывающее интеграцию гипервизора Nutanix AHV в среду управления vRealize Automation 7.
Это возможно, и сравнительно несложно, используя наш RESTful API, подробнее — в видео:

Кроме этого следует упомянуть, что у нас есть и свой собственный «портал самообслуживания» (SSP, Self-Service Portal), встроенный в Acropolis.