Несколько постов назад, в комментах, разгорелась нешуточная дискуссия о том, можно ли считать 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.
Увы, дьявол кроется в деталях, и “всегда читайте написанное мелким шрифтом”. Первая версия FAST была весьма сырой, например, позволяла переносить только LUN-ы целиком, что, очевидно, неприемлемый на практике уровень “гранулярности” данных. Только в FASTv2 появилась возможность суб-LUN-овой миграции, впрочем, по-прежнему, мигрируемый минимальный фрагмент данных весьма велик (1GB!), да и еще окружен множеством ограничений использования (не поддерживается компрессия для данных, которые подлежат миграции, например).
К тому же, к сожалению, принадлежность данных к той или иной группе не фиксирована. Так, бухгалтерские проводки за прошлый квартал могут лежать “холодными”, до момента составления квартального или годового отчета, когда обращение к ним резко увеличится. Значит пока мы не распознаем и не смигрируем ставшие активными данные на быстрое хранилище, мы рискуем значительно терять в быстродействии, а если наш алгоритм выявления активных данных не обладает достаточным быстродействием, мы рискуем и вовсе не получить прироста, если “пики” доступа окажутся менее “разрешающей способности” анализирующего алгоритма, и не будут им распознаны как активность. Это же относится и к “устойчивости к помехам”, так, например, регулярный бэкап может свести с ума алгоритм анализа активности, ведь к данным обращаются каждую ночь!
Как вы видите, внешне очевидная и тривиальная задача анализа активности данных и переноса в соответствии с ними на те или иные типы дисков, обрастает сложностями.
Однако, почему задачу повышения быстродействия доступа к данным можно решать только лишь физическим перемещением данных с диска на диск? Вспомним про механизм, который называется “кэширование”. При кэшировании, копии данных, к которым осуществляется активный доступ, накапливаются в специальном высокоскоростном пространстве, доступ куда значительно быстрее (впрочем, см. выше, оно и значительно дороже, этим ограничивается расширение его размера), когда же активность доступа к данным падает (читай: снижается необходимость в этих данных), эти копии удаляются из кэша, при этом собственно содержимое данных по прежнему сохраняется в сравнительно недорогом и малопроизводительном, по сравнению с кэшем, “основном хранилище”.
Большой плюс метода кэширования заключается, во-первых, в полной “автоматизации процесса”, ни пользователю, ни его программе не надо предпринимать какие-то дополнительные действия при его использовании. Если они часто читают этот участок данных, он оказывается в кэше, и скорость доступа к нему повышается, если они перестают его читать, то он вытесняется более активными данными, и остается только в основном хранилище.
Во-вторых, в область дорогого, но высокопроизводительного хранения – “кэша” – попадают “по определению” только “горячие” данные. Место в кэше всегда занимают только данные, к которым сейчас идет активное обращение. Все 100% дорогостоящего объема кэша используются для повышения производительности системы, а не просто “хранения”. Следствием этого является более высокая эффективность работы кэша. Процессор Intel Xeon имеет всего 8Mb кэша, что не мешает ему работать с в тысячи раз большими объемами ОЗУ на сервере, и, за счет этого, сравнительно небольшого, по относительной величине, кэша, эффективно ускорять доступ к размещенным в обширной памяти данным.
В третьих – процесс ускорения доступа и улучшения результата IOPS/$ путем кэширования есть, с алгоритмической точки зрения, процесс тривиальный. А раз так, он имеет минимум побочных эффектов и ограничений использования, а работать (и давать результат в виде повышения производительности) начинает сразу же, а не когда накопится статистика использования и, наконец, в соответствии с ней произойдет миграция данных с одних дисков на другие.
Минусы? Ну как же в нашей жизни и без минусов. Эффективность кэша, действительно высокая при чтении, сильно падает на операциях записи. Ведь если мы изменяем данные в их копиях в кэше, нам надо регулярно и своевременно обновлять их непосредственно по месту их размещения (этот процесс имеет название “сброса содержимого кэша” или “flush”). Значит, если мы изменяем содержимое блока, нам надо это изменение распознать и переписать его содержимое в основном хранилище, чтобы, когда блок будет вытеснен по неактивности из кэша, его новое, измененное содержимое не потерялось. Кэширование записи, хоть и ускоряет собственно процесс записи, сильно усложняет ситуацию алгоритмически, и, как следствие, может вести к значительному снижению эффективности работы.
Таким образом, взглянув на задачу “со стороны пользователя”, мы видим два эквивалентных по результатам решения. Оба решают задачу в нужном пользователю русле, а именно, распределяют данные по “уровням” хранения с различной ценой и производительностью, в зависимости от их активности, улучшая, в результате, экономическую эффективность хранилища, повышая производительность и снижая затраты, то есть улучшая уже названный выше ключевой экономический параметр хранилища – IOPS/$.
Да, действительно, “метод кэширования” имеет в основе другой механизм, чем “метод переноса”, но если результат для пользователя – тот же самый: изменение характеристик доступа к данным, ведущее к улучшению параметра IOPS/$ и эффективности хранилища, то “неважно, какого цвета кошка, если она хорошо ловит мышей”. Будет ли это tiering как перенос данных между двумя типами дисков, или в виде переноса между диском и кэшем, для пользователя и его задач это, по большому счету, безразлично, если это дает эквивалентный прирост эффективности.
Вот почему я считаю, что как EMC FAST, так и EMC FASTcache и NetApp FlashCache, все они являются формами организации tiering-а, и их можно рассматривать вместе, как формы одного решения.
