Среди стандартного функционала, предоставляемого различными СХД корпоративного уровня, тиринг стоит на особом месте. Этот функционал в теории очень хорош, однако на практике большинство клиентов не получают от него желаемой пользы.
Тиринг (Tiering) — умение системы хранения данных автоматически балансировать нагрузку по разным типам дисков. Например, горячие данные, к которым наиболее часто обращаются пользователи, должны на основании определенных алгоритмов перемещаться на самые быстрые диски (SSD / SAS 15K); умеренно используемые данные переносятся на средний уровень хранения (SAS 10K); и, наконец, холодные данные, к которым идет обращение реже всего, хранятся на самых медленных и дешевых дисках (NL-SAS 7K).
Согласно маркетинговым заявлениям, перемещение данных на основании частоты обращений автоматически раскладывает данные на тот уровень, который необходим. Однако на практике, из-за особенностей реализации алгоритма, данные не всегда распределяются по уровням хранения правильно.
Типичный пример. В течение дня базы данных, к которым постоянно обращаются пользователи, попадают на верхний уровень хранения, как и должно быть. Вечером, при наступлении окна бэкапа, СХД видит, что теперь самые горячие данные — это не база данных, а бэкап, и успешно мигрирует бэкап на быстрые диски, а базы данных — на медленные. На следующее утро, в начале рабочего дня, во время Boot strom, все пользователи начинают логиниться в систему, а на вернем уровне в это время — ночной бэкап. СХД понимает, что держит необходимые в это время данные на медленных дисках, начинает их потихоньку перемещать. Что в совокупности c одновременными массовыми обращениями к этим данным значительно сказывается на общей скорости работы СХД.
Аналогичных сценариев много, например, локальные периодически возмущения вроде окончания квартала, когда бухгалтерия поднимает какие-то архивы, а СХД начинает выносить эти данные наверх, и т.д.
Получается, что в реальной жизни доверять СХД автоматическое распределение данных оказывается нецелесообразно. Все понимают, что база данных должна лежать на быстрых дисках, и с самого начала можно ее туда положить без какого-либо анализа обращений.
Поэтому ведущие производители, изначально выпустив данный функционал вслед за EMC, больше не акцентируют на нем внимание как на конкурентном преимуществе — на продуктовых презентациях максимум упоминают в ключе "у нас тоже есть тиринг". Некоторые из производителей в принципе отказались от реализации тиринга в своих системах за ненадобностью. Однако, есть и удачные примеры реализации автоматического многоуровневого хранения.
В качестве удачного примера работы тиринга можно привести СХД Fujitsu. В них анализ обращений к данным осуществляется сторонним сервисом, который работает на сервере, анализирует обращение к данным и ведет журналирование. Только после окончания длительного периода наблюдений (например, 1 месяц, или полгода, как администратор сочтет нужным), запускается команда на перемещение данных. Можно настроить так, что цикл анализа стартует раз в неделю, и длится положенный срок. В итоге перемещение данных происходит не автоматически на лету, а на основании статистики, собираемой за весь цикл анализа. Поэтому никакие временные данные, бэкапы, видеоархивы не будут влиять на работу.
Системные администраторы могут изначально разделить данные по двум-трем-четырем уровням хранения, в соответствии с имеющимися задачами. Функционал распределения пространства по запросу (thin provisioning) доступен у всех корпоративных СХД и позволяет как угодно растягивать тома. В этом случае данные размещаются один раз вместо постоянной миграции, которая дополнительно нагружает дисковую подсистему и процессор СХД. Этот вариант в целом удобней, быстрее и эффективней использования тиринга.
Иногда вместо единой СХД с тирингом для всех задач сразу (базы данных, видеонаблюдение, виртуальные машины, медиаконтент и др)., имеет смысл построить решение на нескольких СХД, оптимизированных под конкретные процессы. Каждая отдельная система при этом будет обладать необходимыми характеристиками, скоростью и функционалом.
Когда мы говорим о тиринге, необходимо также вспомнить о такой интересной пограничной технологии, как Flash Cache (Flash Pool, SSD Cache и др., — названия отличаются у разных брендов). Это функционал использования SSD накопителей как расширение памяти контроллера.
Преимущества этого подхода в том, что самые горячие данные находятся в кэше контроллера, увеличенного за счет SSD дисков. При этом в SSD кэше находится только копия данных, оригинальные данные продолжают храниться на медленных дисках. Как только данные перестают быть горячими, система от них избавляется, причем не миграцией на медленные диски, а просто затиранием, и далее в SSD кэш записываются новые актуальные данные. Таким образом, замена данных на верхнем уровне хранения происходит значительно быстрее, т.к. требуется только считать новые данные без перемещения.
Для управления Flash Cache возможно задавать различные настройки, выделить для кэш каких-то томов отдельно и т.д. В целом данная технология хорошо работает и у всех производителей дает значимый прирост к скорости.
На наш взгляд, существует два варианта инсталляций, в которых тиринг хорошо работает:
В таких инсталляциях нивелируются слабые места технологии тиринга, и горячие данные поднимаются наверх четко в соответствии с количеством обращений.
В заключение можем сказать, что несмотря на то, что в некоторых инсталляциях тиринг действительно дает значимые преимущества, для большинства клиентов оптимально будет использовать технологию Flash Cache, вручную установить распределение данных по уровням хранения или разнести задачи на разные СХД. А для самых требовательных к скорости инсталляций — рекомендуем хранилища полностью на SSD дисках.
15 ноября 2017 г.