X vs. Y: Nutanix и SimpliVity

Не секрет, что на рынке гиперконвергентных систем Nutanix играет не один. Более того, на рынок гиперконвергентных систем разом вышло сразу несколько сильных и интересных игроков.
Начнем же в этом блоге, потихоньку, смотреть, что предлагают рынку и пользователям компании-производители конкурирующих с Nutanix продуктов. Разберем их слабые и сильные места, и что они предлагают в сравнении с продуктами Nutanix.
А стартуем, пожалуй, с компании SimpliVity, и ее OmniCube.

Для начала немного сухих фактов.

Компания SimpliVity образовалась в 2008 году, и первоначальной целью ее была разработка производительного устройства для потоковой, «онлайн»-дедупликации и компрессии данных. Такое устройство было создано с использованием «аппаратного» устройства на базе FPGA. В 2012 году компания вышла на рынок и в апреле 2013 года представила на нем свой продукт — платформу для виртуализации с использованием VMware vSphere, названную OmniCube. Система OmniCube построена на базе 2U серверной платформы Dell, собственной аппаратной разработки SimpliVity — PCIe-платы OmniCube Accelerator (OAC) и программного компонента — т.н. «virtual appliance» OmniCube Virtual Controller (OVC).
На январь 2014 в компании трудилось 170, а в июне 2014 — уже 350 сотрудников. Расположена компания в США, Вестборо, штат Массачусетс. CEO и founder SimpliVity — Doron Kempel — в прошлом вице-президент EMC. Ходят слухи, что приобретением компании интересуется HP.

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

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

simplivity-product-home-image

Несомненно, одним из ключевых особенностей и «козырей» SimpliVity OmniCube является ее возможности по онлайн-дедупликации и компрессии данных, выполняемой отдельным «аппаратным» устройством, устанавливаемой в систему PCIe-платой OmniCube Accelerator, выполняющей потоковую дедупликацию и компрессию данных, особо востребованную для систем виртуализации, в особенности для VDI.

simplivity_doron_kempel_bbj[1]

подпись под фото на сайте источнике: Doron Kempel держит в руках OmniCube Accelerator card

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

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

С тех пор прошло много лет, а в терминах IT — даже эпох. За эти годы процессоры не только увеличили свою производительность в сотни и тысячи раз, но и обзавелись многоядерностью и разнообразными внутренними «ускорителями» и специальными наборами инструкций, которые позволили резко увеличить производительность некоторых часто используемых задач, таких как, например, вычисление криптографических функций и хэшей (например, AES и SHA-1), SIMD-операций (Single Instruction Multiple Data), и так далее. Такой рост производительности центральных «процессоров общего применения» системы дал возможность разработчикам крутить на них различный дополнительный к коду Самой Главной Задачи программный код, без существенного влияния на ее производительность (см. например, успешно используемые в десятках тысяч инсталляций в мире Software iSCSI Initiator). Немаловажно также то, что такой подход позволил значительно быстрее изменять, модернизировать и оптимизировать код, а, значит, «программное» решение всегда оказывается на шаг впереди «аппаратного», просто за счет более короткого «цикла производства», от идеи до реализации.

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

А теперь давайте вернемся к тому, что делает SimpliVity.
SimpliVity сделал «аппаратную» железку (кавычки мои, так как «аппаратность» там это, фактически, FPGA, а не ASIC), которая неплохо делает на лету дедупликацию и компрессию. Она снимает эту задачу с процессора платформы. Что-то еще? А вот на самом деле и все что она делает.
Делает ли она это хорошо? Допустим — да. Сам SimpliVity утверждает, что она это делает очень хорошо. Делает ли эта волшебная железка что-то еще? Нет, больше ничего. Это One-trick Pony, как называют это американцы, нечто, умеющее делать ровно один «трюк», одну задачу.
Достаточно ли уметь хорошо выполнять один трюк, чтобы стать «убийцей айфона Nutanix» (и это при том, что Nutanix тоже умеет делать дедупликацию и компрессию, пусть и без волшебной платы)? Я не буду вас подталкивать к ответу. :)

Пойдем дальше.
Выбрав такой способ решения, SimpliVity неизбежно столкнулась с рядом ограничений, вызванных «аппаратностью» решения.
На сегодня, SimpliVity работает ровно под одним гипервизором — VMware ESX. Уже год как в SimpliVity обещают сделать поддержку Hyper-V, но пока в релиз это не выпущено. Причины здесь две. Во-первых, проброс «железной» карты PCIe OmniCube Accelerator в виртуальную машину OmniCube Virtual Controller требует PCI Passthrough, и работает сейчас только в ESX.
Во-вторых, управление OmniCube сделано в виде плагина к vCenter. Это удобно, если вам нужен только vSphere. И это также резко усложняет дело при необходимости работы под другими гипервизорами, фактически требуя написать интерфейс управления заново, например в виде модуля интеграции с SCVMM.

Такая ситуация принципиально отличается от «мультивендорного», hypervisor-agnostic подхода Nutanix, который остается собой и работает независимо от типа гипервизора, которых на сегодня поддерживается три, фактически все три топовых гипервизора на энтерпрайз-рынке, VMware VSphere, MS Hyper-V и RedHat KVM.

Большие вопросы возникают и к отказоустойчивости этой «аппаратной платы». Такая плата стоит одна в каждом OmniCube node. Ее отказоустойчивое дублирование конструкцией не предусмотрено. Что происходит, если она выходит из строя? Предполагаю, что, в наилучшем случае, уже записанные данные останутся доступными, но прекратится дедупликация и компрессия новых данных на данной ноде. Часть функциональности при этом неизбежно будет потеряна. После восстановления работы платы (например ее замены через несколько дней) есть ли способ оффлайново дедуплицировать или сжать данные, которые были записаны на систему, пока плата не работала? Останутся ли в самом деле данные доступны при выходе из строя OAC?

К сожалению, OmniCube Accelerator — «черный ящик», и детали внутреннего устройства и алгоритмов его работы компания не раскрывает (в отличие от, например, Nutanix), мы можем только доверять утверждению инженеров SimpliVity о ней и особенностях ее работы.
Подходит ли вам такой источник уверенности в отношении покупаемой за многие десятки тысяч основы вашей будущей виртуальной инфраструктуры? Решать вам.

Хорошо, но как в SimpliVity OmniCube обстоят дела с отказоустойчивостью и надежностью хранения вообще? Я уже рассказывал здесь, что у Nutanix надежность и отказоустойчивость обеспечивается путем размещения данных в кластерной избыточной файловой системе, где каждый блок хранится в двух резервных копиях на двух других нодах или, если это возможно, в двух других физических блоках нодов. Nutanix не использует RAID для дисков, справедливо полагая, что на современных емких дисках SATA восстановление в случае сбоя может занимать неоправданно длительное время. Собственно именно эта распределенная кластерная файловая система, NDFS, Nutanix Distributed Filesystem, и является ядром, основой всей архитектуры Nutanix.
Как отказоустойчивость, кластерность и распределенность реализована у SimpliVity OmniCube?
Ничего интересного. Отказоустойчивость решена совершенно традиционным образом. Для дисков используется RAID (RAID5 для SSD и RAID6 для SATA), а каждый «нод» общей системы объединенных вместе нодов-OmniCube, называемой «federation», просто является HA-парой для своего партнера.

Решение классическое, и довольно тривиальное, и которому, увы, присущи все характерные для «классической» HA-пары с RAID недостатки. Минимальная отказоустойчивая структура federation, таким образом, составляет 2 штуки 2U OmniCube, а максмальная на сегодня продемонстрированная хотя бы в виде теста, проведенного аналитической компанией ESG — 40 нодов OmniCube. Предположительно, эта 40-нодовая federation, собранная в тестовом датацентре компании, и настроенная силами ее собственных инженеров, и является фактическим максимумом для данной архитектуры. К слову, ESG ее также, судя по отчету, продемонстрировали как «черный ящик», без деталей конфигурации и без возможности провести на ней полный набор тестов, проведенный на 6-нодовой системе ранее.

Из описания можно понять, что мало того, что часть дисков, как SSD, так и SATA, заняты под RAID-parity, но еще и зеркальная копия данных хранится на партнере ноды в federation-кластере, что выглядит как «RAID-51» и «RAID-61» (RAID-5 или -6 для данных и метаданных соответственно, плюс сетевое «зеркало» на дисках партнера). Неэффективность расходования места видимо предполагается компенсировать за счет выигрыша от дедупликации хранимых данных.

Из описания становится ясно, что SimpliVity OmniCube federaton, фактически, в отличие от Nutanix, вообще не является распределенной web-scale системой как таковой, а только набором пар нод-вычислительных узлов, отдающих свои дисковые ресурсы по NFS для единственного поддерживаемого гипервизора, а также контроллера управления межнодовой репликацией данных, и платой FPGA, в виде virtual appliance. Вся эта кухня управляется, в свою очередь, из плагина к vCenter, как единственный возможный вариант.

Интересный вопрос, на который не удалось найти ответа: что произойдет в случае выхода из строя vCenter, сохранится ли доступность данных и функциональность системы (например возможность миграции, доступ к функциям в случае выхода из строя) без управляющего модуля?

По контрасту, кластер Nutanix состоит минимум из трех нод, обеспечивающих достаточную избыточность для доступности всех его данных, при отказе любого из них. Продемонстрированный потолок числа нод составляет на сегодня около 50 нод в реальном, «боевом» продакшне, развернутом у конечных заказчиков (не HA-пар, а именно полноценных распределенно-кластерных нод), а максимальная «упаковка» для модели NX-3000 составляет 4 ноды в 2U, что вчетверо более плотное размещение, чем у SimpliVity, и это может быть критически важно в случае больших инфраструктур, где каждый U в датацентре может стоить весьма дорого.
Хотя, возможно, все это может быть и не столь важно, если вы хотите ограничиться минимальной конфигурацией.

Таким образом становится понятно, что, в его имеющемся на сегодня состоянии, SimpliVity OmniCube хорошо подходит и должен привлечь клиентов «начального», «нижнего» сегмента подобных систем, при этом использующих исключительно VMware ESX. Однако, стоит понимать, что при росте размеров клиентской системы она может столкнуться с рядом архитектурных проблем и ограничений, изначально присущих архитектуре решения от SimpliVity.

Главный Weakness системы, как пишет в таких случаях Gartner, это как раз ясно видимые проблемы «архитектурного» плана решения как такового. Не являющиеся, скорее всего, существенной проблемой для Low-Enterprise и ROBO (Remote Office — Branch Office), проблемы эти существенно затрудняют не только дальнейшее расширение инфраструктуры для компаний, выбравших решение от SimpliVity, но и, вероятно, затруднят дальнейшую разработку в «топовом» сегменте линейки продуктов самой компании. Привлекая клиентов ценой и востребованными «фичами» в «нижнем» сегменте, компания может затруднить своим клиентам процесс scale-out, который, во многом, является «двигателем» для гиперконвергентных решений.

На мой взгляд, сегодня, «ставить» на SimpliVity можно в двух случаях. Если вы осознанно выбрали VMware vShpere как единственный тип гипервизора и не планируете в будущем переходить на какой-либо еще (и вас не пугает некоторая импульсивность в отношении ценообразования на продукт от лидера рынка, демонстрируемая им в последние годы). И, второе, вы сравнительно небольшая, локально расположенная компания, которая не планирует резкий рост, за пределы мощности 2-6 OmniCubes в federation, и вам не требуются многочисленные фичи, позволяющие Nutanix расти кластером до десятков нодов, в том числе географически распределенных.
Наконец, ваша задача — это преимущественно VDI, или иной крайне хорошо дедуплицирующийся контент, на котором Deduplication engine в OAC продемонстрирует свои возможности, и, вдобавок, со средними требованиями к безотказности и непрерывности работы инфраструктуры.
В этом случае, вероятнее всего, вы будете довольны SimpliVity, и не столкнетесь с рядом его архитектурных gotchas, которые могут так неожиданно вылезти при будущем росте инфраструктуры вашей компании.

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

PS. Здесь и далее. Невозможно быть абсолютным специалистом во всех продуктах всех вендоров разом. Если вы хорошо знакомы с предметом обсуждения, и видите что автор, то есть я, допустил при изложении материала какую-то неточность, или демонстрирует непонимание особенностей работы продукта конкурента, не стесняйтесь указать мне на это в комментариях (разумеется приведя проверяемый авторитетный источник, подтверждающий вашу позицию), я обязательно исправлю пост.

X vs. Y: Nutanix и SimpliVity: 6 комментариев

  1. comotoza

    У Simplivity есть лимит — 4 узла в рамках одного кластера. Как такового лимита на количество кластеров в федерации нигде не видно в оф документации, но вроде как тесты проведенные ESG с 40 узлами — это не поддерживаемое решение.
    Вроде скоро вместе с анонсом поддержки 5.5 (на сайте варе уже в листе совместимого оборудования есть) будет поддержка большего числа узлов в кластере. Касательно размеров федерации — не известно.
    Касательно дедупа Simplivity VS Nutanix вроде как разница в том что и когда дедупится, Nutanix дедупит онлайн только fingerprint, а далее пост процессом сами данные, не?
    Касательно еще возможностей — у Nutanix легче изменить конфигурацию CVM и пожертвовав например оперативной памятью разгрузить хранилку отдав под кеш на чтение. Для того же VDI нет аналога shadow vm, потому отчасти рекомендация для Simplivity — использовать full clone vm — с ними оно работает лучше.
    Ну и не особо критично, но вопрос первоначального запуска системы — пока нет аналога foundation (потому что привязка к vcenter и он обязательно должен быть win), время запуска в эксплуатацию Simplivity дольше (даже у EVO: RAIL есть автоустановщик для автоматизации).

    1. Maxim Shaposhnikov

      «Касательно дедупа Simplivity VS Nutanix вроде как разница в том что и когда дедупится, Nutanix дедупит онлайн только fingerprint, а далее пост процессом сами данные, не?»

      Именно так. Map-reduce фреймфорк, настоящая bigdata. Спокойно, не торопясь, спускаемся с горы… И дедуплицируем данные :) Нет никакой спешки их «на лету» дедуплицировать.

      Понятно, что ребята из Симпливити будут пытаться выпячивать это как преимущество (особо больше нечего), но это все забавно.

      Ну а в общем-то вывод верный. Симпливити конкурент нам только для систем начального уровня (фактически SMB), но и там у нас есть та-же 1000-я серия с полноценным ПО.

      Ну а симпливити — главное проводить тесты.

      Берем, выключаем vcenter (например авария двух нодов на которых в линккованном режиме он запущен), смотрим дальше что будет :)
      Если на Nutanix можно смело гонять vcenter на том же кластере (на самом Нутаниксе), то для симливити это крайне противопоказано.

      1. romx Автор записи

        > Нет никакой спешки их «на лету» дедуплицировать.

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

        Но согласен с тем, что такая уж острая надобность именно онлайновой дедупликации сильно переоценена.

        1. Maxim Shaposhnnikov

          И да и нет.

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

          Инлайн дедупликация (которая у Смпливити по определению локальная) — крайне опасная штука с точки зрения надежности, ибо фактически они имеют просто RAID 60 / 50 (федерация из двух узлов с Mirror + локальные 6/5 рейд для SSD / SATA).

          В общем-то — откровенно слабый и архаичный дизайн, даже VSAN и тот умнее.

          1. Sergey

            А давайте посмотрим на производительность VSAN при падении одного диска хотя бы ? :))))

  2. Уведомление: X vs. Y: Nutanix и VMware EVO:RAIL - Virtualization solution with a nuts

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *