Архив рубрики: whoiswho

Кто есть кто в компании и продуктовой линейке

VSAN: facts to know

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

Ранее, в публикациях про VSAN я уже упоминал тот факт, что, согласно документации VMware, объем кэша записи (спасибо за важную поправку Nikolay из комментов) дисковой группы для ноды в VSAN ограничен емкостью в 600GB, что, явно, выглядит недостаточным даже для современных емких SSD, таких, как наши 3.8TB, и уж точно мал для ожидаемых в будушем году Самсунгов на 16TB. С этим в комментах к предыдущим постам как-то вяло пытались спорить, но я так и не понял как предлагается это ограничение обходить в жизни, и почему оно, по поводу критиков моей позиции «не важно» (пояснение почему это так — в комментариях). Ограничение это оставалось и в v6.2, если верить официальному гайду:

http://www.vmware.com/files/pdf/products/vsan/virtual-san-6.2-design-and-sizing-guide.pdf

С учетом того, что там же, в документе, ниже, указывается, что основное правило в сайзинге кэша — кэш составляет 10% от хранимой usable (не raw) емкости (cache:capacity ratio) — что означает, что конфигурации размером более 6TB на ноду на дисковую группу будут, вероятно, испытывать недостаток пространства кэширования. (также смотри в комментарии о деталях)

Изменилось ли что-то тут в VSAN 6.5? Похоже, что нет:

http://pubs.vmware.com/Release_Notes/en/vsan/65/vmware-virtual-san-65-release-notes.html

VSAN все еще требует Multicast.

http://www.vmware.com/files/pdf/products/vsan/virtual-san-6.2-design-and-sizing-guide.pdf

Поменялось ли это? Нет, multicast по-прежнему нужен в VSAN 6.5

http://pubs.vmware.com/Release_Notes/en/vsan/65/vmware-virtual-san-65-release-notes.html

Готова ли у вас сеть к использованию в ней Multicast? Умеете его настраивать, отлаживать странности, понимает ли работу с ним ваши роутеры и иное оборудование в сети?

Дедупликация И компрессия. Я не зря ставлю тут «И», потому что в VSAN они включаются ТОЛЬКО ВМЕСТЕ, и на ВЕСЬ КЛАСТЕР целиком. И по-прежнему ТОЛЬКО на AllFlash.
Если у вас есть в кластере задачи, которые плохо переносят дедупликацию или компрессию, то вам придется выключить эти фичи для всего кластера целиком, даже если какие-то задачи и нуждаются в них.

Это соханилось в VSAN 6.5:

http://pubs.vmware.com/vsphere-65/topic/com.vmware.vsphere.virtualsan.doc/GUID-2285B446-46BF-429C-A1E7-BEE276ED40F7.html

Обоатите внимание также на warning, показываемый при включении deduplication & compression.

Документация подтверждает:

http://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.virtualsan.doc%2FGUID-5A01D0C3-8E6B-44A7-9B0C-5539698774CC.html

Про Data Locality.
Даже несмотря на то, что у VMware даже есть специальный документ по этому поводу: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-virtual-san-data-locality.pdf
просто взгляда на картинку со схемой размещения данных виртуальной машины достаточно, чтобы понять, что data locality в том смысле, в котором его понимает Nutanix, в VSAN нет.

Поэтому ничего удивительного в том, что в приведенном выше документе термин Data Locality VMware трактует иначе, и достаточно своеобразно:

Поддержка и обновления.
Поправьте меня, если я что-то понимаю не так, но из вот этой картинки следует, что обновления ПО у VxRail доступны только для Premium support:

Ну и, чтоб уж, как говорится, два раза не вставать, надо помнить, что, с точки зрения DellEMC покупатель VxRail НЕ МОЖЕТ смешивать их в одном кластере с «самосборными» нодами. То есть купили VxRail с поддержкой — продолжайте покупать их для расширения системы дальше. Но подключать в кластер из VSAN/VxRail самосборные ноды VSAN вы технически — можете, но поддерживаться эта конструкция на стороне DellEMC не будет. Помните об этом.

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

UPD: В комментах развернулась дискуссия, где обсуждается много интересных моментов, не пропустите.

Nutanix vs. SimpliVity: полтора года спустя. Что нового?

Быстро летит время. Я уже писал обзор особенностей продукта SimpliVity в 2014 году, пришло время обновить материал.
Так сложилось, что в США продукты SimpliVity для нас самый важный конкурент. Вопреки сложившемуся в России положению, VSAN «там» как-то мало кто знает, продается он не очень. Наоборот, до недавнего времени SimpliVity не продавался в России. Но теперь он появился здесь, давайте более внимательно посмотрим на то, что это и как он соотносится с продуктами Nutanix.

omnicube

Итак, что произошло у SimpliVity за прошедшее с прошлого разбора время.
К уже имеющемуся у SimpliVity продукту OmniCube, представляющему собой свою собственную x86-платформу, добавились совместные продукты с Cisco, на базе их C240 M4, и с Lenovo (на x3650M5), которые компания называет Omnistack, схема, сходная с нашими OEM-проектами с Dell и тем же Lenovo. Как вы заметили, Nutanix довольно часто пересекается в OEM с конкурентами, так, в Dell мы пересекаемся с EMC VxRail, а в Lenovo — с Omnistack. Таковы реалии рынка, никто не монополист.

Что же произошло с продуктом за прошедшие с прошлого разбора полтора года? Ничто так полно не рассказывает о продукте, как динамика его развития.

15 сентября 2014 года я писал: «Уже год как в SimpliVity обещают сделать поддержку Hyper-V, но пока в релиз это не выпущено.» Ситуация на сегодня, июнь 2016, полтора года спустя, прежняя. “SimpliVity has focused on vSphere first, in part for its market share and in part for its excellent breadth of capability. We are also working on expanding our coverage. KVM support has been announced, and Hyper-V is on our roadmap for GA.”
«Сеня, жарьте рыбу, рыба будет»(с). Интересно, дождутся первые купившие OmniCube поддержки Hyper-V, которая «is in our roadmap for GA», прежде чем у них кончится саппорт на купленную систему? Принимаю ставки :)

По-прежнему никак не движется ситуация у компании с ограниченностью расширяемости решения. По-прежнему только 4 ноды на кластер (или, вернее, на vCenter Datacenter), и не более 32 год на federation. Я писал, что в решении налицо серьезные архитектурные просчеты, которые помешают что-то сделать с этим в будущем. И, таки да, ничего за полтора года тут и не произошло. Четыре ноды, плюс одна для HA — это лимит сверху для кластера. Нужно больше емкости или нод, например при увеличении объемов нагрузки или числа мест для VDI — берите еще 4+1 ноды для нового кластера. Дробите дисковое пространство и увеличивайте число точек администрирования инфраструктуры. ОК, сегодня у вас на предприятии 200 VDI и вы их положили на 4-нодовую SimpliVity Omnicube. Через полгода у вас решили расширить проект до 2000 мест. Вы себе представляете администрирование десяти отдельных кластеров/датацентров vCenter? Вот то-то и оно. :(

По-прежнему нет, и, более того, неясны перспективы с All-Flash предложением. Его нет даже в roadmap. Сегодня, когда вся индустрия стремительно переходит на SSD, емкость которых резко растет, а цена — падает, такая неясность и неготовность выглядит странно.

Все также управление сделано через плагин к vCenter. Все ОК если vCenter — «ваше все». Но такой подход с привязкой к интерфейсам одного вендора в управлении чревато проблемой при попытке «отвязаться» от этого вендора, см. выше про проблемы с поддержкой Hyper-V.

Очень сомнительным, на мой взгляд, явилось решение продолжать использовать их собственную «железку», плату Omnicube Accelerator. Фактически, это «сердце» решения, полагаю, он был первоначальным стартап-продуктом, а уж hyperconvergence приложилась. Увы, сегодня «железка» есть наиболее очевидный лимитирующий элемент решения. Еще в прошлом посте про SimpliVity я задавался вопросом: Что будет с системой в целом, с ее функциональностью и с ее данными, если эта карта выходит из строя?

Еще сомнительнее выгляди то, что SimpliVity активно педалирует высокий data reduction rate своих систем с OAC (OmniCube Accelerator Card). Мой опыт говорит, что все методы повышения data storage efficiency на этапе сайзинга надо рассматривать исключительно как бонус. Данные сжимаются и дедуплицируются непредсказуемо. Нельзя сказать «А, ну у вас там 200TB, но у нас дедупликация и компрессия, так что вам надо взять всего на 100TB дисков, и все будет ОК!». Не факт. Есть данные, которые не сжимаются и не дедуплицируются, даже «волшебной платой» SimpliVity. К сожалению, пресейлы SimpliVity часто чересчур свободно обещают результаты дедупликации с помощью OAC, используя этот rate в сайзинге решения. Это может (впрочем, может и не) быть неприятным сюрпризом, если фактический результат работы data efficiency окажется хуже ожидаемого.

Следует также учитывать, что дедупликация — процесс by design очень сильно потребляющий память. Необходимость хранить в памяти и проводить проверку и сравнение по базе fingerprint-ов блоков в процессе проведения дедупликации есть очень RAM-емкая процедура. Даже у Nutanix, при включении компрессии и дедупликации, которая у нас емкость RAM, резервируемой CVM рекомендуется увеличить вплоть до 32GB. Пользователям рассказывают на презентации SimpliVity про волшебную «аппаратную» плату дедупликации OAC, и они представляют себе, что, в общем, это такой «черный ящик», куда на вход подается поток данных, а на выходе он выходит волшебным образом дедуплицированный, в 10 раз меньше, не загружая этим систему, и все. Однако обескураживающим является то, что, на самом деле, «разгружается» только CPU, память системы для работа дедупликации занимается. И еще огого как занимается, на младших системах может быть занято до 57GB (!), а на старших вплоть до 100GB (!!) памяти платформы, и это только лишь на поддержку работы OAC. Эта память, естественно, отнимается от ваших VM, от общего пространства, доступного гипервизору. И это в разы больше, чем занимает наш Nutanix CVM, за что его часто критикуют (и иногда даже справедливо). Такая вот «аппаратная плата дедупликации», съедающая 100GB RAM платформы при работе. При прочих равных это заставит вас купить на хосты SimpliVity больше памяти. Гораздо больше.

Столь же вводящим в заблуждение является предложение «2-node» конфигурации. Напомню, что у Nutanix минимально — 3 ноды, и это активно используется против нас в SMB-сегменте. Рассказ, почему мы не можем сделать менее 3 нод в кластере выходит за рамки поста. Однако стоит заметить, что и в «2-node» предложении SimpliVity эти «2 ноды» довольно лукавые. То есть, да, от самой SimpliVity нужно действительно 2 ноды. Но еще один сервер нужен для размещения Arbiter Service и vCenter. То есть две ноды плавно превращаются в три сервера. К слову, мы в Nutanix тоже рассматривали такую конструкцию, разрабатывая Xpress, но, в результате, решили, что такое не годится.

Все также нельзя смешивать в один кластер/vCenter datacenter разные модели. Набор моделей довольно узок, по-прежнему нет моделей all-flash, storage-only nodes, а GPU для тяжелых GPU-powered VDI может быть установлена только на выделенную ноду. Все это показывает, что SimpliVity все еще не вышла за пределы VDI-only решения для 200-300 рабочих мест.

Очевидно, и это вновь осталось неизменным за полтора года, решение SimpliVity нацелено на SMB-сегмент, и там, вероятно, вполне неплохо смотрится. Но любая попытка выйти из него немедленно натыкается на «зашитые» архитектурные проблемы. Повторю уже написанное полтора года назад, оно, на удивление, не изменилось. Если вам годятся ограничения SMB, если вас не пугают архитектурные ограничения, присущие решению, и не настораживает фактическое отсутствие развития за полтора года и «долгострой» в Roadmap, то SimpliVity может рассматриваться как вариант. Но меня бы, будь я клиент, такое бы напрягло. На фоне столь быстрого развития HCI (Hyper-converged Infrastructure) как направления, такая пробуксовка лично для меня показывает проблемы в управлении и явную нехватку сил для движения вперед в компании.

Просто для сравнения, за эти же полтора году у Nutanix появился:

  • Свой бесплатный для пользователя гипервизор Acropolis.
  • Nutanix Xpress Edition для рынка SMB
  • Распределенный файловый сервис Meduza, работающий в среде нашего кластера
  • Volume Groups для «блочного» iSCSI хранилища для VMs
  • Erasure coding
  • В два с половиной раза увеличилась производительность простым обновлением ПО
  • Появилась конфигурация All-Flash
  • Пройдена сертификация под SAP Netweaver
  • Сделана Metro Availability для vSphere
  • Написан плагин для интеграции XenDesktop с AHV
  • Сделан One-Click Upgrade
  • Вышел Prism Pro
  • Выпущена бесплатная версия Nutanix Community Edition

Что бы вы хотели знать о VSAN и EMC VxRail (но не догадывались спросить;)

9cff0216a1cc4461ab6f6de87b15af37[1]

В связи с выходом новых продуктов на VSAN — EMC VxRail, маркетинговая машина EMC запустилась, и начала свою работу по продвижению нового продукта семейства EVO:Rail. Новостей о «новом революционном продукте от изобретателей гиперконвергенции» будет много по всем каналам, как у EMC и заведено. Тем не менее для нас, технарей, важно сохранять трезвый взгляд, и знать не только о достоинствах, но и недостатках продукта, в конце концов CIO отрапортуют на chairman’s board о внедрении и пойдут пить свои коктейли, а нам с этим всем жить.
Поэтому я бы хотел остановиться на некоторых моментах VSAN/VxRail, о которых как-то не слишком говорят в презентации продукта.
Поэтому я и написал нижеследующий пост.

Я уже упоминал это, но обратил внимание, что часто этот факт как-то минует сознание многих.
Есть VSAN 1.0, который работает на vSphere 5.5. Он имеет кучу недостатков, о которых я писал раньше в этом блоге. VMware провела большую работу над ошибками, и выпустила следующую версию, которая стала сразу называться «VSAN 6.0». Однако так как VSAN это модуль ядра, то VSAN 6.0 нельзя поставить на vSphere 5.5. Вам придется обновиться на vSphere 6.0. Все бы ничего, но, к сожалению, качество релиза vSphere 6 «оставляет желать». Многие компании продолжают сидеть на 5.5 + Updates, в ожидании, пока 6.0 стабилизируется. Но если вы не готовы мириться с многочисленными проблемами vSphere 6.0, и при этом нуждаетесь в VSAN, то единственный выход для вас — VSAN 1.0, со всеми ее проблемами.

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

Добавить еще SSD в систему можно только в создаваемую новую disk group.

Если disk latency для HDD вырастает, по каким-то причинам, до 50ms, то этот диск выводится из дисковой группы, так как считается неисправным. Если по каким-то причинам для операций ввода-вывода на SSD также вырастает latency до 50ms, то он также выводится из дисковой группы, но при этом, см. выше, прекращает работу вся дисковая группа! Это поправлено в VSAN 6.2, но, например, EMC VxRail — это сейчас VSAN 6.1!

В VSAN отсутствует поддержка VCAI (View Composer API for Array Integration), что может стать проблемой с производительностью при развертывании большого числа VDI-десктопов разом.

Соотношение 70/30 для Read/Write операций в VSAN Cache не изменяемо. Это также может быть проблемой для ряда нагрузок, отличающихся от типичных (пример — VDI, где в типичной среде записей происходит больше, чем чтений).

Максимальный размер Write buffer — 600GB. Остальное место, если оно есть на SSD (сегодня есть SSD уже и 1,2TB), как я понимаю, просто не используется?

По-прежнему используется крайне спорное решение, когда при выходе из строя ноды кластера VSAN система ожидает его возвращения в строй 60 минут (целый час!), и только потом начинает процедуры ребилда информации и состояния системы. Если в течение этого часа для системы с FTT=1 происходит отказ в еще одной ноде, то, как я понимаю, все становится очень плохо.

Дедупликация, компрессия, а также Erasure coding доступно ТОЛЬКО на All-Flash системах, и недоступны на Hybrid-конфигурациях (SSD+HDD).

Официально поддержка SAP Core появилась только в VSAN 6.2, см выше про VxRail, а Oracle RAC и Windows Clustering — только с VSAN 6.1.

Я стараюсь писать это в каждом competitive-посте, напишу и тут: Я не являюсь глубоким специалистом в продуктах VMware. Если вы видите тут какое-то утверждение, которое не соответствует действительности, и готовы со ссылками на документацию указать мне на это, то напишите в комментариях, я откорректирую пост. Я стремлюсь к тому, чтобы вся информация в этом блоге была максимально достоверной и качественной.

UPD: Заходите в комментарии, там тоже есть много интересного. Я рад, что мое замечание о намерении избежать FUD-а и оперировать фактами было замечено, очень часто комментарии к подобным статьям не менее важны и содержательны, чем сам пост. Как только я разберусь с приведенными контраргументами, я обновлю пост там, где это он заслуживает.

Nutanix и ceph

ceph-logo

…Другой частый вопрос, который мне задают, когда я рассказываю про Nutanix это: «Ну есть же ceph? Он бесплатный и делает почти то же самое. Мы возьмем его, скачаем, соберем, и сделаем себе свой нутаникс с б.дж. и ш.»
Что я могу сказать на это.

Недавно, на выставке РИТ++, мне довелось поговорить со специалистом из компании, которая работает на рынке облачного хостинга под брендом flops.ru. Эта компания известна тем, что использует как раз ceph и построила на нем платформу публичного облачного хостинга. Интересные ребята, кстати, энтузиасты и большие молодцы, серьезно. Я воспользовался случаем узнать «из первых рук» их компетентное мнение о том, насколько реально «скачать ceph и сделать все то же самое на нем». Ответ был однозначен: «Это утопия».
Так, в частности, он рассказал, что они в flops потратили на доводку, допиливание и вычищение багов примерно полтора года труда их команды разработчиков. Они взяли довольно старую версию (v 0.67 «Dumpling») и «пилили» ее. И в итоге действительно допилили ее до продакшна. Текущая же версия, в том виде, в котором она выложена в паблик, несмотря на major и stable в названии, в продакшн непригодна.
«Помните историю cloudmouse, который, в результате слова бага и сбоя в марте этого года потерял данные 22 тысяч виртуальных машин (включая их бэкапы, а перед этим они теряли данные в феврале) и, в результате, ушел из бизнеса? Ребята взяли текущую версию ceph, и сделали свою систему на ней. Результат — вот такой.»
Собственно мне больше нечего добавить к этому ответу на вопрос, «можно ли скачать ceph и сделать бесплатно то же самое, что у вас за деньги?».
Можно. Но не сразу, не быстро, и, по факту, не бесплатно.

А сам flops.ru, повторюсь, молодцы, и хорошо поработали. Но есть ли у вас полтора года и достаточно компетенции, чтобы пройти их путь? Вам отвечать на это.

X vs. Y: VSAN 6.0. Что нового?

Я уже писал в этом блоге подробный разбор того, чем Nutanix отличается от VSAN (EVO:RAIL), однако там речь шла о VSAN 5.0. В версии 6.0 было многое поправлено и изменено, но все ли? Этим мы сегодня и займемся.
Читать далее

SQL серверы на Nutanix

Мне часто, в процессе общения с клиентами, приходится слышать мнение, что, мол, Nutanix — не для SQL-задач. Что, дескать, вот веб-задачи, хостинг, VDI, вот это — да, а SQL там, ERP, и прочее такое — не подходит.
Стоит признаться, что год назад и я сам (еще до того, как присоединился к Nutanix) такого же мнения придерживался. :)

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

Вот такой скриншот показал нам один наш клиент в России:

Screenshot-2015-01-20-20_52_01

Около 20 VM с задачами SQL-серверов из более чем 500 VM всего крутящихся на этом 28-нодовом кластере.

Отчет IDC по гиперконвергентному рынку 2014

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

IDC chart 2014

Такой красный помидор на Nutanix это сама IDC нарисовала, это не я выделил :)
Да, конкурентов по именам пока еще немного, но среди них есть и довольно именитые. Впрочем, кто наши конкуренты, и чем мы от них отличаемся вы можете в этом же блоге, в моей рубрике «X vs.Y», в которой я сравниваю Nutanix с продуктами-конкурентами.

Acropolis in da house!

Acropolis, наш инструментарий для создания и управления виртуальными машинами для среды гипервизора Linux KVM непосредственно из Nutanix Prism UI, получил свой GUI и REST API.
Релиз состоится вместе с выходом NOS 4.1.1, 28 января, завтра.
Велкам пробовать!

Создаем VM с нужными параметрами прямо из Prism UI:

Screenshot 2015-01-24 21.45.02

Управляем миграцией VM по хостам кластера:

Screenshot 2015-01-24 21.50.05

Screenshot 2015-01-24 21.50.27

REST API:

Screenshot 2015-01-24 21.52.44

Производительность NVIDIA GRID K в NX-7110

Несколько раз задавали вопросы, чему соответствует производительность карт NVIDIA GRID K1 и K2, используемых в нашем модуле для «высокопроизводительного VDI» — NX-7110.
Беглое гугление позволило найти результаты бенчмарков этих карт, вместе с другими GPU, на сайте PassMark (http://www.videocardbenchmark.net). Да, это бенчмарки (G3D Mark), а не реаллайф, но, тем не менее, это почва для размышлений и какие-то данные для оценки.
Напомню, что NVIDIA GRID K это новое семейство GPU, предназначенное для использования под виртуализацией, GRID K1 это GPU уровня «entry level», по позиционированию самой NVIDIA, и предназначен для работы преимущественно в режиме vSGA, а GRID K2 — «high-end GPU», и нацелен на применение в режиме vDGA, то есть аппаратно проброшенного в виртуальную машину GPU.

К сожалению, на сайте можно выбрать для сравнения только три GPU, поэтому результаты пришлось комбинировать.
Сравнивал я их с серией GPU для профессионального применения, серией Quadro.

Вот, что показыывает бенчмарк PassMark G3D Mark:
NVIDIA GRID K2 примерно соответствует NVIDIA Quadro K5000, и примерно вдвое уступает Quadro K6000.

gridbench#1

Обратите внимание, что у NVIDIA есть также карты Quadro без K, прежнего поколения, они сильно, примерно вдвое уступают по производительности картам Quadro K. Таким образом, GRID K2 соответствует «старой» Quadro 6000, без K, или K5000 из новой серии.

gridbench#2

Так как GRID K2 в вашей системе наверняка будет использоваться в режиме vDGA, то, скорее всего, никаких оверхедов виртуализации тут не будет.

Карта GRID K1 примерно соответствует карте Quadro K600, и примерно впятеро ниже по результатам бенчмарка, чем K2.

gridbench#3

Возможно тут будет некоторый оверхед, но вряд ли значительный.
Также напомню, что на одну карту GRID K2 можно повесить два пользовательских рабочих места с виртуализацией vDGA (то есть, фактически, разделить эту видеокарту на две независимых карты) для «хардкорного» 3D, либо 2-16 пользователей в не таком требовательном 3D (например «не таким требовательным» NVIDIA называет AutoCad и другие подобные программы), а карта K1 — до 32 пользователей vSGA на карту.

Вот такая вот оценка производительности и возможностей для NVIDIA GRID K в сравнении с NVIDIA Quadro поколений 2012-2013 годов, и которые часто приводятся как референсы в ТЗ наших клиентов.

X vs. Y: Nutanix и VMware EVO:RAIL

Несколькими постами ранее я начал серию обзоров конкурентов Nutanix, с подробными разбором «кто есть кто», и что конкуренты предлагают в сравнении с продуктами Nutanix, и начал я с SimpliVity OmniCube.

Продолжим наше исследование ландшафта рынка гиперконвергентных систем, и представленных на нем продуктов. Следующим заметным игроком на нем является VMware со своим уже хорошо известным VSAN, и недавно объявленным новым «хардварным апплаенсом» на его базе — EVO:RAIL.
Давайте посмотрим, что интересного предлагает Vmware, и как они смотрятся в сравнении с Nutanix.
Для начала несколько слов, что же такое EVO:RAIL, и чем он отличается от VSAN, продукта уже, в общем, известного пользователям.

SYS-2027PR-HTR_25[1]

Читать далее