История про интеграцию Unity 400F, Wabi-Sabi и гонке на ¼ мили.

Пошел уже 153 год, как с легкой руки Льюиса Керролла идея о мирах, где “Красная Королева должна бежать, чтобы оставаться на месте” заражает своей модной эпистемой самые широкие круги читателей. Западные традиции, лежащие в основе этого разрыва в археологии знаний настолько сильны, что для душевного равновесия на другую чашу весов требуется поместить не менее фундаментальные восточные концепции. В этом смысле очень показательна история создания СХД Unity. Если обратить внимание на позиционирование этой СХД самим производителем, то у интеграторов может ненароком случиться инсайт или душевное расстройство от предвкушения очередной гонки за выживание:

По показателям $/GB и “Solution Integration” у СХД твердая пятерка, а по отказоустойчивости и стоимости операции – четверка. Просто-напросто, райский уголок для интеграторов в SMB секторе. Когда эта “паутина” в первый раз попалась мне на глаза, то первая реакция на нее была очень резкой – пустой маркетинговый ход. Действительно, если в контексте интеграции решения предлагается сосредоточить внимание сразу на нескольких точках из указанной выше паутины, то, как оценить ее эластичность? Часто подобные диаграммы рисуют исходя из того, что одна твердая пятерка в ней достижима только по отдельности, за счет снижения остальных показателей. В этом смысле, интереснее всего те нагрузочные тесты, в которых СХД демонстрирует размер диагоналей в отмеченной фигуре, а не ее площадь в последовательных тестах по точкам. Тогда и возникает возможность оценки эластичности этой фигуры при комбинировании указанных параметров. Попробуем поставить эту задачу так, чтобы она была еще и с инженерной точки зрения не самой банальной:

·          Как испытание на надежность (RAS) влияет на стоимость операции СХД ($/IOps)?

·          Как виртуализация клиентской среды (Solution Integration) влияет на стоимость операции ($/IOps)? 

Читать дальше ...

EMC DSSD D5 - технологический прорыв для систем хранения

После долгих обещаний, многочисленных показов прототипов на выставках и рассказов на конференциях объявлено о доступности систем EMC DSSD D5.  Казалось бы, еще один анонс очередной All Flash СХД - мы чуть ли не каждый день про них читаем. Но эта СХД настолько уникальна по нынешним меркам, что стоит рассказать про нее подробнее.

Если говорить о производительности, то пропускная способность DSSD D5 может достигать 100ГБ/сек, а количество операций ввода-вывода (случайное чтение блоками 4КБ) - 10 миллионов в секунду. И эти результаты обеспечивает система размером всего в 5U! При этом латентность не превышает 100мкс. Все это достигается за счет принципиально новой архитектуры СХД.

Читать дальше ...

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 внутри пула, независимо от типа дисков).

Изменения коснулись и технологии 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.

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

Читать дальше ...

EMX VMAX 40K

Как обычно, громко и шумно 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:

 

За счет этого добились (по заявлениям) двукратного роста производительности в бэкенде и на линейных нагрузках “снаружи”. Что касается 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 (ах, как этого недостает!)?

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

Читать дальше ...

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

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

Решение, предложенное в 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), которая используется не как супер-быстрый диск в операционной системе, но как кэш для операций чтения.

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

Читать дальше ...

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

Еще один уверенный шаг EMC в сторону концепции IT as a Service сделан. Под брызги шампанского и бурные овации на EMC World 2010 анонсирован VPLEX. Выбранное имя конечно не удивляет – сейчас продукт, в названии которого не будет буквы “V”, могут представить только аутсайдеры (даже если к виртуализации никакого отношения продукт и не имеет, а здесь-то как раз виртуализация на месте). Прозвучали и громкие слова “Storage federation”. VPLEX преподносится как таблетка от всех проблем, связанных со сложностью администрирования разрозненных “островков” систем хранения. Казалось бы, что нового? Все это уже давно есть и у IBM (SVC), и у HDS (USP-V), и даже у самой EMC (Invista) – системы виртуализации СХД уже не первый год на рынке. Но ключевой особенностью 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ом, но и продолжать следить за виртуализированными СХД и, возможно, гораздо аккуратнее заниматься выделением пространства, так как теперь между СХД и серверами окажется новое устройство, которое будет усложнять представление данных.

Что же за устройство скрывается за красивым названием 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 с дисковой системы без изменения).  В общем случае, картина примерно такая: 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) на рынке систем виртуализации – большой вопрос. И на сегодняшний день мой прогноз – в ближайший год шансов очень и очень мало.

Читать дальше ...