Как работает Auto-Tiering (ярусное хранение данных) в DataCore SANsymphony-V

Сегодня речь пойдет о механизме работы автоматического тиеринга в DataCore SANsymphony-V, программном продукте для виртуализации систем хранения данных. О том, что представляет из себя SANsymphony-V, решаемых задачах, функционале и нескольких референсных платформах можно почитать на сайте True System.
Ярусное хранение данных (tiering) — одна из самых обсуждаемых последнее время технологий. Вы наверняка слышали о том, что это некий способ автоматически перераспределять "горячие" и "холодные" данные между быстрыми/дорогими носителями и дешёвыми/ёмкими/медленными. Для начала стоит рассказать об основах (например, отличия от простого одноуровневого кэширования), затем можно будет перейти к конкретной реализации в DataCore SANsymphony-V. Принцип работы одноуровневого кэша достаточно прост. На примере реализаций в SAS RAID контроллерах (LSI CacheCade и Adaptec MaxCache) это выглядит так:

• Создается пул из SSD, используемых для кэширования. При включённом кэшировании запись он, естественно, должен быть защищённым (RAID 1, 1E, 10, 5).
• Тома на контроллере имеют простую настройку "кэшировать / не кэшировать".
• При включённом кэшировании контроллер анализирует доступ к данным тома и копирует часто читаемые блоки в кэш. Если включён write-back, то любая запись попадает сначала в кэш, затем вытесняется на том.

Простой способ подходит для простой задачи — обеспечить гибкий прирост производительности. Самый распространенный сценарий: база достаточно большого для размещения полностью на SSD-томе объема, к определенным таблицам которой нужно обеспечить быстрый доступ. Но при наличии более сложной ситуации возникают проблема, связанные, во-первых с наличием только двух уровней производительности (исходный том + SSD-кэш), во-вторых — отсутствие какого-либо QoS. Что делать, если кэшируемых томов несколько и одному из них нужен приоритетный доступ к кэшу? Просто взять и поделить кэш (например - 50ГБ для первого тома, 100ГБ — для второго) нельзя, придётся вручную размещать нужные данные на SSD-томах, что противоречит исходной задаче по увеличению эффективности использования быстрых, но дорогих носителей.
Что делать, если жизненный цикл ваших данных сложнее, в наличии имеется несколько томов на разных СХД с различной производительностью, и есть необходимость организовать автоматическое "оседание" редко используемых данных на медленных носителях?
Тут на помощь приходит ярусное хранение данных и устроено оно несколько сложнее, чем просто многоуровневый кэш. Разберём принцип работы на примере DataCore SANsymphony-V (далее — SSV). С некоторыми отличиями тот же принцип используется и в других реализациях, например в IBM SVC.
SAU (storage allocation unit). Логические блоки, на которые нарезается дисковое пространство в пуле. В SSV размер SAU может быть от 4-х до 1024МиБ. В других системах могут называться chunks, logical blocks и т.п. Именно с дискретностью в один SAU осуществляются все операции — выделение дискового пространства для томов, операции по перемещению данных при использовании ярусного хранения и т.п.
Tier (ярус, уровень) — свойство, назначаемое диску в пуле (под термином диск подразумевается не одиночный диск, а некий используемый SSV защищённый том, например, с локального RAID-контроллера или внешней СХД). SSV ничего не знает о физическом устройстве диска (тип RAID, кол-во и тип физических дисков в нём) и, как следствие — о производительности. Так что tier'ы присваиваются вручную. Их можно создать до 15-ти, но в большинстве случаев достаточно трёх-четырёх. Важно, чтобы по производительности на случайный доступ они существенно (хотя бы в разы) отличались друг от друга. Операции по перераспределению данных между ярусами создают дополнительную нагрузку, так что желательно, чтобы они выполнялись не зря.
Кажется, что все необходимые для организации ярусного хранения компоненты уже есть. Но как быть с теми же приоритетами? Для решения этой задачи у тома (виртуального диска DataCore) есть storage profile (профиль хранения), который помимо приоритетов не относящихся к ярусному хранению (приоритет репликации и приоритет восстановления для зеркальных томов) определяет т.н. tier affinity, привязку тома к определенным ярусам. Например, для конфигурации с 4-мя ярусами и пятью профилями (critical, high, normal, low и archive) tier affinity выглядит так:

Том с профилем normal (обычный) привязан ко всем ярусам, т.е. его SAU в зависимости от частоты использования могут свободно мигрировать между любыми ярусами. Для обеспечения гарантированного уровня производительности тому можно назначить приоритет high (высокий) или даже critical (критичный). Например, для профиля critical SSV будет стараться разместить все данные тома исключительно на дисках первого, самого быстрого яруса, причём они будут иметь приоритет перед томами с более низкими профилями, привязанными к этому ярусу. Т.е. SAU на томе со storage profile = critical будут полностью размещаться на дисках tier-1, если при этом для остальных томов с high или normal на ярусе tier-1 не останется места, то их SAU будут перемещены на менее производительные ярусы.
Вы можете спросить, чем же ручное назначение профилей томам существенно отличается от использования простых СХД без всякого tier'инга, с ручным распределением данных по томам с нужной производительностью. Сценариев много:
отличается эффективностью использования дорогостоящего пространства на SSD — до тех пор, пока тома с наивысшим приоритетом не исчерпают всё быстрое пространство, вы можете поделиться им с другими томами;

• даже если вы столкнулись с нехваткой быстрого пространства — не беда, не нужно ничего останавливать и перемещать, часть данных временно осядет на более медленных ярусах до тех пор, пока не появится свободное место за счет удаления данных или добавления дискового пространства;
• отсутствие даунтайма при любых изменениях в приоритетах производительности, так все перемещения абсолютно прозрачны для приложения, SSV продолжает отдавать те же LUN'ы, просто меняя в фоновом режиме физическое расположение данных;

Как это выглядит на практике
Рассмотрим управление ярусным хранением на примере DataCore SANsymphony-V 9.0. Заодно будут разъяснены различные улучшения в новом релизе 10.0.

На виртуальном стенде с SSV у нас есть пять физических дисков в одном пуле. Мы можем представить, что это физические бэкенды трёх категорий производительности: массивы (с одинаковым типом RAID и примерно одинаковым количеством дисков) из SATA HDD, массивы из SAS HDD и массивы из SSD, и присвоить им различные ярусы.

Далее можно создать несколько виртуальных дисков (томов). По умолчанию всем присваивается профиль normal.

Обратите внимание: в версии 10 появилась возможность задать резервирование до 20% свободного места на каждом ярусе в пуле. Это помогает сократить количество операций по перемещению данных между ярусами. Новые SAU для тома, имеющего профиль с высоким приоритетом, будут выделяться из этого зарезервированного пространства. Отсутствие предварительного резервирования при условии заполненности быстрого яруса привело бы к тому, что SAU сначала были бы выделены на нижних ярусах, а потом в соответствии с профилем их нужно было бы переместить наверх, предварительно переместив вниз данные с менее приоритетных томов.

Вот так выглядит изначальное распределение данных по ярусам для тома vd03_test_mirror. Тёмно-синим подсвечены "горячие" данные. По умолчанию SSV для Auto-Tiering'а отслеживает только нагрузку на чтение. В SSV 10 появилась не только экспериментальная поддержка отслеживания нагрузки на запись, но и синхронизация т.н. heat map'ов (таблиц распределения "горячих" данных) между двумя узлами, на которых размещён зеркальный том. Это помогает избежать ситуации с резким снижением производительности при отказе основного узла.

Сменим профиль тома vd03_test_mirror на archive. Этому профилю соответствует tier affinity с привязкой только к самому медленному ярусу Tier-3. Данные (с гранулярностью на уровне отдельных SAU) начинают перемещаться вниз. Обратите внимание на то, что том всё ещё нагружен, все области подсвечены тёмно-синим, но политика размещения уже не даёт занять пространство на быстрых ярусах.
Для того, чтобы снизить влияние перемещения данных на производительность, SSV производит операции по миграции SAU в соответствии с несколькими т.н. планами миграции:
Высокоприоритетный план (перемещается один SAU в секунду):

• перемещения, необходимые для соблюдения tier affinity. Например, место на нужном ярусе закончилось и приходится выделять новые SAU на медленных ярусах, но затем нужно привести всё в соответствии с tier affinity, чтобы обеспечить высокоприоритетным томам должный уровень производительности;
• при плановом отключении диска. Допустим, мы планируем отключить для обслуживания (или вообще списать) целую СХД, тома с которой использует SSV. Естественно, это необходимо сделать как можно скорее;
• при изменении назначенного яруса для физических дисков или изменении профиля для тома SSV (виртуального диска);

Обычный план (перемещается один SAU раз в 30 секунд):
все остальные перемещения основаны на мониторинге нагрузки, т.е. на статистике доступа к SAU ("горячие"/"холодные" данные).

Все данные с vd03_test_mirror осели вниз, на медленный tier-3, освободив дорогостоящее быстрое дисковое пространство первого и второго ярусов.
Этот финальный скриншот уже из 10-й версии SSV, где разработчики дополнительно решили поменять визуализацию распределения SAU. Теперь акцент сделан на соотношении объемов горячих/холодных данных и свободного пространства, без учёта малополезной для администратора информации о точном расположения SAU на физических дисках.
Заключение
Как обычно, если вас интересует более подробная информация по любой теме, описанной в данном блоге, или нужен демо-стенд, то вы всегда можете обратиться в компанию True System.