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

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

Несколько вводных слов по теме. VMware — компания, выпускающий лидирующий продукт в области виртуализации, заслуженно пользуется репутацией лидера. Компания стояла у истоков самого явления как такового, фактически была первой компанией, выведшей на рынок гипервизор виртуализации, и первой превратила его из игрушки для сисадминов, чтобы запускать Линукс в Windows, в фактически определяющий вектор развития современного IT и датацентров. Основанная в далеком 1998 году компания, выпустила первую версию гипервизора ESX, лежащего в основе сегодняшнего решения, в 2001 году, а в 2004 она была приобретена гигантом отрасли систем хранения данных, EMC, за огромные тогда 625 миллионов долларов. Впрочем, следует отметить, VMware не влилась в EMC, а осталась частично самостоятельной компанией, находящейся в листинге биржи, 15% ее акций находится на NYSE.
На сегодня в компании работает 18 тысяч человек, и на 2014 год она заработала 860 миллионов чистой прибыли.

В 2009 году компания выпустила прорывный продукт для enterprise-рынка виртуализации — vSphere, включающий в себя гипервизор, плюс ряд инфраструктурных инструментов управления, позволяющий использовать гипервизор в проектах уровня датацентров.

Несколько лет назад внутри компании начали разрабатывать новый продукт, который был представлен в 2013 году как VSAN (он сразу стал называться «5.0», чтобы сравняться визуально с версией vSphere). По слухам, его разработала группа всего в 12 человек, что, безусловно, делает им честь. Проведя какое-то время в статусе бесплатной беты, и попробованный на своих системах множеством энтузиастов, VSAN вышел в GA в марте 2014 года, и, наконец, в феврале 2015 года вышла вторая его версия, получившая название «VSAN 6.0».

Тогда же, в прошлом году, VMware запустила интересную инициативу, предложив рынку совместный с партнерами-сборщиками серверов продукт — VMware EVO:RAIL. Это VSAN, установленный на готовую серверную платформу, и продаваемый как готовое решение OEM-партнерами компании.
Именно EVO:RAIL является прямым и непосредственным конкурентом для Nutanix, но следует помнить, что VMware EVO:RAIL есть ничто иное, как VMware VSAN, плюс VMware ESXi (vSphere) с лицензией Enterprise Plus, установленный на готовый сервер в фиксированной конфигурации, и продаваемый партнером компании, например, Fujitsu, или кем-то еще.

Также следует отметить, что, по ряду внутренних причин, VSAN новой версии становится доступным для установки OEM-партнерам в EVO:RAIL только спустя 180 дней после его официального релиза, это значит, что нынешние EVO:RAIL получат новую версию VSAN только в сентябре 2015 года.

Ясно видно, что VSAN (EVO:RAIL) есть ближайший конкурент для Nutanix, находящийся к нему настолько близко, насколько это возможно. Но разница, безусловно, есть. Для того, чтобы подробнее рассмотреть где между ними разница, я писал предыдущий пост, про VSAN 5.0, а в этом мы посмотрим, что изменилось с тех пор.

  1. В VSAN 6.0 появилась поддержка All-Flash конфигураций. Ранее была возможна только конфигурация SSD+HDD. У Nutanix с прошлого года есть NX-9000, All Flash-система.
  2. Увеличилось с 32 до 64 максимальное число нодов кластера. Так как это число определяется размером поддерживаемого в кластере VMware числа хостов виртуализации, это предел. Напомню, что архитектурно у Nutanix нет ограничений на размер кластера, однако, если вы используете кластер Nutanix в среде VMware vSphere, то она ограничит этот размер той же величиной.
  3. Максимальное число виртуальных машин на хост виртуализации (ноду VSAN) увеличилось вдвое, со 100 до 200 VM.
  4. Соответственно увеличилось число VM в кластере VSAN с 3200 до 6400 (однако только 2048 может быть защищено HA).
  5. Утверждается, что увеличилось максимальное значение IOPS на хост с 20K на VSAN 5.0 до 90K.
  6. Важное изменение, вызванное крупными изменениями в структуре хранения. Предельный размер VMDK (файла виртуального диска) увеличился с 2TB до 62TB.
  7. Крупное изменение структуры хранения позволило реализовать снэпшоты и клоны (до 32 снэпшотов на VM), гораздо менее, чем раньше, влияющие на производительность VM. Раньше наличие снэпшотов у VM губительно сказывалось на производительности ее работы. Напомню, что внутренние снэпшоты Nutanix на NDFS работали независимо от снэпшотов VМware, и не страдали ее проблемами влияния на производительность, что позволяло применять их неограниченно и широко, например, для защиты данных (TimeStream Backup), клонирования виртуальных машин и репликации данных.
  8. Появилась дополнительная функциональность rack-aware fault domain, при которой данные в большом кластере хостов VSAN распределяются так, чтобы обеспечить защиту от инфраструктурного отказа, например выхода из строя блока или группы блоков. Эта функциональность также есть у Nutanix.
  9. Поддерживаются Direct-attached стораджи (JBOD).
  10. Появилась защита целостности данных с помощью вычисляемых контрольных сумм блоков. Эта функциональность также есть у Nutanix.
  11. Поддерживается аппаратное шифрование хранимых данных, аналогичное шифрованию у «-E» моделей Nutanix.
  12. Появилась ряд новых возможностей в области управления VSAN, например: Proactive Rebalance, Disk/Disk Group Evacuation, Disk Serviceability Features, Storage Consumption Modelling, Health Services.

Как видите, VSAN активно сокращает заметный разрыв между собой и лидирующим Nutanix.

Однако есть у Nutanix пока и существенные преимущества.

Прежде всего, это «гипервизоро-независимость». Выбор VSAN означает, что вы используете сейчас, и будете использовать в будущем ТОЛЬКО VMware vSphere. Вы принимаете все, что решит для вас придумать VMware, +15% к цене американского прайслиста для России, «эксперименты» с лицензированием (помните vRAM?), web-матьее-консоль vCenter, ограничения HCL, и так далее. VSAN реализована как ядерный модуль гипервизора, что накрепко привязывает это решение к ESXi.

Кроме того, Nutanix гибче в конфигурации, так как продуктовая линейка шире (и длиннее;), и в ней есть множество вариантов, что контрастирует с довольно узким предложением ready-made нод для VSAN у VMware.

VSAN использует flash исключительно как кэш данных (исключая конфигурацию All Flash), это приводит к тому, что емкость SSD не увеличивает общую usable-емкость хранения, напротив, у Nutanix емкость SSD включена и суммирована с емкостью HDD. А, например, в конфигурации из 4 SATA HDD по 2TB, и 2 SSD по 1,6TB (а такие SSD мы сейчас поставляем на новых нодах Haswell), емкость SSD составляет 40% (!) емкости ноды. В случае Nutanix эта емкость плюсуется к емкости HDD, так как данные могут лежать ИЛИ на HDD, ИЛИ на SSD, а у VSAN данные на SSD есть копия данных на HDD, и емкость ноды они не увеличивают.

Использование CVM, работающего в userspace (в отличие от модуля ядра VSAN) не только улучшает изоляцию и отказоустойчивость («падение» CVM просто приводит к временной перемаршрутизации ввода-вывода на CVM соседа, и перезапуску VM, а вот падение или бага модуля ядра влечет за собой куда более серьезные последствия), не только упрощает процесс его обновления, независимого от обновления самого гипервизора, но и облегчает поддержку новых продуктов и решений (например, Docker).

VSAN требует в сети работы multicast и Jumbo frames. Nutanix не требует ни того, ни другого, и оставляет выбор использовать ли Jumbo Frame за пользователем.

VSAN не поддерживает VAAI. Парадоксально, но факт. Напротив, Nutanix поддерживает функции VAAI, в том числе storage-based cloning/copy. Эта функциональность очень востребована во многих больших инфраструктурах виртуализации для быстрого развертывания VM из Golden image.

У VSAN нет чего-то аналогичного нашему механизму Shadow Clones, о котором я как-то писал подробно ранее. Shadow Clones это механизм, который позволяет решить проблему, когда сотни и тысячи VDI-десктопов разворачиваются из единого Golden image VM, при этом данный образ лежит на одной ноде, что может привести к ее перегрузке при масштабном обращении к его данным, например, в результате boot storm. У Nutanix для этого образа создается виртуальный «теневой» клон, помещаемый на каждую ноду локально, и используемый «read-only». При этом данные golden image читаются локально, а не по сети.

У VSAN отсутствуют средства дедупликации и компрессии, которые есть у Nutanix. У Nutanix есть, напомню, inline компрессия и дедупликация (выполняемая непосредственно в момент записи данных на диски), а также Map/Reduce компрессия и дедупликация, выполняемая отложенно и распределенно, всеми нодами кластера, что ведет к большей эффективности и меньшей загрузке CPU. При этом, для задач виртуальных инфраструктур, в которых, часто, сотни VM используют один и тот же образ OS, эффективность дедупликации файлов виртуальных дисков может составлять десятки процентов. Nutanix также умеет дедуплицировать SSD и кэш-память, что означает, что эффективный объем дорогой кэш-памяти для вашей VM увеличивается пропорционально коэффициенту дедупликации.

По-прежнему, у VSAN никак не решается проблема ребалансировки данных по кластеру при добавлении и расширении нодами этого кластера. Так как хранение данных организовано таким образом, что они лежат «в сети» и доступ к соответствующему блоку всегда осуществляется по сети, то добавление ноды и перенос туда VM никак не влияет на то, как будут распределены блоки хранимых данных по дискам нод, их данные VM по-прежнему будут получать через сеть кластерного интерконнекта. Только вновь создаваемые VM будут использовать диски новых нод. Впрочем, тема data locality и ребалансировки подробно рассматривалась ранее в статье про VSAN 5.0.

У VSAN отсутствуют собственные средства репликации данных VM, тут она полагается на средства host-based репликации vSphere. У Nutanix есть своя, независимая от гипервизора, и доступная поэтому на любом гипервизоре, репликация данных, one-to-one, many-to-one, one-to-many, двусторонняя и односторонняя, и так далее. Ее использование позволяет легко строить различные распределенные и защищенные структуры хранения данных, например, для целей построения DR-центра.

Отдельно несколько слов о производительности.
Отнеситесь критично к демонстрации производительности VSAN на синтетике с 100% read или 100% write. Опыт показывает, что на mixed workload результаты могут весьма сильно отличаться.

Удивительно, но факт. Размер write buffer для SSD в all-flash config имеет предел в 600GB, вне зависимости от использованного SSD. Для SSD большего размера, чем 600GB, его «лишняя» емкость просто не используется. При этом, напомню, у Nutanix уже сейчас есть и поставляются SSD, емкостью 1600GB, и практически вся она доступна для пользовательских данных.

Отказ SSD в соответствующей дисковой группе VSAN ведет к потере доступа ко всей этой группе, включая и HDD. Это существенное отличие от Nutanix, в котором отказ SSD — это просто отказ данного SSD, не приводящий к недоступности всей группы.

Существенная разница также в том, как система отрабатывает факт отказа диска. В случае Nutanix эта задача распределяется между всеми нодами кластера, все ноды кластера, обладающие нужными блоками данных, отправляют их на восстанавливаемый диск, вследствие чего восстановление проходит очень быстро, за минуты. Причем, парадоксально, для знакомых с только RAID-стораджами, увеличение размеров кластера *ускоряет* его восстановление.

Также следует помнить, что VSAN начинает процесс восстановления не сразу же, а спустя 60 минут после истечения таймаута недоступности. Nutanix начинает процедуру восстановления данных сразу же.

В случае VSAN восстановление затрагивает только одну ноду, хранящую копию данных отказавшей, так как VSAN, напомню, это не распределенное хранилище, как Nutanix, а, фактически, «сетевой RAID-1». Время восстановление выше, как выше и загрузка единственной ноды, владеющей зеркальной копией данных.

Несмотря на то, что VSAN надежен, и не имеет единой точки отказа, вам надо помнить, что управление им осуществляется из одной точки — vCenter. Ваш vCenter, для удовлетворения всем требованиям отказоустойчивости, должен быть дублирован в инфраструктуре, его база SQL также должна быть реплицирована и защищена, что и само по себе непросто. Напротив, Nutanix использует распределенную по всему кластеру встроенную систему управления, которая by design не имеет «единой точки отказа», и не зависит от vCenter и его SQL-базы.

Также сравнительно с Nutanix бедно выглядят средства VSAN по мониторингу кластера, и анализу его работы. Отсутствуют средства непрерывающего работу кластера обновления (о чем я уже упоминал выше, говоря о архитектурной разнице между user-space и kernel-space), отсутствует решение, эквивалентное Prism Central для управления несколькими распределенными кластерами компании и, например, ее отделений в других городах и странах.

Помните, что условия поддержки существенно отличаются для DIY-систем с VSAN, и с системами EVO:RAIL, или иных VSAN-ready платформ.

Таким образом, резюмируя, вот, что мне кажется, самое важное (не все, но самое важное), в чем проигрывает VSAN 6.0 текущей версии Nutanix:

Нет принципиальной возможности поддержки других гипервизоров, кроме ESXi.
Нет поддержки дедупликации и компрессии
Нет поддержик Shadow Clone, решающих проблему перегрузки ноды-держателя golden-image
Нет поддержки VAAI
Нет инструмента управления распределенными кластерами, аналогичного Prism Central
Есть потенциальная точка отказа инструмента управления в лице vCenter
Нет ребалансировки данных при добавлении нод в кластер
Нет распределенности защиты данных, только зеркало на ноду-соседа (network RAID-1).
Write buffer ограничен 600GB
Максимальное число защищаемых НА виртуальных машин в кластере — 2048
Нет собственных средств репликации данных
Нет средств не прерывающего работу кластера обновления

На следующей неделе я постараюсь некоторые вопросы исследовать и описать более глубоко.

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

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

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