Архив за месяц: Апрель 2017

Как дела у 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.