Архив рубрики: запоговорить

Как дела у Nutanix: итоги года и почему «успех» не всегда «прибыльность»

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

Итак, 30 сентября компании исполняется год, как мы вышли на биржу, проведя IPO и став с этого момента Public Company. Это и достижение, и ответственность, так как с момента выхода на биржу компания обязана публиковать полную отчетность, все ее финансовые результаты должны быть публично доступны и открыты.

Однако, в отличие от США, «игра на бирже» по-прежнему не является сколь-нибудь массовым занятием, поэтому, как правило, представления многих моих читателей о том, как происходит биржевая игра и вся прочая активность вокруг акций, их курса и финансовых результатов публичных компаний, находятся на довольно примитивном уровне века этак XIX примерно. Я уже писал немного на тему того, что курс акций совсем не всегда и не напрямую, и не линейно связан с успехом компании. Позволю себе поговорить на эту тему еще раз.

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

Но для начала давайте посмотрим, как обстоят дела с прибылью у Nutanix по результатам годового отчета. Напомню, мы закончили год в конце июля, так как FY, Financial Year, в США принято завершать летом.
Спасибо комментатору Сергею, который извлек из отчета эти данные за меня:
Net Loss: GAAP net loss of $458.0 million, compared to a GAAP net loss of $168.5 million in fiscal 2016; Non-GAAP net loss of $199.1 million, compared to a non-GAAP net loss of $150.4 million in fiscal 2016

GAAP, напомню, это Generally Accepted Accounting Principles, некий общепринятый стандарт бухгалтерского учета. Особенности США как страны заключаются в том, что там кроме GAAP существует (и общепринят) и другой способ «подсчета денег», он обозначается как non-GAAP, и поэтому в финансовой документации публичные компании приводят как GAAP-результаты, так и non-GAAP. Не будем сейчас углубляться в детали того, в чем состоит разница, как мы видим, и в том и в другом случае Nutanix пока, формально, согласно приведенным в отчете данным, не вышел на зарабатывание денег и «приносит убытки», по крайней мере владельцы акций дивидентов по ним не получают. Оставим сейчас в стороне вопрос, часто ли вообще в Америке получают дивиденты по акциям высокотехнологичных компаний (ответ:нет, не часто). Посмотрим, бывает ли, чтобы компании, в том числе публичные, вели бизнес принося убытки, и насколько долго.

Рассмотрим такую, всем известную компанию, как Amazon (NASDAQ:AMZN). Компания Amazon была основана Джеффом Безосом (Jeff Bezos) в далеком 1994 году, в мае 1997, три года спустя, она вышла на IPO, и с тех далеких пор, вот уже 20 лет является общеизвестной компанией, причем не только в области интернет-торговли, но и, например, является крупнейшим в мире публичным облачным провайдером, под торговой маркой AWS, Amazon Web Services. Услуги облачного провайдинга, насколько мне удалось узнать, также являются частью общей компании Amazon, и учитываются в ее финансовом отчете.
Никто не будет спорить с тем, что Amazon — успешная компания.
Но как обстоят дела с их прибыльностью, и вообще, когда Amazon начал приносит прибыль?

Оказывается, первый прибыльный год, согласно найденным мной данным, был аж 2003-й, то есть спустя 9 лет с момента основания, и спустя 6 лет с момента IPO! Все это время компания наращивала объемы, но прибыли не получала! Тем не менее, сложно было бы назвать Amazon компанией «неуспешной», несмотря на такую ситуацию с прибылью (кстати и после 2003 года у Amazon не раз были убыточные кварталы и даже года).

А вот как выглядела стоимость их акций в этот период:

До помеченной вертикальным пунктиром линии Amazon денег в прибыль не зарабатывала. Вообще. Да, в «пузырь 2000-х» акции успели подрасти, потом, как все, упали. Потом понемножку дорожали, например от декабря 2000 года, когда взрыв «пузыря» практически закончился, и курсы упали на стабильное значение, и до декабря 2006-го, до того, как начался существенный и значительный рост курсов акций Амазона, продолжающийся до сих пор, курс вырос с примерно 15 долларов за акцию до примерно 40, и это — за 6 лет, половина из которых шла полностью в убыток. Убила ли эта ситуация компанию Amazon? Очевидно что — нет. Напомню, что сегодня акции AMZN котируются на уровне близком к 1000$ за акцию, тогда как цена размещения их в далеком 1997-м году была где-то 1.5$, а Джефф Безос из своих личных средств, которые ему дает владение акциями Amazon и периодическая продажа их, строит ракеты для космического туризма в компании Blue Origin.

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

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

Вот это — уровень выручки и уровень прибыли для компании Amazon от ее основания:

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

А так выглядит график отношения Free Cash Flow (FCF) и Operational Cash Flow (OCF) к revenue (выручке) компании:

Как вы видите из графика, величина FCF в среднем составляет около 5% от выручки, с момента появления прибыльности, а OCF — постоянна и весьма невелика.
Причем в 2003-м, первом своем прибыльном году, Amazon заработала всего каких-то 35 с небольшим миллиона долларов чистой прибыли!
И тут еще надо учесть, что, например, AWS до 2012 года вообще была невыделенной частью Amazon, но даже и сейчас доходы ее (а AWS — очень прибыльный для компании бизнес, утверждается, что больше половины операционной прибыли Amazon приносит AWS) очень существенная доля доходов компании в целом.

Единственный ли это пример? Нет, конечно. Еще один лежащий на поверхности пример — небезызвестная Tesla. Компания главного «железного человека» Америки не приносит прибыли много лет. В отдельные кварталы компания показывает прибыль, но стабильной прибыльности у нее не было никогда. Из трех основных активов Маска, Tesla Motors, SpaceX и SolarCity, только Tesla — публична, однако по всем трем компаниям оценка аналитиков сходна, все три убыточны. Убыточны, также, например, такие «громкие» компании как Uber и Lyft. Да и вообще, есть такое ощущение, что прибыльность, по крайней мере среди сегодняшних «компаний новой экономики», хайтек и IT, это скорее исключение, чем правило, по крайней мере в первые годя их существования и выхода на рынок.

Плохо это или хорошо? Конечно же, в идеальном мире самое лучшее было бы, чтобы компании приносили прибыль, платили своим акционерам дивиденты, а по радуге бы скакали белые пони. Увы, мы живем в мире, в котором корпоративный налог на начисляемые дивиденты составляет в США 30%, что означает, что треть передаваемых на выплату дивидентов денег забирает себе правительство. Последнее и заставляет многие компании вместо показания прибыли и, следовательно, выплаты дивидентов акционерам, тратить заработанное в виде само-инвестиций в развитие компании. В суперконкурентном мире хайтека, получить на развитие на 30% денег больше — зачастую критически важно. Это, например, одна из причин, отчего тот же Nutanix вместо выхода на прибыль пока не торопится показывать положительный баланс. Пример Amazon показывает нам, что жить так можно буквально десятилетиями.
Биржа и мир бизнеса уже давно не так линейны и просты, как в XIX веке, когда есть прибыль — хорошая компания, нет прибыли — плохая. Растут цены за акции — хорошо. Падают — плохо. Сегодня, как видите, ситуация куда сложнее, чем то, к чему мы привыкли знать «про биржи и капиталистов» по книжкам времен Маркса, Диккенса и Драйзера.

Итого, о чем я, в результате хотел сказать-то:
Не пытайтесь делать далеко идущие предсказания, не владея в полном объеме картиной, и не ориентируясь свободно в сегодняшней фондовой и инвестиционной жизни США. Не торопитесь обещать разорение, исходя лишь из вашего скромного опыта владения ценными бумагами в виде ваучеров приватизации 90-х (а для большинства из нас опыт владения ценными бумагами ими и ограничивается). Сегодняшняя жизнь бирж и хайтек-компаний куда сложнее и непредсказуемее.
И значит, господа злопыхатели и предсказатели, поход на помойку за стеклотарой откладывается. :)
Удачи нам, и, конечно, скорейшего выхода на прибыльность. А когда это будет, как выражаются по российскому телевизору, «покажет время».

PS. Пользуясь случаем, хочу отдельно напомнить моим читателям, что в блоге действует возможность писать комментарии без регистрации, однако для автоматической публикации их требуется иметь уже заапрувленные комментарии раньше. Первый коммент с данного IP, с данным именем и E-Mail ставится в очередь на модерацию. Кроме того, посты, имеющие явные признаки спама, автоматически уходят в спам. Я, как хозяин и владелец этого блога, решил, что буду требовать от желающих публиковать комментарии, соблюдения простых требований: подписывайтесь своим именем, либо ником, и используйте реальный email, указав его в соответствующем поле формы коммента (он не публикуется, его вижу только я). Отсутствие имени или ника, а также указание заведомо недействующего email приводит к блокировке вашего коммента антимспамными средствами блога (у меня тут примерно по пять сотен спама в комменты пытается запоститься каждую неделю, на разные темы, вы не хотите это читать ;). Я полагаю, что человек, который хочет опубликовать свое мнение в комментариях, не должен стесняться подписать свое мнение своим именем, тем самым беря на себя ответственность за высказывание. Иначе, скорее всего, писать его не стоит вовсе.

1242 страницы качественной бумаги

Книга, озаглавленная «Storage Design and Implementation in vSphere 6». 1242 страницы. Второе издание. Тысяча двести сорок две, my ass! Только про то, как правильно подключить к серверу и настроить СХД.

Мы, в Nutanix, в конечном счете, работаем в том числе и для того, чтобы такие книги стали, наконец, админу не нужны.

Как дела у Nutanix?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, вошел во вкус. ;)

О пользе точной настройки перед проведением 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, получен двенадцатикратный прирост ее производительности.

История двухлетнего опыта использования ceph в веб-хостере и полученный опыт.

Интересный пост на Хабре, описывающий опыт веб-хостера FirstVDS в его попытках сделать кластер на ceph, и честное описание всех значительной части проблем, которые они хапнули в процессе. Полезное и душеспасительное чтение для всех, кто рассматривает ceph как enterprise-grade решение.
Вкратце, бегло о lessons learned:

* Процесс «выучивания уроков» занял примерно два года, на сегодняшний день. Первая версия была собрана осенью 2014 года.

* Не все x86 сервера «одинаково полезны». Купленные специально под кластер сервера оказались глючными.

Чтобы опробовать новую архитектуру и избавиться от прежних недостатков, собрали тестовый стенд. И тут выяснилось интересное — специально купленные для сборки первой версии серверы оказались «палёными». Системная шина всех серверов работала медленно. В результате, все устройства, связанные с северным и южным мостами — карты IB, подключенные по PCI-E, диски, память — также работали медленно. Это объясняло большую часть проблем, с которыми мы столкнулись. В качестве пробы взяли несколько свободных нод, на которых обычно запускаем клиентские VDS. По тех. характеристикам они почти ничем не отличались. Собрали и запустили кластер на этих машинах, стали прогонять тесты. Всё летает! … купили новые серверы на базе Xeon 2630 …

* Далекая от оптимальности схема восстановления избыточности в ceph, требующая ручной регулировки.

Кластер справлялся с задачами — при выходе из строя дисков или нод целиком, он продолжал функционировать. Однако, каждая перебалансировка превращала ситуацию в критическую. При добавлении нового диска сглаживали пик нагрузки, используя веса. Вес отвечает за степень использования конкретного физического носителя. Устанавливаем новый диск, ставим вес 0 — диск не используется. После этого увеличиваем вес постепенно, и перебалансировка происходит маленькими порциями. Если же диск выходит из строя, то веса не срабатывают: ~1 Тб реплик надо «размазать» по оставшимся дискам сразу, и Ceph надолго уходит в режим записи данных, загружая диски «пустой» работой.

* Перестроение кластера ceph на ходу вызывает существенную нагрузку на серверы и влияет на нормальную работу приложений

* Для построения в чистом виде гиперконвергентной системы, когда одни и те же сервера являются и узлами хранения и хостами виртуализации, ceph оказался малопригоден.

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

* Несбалансированная система с купленными «для экономии» дисками SATA большой емкости стала проблемой при увеличении нагрузки.

* Сетевая распределенная запись на хранилище, без data locality, одновременно с высокой загрузкой кластера по вводу-выводу — зло.

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

Около 5-ти месяцев система замечательно работала, радуя нас и клиентов. Так было, пока количество клиентов не достигло критического значения. Вместительные диски по 4-8 Тб всё-таки вылезли нам боком. При заполнении диска уже наполовину, он превращался в бутылочное горлышко — большое количество файлов, принадлежащих разным VDS, располагались на одном физическом носителе, и ему приходилось обслуживать большое количество клиентов. При выходе его из строя перебалансировка тоже проходила тяжело — надо перераспределить большой объём информации. SSD-кэш в таких условиях плохо справлялся со своими обязанностями. Рано или поздно диск кэша переполнялся и давал сигнал — с этого момента я ничего не кэширую, а только записываю сохраненную информацию на медленный HDD-диск. HDD-диск испытывает в это время двойную нагрузку — обрабатывает прямые обращения, которые поступают минуя кэш, и записывает сохраненные в кэше данные. Хранилище хорошо работало, пока дело не доходило до изменения дисковой конфигурации. Выпадение диска или добавление нового сильно замедляло общую пропускную способность хранилища.

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

Используйте LTS-выпуски Ceph. Не рассчитывайте, что будете накатывать новую версию с каждым релизом. Обновление — потенциально опасная операция для хранилища. Переход на новую версию повлечёт изменения в конфигах, и не факт, что хранилище заработает после обновления. Отслеживайте багфиксы — они бэктрекаются из новых версий в старые.

* Баги могут уничтожить как работу кластера в целом, так и содержимое хранилища.

18 февраля 2016 мы столкнулись с критическим багом Ceph: в процессе скидывания кэша на диск происходила некорректная запись блока данных. Это приводило к отключению процессов ceph-osd всех дисков, где хранились реплики злосчастного блока. Система сразу лишалась трёх дисков, а значит и всех файлов, размещенных на них. Запускался процесс перебалансировки, но не мог завершиться до конца — ведь из системы пропадали все три копии как минимум одного блока данных (и соответствующего файла), с которого началась проблема. Консистентность хранилища была под угрозой. Мы вручную удаляли ошибочные блоки, перезапускали процессы ceph-osd, но это помогало ненадолго. Ошибочная запись повторялась, балансировка начиналась снова, и хранилище рушилось. …
Напряженный поиск в интернете дал результат — закрытая бага в последнем на тот момент релизе Ceph Hammer. Наше хранилище запущено на предыдущей версии — Firefly.
Предупредили клиентов о недоступности серверов и приступили к обновлению. Переключились на другой репозиторий, в который залит фикс баги, выполнили yum update, перезапустили процессы Ceph — не помогло. Ошибка повторяется. Локализовали источник проблемы — запись из кэша в основное хранилище — и отключили кэширование полностью. Клиентские серверы заработали, но каждая перебалансировка превращалась в ад. Диски не справлялись с обслуживанием системной балансировки и клиентского чтения-записи.
Решили проблему кардинально — отказались от SSD-кэша

* Для полноценной работы кластера ceph требуется allflash конфигурация.

поставили SSD-накопители в качестве основных. Тут помогли ноды с большим количеством дисковых корзин, предусмотрительно купленные для кластера хранения. Заменяли постепенно: сначала добавили по четыре SSD в оставшиеся пустые корзины на каждом сервере, а после балансировки данных, стали по одному заменять старые HDD-диски на SSD. Делали по схеме: удаление диска, установка диска, балансировка данных, удаление, установка, балансировка и так далее по кругу, пока в нодах не остались только SSD. Заменяли на горячую …
Использовали промышленные накопители Samsung 810 размером 1 Тб. Не стали использовать SSD большего размера, чтобы не провоцировать ситуацию «узкого горлышка», когда на одном физическом носителе располагается много данных, и, следовательно на него приходится большое количество обращений.
Таким образом, постепенно мы заменили все накопители на SSD. И наступило счастье

Мои выводы (которые могут не совпадать с выводами авторов оригинального поста): ceph в продакшне — опыт для людей с железными яйцами. Скупой платит. И хорошо если только дважды. И тем более хорошо, если только деньгами. Забудьте об отпусках с семьей и отключенном на ночь звонке телефона. Это не для вас теперь.
Зато не скучно. :)

VMware исполняется 17 лет!

Совсем недавно я в этом блоге отметил 60 лет, исполнившихся HDD. А сегодня еще одна важная дата, пусть некруглая, это все равно повод вспомнить, что 17 лет назад была образована компания VMware. Компания, так важно и сильно изменившая наш IT-мир и современные датацентры. Тогда, 17 лет назад, виртуализация и гипервизоры сперва были просто неким забавным способом запустить Linux на Windows, и поиграться с ним на компьютере админа. Сперва это рассматривалось просто возможностью выполнять другую OS на персоналке, например для учебных или тестовых целей. Но прошло совсем немного лет, и стало ясно, что цели у новой компании куда более дальние. Сегодня же виртуализация, на мой взгляд, совершила переворот, сравнимый с приходом «персональных компьютеров» и «серверов стандартной архитектуры» на смену мэйнфреймам, переворот, который осознавался далеко не сразу и не всеми.
Так что не стоит забывать то, что всего 17 лет назад родилась компания, которая эту революцию сделала возможной, и поздравления коллегам из VMware с этой датой!

HDD — 60 лет!

В этот день, 4 сентября далекого, 1956 года, компания IBM представила рынку новое устройство, незамысловато названное IBM 350 Model 1 Disk storage unit (они входили в состав системы, носившей название IBM 305 RAMAC). Устройство IBM 350 имело емкость 3,75 мегабайта, скорость вращения 1200 об/мин. и latency time 1 секунду. Оно стало первым коммерчески доступным устройством хранения информации на пакетах вращающихся магнитных дисков. Кто бы мог тогда подумать, что эти незамысловатые штуки переживут всех своих создателей, а также всех своих ровесников в IT-мире, пройдут такой путь развития и доживут до столь преклонного возраста, до наших дней.

ramac-350

SSD, AllFlash и гиперконвергенция

Несколько новостей этих летних месяцев заставили меня написать такой несколько визионерский текст, с которым, возможно, кто-то будет несогласен. Этим летом как-то врывообразно появилось множество публикаций, посвященных SSD, Flash, да и вообще новым технологиям хранения данных, «поднявшимся над горизонтом». Не секрет, что HDD, «жесткие диски», технология, история которой насчитывает уже 60 лет (!) сегодня довольно очевидно стагнирует. Она развивается несколько последних деятилетий уже просто раз в пару лет удваивая емкость, но ничего не добавляя существенно нового. Достаточно ясно, что сегодня HDD это такие «магнитные ленты», давно остановившаяся в своем развитии технология. Она в целом устраивает всех на своем месте, но уже не являнтся «острием прогресса», обреченная на постепенное проваливание в нишу, где когда-то и утонули «магнитные ленты». Развитие IT идет совсем в другом месте.

Все кто внимательно следят за тем, что происходит в отрасли видят, что сегодняшее острие прогресса — так называемые «твердотельные устройства хранеия». SSD стали уже бытовой повседневностью. Например, пока я писал эти строки, я понял, что у меня, в моем многочисленном домашнем IT-парке (2 десктопа, 3 ноутбука, AppleTV, домашний лаб-сервер, три RaspberryPie-подобных девайса) нет ни одного устройства без SSD, исключая стоящий на полке 4-дисковый NAS Synology где я храню фильмы, музыку и бэкапы. Конечно, не только SSD, не нужно забывать про новое направление использования Flash не в форме «эмуляции диска» (а именно это и есть SSD, по большому счету), но и как нативную память, в форме разнообразных NVMe, NVDIMM, и так далее, но SSD — в первую очередь.
Достаточно посмотреть на то, что все вендоры классических СХД сегодня выпустили свои AllFlash системы хранения, избавившись в них от HDD, и предложив пользователям невиданную ранее с обычными «блинами» производительность и latency.

AllFlash06

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

Возьмем, например, один из самых свежих образцов современных SSD, доступных на массовом рынке, SSD Samsung EVO 950Pro, в формате M.2, с поддержкой NVMe. Это один из самых производительных SSD, и давайте посмотрим, что это значит.
В техспеке для устройства, емкостью 512GB указаны показатели рандомного чтения (random read) блоками 4K при глубине очереди 32 (Q32) и 4 потоках ввода-вывода равные 300K IOPS. Измерения «реальной жизни», проведенные Storagereview.com для 4K aligned read, с использованием IOmeter по их методике, показывают примерно 200K IOPS для величины Outstanding IOs равной 64. Возьмем эту величину за основу.
200 тысяч IOPS рандомного чтения блоком 4Kбайт означают, что поток данных рандомного (!) чтения через интерфейс ввода-вывода с одного SSD емкостью 512GB равен:
200 000 * 4096 = 819 200 000 байт в секунду = 0,763 Gbyte/s = 6,1 Gbit/s
что означает, что один современный высокопроизводительный SSD для кастомерского рынка, при правильном его подключении и использовании, на рандомных операциях сегодня утилизирует полностью интерфейс SATA-3, или же половину SAS-3 (12Gbit/s). Два таких диска, с суммарной емкостью всего в 1TB, забьют собой канал SAS в 12 гигабит в секунду. И это — два диска, сегодня, без учета завтрашнего дня и перспектив NVMe.
Устройства NVMe с легкостью забьют трафиком канал 40G Ethernet.

А уж когда выйдет на рынок 3D Xpoint, который нам уже «вот-вот» обещают Intel с Micron, то ситуация с попыткой использовать сетевые системы хранения с новыми flash-подобными твердотельными устройствами хранения становится окончательно безнадежной.

Flash-vs-Network-Throughput

Нельзя сказать, что в индустрии этого не понимают. Да, уже с самого начала использования Flash, для хранения для решения этой проблемы что-то пытаются делать, прежде всего это попытка реализовать «многослойное кэширование», где одним из слоев был бы Flash, причем, часто, этот flash переносят поближе к серверу. Однако это все были полумеры. Не секрет, что кэширование, в особенности кэширование записи, сильно усложняет логику работы системы, а многоуровневое каскадное кэширование и double buffering еще и пагубно влияет на latency. Вся эта цепочка переливаний данных «из ведра в ведро», последовательно, во все более быстрое «ведро», конечно, на тот момент, было способом решения, но совсем не идеальным. Доступ к данным на flash все еще оставался на порядок медленнее тех скоростей, которые обеспечивал доступ к DDR DRAM (что убивало любую синхронность операций), плюс создавало множественные сложности с организацией доступа. Постепенно становится ясно, что flash, используемая как кэш к хранилищу данным, это не то, что может полностью раскрыть ее потенциал.

Стало видно, что назревает классическая «революционная ситуация», когда пользователи не хотят жить по-старому, а вендоры СХД — не могут жить по старому, и, что еще более важно, не имеют средств и желания это «по-старому» похоронить, просто потому, что СХД, как архитектура и концепция, используемая с flash и flash-подобными устройствами хранения, изжила себя. Для flash сегодня архитектура, при которой данные хранятся «где-то» в одной «кучке», которую мы целенаправленно держим вместе, раздавая множеству потребителей из одного места по одному (двум) проводам, это очевидная «гиря на ноге». Она существовала только потому, что скорость передачи по каналу SAN была заведомо, на порядки быстрее, чем производительность канала к данным на самом устройстве хранения, то есть к диску, и это позволяло загружать канал SAN, агрегируя в нем множество каналов к HDD. Сегодня, когда один SSD с достаточно пустяковой емкостью в состоянии полностью заполнить своим трафиком весь интерфейс от системы хранения к серверу, эта архитектура очевидно изжила себя.

Я не хочу сказать что СХД умрут вот прям завтра. В конце концов, даже уже давно и справедливо похороненный RAID 5 все еще где-то используется, вопреки всем мрачным прогнозам о его неминуемой смерти. Кому-то вполне хватит для его скромных задач дешевой полочки с 12 дисками SATA, подключенной по 4G FC. Такие пользователи есть, тысячи их.

Но если мы смотрим в будущее, и если нацеливаемся на максимумы производительности, которые может дать нам сегодняшняя технология, то СХД в этом будущем места нет. Они обречены угаснуть как угасают все старые и пережившие свой век технологии, как память на ферритах, или накопители на магнитной ленте, когда-то бывших символами «ЭВМ». Так и шкафы с моргающими рядами лампочек на стоящих рядочками жестких дисках последуют за ними. В будущем, если сохранятся нынешние тренды, а я не вижу, отчего бы им не сохраниться, СХД, как некоему отдельному устройству, где стоят все наши жесткие диски, отдающиеся потом по сети потребителям, этим устройствам в будущем места нет.
Единственный способ эффективно использовать новые методы хранить данные — хранить их максимально близко к CPU и RAM, в идеале — на той же шине, обеспечивая максимально короткий путь между «устройством хранения» и «устройством обработки» этих данных. И это именно то, чем сейчас занимается Nutanix и вся наша гиперконвергентная тусовка из десятка молодых вендоров.

Вот почему, как мне кажется, гиперконвергентность и AllFlash — «созданы друг для друга», и именно сюда, в направлении архитектурного объединения «дисков» и «CPU» будет расти индустрия систем хранения, если она рассчитывает в самом деле использовать все потенциальные возможности будущих устройств хранения, в особенности SSD и NVMe.