Показаны сообщения с ярлыком EMC. Показать все сообщения
Показаны сообщения с ярлыком EMC. Показать все сообщения

четверг, 5 февраля 2015 г.

Еще один игрок среди реализаций EVO:RAIL

На днях EMC анонсировала свой EVO:RAIL appliance - VSPEX BLUE, присоединившись, тем самым, к не слишком многочисленной компании, в которой готовых отгружать решение еще меньше.


VSPEX BLUE


Для крупных игроков на рынке довольно сложно продвигать свою реализацию EVO:RAIL. Им нужно заработать, а в случае с EVO, мы имеем жесткие лимиты по дизайну системы, определенный софт и, собственно, практически всё. Поэтому основная задача - показать ценность своего решения, чтобы клиенту не казалось, что цена идет только за брэнд EMC, когда он сравнивает VSPEX BLUE с практически точно такой же (по железным характеристикам) системой от Supermicro (например).

В EMC это прекрасно понимали и на разработку решения потратили довольно много времени и приложили максимум усилий, чтобы потенциальный клиент понимал, что не зря тратит свой бюджет. 
VSPEX BLUE front

VSPEX BLUE back
Что касается аппаратной части, то здесь всё довольно стандартно - можно выбрать между двумя моделями - 128ГБ памяти на узел, либо 192ГБ. Других отличий нет -  2 процессора Intel Xeon E5-2620 V2, 3*1.2TB SAS, 400GB SSD, 2*10G ethernet. Всё, что потребуется клиенту для запуска - стойка, коммутатор (10Гбит), электропитание и ноутбук для настройки. EMC обещает, что за 15 минут можно вполне уложиться с первоначальной инициализацией системы и уже приступать к созданию виртуальных машин. Настройка, по большей части, происходит автоматизировано и от администратора требуется минимум участия.

Так что отличия решения от конкурентов это конечно не железо, а программные “фишки”. 

Первая отличительная особенность, которая сразу бросается в глаза - существенно расширенная система управления (Blue Manager). Она позволяет администратору “видеть”, что происходит с железом на более низком уровне, чем стандартный vCenter. В нее встроены ссылки на дополнительный, предназначенный для VSPEX BLUE, софт от EMC (о нем чуть ниже). Присутствует и доступ к ресурсам технической поддержки, все сервисы, как это теперь модно, "в одном окне".

Раз речь зашла о поддержке, то мы помним, что ранее VSPEX был лишь референсным дизайном для партнёров и именно они должны были обеспечивать первый уровень поддержки. Напротив, VSPEX BLUE это система, которая поддерживается EMC “от и до”. Более того, система ESRS (EMC Secure Remote Services) сама периодически отправляет информацию о состоянии оборудования в службу поддержки (если конечно есть доступ в интернет), поэтому, если не очень внимательно относиться в средствам мониторинга,  вы сможете получить сигнал от службы поддержки ещё даже до того, как узнаете о потенциальных проблемах. Проактивный удалённый мониторинг всегда является большим плюсом для заказчика,так как позволяет отчасти переложить ответственность на плечи вендора. Поддержка уровня Premium, помимо времени реагирования 24*7*4 на критичные проблемы,  включает в себя еще и установку апдейтов на систему, так что про обслуживание можно практически забыть и заниматься только развертыванием нужных сервисов (и управлением ими).

Защита от сбоя в рамках кластера это прекрасно, но для компаний, использующих более одной площадки для размещения своей ИТ-инфраструктуры, довольно часто бывает востребован такой функционал как репликация данных для обеспечения отказоустойчивости. Поэтому в поставку уже включены лицензии на RecoverPoint for Virtual Machines - по 15 лицензий на каждый из физических серверов, т.е. каждый appliance поддерживает репликацию до 60 виртуальных машин. Это полностью программное решение по репликации и не требует никакого дополнительного оборудования. Но даже если у вас нет удаленной площадки, никто не мешает использовать локальные реплики для быстрого восстановления в случае сбоя (это совсем не то, что снапшоты внутри VMware). Мы можем сами указать требования по RPO для наших виртуальных машин и обеспечить уровень доступности сервисов, соответствующий бизнес-задачам.

Ещё одной особенностью системы является система резервного копирования VDPA (а не только VDP, входящая в состав лицензии на Enterprise Plus) с коннектором для Data Domain. Ведь нельзя же делать резервную копию данных на сам VSPEX BLUE. :) Вся необходимая программная часть уже включена в поставку  VSPEX BLUE (конечно, кроме самого Data Domain). Поддержка дедупликация и высокой скорости disk-to-disk резервного копирования позволяют оптимизировать схему бэкапа и минимизировать его влияние на продуктивную среду. Одна из "младших" систем Data Domain станет отличным дополнением к проекту по внедрению.

Меня всегда настораживал ограниченный объем дискового пространства, который характерен для систем EVO:RAIL -  в случае с EMC это по 3 диска 1.2TB SAS плюс 400GB SSD для VSAN Cache на каждый узел. Это даёт примерно 12ТБ на систему, но ведь полезная емкость будет ещё минимум в 2 раза меньше. Конечно, 6ТБ это не так мало, но, по современным меркам, совсем не так уж и много. Поэтому ещё одна “фишка” системы нацелена как раз на тех, кому нужен объем, но нет желания ставить свою собственную дополнительную дисковую систему (либо из-за невысоких требований к производительности, либо из-за того, что обращение к данным не такое уж и частое). Каждый покупатель VSPEX Blue получает возможность подключить до 10ТБ данных из “облака” (Amazon, Google и др.) к EMC Cloud Array VE. Поддерживается до 1ТБ локального кэша, который обеспечивает высокую производительность при работе с “облачными” данными. В облаке можно размещать как данные, так и непосредственно образы виртуальных машин (работающих!).

И, да, для тех кому мало одной системы - можно поставить до 4х VSPEX BLUE в один кластер (16 физических хостов). 

Получилась довольно интересная система, тем более, что на таком массовом рынке серверов EMC никогда не играла. Посмотрим, насколько быстро получится "отхватить" долю. Весьма успешный и совсем недавний пример Cisco подтверждает, что можно и с места высоко прыгнуть.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

понедельник, 28 мая 2012 г.

EMC VNX–что день грядущий нам готовит

Я уже писал про новости в high-end системах EMC, но гораздо более интересным для меня является анонс новых возможностей систем среднего уровня – VNX. И дело не в том, что такие системы гораздо больше распространены и в разы больше продаются. Речь о тех технологических возможностях, которые в них появятся. Да, несмотря на анонс, их пока нет и ждать их стоит во втором полугодии 2012. Так что же было объявлено?

Если кто-то вникал, как именно работают пулы (pools) в VNX, то наверняка обратил внимание на “магические” числа. Это, в частности, число “5” для RAID5 и “8” для RAID-6. Дело в том, что при создании пулов, именно такой размер RAID-группы всегда старается выбрать система. Конечно, если дисков недостаточно, то пул все равно будет создан, но  в одной из RAID-групп дисков будет недостаточно (или слишком много), а это скажется на равномерность нагрузки. Подробности можно прочитать вот в этой замечательной заметке, либо в ее переводе здесь. Таким образом, для RAID5 эффективность использования дискового пространства составляет 80%, а для RAID6 – 75%. В новой версии было принято увеличить размер дисковых групп – для RAID5 он может составлять 8+1 (эффективность 88.9%), а для RAID6 даже 14+2 (эффективность 87.5%). С одной стороны, это позволит несколько повысить эффективность использования дисков. С другой стороны, планирование системы становится еще более творческим занятием. Предположим, что нам нужен пул из NL SAS дисков. Логично использовать RAID6 и, как следствие, мы вынуждены использовать 17 дисков (одна группа 14+2 и пригодится хотя бы 1 hot-spare диск). Если же нужно увеличить объем системы, то дисков нужно уже 33 (а лучше бы 34). И здесь мы сталкиваемся с тем, что уместить 34 диска в дисковые полки по 15 дисков довольно проблематично, а значит потребуется 3я полка, которую мы также не сможем заполнить. В любом случае, выбор “большой” RAID группы накладывает определенные ограничения на апгрейд системы (в плане стоимости такого апгрейда). Конечно, есть полки высокой емкости, но и там диски “ровно” не укладываются.

Такими изменениями производитель нам как бы сам намекает, что оставшееся место самое время заполнить дисками SSD, чтобы использовать все прелести FAST Cache или FAST VP. И здесь мы сталкиваемся с новым изменением – в пул можно будет включать RAID-группы разного типа, т.е. в пул с  RAID6 из NL SAS дисков можно спокойно подключить RAID5 из SSD дисков (сейчас пользователь вынужден использовать только один тип RAID внутри пула, независимо от типа дисков).

image

Изменения коснулись и технологии FAST VP – в новом релизе данные будут сначала попадать на SSD, а уже потом перемещаться на более медленные диски. Такой подход имеет свои плюсы и минусы, но зато позволяет получить немедленный видимый эффект от использования SSD. И становится заметно проще демонстрировать преимущества от FAST VP заказчику – достаточно немного нагрузить систему. Фактически, технология FAST VP становится более похожей на FAST Cache (хотя отличия, несомненно, остаются).

В упомянутой выше статье было много сказано про недостатки пулов в VNX, связанные с расширением дискового пространства. Похоже, что и эту проблему в EMC не обошли своим вниманнием – помимо уже описанных новшеств, нас ждет еще и автоматическая ребалансировка внутри пула. При добавлении дисковых групп в общий пул, произойдет перераспределение данных по пулу. С одной стороны, это очень хорошо – добавили диски и увеличили производительность, а не только объем. С другой стороны, перераспределение занимает время и нагружает контроллеры. А как обычно происходит? Диски добавляем, когда уже и места нет, и производительность ниже необходимой. Планируйте своевременно апгрейды! (Это правило, кстати, относится не только к EMC, но и ко всем другим системам).

Ну и самое радикальное новшество – на пулах появятся новые снапшоты! Это действительно принципиальное изменение (и я понятия не имею, почему еще все производители, которые так рекламируют thin provisioning, не начали так делать). Появляются снапшоты, работающие по технологии redirect on write. Т.е. больше нам не нужно резервировать отдельное место под мгновенные снимки и системе не нужно копировать “старые” данные в этот резервный пул. В случае redirect on write новый блок данных (после создания снимка) просто записывается в новое место, а LUN “собирается” на основе указателей. Т.е. примерно так, как это реализовано в NetApp или в IBM XIV. А это дает существенные преимущества – до 256 снимков на том, нет потери производительности из-за использования снимков, возможность делать снапшоты снапшотов, доступность снапшотов на запись. Да, да -  извечные противники в плане технологий стали еще ближе друг к другу! Если NetApp выступает своего рода первопроходцем, то EMC идет по намеченному курсу, делая нужные изменения (не факт что в нужный момент, но зато не приходится растрачиваться на рекламу новых фишек – публика уже “подогрета” рассказами NetApp).

Но гонка с NetApp на снапшотах не закончена и у VNX появляется еще один дополнительный программный продукт – AppSync. Он предназначен для защиты приложений (на старте - Exchange и VMware, потом планируются и другие). Пользователь задает уровень доступности  (SLA) для конкретного приложения и может самостоятельно восстанавливать данные в случае сбоя.

Большинство из объявленных новшеств доступны только в системах VNX, а владельцам VNXe придется подождать – из-за особенностей реализации блочных протоколов в VNXe.

Посмотрим, что готовят конкуренты в ответ!

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 22 мая 2012 г.

EMX VMAX 40K

imageКак обычно, громко и шумно EMC анонсировали новую high-end дисковую систему. На смену VMAX и VMAXe пришли аж целых три системы - VMAX 10K, 20K и 40K. Правда, здесь есть и небольшой подвох - 10K и 20K вроде как никуда и не пришли. А не пришли они из-за того, что никуда и не уходили - это уже хорошо знакомые нам VMAXe и VMAX, только с новыми названиями. Действительно, в прошлый раз маркетологи в EMC явно перемудрили и назвали все модели новыми именами (VMAX, VPLEX, VNX...), но никто не побеспокоился о том, что же делать, если потребуется все-таки их немного усовершенствовать - процессоров там добавить, либо еще что-нибудь прикрутить. Вот и пришлось теперь менять название. Что касается новой “звезды” в лице VMAX 40K, то из “железных” изменений все довольно ожидаемо - более современные шестиядерные процессоры (2.8ГГц Westmere), больше кэш памяти плюс шина PCI express 2.0:

 image

За счет этого добились (по заявлениям) двукратного роста производительности в бэкенде и на линейных нагрузках “снаружи”. Что касается OLTP нагрузки, то здесь декларируется примерно 25% роста. Без изменений осталось максимальное поддерживаемое количество дисков 3.5” (2400), но зато можно использовать до 3200 дисков форм-фактора 2.5” (причем их можно установить до 400шт в стойку). Как и прежде, используется FC бэкенд и FС диски. Кроме EMC и HP (3PAR) в системах high-end c FC дисками никого не осталось - IBM и Hitachi уже давно перешли на SAS. Существенное ограничение - нельзя смешивать в одной системе диски 2.5” и 3.5” (не только в одном шкафу, но и вообще во всей системе). Нельзя и проапгрейдить 10K до 20K, а 20K до 40K, так что, несмотря на схожесть названий, эти системы разделены жестким барьером и пользователь не имеет возможности вспрыгнуть на подножку стремительно уходящего поезда прогресса, зацепившись за “младшую” систему. Хотите перспективы - берите сразу 40K.

Видимо в EMC получили ряд нареканий о том, что затруднительно бывает разместить монстра VMAX в ЦОД из-за нехватки площадей, поэтому сейчас можно “разбросать” части VMAX 40K (опять же, только 40K!) по ЦОД (в пределах 25м).

Если с точки зрения железа все, как я и написал, ожидаемо и логично, то в софте добавилось возможностей несколько больше. Самое заметное - Federated Tiered Storage (FTS). Говоря простыми и понятными словами, это виртуализация внешних (сторонних) СХД. “Сторонних” звучит, правда, несколько натянуто - на первом этапе поддерживаются только Symmetrix DMX-4, DMX-3, DMX, CLARiiON CX4 / CX3, VNX и (вот же она, “сторонняя система”!) Hitachi USP-V. Список конечно весьма и весьма скромен, да и виртуализация динозавра в лице DMX3 (а и USP-V тоже) выглядит довольно - нужно дважды заплатить за лицензии на емкость - сначала за емкость самого DMX3, а потом за нее же, но уже в ценах для VMAX. Однако хочется надеяться, что список протестированных и поддерживаемых устройств будет расти. Виртуализованная емкость может использоваться со всеми замечательными функциями (FAST VP, TimeFinder, SRDF, VLUN). В этом плане VMAX выглядит, на мой взгляд, даже немного интереснее, чем VPLEX. С другой стороны, получается соревнование по функционалу между двумя “топовыми” продуктами одного производителя. Уж лучше бы сделали “VMAXPLEX”, который бы обладал преимуществами обеих систем! Из приятного - Federated Tiered Storage доступен не только на VMAX 40K, но и на 20K (напомню, что это нынешний VMAX).

Для FAST VP появилась возможность интеграции с SRDF и теперь на удаленной площадке система в курсе о том какие блоки должны лежать на быстрых дисках, а какие - нет. Теперь при переходе на резервную площадку можно надеяться на сопоставимую производительность (если конечно системы на площадках идентичны).

Перевод всех бородатых администраторов на простой и понятный GUI продолжается, поэтому теперь можно управлять VMAX из красивого Unisphere (правда, с приставкой “for VMAX”).

Программные улучшения коснулись в том числе и интеграции VMAX с RecoverPoint (поддержка сплиттера на уровне СХД).

Получилась ли принципиально новая система? Не уверен – подавляющее число новшеств это либо результат планового развития архитектуры x86, либо усовершенствования очередного релиза Enginuity. Остается открытым и вопрос узких мест – апгрейд узлов и увеличение дисков в бэкенде на 33% привели лишь к 25% росту производительности (OLTP). А как на производительность будет влиять FTS? Подрастет ли производительность за счет кэша VMAX или, напротив, подрастет только латентность? Если FTS позволяет использовать возможности VMAX на системах класса ниже, то смогут ли разработчики перенести эти возможности в VPLEX (ах, как этого недостает!)?

Как обычно, много вопросов на которые мы сможем найти ответы лишь по прошествии некоторого времени и (ведь такое хотя и маловероятно, но тоже может случиться!) каких-то публичных тестов. Но это я уже совсем размечтался наверное!

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

понедельник, 13 февраля 2012 г.

Кэшировать всегда, кэшировать везде!

Уже во время анонса системы IBM XIV Gen3 было объявлено о скорой поддержке SSD внутри модулей. “Скоро” уже настало и вот теперь можно не только заказать новый XIV Gen3 с установленными SSD дисками, но и установить SSD в уже инсталлированную систему XIV Gen3 (процедура не требует остановки – только обновления микрокода). В каждый узел XIV можно установить по одному диску SSD 400GB (суммарно это даст от 2.4ТБ до 6ТБ на систему, размер немного занизили – изначально обещали диски по 500GB). Почему так мало? Потому что это пространство может быть использовано только как кэш чтения, а не для хранения самих данных, а 6ТБ кэш памяти это не так уж и мало. Кэшируются только операции чтения – для кэширования операций записи используется оперативная память узлов XIV (суммарный объем которой достигает 360GB). Чтобы обеспечить для SSD модулей долгое и безоблачное существование под высокой нагрузкой используется специальный механизм оптимизации: изначально в оперативной памяти узла формируются блоки размером по 512КБ и уже именно эти блоки последовательно и циклично записываются на SSD. Таким образом, операции записи на SSD всегда идут последовательно, а ячейки используются равномерно. Обещают неплохой прирост в производительности:

image

Решение, предложенное в XIV безусловно не является технологическим прорывом – всем уже вспомнился и EMC FastCache, и NetApp FlashCache. Каждое из этих решений имеет и свои плюсы, и свои минусы. От EMC FastCache заказчик получает не только кэширование при чтении, но и кэширование операций записи. Платой за это является существенное сокращение кэша в оперативной памяти SP и сравнительно небольшой объем – для “топового” VNX7500 он составляет 2.1ТБ (при использовании 100GB дисков). В случае с NetApp FlashCache кэшируется только чтение, но зато кэш является дедублицированным и может достигать 16ТБ. Кроме того, FlashCache является PCI-e платой, поэтому “дорога” от кэша до процессора (а значит и до хоста) гораздо короче, чем при использовании SSD дисков. А это, в свою очередь, потенциально позволяет получить довольно низкую латентность. С другой стороны, если мы захотим получить 16ТБ кэша, то на придется задействовать 16 слотов расширения из 24х возможных, что существенно ограничит возможности расширения (как по дискам, так и по используемым протоколам подключения хостов).

EMC тоже отметились и с шумом выкатили свое решение для кэширования VFCache (Very Fast Cache). Что это и как “привязано” к дисковой системе? По факту VFCache это обычная PCI-e плата (как и аналоги у FusionIO, LSI и пр.) 300GB (производства Micron), которая используется не как супер-быстрый диск в операционной системе, но как кэш для операций чтения.

image

В принципе (насколько я понял из прочитанного/найденного), никто не мешает использовать VFCache с любой дисковой системой (и без нее в т.ч.). Можно даже часть VFCache “отрезать” и использовать как жесткий диск. Среди явных минусов – пока поддерживается только одна карта в сервере, так что использование части VFCache как DAS, не может обеспечить отказоустойчивость. Кроме того, поддержка в VMware серьезно ограничивает такой функционал как vMotion (а точнее он просто не поддерживается). В данном случае решение EMC тоже уникальным не назовешь. Один из пионеров в выпуске PCI-e SSD карт – FusionIO уже некоторое время предлагает аналогичный продукт ioCache (который, кстати, vMotion как раз поддерживает). Есть надежда, что в последующих релизах VFCache будет существенным образом доработан и появится не только более тесная интеграция с VMware, но и с собственными продуктами (FAST Cache/ FAST VP).

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 14 декабря 2010 г.

Семь негритят дрова рубили вместе…

Массовое поглощение производителей систем хранения данных идет полным ходом. Большие игроки стремятся собрать наиболее полный пакет решений под свою марку, чтобы иметь возможность конкурировать на всех фронтах. Сначала DataDomain, потом 3PAR, в ноябре было объявлено о намерениях EMC по приобретению Isilon. Несколько дней назад Dell заявил о предварительной договоренности с Compellent. Я уже не вспоминаю более ранние истории с XIV, Exadata, EqualLogic и другими. Если XIV, EqualLogic, DataDomain и 3PAR сразу нашли свою нишу у покупателей, то Exadata исчезла и про продукт ничего не слышно. Может быть и будет какое-то продолжение, но столь длительное “молчание” не добавит очков и без того очень нишевому продукту. А кто же остается? DDN, Panasas, Pillar, Xiotech, да наверное больше и назвать некого.  Думаю, что к кому-нибудь из них уже приглядываются потенциальные покупатели. Из покупателей пока “самым голодным” должен быть все тот же Dell, существенную долю в продажах пока еще составляют системы EMC – EqualLogic хорошие системы, но могут “играть” только в нижнем сегменте. С приобретением Compellent, возможностей по продаже собственных систем хранения у Dell существенно прибавится. А может быть следующим покупателем будет Oracle? От перепродаж HDS уже отказались, может быть пора и от LSI отказаться, а вместо этого прикупить что-то себе?

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 27 мая 2010 г.

Маркетинг против технологий

Не могу не скроспостить сообщение из блога про NetApp уважаемого romx. Речь про анонсы различных технологий в системах хранения компанией NetApp и реакцию EMC на эти анонсы. Собственно картинка:

В третьей колонке – время анонса аналогичных технологий в системах EMC.

По большому счету – ничего удивительного, так делают буквально все. Если конкурент анонсирует решение, то самое правильное – сначала поругать, а если уж пойдет, то надо и у себя внедрять. Но, тем не менее, выглядит очень забавно.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 13 мая 2010 г.

Убийца SVC где-то рядом?

Еще один уверенный шаг EMC в сторону концепции IT as a Service сделан. Под брызги шампанского и бурные овации на EMC World 2010 анонсирован VPLEX. Выбранное имя конечно не удивляет – сейчас продукт, в названии которого не будет буквы “V”, могут представить только аутсайдеры (даже если к виртуализации никакого отношения продукт и не имеет, а здесь-то как раз виртуализация на месте). Прозвучали и громкие слова “Storage federation”. VPLEX преподносится как таблетка от всех проблем, связанных со сложностью администрирования разрозненных “островков” систем хранения. Казалось бы, что нового? Все это уже давно есть и у IBM (SVC), и у HDS (USP-V), и даже у самой EMC (Invista) – системы виртуализации СХД уже не первый год на рынке. image Но ключевой особенностью VPLEX является возможность объединять не только СХД, расположенные на одной площадке, но и системы территориально распределенные (в перспективе – на сколь угодно большие расстояния). Можно сказать, что VPLEX это вертикально и горизонтально масштабируемая система виртуализации СХД, позволяющая использовать глобальный (распределенный) кэш. В основу продукта положены технологии приобретенные вместе с компанией Yotta Yotta. Вполне логично, что VPLEX эффектно подается в связке с VMware vMotion как решение, позволяющее беспрепятственно перемещать нагрузку между датацентрами и, тем самым, обеспечивающее максимальную гибкость и подкупающую простоту администрирования. Идея произвольным образом “двигать” сервисы между площадками если смотреть “сверху” конечно импонирует (по крайней мере, до того как надо будет закопаться в детали). Привлекательно выглядит возможность передвигать ресурсоемкие сервисы по часовым поясам в зависимости от стоимости вычислительных ресурсов в данное время суток. Звучит красиво, ничего не скажешь!

Но, как и всегда, есть несколько “но”. В настоящее время VPLEX поставляется только в двух вариантах – VPLEX Local (для работы на одном сайте) и VPLEX Metro (для объединения двух площадок, расстояние между которыми позволяет использовать синхронную репликацию, т.е. до 100км). В первом случае решение ничем не отличается от любой другой системы виртуализации СХД,  во втором конечно есть отличия, но и здесь конкурентам есть что предложить. Справедливости ради нужно сказать, что в перспективе EMC обещает еще две версии VPLEX – Global, для объединения двух площадок на расстоянии более 100км (асинхронная репликация) и VPLEX Geo, который уже позволит объединять несколько датацентров на произвольном расстоянии друг от друга. Все это, однако, ждет нас не раньше 2011 года. Кроме того, функционал VPLEX в плане виртуализации также довольно ограничен на текущий момент – поддерживаемые “чужие” СХД (IBM, HDS) можно пересчитать на пальцах одной руки (список конечно планируют еще расширять); нет поддержки ни thin provisioning, ни мгновенных снимков – если это необходимо, то придется пользоваться функционалом СХД. Собственно, из-за этого скорее всего и не было объявлено о смерти Invista. Картина становится несколько мрачнее – в настоящий момент VPLEX для большинства не принесет долгожданной простоты управления, а скорее добавит сложностей. Нужно будет не только научиться управлять VPLEXом, но и продолжать следить за виртуализированными СХД и, возможно, гораздо аккуратнее заниматься выделением пространства, так как теперь между СХД и серверами окажется новое устройство, которое будет усложнять представление данных.

imageЧто же за устройство скрывается за красивым названием VPLEX? Минимальный модуль (VPLEX Engine) состоит из двух кастомизированных x86 серверов (каждый отдельно называется Director), упакованных в одно шасси высотой 4U. Каждый director оснащен двумя 4х ядерными процессорами, 32ГБ памяти и имеет 16 дисков и 16 хостовых портов FibreChannel 8Gbit. Разумеется в комплекте обязательным образом идет еще и SPS (ИБП). Максимум в кластер для увеличения производительности можно объединить до 4х Engine (получается 8 директоров). Друг с другом директоры общаются через выделенные FC порты (помимо упомянутых выше 32х штук), для чего используются отдельные коммутаторы. На каждом директоре присутствует по 2 порта для взаимодействия внутри кластера и 2 порта для взаимодействия с удаленными комплексами. В максимальной набивке комплекс VPLEX выглядит примерно как на картинке справа. Помимо 4х узлов и двух коммутаторов в стойке также размещается управляющий сервер, через который собственно и происходит вся работа с VPLEX. Из 32ГБ памяти каждого директора, в качестве кэша используется около 20ГБ, таким образом, на каждой площадке можно получить до 160ГБ кэша. Кэш используется только для чтения: при получении запроса VPLEX проверяет наличие данных у себя в кэше, если данных там нет, то проверяется глобальный кэш (память остальных узлов) и только если данных не оказывается и там, делается запрос на чтение с дисков. Вся запись ведется “сквозным” образом, т.е. подтверждение хосту об успешном завершении отправляется только после того как VPLEX получит соответствующее подтверждение от всех дисковых систем, участвующих в записи блока данных. Так как VPLEX это по сути своей система виртуализации СХД, то выделение LUNов хостам делается через VPLEX (хотя конечно можно и просто “пробрасывать” LUN с дисковой системы без изменения).  imageВ общем случае, картина примерно такая: LUNы, созданные на дисковой системе, отдается во владение VPLEXу, на них создается один или несколько экстентов (extent) произвольного размера, затем эти extent объединяются в девайсы (devices), на которых можно уже создать виртуальные тома (virtual volume) и уже эти самые virtual volume можно раздавать хостам. На первый взгляд немного запутано, но практически все системы виртуализации так и работают. Каждый комплекс VPLEX может раздавать хостам до 8000 LUNов.

Итак, анонс прошел, фанфары прозвучали, что в сухом остатке? Отношение неоднозначное. Сказать, что EMC “стрельнули” уникальным продуктом я не могу. Вот если бы все это было реализовано на базе VMAX, это было бы действительно “круто”! Концептуально предложенное решение мне, впрочем, и так нравится. Но вот что не нравится: отсутствие кэша на запись, отсутствие таких функций как thin rpovisioning, снимки, клоны и т.п. Сейчас можно говорить лишь только об озвученном плане на будущее развитие. План радужный, но насколько он будет воплощен в жизнь остается под вопросом. А пока заказчикам остается выслушивать истории про Storage Federation и IT as a Service ну и конечно про Cloud Computing. Впрочем, если вдруг прямо сейчас нужно взять и начать строить (именно начать) пресловутое облако, то возможности VPLEX могут оказаться востребованы. Для двух площадок можно даже обойтись и без VMware SRM, продолжая обеспечивать высокий уровень доступности сервисов. Так что заказчики на VPLEX безусловно найдутся, но сможет ли он серьезно потеснить IBM SVC (или хотя бы HDS) на рынке систем виртуализации – большой вопрос. И на сегодняшний день мой прогноз – в ближайший год шансов очень и очень мало.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 9 февраля 2010 г.

SPC-1, IBM SVC, DS8700 и другие…

Сегодня конечно надо писать про POWER7 или в крайнем случае про Itanium, но об этом и так напишут без меня. Единственное что мне в этом анонсе интересно, будет ли реакция оракла в виде изменения коэффициентов при расчете лицензий. Мне же сегодня хочется вспомнить про опубликованные на прошлой неделе результаты тестирования дисковых систем.

Про выход EMC из тени и возврат в тесты sfs2008 (впервые с 2007го года) с Celerra Gateway NS-G8 и Symmetrix V-Max, набитой SSD, не написал еще только самый ленивый приверженец нетапа. При всей нелюбви EMC к синтетическим тестам, заход с публикацией тестов действительно довольно странный – и ладно бы результат был бы рекордным, так нет, ни флагман хай-энда V-Max, ни использование SSD (EFD) дисков не дали забраться на пьедестал почета. Впереди оказались и NetApp, и BlueArc, и Exanet…

А вот про IBM с его результатами тестов SPC-1 для DS8700 остался как-то в тени. Что же тут такого? Удивляет, что с момента выхода DS8700 прошел уже не один месяц и, если результаты появились только сейчас (и это при всей любви IBM к публикации результатов всевозможных тестов), то в чем причина такой задержки? Может быть система оказалась слабее, чем HDS USP-V, которая занимала первое место в SPC-1 среди хай-энда уже более двух лет? (Да, у IBM был результат и выше, но он был у SVC в связке с несколькими DS4700) Или все дело в том, что радикального преимущества можно было достичь только на числе дисков, большем нежели в USP-V (а там их было 1024)? И потребовалось добавить SVC, чтобы объединить две системы DS8700 и получить в сумме 2048 дисков. Все это нам, простым людям, узнать наверное не получится, но давайте посмотрим на результаты:

 

HDS USP-V

IBM DS8700 + 4xSVC

IBM DS8700 + 6xSVC

SPC-1 IOPS

200 245.73

315 043

380 489.3

$/SPC-1 IOPS

17.61

22.65

18.83

С одной стороны, критики SPC как инструмента для сравнения вроде бы правы и увеличение числа дисков в два раза дает почти в два раза лучший результат. С другой стороны, апологеты SPC тоже с виду правы, так как могут сказать, что качественное улучшение платформы (увеличение числа узлов SVC) при неизменном числе дисков может дать существенный прирост (в данном случае - примерно 20%). Но давайте взглянем немного более внимательно на результаты тестов:

 

HDS USP-V

IBM DS8700 + 4xSVC

IBM DS8700 + 6xSVC

SPC-1 IOPS

200 245.73

315 043

380 489.3

$/SPC-1 IOPS

17.61

22.65

18.83

resp. time      

100% load

4.99ms

28.13ms

7.64ms

90% load

3.89ms

10.36ms

5.20ms

80% load

3.62ms

7.19ms

4.36ms

Drives

1024 x 146GB

2 x 1024 x 146GB

2 x 1024 x 146GB

ASU, GB

26 000

97 581.657

97 581.657

ASU, % used

17%

32%

32%

В табличку мы добавили время отклика при 80, 90 и 100% нагрузки, а также информацию по числу дисков и их утилизации (%, который составляет размер ASU от общего пространства). Что изменилось? На мой взгляд, приведенные результаты свидетельствуют только о том, что добавление 2х узлов к 4х узловому кластеру SVC было вынужденным действием. “Дури” у DS8700 оказалось столько, что 4х узлов просто было недостаточно. Два дополнительные узла проблему решили и “бутылочное горло” пропало и, как следствие, снизилось время отклика. Попутно хочется обратить внимание на еще один немаловажный параметр – размер ASU. Конечно после учета всевозможных расходов на метаданные, спаре-диски и зеркалирование размер “полезной” емкости будет меньше 50%, но вот насколько меньше? В случае с HDS объем ASU составлял 17%, а в случае с IBM – 32%, а это почти в два раза выше. Почему это важно? Достаточно взять в руки iometer и потестировать любой массив, варьируя размер тестируемой области. Типичный график зависимости IOPS от используемого дискового пространства на рисунке:image

Таким образом, размещая данные в начальных областях дисков можно заметно повысить свой рейтинг в тестах. Какой можно сделать вывод? Боюсь что никакого толкового сделать нельзя. Хороша ли HDS USP-V? Безусловно! Результаты отличные (особенно учитывая то, что им уже более двух лет). Может быть плоха IBM DS8700? Конечно нет! SVC скорее всего все-таки был нужен именно для того, чтобы иметь возможность использовать 2048 дисков, а не для повышения производительности.

И в свете всего вышесказанного, мне не совсем понятно как IBM преподносит свой хай-энд в тестах и почему именно такая конфигурация была выбрана для тестирования:

  • Почему не взяли 8 узлов SVC? (неужели больше не было никакого эффекта?)
  • Почему не использовали SSD диски в DS8700? (может быть из-за ограничения на число дисков?)
  • Почему даже в SVC не использовались SSD? Объем кэша в двух DS8700 суммарно в три раза больше, чем у USP-V, но в расчете на размер ASU получается все-таки меньше и дополнительное кэширование должно было дать эффект (или все-таки нет?).

Вполне вероятно, что со временем последуют другие, более интересные результаты, которые прояснят ситуацию. Время покажет. Но относиться к результатам SPC (да и другой синтетики) нужно очень и очень аккуратно. Так как даже если считать, что сам тест предполагает воспроизводимость результатов и объективную методику тестирования, нужно признать что трактовка результатов (в первую очередь из-за огромного числа варьируемых параметров) вызывает больше споров и сомнений, нежели понимания общей картины.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 9 июня 2009 г.

НЕкорпоративное видео

EMC в "лучшем" свете:

is that another fucking company I have to buy?
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 2 июня 2009 г.

EMC очень хочет отнять Data Domain у NetApp

Как оказалось, EMC очень хотят, чтобы DataDomain достался все-таки им (хотя, наверное, еще больше не хотят чтобы его получил NetApp), поэтому предложили уже 30$ за акцию, что соответствует примерно 1.8млрд$ в кэшэ. Предложение явно выгоднее, чем то, которое NetApp сделал немногим ранее (у NetApp нет столько кэша не то, чтобы переплюнуть EMC, но даже и чтобы сравнять ставки). Пока, впрочем, никто ничего внятного не сказал, но вполне возможно, что EMC получит в дополненение к своему Amavar еще и аппаратное решение по дедупликации. Ни NetApp, ни DataDomain комментарии пока никакие не дали.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

среда, 29 апреля 2009 г.

Из огня да в ... HP

Вот буквально совсем недавно объявили, что David Donatelli, долгое время проработавший в EMC, перешел в HP на должность executive vice president Enterprise Server, Storage and Networking (ESS). Очень интересно будет увидеть, как такое перемещение (все-таки Донателли был очень и очень заметной фигурой в стане EMC) отразится на успехах обеих компаний.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

среда, 15 апреля 2009 г.

Не оставаться же в стороне!

Все вокруг заполнено новостями про выпуск EMC Symmetrix V-Max. Вынужден поддаться соблазну и тоже написать пару слов :)

Система действительно новая и, наверное можно даже сказать, революционная. EMC ушла от уже ставшей привычной (с момента выпуска DMX) матрицы соединений между фронт-эндом, кэшем и бэкэндом. Официальная точка зрения состоит в том, что архитектура DMX является безусловно лучшей, но не позволяет расти в "ширь", поэтому вместо Direct Matrix теперь будет Virtual Matrix, которая (помимо всего прочего) позволит почти бесконечно наращивать производительность, объем, число обслуживаемых хостов, добавляя новые модули. Что же из себя представляет V-Max Engine? По сути своей это обычная пара серверов, конечно выполненных в кастом-дизайне. Внутри - стандартные интелловские процессоры, вся архитектура тоже стандартная. Ключевой момент - объединение нескольких V-Max Engine в единое целое, для этого используется технология RapidIO - в результате каждый Engine имеет доступ к памяти другого комплекса, как к своей локальной, т.е. сохраняется идея "общего/глобального" кэша.

На текущий момент можно объединить вместе до 8-ми V-Max Engine, а в дальнейшем можно будет увеличивать их число еще больше, давая возможность создавать небывалую по мощности/объему, да и просто небывалую единую управляемую систему. В плане софта тоже очень много новинок - прозрачная миграция между EFD-FC-SATA дисками, поддержка SRDF с ранними моделями, радикально упрощенное выделение дискового пространства серверам.

Некоторый скептицизм вызывают восклицания о новизне решения - "первое в мире", "единственное", "неповторимое". Спишем это наверное на маркетологов - пусть кричат. Потому как первая high end система на стандартных компонентах появилась уже очень давно - IBM ESS/DS8000, масштабируемость тоже не есть что-то революционное (тот же IBM со своим SVC - да, конечно, там нет общей памяти, но сама идея отнюдь не нова).

Еще одна ожидаемая, но так и оставшаяся среди ожидаемых, возможность - виртуализация. EMC не пошла по пути HDS и не стала добавлять такой функционал в свой V-Max. Видно безуспешность инвисты (на фоне остальных решений) похоронили идею виртуализации окончательно.

Много полезной и интересной информации можно почерпнуть на блоге Barry Burke (вот ссылки на конкретные посты): symmetrix v-max - a revolutionary evolution; inside the virtual matrix architecture; symmetrix v-max - scale up, scale out, scale away!; fully automated storage tiering (fast)

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 14 апреля 2009 г.

А тем временем в замке...

Хотя анонса еще не было, но уже отовсюду начинает просачиваться информация относительно новой (как утверждается, радикально новой) системы EMC Symmetrix V-Max. Barry Burke уже выложил у себя на блоге ролик, на котором (без особых подробностей) можно увидеть саму систему в максимальной набивке (11 шкафов, 2400 драйвов):

Ждем анонса и подробностей...
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 19 марта 2009 г.

SSD - хорошие вещи должны быть большими?

EMC анонсировали EFD (SSD) диски объемом 200 и 400ГБ для системы Symmetrix DMX-4. Через некоторое время обещают доступность и в младших системах (CLARiiON, Celerra). Как я понимаю, это все те же STEC Zeus IOPS (хотя у стека заявлены немного другие размеры).
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!