Archive for мая 2011

Оптимизация на Large Sequental Read

Large Sequental Read, или чтение последовательными большими блоками, это один из распространенных паттернов доступа к данным. Например, с таким характером доступа работают такие задачи, как Decision Suport System (DSS), системы Business Intelligence (BI), а также многие задачи резервного копирования (full backup, например).

Вследствие характера работы WAFL, такой паттерн доступа может быть проблемным для систем хранения NetApp, поэтому, если ваши задачи часто используют Large Sequental Read, то стоит позаботиться о некоторых методах оптимизации. Я уже писал, что ситуацию с производительностью на последовательном чтении улучшает регулярное выполнение операций реаллокации (они выполняются по расписанию, или при превышении порогового уровня non-contiguous blocks placement, не обязательно гонять его вручную). Также в блоге специалиста NetApp по нагрузочному тестированию и производительности, Wei Liu, я приметил еще одну оптимизационную фишечку.

В системах Data ONTAP версии 7.3.2 и новее имеется опция wafl_max_write_alloc_blocks, по умолчанию она установлена в 64. Если у вас работа с данными осуществляется преимущественно большими блоками, имеет смысл увеличить его значение до 256. Этот параметр, наскольно я могу судить из его названия, управляет размером экстента записи данных. О влиянии и смысле этого элемента дисковой структуры я недавно писал в посте про “фрагмнтацию”. Для версий до 7.3.2 этот параметр нужно было установить в файле /etc/rc в виде строки:
setflag wafl_max_write_alloc_blocks 256

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

Опция была подсмотрена в документе: TR-3760: Building a Scalable Data Warehouse Solution, кстати любопытного и самого по себе чтива.

Отдельно обращу ваше внимание, что не стоит сразу бросаться “тюнить” систему, так как данная опция, вероятнее всего, положительно влияет только на производительность large sequental read, и может не сказаться, или сказаться отрицательно на всех других. Но если у вас DSS-like база, то, может быть, можно и попробовать.

Last call: Конкурс “экономия пространства на NetApp”

Напомню, что месяц назад я объявил своеобразный “конкурс”, или вернее будет сказать “розыгрыш приза”, предложив присылать мне результаты экономии пространства с помощью дедупликации и компрессии на томах ваших систем, вывод консольной команды df -s –g.

Я пообещал разыграть, в случайном порядке, между всеми приславшими, по выбору выигравшего, gift card Apple iTunes на 25$, такую же карточку от Amazon, или же подарочную карту от OZON на 1000 рублей.

То есть от вас – вывод команды, и, возможно, карточка достанется вам. Карточка, разумеется, не физическая, а ее номер, который вы можете активировать в соответствующем интернет-магазине.

Подробнее – в том посте.

Конкурс “экономия пространства на NetApp”

 

Напоминаю, что результаты принимаются до 1 июня. Вы еще вполне успеете сделать свою попытку в понедельник или вторник.

Про 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-а, и их можно рассматривать вместе, как формы одного решения.

Запускаем новую систему хранения. Часть 1.

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

Давайте с самого начала рассмотрим путь самурая нового пользователя NetApp, и те сложности, с которыми он может столкнуться, запуская новую для себя систему.
Вот вы купили сторадж, и вам его даже доставили, и вот он стоит у вас в датацентре, в коробке. Что делать дальше?
(тут должна быть ссылка на видеоролик на ютубе, в популярном нынче жанре unboxing. Надо будет сделать как-нибудь;)

Continue reading ‘Запускаем новую систему хранения. Часть 1.’ »

Полезные документы по PowerShell Toolkit

Я уже писал (тут, тут и тут) в этом блоге о чрезвычайно полезном, свободно распространяемом тулките для PowerShell, разрабатываемом в NetApp. Этот тулкит представляет собой целый набор разнообразных “командлетов” (commandlets), для администрирования систем хранения NetApp.

На сайте communities.netapp.com (если вы работает с NetApp, но еще не там, то самое время вливаться, доступ и создание логина там свободные) можно найти хорошую презентацию о том, как установить и пользоваться тулкитом:

Getting Started With Data ONTAP PowerShell Toolkit

А недавно был выложен обновленный документ:

Making The Most Of Data ONTAP PowerShell Toolkit

Если вы умете использовать PowerShell, и планируете использовать его возможности для управления системой хранения NetApp, то рекомендую всячески.

TechTalk Live, Москва, 19 мая.

Хочу еще раз привлечь внимание моих московских читателей к встрече TechTalk Live, которая состоится ЗАВТРА в Москве (Holiday Inn Сокольники, ул. Русаковская, 24)

Программа семинара NetApp TechTalk Live

09:3010:00

Регистрация, приветственный кофе

10:00 – 10:10

Обзор программы семинара

10:1010:50

Большие данные - тенденции и технологии.
Data ONTAP C-mode и не только

Роман Ройфман

10:50 – 11:30

Рекомендации для систем с большим числом файлов
Игорь Увкин

11:30 – 12:10

Новое в протоколах: pNFS, SMB 2.1
Игорь Увкин

12:10 – 12:30

Кофе-брейк

12:30 – 13:10

К вопросу производительности с примерами
Тимофей Гудилин

13:1013:50

NDO - обеспечение безостановочной работы. Рекомендации
Михаил Швыдкий

13:5014:10

Сессия вопросов и ответов

14:1015:00

Лотерея, фуршет

Usable capacity на системах NetApp

Вокруг ситуации с usable capacity на NetApp накручено очень много довольно низкопробного манипулирования и FUD-а, см. например мою же статью в блоге, посвященную разоблачению одного из таких текстов.

Как вы знаете, системы на поддержке отсылают в Support Center в NetApp данные о своем состоянии, в том числе и о конфигурации. Интересный график был обнаружен в одной из технических презентаций NetApp. Это анализ соотношения между raw и usable capacity для реальных, рабочих систем NetApp, установленных у клиентов компании, эксплуатирующихся в настоящее время и отсылающих сообщения autosupport. В среднем, для 7597 рассмотренных систем, их usable capacity, то есть доступная для использования емкость хранения, емкость дисков за вычетом RAID-penalty (parity drives), spares, WAFL-metadata, reservations и прочего, составила 66,27% от их raw.

image

Такие дела. Как видите, в реальной жизни достигнутая на системах NetApp средняя величина usable всего на 3% хуже теоретически рассчитанной мной в посте с разоблачением FUD-а.

TechTalk Live в Москве, 19 мая.

Хочу дополнительно привлечь внимание моих читателей к встрече российского NetApp в Москве.
Через неделю, 19 мая, в Москве (Holiday Inn Сокольники, ул. Русаковская, 24) состоится TechTalk Live - открытый технический семинар для всех желающих, интересующихся темой решений NetApp.

Программа сугубо техническая и довольно интересная.
Будут рассмотрены вопросы построения больших систем, в том числе в пока все еще не слишком известной, но очень многообещающей Cluster-mode в Data ONTAP 8.x, рассмотрены вопросы работы с новыми для NetApp протоколами pNFS и SMB2.1, будет тронута тема производительности систем хранения. Самое главное - можно будет непосредственно, напрямую пообщаться с главными специалистами российского отделения NetApp.
Если у вас все еще есть вопросы к NetApp непосредственно, то это - самое правильное и лучшее место их задать и услышать ответы.

Дата: 19 мая 2011r.
Время: 9.30 -15.00
Место: Holiday Inn Sokolniki
ул. Русаковская, 24
м. Сокольники

Регистрация там.

Если вы испльзуете в работе электронный календарь, в Outlook, Google или iPhone/iPad, то можете взять вот этот файлик ics (884 byte) для того, чтобы занести в свой календарь себе напоминание.

Публичная Beta для System Manager 2.0

NetApp опубликовал в своем community приглашение к публичному бета-тестированию новой версии их инструмента администрирования системы хранения – System Manager.

Существующая версия System Manager (v1.1) это программа на .Net под Windows. В версии 2.0 было принято решение делать новый System Manager под Java, он работает как java-приложение в браузере.

image

Что до моего мнения, то решение о возврате на Java крайне сомнительное, но поживем-увидим. Зато появилась версия под Linux. Возможно, тот небольшой процент администраторов, не имеющих в хозяйстве Windows, будут рады.

http://communities.netapp.com/groups/netapp-system-manager-20-public-beta

Ну и, понятно, вы осознаете, что это бета-версия, что компания рекомендует тестировать ее на non-production, и прочее бла-бла-бла.

Flash Cache 1TB

Без особого шума обновилась информация о доступной конфигурации плат Flash Cache (PAM II), нетапповского средства Virtual Tiering, представляющего собой плату с SLC Flash, между дисками и собственно системным кэшем контроллера, и позволяющего значительно повысить производительность в IOPS, без необходимости увеличивать количество дисковых шпинделей.

От SSD это решение отличается тем, что его емкость занимают только “горячие”, активные данные, то есть высокопроизводительный объем flash занимается максимально эффективно, а от auto-tiering, наподобие EMC FAST это отличается полностью автоматической работой, быстротой заполнения и гибкостью использования, так как минимальный “квант” tiering-а равен блоку WAFL – 4KB, в отличие от огромного, размером 1Gb, сегмента, которым оперирует EMC FAST.

Результаты производительности систем хранения с платами Flash Cache широко опубликованы, например в тестах SPEC SFS (NFS/CIFS) и в тестах SPC-1/E (SAN), и они широко продаются с системами хранения NetApp, утверждается, что ныне каждая четвертая система из всех, продаваемых NetApp идет с Flash Cache..

До сих пор были доступны платы с объемом 256 и 512Gb SLC Flash, теперь к ним добавилась плата с 1Tb, доступная для самых старших систем – 6200 и 3270. Доступность к заказу объявлена с 13 июня.

Как побочный результат это также означает, что к 13 июня должна также выйти система Data ONTAP 8.0.2, которая необходима для работы этих модулей.

18/0.175

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.