Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Fast | about NetApp

Posts tagged ‘fast’

EMC Storage Pools – как это работает “под крышкой”.

Продолжаю свои изыскания в теме технологий EMC. На этот  раз я заинтересовался механизмом, лежащим в основе всех новых фишечек EMC CLARiiON/VNX – так называемым Storage Pool. Самым интересным и понятным для меня объяснением оказалась статья блоггера virtualeverything (он не сотрудник EMC, а, как я понял, работает в партнере-интеграторе, и имеет довольно широкое поле зрения, в котором и продукты EMC, и NetApp, и, например, Hitachi). Незначительно сокращенный перевод этой его заметки я предлагаю вашему вниманию.

Глубокое погружение в тему EMC Storage Pool.

Posted by veverything on March 5, 2011

?спользование Storage Pools это довольно частая тема для дискуссии с моими коллегами и пользователями. Многая информация о устройстве и механизмах работы не слишком распространена или известна, поэтому я решил провести мое собственное исследование на этот счет, и поделиться его результатами.

Некоторое время назад EMC представила в своей линейке систем хранения CLARiiON новый принцип так называемого Virtual Provisioning и Storage Pools. Основная идея заключалась в упрощении администрирования системы хранения. Традиционный метод управления хранилищем это взять дисковый массив, наполненный дисками, создать из них дискретные группы RAID, и затем нарезать из этих групп LUNы, которые, затем, предоставляются хостам. Дисковый массив, в зависимости от своего размера, при этом может содержать до нескольких сотен таких групп, и часто превращается в архипелаг разрозненных "островков хранения" на этих RAID-группах. Это может вызывать серьезные затруднения при планировании пространства хранилища, чтобы устранить проблему нерационально потраченного при таком разбиении места, так как у большинства пользователей их потребности к хранилищу, и планы как разбить под задачи, меняются со временем, и, обычно, еще не ясны до конца в "день 1". Нужны были средства гибкого и простого администрирования, и родилась идея Storage Pools.

Storage pools, как следует из его имени, позволяет администраторам создавать "общий массив" (pool) хранения. В ряде случаев вы даже можете создать один большой, общий пул, куда входят все диски системы хранения, что значительно упрощает процессы администрирования. Больше нет отдельных пространств, не нужно углубляться в "тонкие материи" устройства и организации RAID group, схем разбиения, и так далее. Кроме того, появилась также технология FAST VP, которая позволяет перемещать блоки данных в соответствии с их активностью, по уровням хранения, например на более емкие и дешевые, или более быстрые и дорогие диски. Просто выделите и назначьте пространство из такого "пула" вашей задаче, динамически, гибко, и при этом еще и позволяя использовать auto tiering. Звучит здорово так? По крайней мере так утверждает маркетинг. Давайте разберемся с тем, как это работает "физически", и нет ли не вполне очевидных "подводных камней".

Continue reading ‘EMC Storage Pools – как это работает “под крышкой”.’ »

Еще немного про autotiering

Проглядывая community.netapp.com обнаружил дискуссию о autotiering-е, откуда выдернул интересное мнение уже известного вам Dimitris K. (recoverymonkey). Хотя в оригинале это были три реплики-ответа в дискуссии в форуме, я слил их оформил их как отдельную “статью”.

Дискуссия идет о реализации autotiering в EMC FAST, а также о системах хранения Compellent, которые, до недавнего времени, были главным игроком на рынке tiering-а, и реализация прозрачного tiering-а в них была сделана ранее всех. В России они почти неизвестны, хотя сейчас, как я понимаю, они могут начать попадать в страну через каналы Dell.

Dimitris Kriekouvkas (recoverymonkey), сотрудник NetApp:

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

Посмотрите на опубликованные бенчмарки EMC – там нигде нет autotiering.

Вы также не найдете и показателей FASTcache. Все бенчмарки у EMC делаются на традиционных RAID-группах, без пулов.

Если вы посмотрите на руководство наилучших практик по производительности и доступности для EMC CLARiiON (ссылку на этот документ я давал в прошлом посте про “матчасть”), то вы увидите следующее:

  • Вместо RAID-5 для больших пулов на SATA рекомендуется RAID-6 с размером группы в 10-12 дисков.
  • Thin Provisioning снижает производительность
  • Storage pools снижают производительность по сравнению с Traditional RAID
  • Данные и ввод-вывод не распределяются на все диски пула, как вы, возможно, предполагали (см ссылку).
  • Рекомендуется использовать drive ownership на только один контроллер
  • Нельзя смешивать разные типы RAID в одном пуле
  • Существуют ограничения по расширению пула дисками, в идеале расширение должно производиться увеличивая емкость пула вдвое (или, хотя бы, кратно количеству дисков в RAID-группе пула)
  • Для пула недоступны reallocate/rebalancing (для MetaLUN вы можете сделать restripe)
  • Процесс Tresspassing pool LUN (обычно при переключении LUN-а с одного контроллера на другой, например при выходе одного из них из строя, но, часто, и при других операциях) может приводить к снижению производительности, так как оба контроллера будут пытаться совершать операции ввода-вывода на LUN. Поэтому для pool LUN-ов важно оставаться закрепленными за тем контроллером, на котором они начали работать, иначе потребуется затратная миграция.
  • Не рекомендуется использовать thin LUN для задач, требующих высокой производительности по bandwidth.

Я хочу еще раз привлечь внимание к простому факту: дьявол кроется в деталях. Читайте мелкий шрифт.

Вам говорят: Autotiering волшебным образом, автоматически, решит ваши проблемы, без вашего участия, не беспокойтесь об этом. В реальности все не совсем так.

При работе autotiering, значительная часть вашего working set, рабочего набора данных, находящегося в активном использовании в данный момент, должно быть перемещено на быстрое хранилище.

Допустим у вас есть хранилище ваших данных, емкостью 50TB. Правило оценки, которым руководствуются инженеры EMC,  что 5% рабочего набора данных пользователя – “горячие данные”. Они перемещаются на SSD (в виде tier или cache). Таким образом вам нужно 2,5TB usable space на SSD, или примерно одна полку дисками SSD по 200GB, может быть больше, в зависимости от типа использованного RAID.

Принято считать, что объем “средней” нагрузки составляет 20% от объема, то есть 10TB, который размещается на дисках SAS или FC.

Остальное размещается на дисках SATA.

Вопрос на 10 миллионов долларов:

Что обойдется дешевле, autotiering и софт кэширования (он небесплатен) плюс 2,5TB SSD, плюс 10TB SAS, плюс 37,5TB SATA, или…

50TB SATA плюс NetApp FlashCache,или, например, 50TB SAS и Flash Cache?

Вопрос на 20 миллионов долларов:

Какая из этих двух конфигураций будет иметь более предсказуемую производительность?

 

Compellent – это еще одна интересная история.

Большинство обсуждающих Compellent не задумывается о том, что tiering-у у него подвергаются “снэпшоты”, а не непосредственно рабочие данные!

То есть принцип там такой: берется снэпшот, данные делятся на страницы, размеров 2MB (по умолчанию, может быть меньше, но тогда нельзя будет увеличить емкость хранилища). Далее, если оценивается, что обращений на чтение с данной страницы мало, то она переносится на уровень SATA.

О чем не знают большинство интересующихся Compellent-ом:

Если вы изменяете содержимое данных на странице, то происходит это следующим образом:

  1. Перенесенная на SATA страница, содержащая данные, которые мы изменяем, остается на SATA.
  2. Новая страница, объемом 2MB создается на Tier1 (SAS/FC), куда реплицируется содержимое страницы с SATA, и где делается запись изменения. Даже если меняется в данных один байт.
  3. Когда с этой страницы будет сделан снэпшот, то он, в свою очередь, также может быть впоследствии перенесен на SATA, заменив прежнюю.
  4. ?того: 4MB занятого места для того, чтобы сохранить 2MB данных и один измененный байт.

? снова укажу: дьявол кроется в деталях. Если вы изменяете свои данные произвольным образом (random), вы получите множество “заснэпшоченных” страниц, и очень неэффективное использование пространства. Вот почему я всегда предупреждаю пользователей, которые интересуются Compellent-ом, задавать эти вопросы, и уяснить себе эти моменты, получив ясное описание от инженеров того, как используется пространство снэпшотов.

На NetApp мы имеем предельно гранулярное пространство, благодаря WAFL. Минимально возможный снэпшот по своему объему очень мал (это указатель, немного метаданных, плюс один измененный блок, размером 4KB). Поэтому на NetApp некоторые наши пользователи могут хранить сотни тысяч  снэпшотов на одной системе (например именно так делает один всем известный банк, использующий наши системы хранения).

 

Гранулярность, на самом деле, это только часть проблемы (производительность – другая ее часть). Сейчас страница у Compellent имеет размер 2MB (можно уменьшить до 512K, но это не позволит изменять размер стораджа). Если они перейдут, как обещают, на 64-битную арифметику в ПО, то они смогут получит  размер страницы 64K (это пока не подтверждено), однако тут есть вот какая проблема. Запись этой страницы на RAID может быть двумя способами.

Если это RAID-1, то тогда мы записываем две копии страницы, размером 64KB на каждый из дисков.

Если это RAID-5/6, то тогда нам надо поделить объем записываемой страницы, размером 64KB, поровну между всеми дисками данных, входящих в RAID. Допустим используется RAID-5 в варианте 4d+1p. Тогда на каждый диск в операции записи получится всего 16KB (и меньше). ? если для RAID-1 размер записи в 64KB это довольно типичный размер записи сегмента в RAID, и запись таким размером достаточно производительна, то для RAID-5/6 это очень маленький кусочек для операции записи, что будет неизбежно отражаться на производительности.

В Data ONTAP мы не перемещаем снэпшоты, поэтому у нас нет такой проблемы, у других же вендоров она очень остра. Получить предсказуемую производительность при использовании autotiering это очень, очень сложная задача. Всякий раз когда мы у клиентов меняем нашими системами сторадж от Compellent, это происходит не потому что им не хватает каких-то фич, а только оттого, что у клиентов с ними проблемы с производительностью. Всякий раз.

Мы ставим 1-2 вида дисков плюс Flash Cache, и проблема решена (в большинстве случаев производительность становится в 2-3 раза выше, как минимум). Часто это получается даже не дороже.

Вот такие дела.

Учу матчасть :)

Как заповедали старшие – изучаю вооружение потенциального противника :)

Нашел тут EMC CLARiiON Best Practices for Performance and Availability (FLARE 30, 01.03.2011) и сижу, читаю.

Особо примечательные места выделяю. Ничего, что я сегодня без перевода? По-моему, в выделенном все достаточно понятно.

Уделяю особое внимание storage pool-ам и LUN-ам в них, так как только в pool-ах возможны новые фишечки, такие как FAST и thin provisioning.

Continue reading ‘Учу матчасть :)’ »

Некоторые данные о производительности EMC FASTcache и FAST VP

Несмотря на то, что EMC наотрез отказывается публиковать результаты производительности систем с FASTcache и FAST VP, храня по этому поводу многозначительное и загадочное молчание, невозможно запретить частным лицам анализировать и делиться своими результатами приобретенных ими систем.

Недавно в интернете удалось раскопать вот такие результаты.

image

Некто проследил и опубликовал результаты real world-работы системы NS480 (CX4-480), объемом 480 SAS, SATA и EFD дисков, на 28TB block и 100TB NAS data, оснащенной как FAST VP, так и FASTcache (4 диска EFD по 100GB, общей usable capacity в FASTcache – 183GB).

Пожалуйста, примите во внимание, что это Real World data, то есть реальная производительность системы, используемой под реальную пользовательскую работу (в рассмотренном случае – ERP, VMware, SQL server databases, CIFS shares), а не какие-то специальные тестовые условия. В этом и сила и слабость приведенных результатов. Сила в том, что это реальные, практические данные. Слабость – в том, что, вполне вероятно, мы не видим всех возможностей FAST/FASTcache.

image

Тем не менее “чем богаты – тем и рады”. Пока EMC хранит загадочное молчание, приходится перебиваться тем, что подарят сердобольные пользователи. Подробно о системе и полученных результатах – по ссылке выше.

Напомню, что, в отличие от EMC, NetApp результаты своих систем с Flash Cache не только не таит, а наоборот, активно пропагандирует и публикует, потому что, по справедливости, там есть чем гордиться.

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

http://sudrsn.wordpress.com/2011/03/19/storage-efficiency-with-awesome-fast-cache/
http://sudrsn.wordpress.com/2011/04/16/emc-fast-cache-increase-performance-while-reducing-disk-drive-count/

Правда там человек темнит о конфигурации.

Про tiering: EMC FAST, FASTcache, NetApp Flash Cache

Несколько постов назад, в комментах, разгорелась нешуточная дискуссия о том, можно ли считать Flash Cache “истинно православным” средство tiering-а, и ставить его в ряд с множеством других аналогичных средств, например с EMC FAST.
Для разъяснения моей позиции на этот счет я и написал этот пост.

Для начала давайте определим что такое tiering вообще.

Tiering-ом (увы, русскоязычного термина пока не прижилось, будем использовать такое) принято называть механизм перемещения данных между “уровнями” (tiers) хранения, характеризующимися теми или иными свойствами, например ценой, быстродействием, защищенностью, и так далее. Обычно tiering-ом принято называть механизмы, для перемещения данных между дисками разных типов, или дисками и магнитными лентами, или же ROM-хранилищем, часто он используется для организации ILM – Information Lifecycling Management – хранилища данных в соответствии с их статусом и уровнями QoS.

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

Что есть tiering с точки зрения приложения или пользователя? Зачем мы его применяем?

Целью tiering-а для пользователя является возможность повысить эффективность (в первую очередь экономическую) использования его системы хранения. Когда “цена значения не имеет”, то все просто – надо купить Symmetrix. Однако в реальной жизни цена очень даже имеет значение, и пользователь вынужден идти на компромиссы между ценой решения и необходимой пользователю производительностью.

?спользуемые в системах хранения диски сегодня имеют различную производительность, емкость и цену, причем производительность и емкость обычно величины обратно пропорциональные: больше емкость – меньше производительность (SATA), меньше емкость – выше производительность  (SAS), еще выше производительность и цена, и меньше емкость – Flash. Система хранения-же целом характеризуется соотношением IOPS/$, то есть количества единиц производительности с “вложенного доллара”.  Повысить этот параметр стремится любой вендор и любой покупатель системы хранения.

Согласно широкоизвестному Закону Парето (“20 процентов сотрудников делает 80 процентов всей работы”) сравнительно небольшая часть данных ответственна за значительную долю быстродействия системы. Напротив, значительная часть данных относится к так называемым “холодным”данным, скорость доступа к которым в принципе не критична.
Было бы неплохо, если бы эти 20% активных данных, скорость доступа к которым напрямую влияет на общую производительность, располагались на максимально быстром разделе хранилища, пусть он дорогой, но его емкость будет всего 20% от емкости хранилища, зато прирост мы получим во все 80%!

?менно эта идея лежала в основе идеи tiering-а. Если этот тип данных – активный, то автоматически перенесем его на более дорогие и быстродействующие диски, и повысим производительность доступа к ним, а менее активные данные – перенесем на менее производительные дешевый тип дисков. ? настанет счастье, в виде повысившегося соотношения IOPS/$.

К такому, “классическому” типу tiering-а относится продукт EMC FAST – (Fully-Automated Storage Tiering). Он позволяет прозрачно для пользователя переносить фрагменты его данных между “уровнями” хранилища, например между разделами на дисках SAS и SATA.

image

Увы, дьявол кроется в деталях, и “всегда читайте написанное мелким шрифтом”. Первая версия FAST была весьма сырой, например, позволяла переносить только LUN-ы целиком, что, очевидно, неприемлемый на практике уровень “гранулярности” данных. Только в FASTv2 появилась возможность суб-LUN-овой миграции, впрочем, по-прежнему, мигрируемый минимальный фрагмент данных весьма велик (1GB!), да и еще окружен множеством ограничений использования (не поддерживается компрессия для данных, которые подлежат миграции, например).

К тому же, к сожалению, принадлежность данных к той или иной группе не фиксирована. Так, бухгалтерские проводки за прошлый квартал могут лежать “холодными”, до момента составления квартального или годового отчета, когда обращение к ним резко увеличится. Значит пока мы не распознаем и не смигрируем ставшие активными данные на быстрое хранилище, мы рискуем значительно терять в быстродействии, а если наш алгоритм выявления активных данных не обладает достаточным быстродействием, мы рискуем и вовсе не получить прироста, если “пики” доступа окажутся менее “разрешающей способности” анализирующего алгоритма, и не будут им распознаны как активность. Это же относится и к “устойчивости к помехам”, так, например, регулярный бэкап может свести с ума алгоритм анализа активности, ведь к данным обращаются каждую ночь!

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

Однако, почему задачу повышения быстродействия доступа к данным можно решать только лишь физическим перемещением данных с диска на диск?  Вспомним про механизм, который называется “кэширование”. При кэшировании, копии данных, к которым осуществляется активный доступ, накапливаются в специальном высокоскоростном пространстве, доступ куда значительно быстрее (впрочем, см. выше, оно и значительно дороже, этим ограничивается расширение его размера), когда же активность доступа к данным падает (читай: снижается необходимость в этих данных), эти копии удаляются из кэша, при этом собственно содержимое данных по прежнему сохраняется в сравнительно недорогом и  малопроизводительном, по сравнению с кэшем, “основном хранилище”.

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

image

Во-вторых, в область дорогого, но высокопроизводительного хранения – “кэша” – попадают “по определению” только “горячие” данные. Место в кэше всегда занимают только данные, к которым сейчас идет активное обращение. Все 100% дорогостоящего объема кэша используются для повышения производительности системы, а не просто “хранения”. Следствием этого является более высокая эффективность работы кэша. Процессор Intel Xeon имеет всего 8Mb кэша, что не мешает ему работать с в тысячи раз большими объемами ОЗУ на сервере, и, за счет этого, сравнительно небольшого, по относительной величине, кэша, эффективно ускорять доступ к размещенным в обширной памяти данным.

В третьих – процесс ускорения доступа и улучшения результата IOPS/$ путем кэширования есть, с алгоритмической точки зрения, процесс тривиальный. А раз так, он имеет минимум побочных эффектов и ограничений использования, а работать (и давать результат в виде повышения производительности) начинает сразу же, а не когда накопится статистика использования и, наконец, в соответствии с ней произойдет миграция данных с одних дисков на другие.

Минусы? Ну как же в нашей жизни и без минусов. Эффективность кэша, действительно высокая при чтении, сильно падает на операциях записи. Ведь если мы изменяем данные в их копиях в кэше, нам надо регулярно и своевременно обновлять их непосредственно по месту их размещения (этот процесс имеет название “сброса содержимого кэша” или “flush”). Значит, если мы изменяем содержимое блока, нам надо это изменение распознать и переписать его содержимое в основном хранилище, чтобы, когда блок будет вытеснен по неактивности из кэша, его новое, измененное содержимое не потерялось. Кэширование записи, хоть и ускоряет собственно процесс записи, сильно усложняет ситуацию алгоритмически, и, как следствие, может вести к значительному снижению эффективности работы.

Таким образом, взглянув на задачу “со стороны пользователя”, мы видим два эквивалентных по результатам решения. Оба решают задачу в нужном пользователю русле, а именно, распределяют данные по “уровням” хранения с различной ценой и производительностью, в зависимости от их активности, улучшая, в результате, экономическую эффективность хранилища, повышая производительность и снижая затраты, то есть улучшая уже названный выше ключевой экономический  параметр хранилища – IOPS/$.

Да, действительно, “метод кэширования” имеет в основе другой механизм, чем “метод переноса”, но если результат для пользователя – тот же самый: изменение характеристик доступа к данным, ведущее к улучшению параметра IOPS/$ и эффективности хранилища, то “неважно, какого цвета кошка, если она хорошо ловит мышей”. Будет ли это tiering как перенос данных между двумя типами дисков, или в виде переноса между диском и кэшем, для пользователя и его задач это, по большому счету, безразлично, если это дает эквивалентный прирост эффективности.

Вот почему я считаю, что как EMC FAST, так и EMC FASTcache и NetApp FlashCache, все они являются формами организации tiering-а, и их можно рассматривать вместе, как формы одного решения.

20/0.107

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.