NetApp для самых маленьких: кэша много не бывает

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

В типичной системе без кэширования (но я таких не знаю, поэтому это рассматривается в теории), каждая операция ввода-вывода будет происходить напрямую с накопителей и может занимать десятки миллисекунд (особенно в случае с HDD). Конечно же DRAM, который используется в качестве системного кэша, намного быстрее даже SSD, а SSD в свою очередь быстрее HDD и, соответственно, может быть использован также в качестве кэша. Так почему бы просто не поместить все данные в кэш? В этом случае есть несколько проблем:

• DRAM достаточно дорога, дороже SSD
• Сложности масштабирования. Даже простое расширение до 1Тб может потребовать использование нескольких процессоров, что сильно усложнит и удорожит систему
• DRAM является энергозависимой памятью, что влечёт за собой дополнительные требования к отказоустойчивости при пропадании питания

Но нужно ли нам хранить абсолютно все данные в кэше? Как показывает практика — нет. В каждой системе существует рабочий набор данных, который составляет лишь часть от общего объёма данных, с которыми работает та или иная система. Рабочий набор данных может изменяться со временем и обращение к каким-то блокам данных происходит намного меньше. Отсюда получается, что нет смысла хранить все данные в дорогой DRAM.

Работа с кэшем происходит довольно просто:

• Чтение — все блоки данных, которые запрашивает хост у нашей СХД, в первую очередь ищутся в кэше. Если данные в кэше присутствуют, то чтение происходит из него, если же данных в кэше нет, тогда чтение происходит с накопителей SSD или HDD
• Запись — все новые данные записываются в кэш, затем переносятся на SSD или HDD, используемые в качестве основного хранилища

В целом такой подход к кэшированию не является уникальным для систем ONTAP, сегодня так работают все известные СХД. Но у систем под управлением ONTAP есть собственный подход к распределению данных на контроллерах и контроллерных парах и, прежде чем продолжать дальше, я крайне рекомендую ознакомиться со статьёй «Как устроена память NetApp FAS: NVRAM, Кеш и Тетрис» Дмитрия Березенко.

Интересное начинается дальше — что, если мы поняли, что кэша нашего контроллера недостаточно для нашей разросшейся системы, а производительность нужно увеличить без покупки новой системы хранения? Считается, что около 80% данных на СХД являются так называемые «холодные данные», соответственно, чтобы ускорить нашу системы, мы должны 20% данных положить на более быстрые, нежели HDD, накопители — SSD. Но подобное расширение системы не всегда возможно, не всегда экономически целесообразно (например, если нам нужно всего 3-4 накопителя SSD на 1Тб, но мы вынуждены будем купить дополнительную полку). Но что, если бы можно было установить эти SSD напрямую в контроллер, без покупки дополнительных полок? Даже если у нас «голова» уже забита HDD? Тут у нас возникает другая проблема — нам необходимо самостоятельно понять и решить  какие данные у нас являются «горячими» и требуют перемещения на SSD, если бы мы использовали его в качестве быстрого тира. Чтобы избежать подобных решений и получить максимальную эффективность от использования Flash, у компании NetApp есть технология Flash Cache.

Flash Cache
Технология Flash Cache позволяет расширить системный кэш на чтение за счёт быстрых Flash накопителей.  Работает это довольно просто. Когда блок данных должен быть «выброшен» из системного кэша для записи туда другого блока, происходит его перемещение на накопитель Flash Cache, который пусть и чуть медленнее, чем DRAM, но по-прежнему более производительный, чем HDD или SAS SSD. Работает эта технология по принципу plug-n-play — достаточно просто установить накопители и не требует никакой дополнительной настройки. Естественно, карточки должны быть зеркально установлены в оба контроллера системы, но при этом данные Flash Cache не зеркалируются между контроллерами, а каждый из них содержит свой набор данных. Вследствии чего выход из строя контроллера и последующий тэйковер приводит к потере кэша вышедшего из строя контроллера. Напомню, что Flash Cache используется только для чтения и все данные у нас уже есть на накопителях, так что данные не теряются, они просто будут прочитаны с дисков при следующем обращении и попадут в системный кэш.

FAS 9000 поддерживает установку накопителей формата NVMe SSD, остальные модели от 2720 до FAS 8300 — NVMe M.2. В контроллеры 27** уже установлены карты, в остальные же системы — можно установить по два. Для системы FAS 9000 доступно 2 накопителя объёмом 1 и 4Тб, для остальных систем — только 1Тб. Отсюда мы можем понять максимальный объём Flash Cache, который мы можем установить в систему.

После установки модуля Flash Cache, у нас изменяется процесс чтения данных с СХД:

1. Ищем нужный блок данных в системном кэше
2. Ищем нужный блок данных во Flash Cache
3. Если данных ни в одном из кэшей не оказалось — читаем его с медленных дисков

Flash Cache позволяет увеличить производительность системы на операциях рандомного чтения и делает это для всех аггрегатов данного контроллера.

Но бывают ситуации, когда мы хотим ускорить производительность конкретного пула и для нас более логично использовать весь доступный flash именно для данного пула, а не на всю систему. Для этого есть Flash Pool.

Flash Pool
Технология Flash Pool позволяет нам использовать уже обычные SSD накопители в нашей СХД в качестве кэша для HDD аггрегатов. Если вы впервые столкнулись с системами под управлением ONTAP, вам может показаться, что подобный механизм реализован и у других вендоров СХД и является тирингом, но нет.  Что такое Tiering? Это распределение ваших данных по разным классам хранения для оптимизации затрат, т.к. хранить всё на дорогих носителя просто не выгодно, как мы это уже выше обсудили. Далеко не всем нужен файловый сервер на SSD, к примеру.
Тиринг предоставляет возможность автоматического многоуровневого перемещения данных вверх или вниз между твердотельными и жесткими дисками. У разных производителей это реализовано по-разному, но сейчас все переходят к схеме, что данные между уровнями (по крайней мере перемещение с холодного на горячий) происходит не через какие-то промежутки времени, а моментально, при обращении к этим данным. Но здесь есть и проблемы — данные могут внезапно стать активными и оказаться на неправильном уровне хранения, в то время как другие данные могут стать неактивными и использовать драгоценные ресурсы. Для перемещения данных между уровнями обычно требуется некоторое буферное пространство для работы, а также создаёт дополнительную нагрузку на накопители. Но стоит упомянуть и о плюсах этого решения — использование механизмов тиринга также позволяет вам за счёт объёма установленных SSD расширить ваш пул по объёму, при этом у нас есть только одна копия блока данных, которая перемещается между HDD и SSD, а не просто копируется в кэш. Но в системах под управлением ONTAP нет тиринга. В случае использования Flash Pool мы хоть и добавляем SSD накопители к нашему HDD аггрегату, но он не расширяет полезный объём этого аггрегата и накопители используются исключительно в качестве кэша для этого конкретного аггрегата.
Механизм работы здесь такой же, как и в случае с Flash Cache — когда какой-то блок данных из системного кэша (и Flash Cache, если он имеется) должен быть «выброшен», он переносится на SSD кэш Flash Pool’а того аггрегата, которому принадлежит этот кэшированный блок данных. Но есть разница с точки зрения чтения данных — если система понимает, что у нас происходит рандомное чтение блоков, то блоки читаются из Flash Pool’а (если они уже кэшированы), если же у нас происходит последовательное чтение, то оно производится напрямую с дисков.

По поводу сайзинга Flash Pool, Артур Аликулов у себя в блоге писал статью на эту тему «Сайзинг Flash Pool«.

Сравнение Flash Pools и Flash Cache

Важное отличие —  Flash Pool может кэшировать случайные перезаписи. Случайная перезапись — это небольшая случайная запись блока(ов), который недавно был записан на накопитель, и теперь мы видим запрос на перезапись этого блока. Тот факт, что мы говорим только о случайной перезаписи, важен, потому что пулы флэш-памяти не ускоряют традиционную и последовательную запись — ONTAP уже оптимизирован для записи. Flash Pool позволяет нам кэшировать эти случайные перезаписи, позволяя записывать точки консистентности (Consistency Point), содержащие случайные перезаписи, в кэш SSD. Запись на SSD происходит быстрее, чем запись на диск, а это означает, что точка консистентности возникает быстрее. Случайная перезапись — самая дорогая (т. е. самая медленная) операция, которую мы можем выполнить с диском, поэтому в наших интересах ускорить их.

Дедупликация — блоки данных, которые дедуплицируются на HDD, так же дедуплицируются во Flash Pools и Flash Cache
Компрессия:

• Flash Pools — кэширует сжатые блоки
• Flash Cache — не кэширует сжатые блоки

Flash Pools и Flash Cache могут работать вместе и дополнять друг друга. И самое приятное — ни одна из этих технологий не требует дополнительных лицензий.

FlexCache
Все говорят о трансформации IT, миграции в облака, гео-распределении данных. Компании давно выросли из рамок одного офиса или ЦОДа. Это влечёт за собой 2 проблемы: удобство доступа к данным и скорость доступа к данным.

Если объяснить простыми словами — FlexCache позволяет кэшировать данные файловой шары (поддерживается только файловый доступ по SBM и NFS) удалённой площадки на площадке, расположенной рядом с хостами, которые производят интенсивное чтение с удалённой шары. Естественно кэшированые данные, которые находятся у нас на площадке рядом с хостами — читаются намного быстрее, чем с удалённой площадки.

Именно в этом и состоит смысл данной технологии. Этот функционал отличается от обычной репликации при помощи SnapMirror, да и в целом use case у него несколько иной.  Идеальной ситуаций, для использования FlexCache является наличие одного большого хранилища, расположенного на какой то центральной площадке, и множество площадок, на которых данные с этой системы обрабатываются и необходимо предоставить качественный доступ к этим данным с минимальными задержками и высокой производительностью.
Александр Миронов поделился со мной опытом и подкинул ещё один кейс — когда в рамках одной площадки у вас есть большая дисковая система и вы ставите на этой же площадке небольшую flash систему, дабы ускорить её работу.

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

При этом FlexCache построен таким образом, что работая с кэш шарой на локальной площадке, данные, записываемые на эту шару всё-равно будут записываться на удалённую площадку и только после этого наш клиент будет получать ответ об успешной записи. Естественно здесь вероятнее всего можно столкнуться с очень высокими задержками на запись, о чём нужно подумать заранее — на сколько этот вариант для вас приемлем.