Сайзинг Flash Pool
Попробуем разобраться как подобрать нужное количество SSD-кэша для систем NetApp. Эти советы подойдут тем, у кого уже используется NetApp или есть возможность взять систему в тест. Даже демо-система без SSD дисков, позволит понять насколько эффективно будет работать кэш с вашими данными.
К сожалению, универсального ответа на вопрос «Как понять процент “горячих” данных?» без тестирования на реальном оборудовании у меня нет. Если кто-то поделится таким рецептом для каких-либо приложений, буду рад.
Как понять насколько эффективно работает Flash Pool в текущей конфигурации? Какая ёмкость SSD-кэша в Flash Pool будет оптимальной, если вы только собираетесь добавлять кэш к обычному агрегату?
Поговорим про AWA — Automated Workload Analyzer. Инструмент, который помогает получить ответы на эти вопросы.
Некоторую статистику по работе FlashPool можно увидеть в OnCommand System Manager. Но она не особо информативна и, например, не позволяет понять какие тома больше используют кэш, а каким он в принципе не нужен.
Куда больше информации можно получить, запустив AWA. Это часть ONTAP. Появилась эта функциональность в Data ONTAP 8.2.1 и доступна для 7-mode и cluster-mode. AWA собирает и анализирует статистику по определенному агрегату. На основе собранных данных рекомендует оптимальный размер SSD-кэша, показывает предполагаемые показатели cache hit rate для рекомендуемой ёмкости Flash Pool и аналогичные показатели при меньшем размере кэша. С выходом Data ONTAP 8.3.1 можно посмотреть информацию в разрезе томов на агрегате.
AWA — это по сути 3 node-shell команды:
- wafl awa start
- wafl awa print
- wafl awa stopВот как это выглядит на практике (вывод можно копировать):
Последовательность действий следующая. Сначала мы запускам AWA для агрегата. Ждём 24 часа, а ещё лучше несколько дней. Останавливаем работу AWA. Желательно, чтобы в период работы AWA на СХД была типичная нагрузка. В процессе можно смотреть результаты работы, используя wafl awa print. Можно запускать анализ сразу нескольких агрегатов одновременно. Максимально работа AWA “отъест” 2% CPU, независимо от количества анализируемых агрегатов и не более 0.2% от кэша контроллера на каждый агрегат.
Для просмотра информации по томам используется опция -t. Если добавить после неё число n, то выведется информация по n самым нагруженным томам.
AWA можно запускать на агрегатах, где уже используется Flash Pool.
Само собой, результат работы AWA, показанный выше далёк от того, что можно увидеть в реальной жизни. Я запускал это на симуляторе.
Вот например, как выглядят результаты работы AWA на «боевой» системе после сбора статистики в течение 2 недель. Это FAS8040 у клиента, который предоставляет облачные услуги.
### FP AWA Stats ###
Host NA-Store-A Memory 28342 MB
ONTAP Version NetApp Release 8.2.1 Cluster-Mode: Fri Mar 21 14:48:58 PDT 2014
AWA Version 1
Layout Version 1
CM Version 1
Basic Information
Aggregate aggr_SAS
Current-time Fri May 13 15:14:56 FET 2016
Start-time Fri Apr 29 00:21:37 FET 2016
Total runtime (sec) 1263213
Interval length (sec) 600
Total intervals 2111
In-core Intervals 1024
Summary of the past 1023 intervals
max
Read Throughput 247.095 MB/s
Write Throughput 274.819 MB/s
Cacheable Read (%) 78.298 %
Cacheable Write (%) 35.510 %
Max Projected Cache Size 5888.973 GB
Projected Read Offload 60.000 %
Projected Write Offload 28.000 %
Summary Cache Hit Rate vs. Cache Size
Size 20% 40% 60% 80% 100%
Read Hit 46.000 52.000 55.000 59.000 60.000
Write Hit 26.000 26.000 26.000 26.000 28.000
The entire results and output of Automated Workload Analyzer (AWA) are
estimates. The format, syntax, CLI, results and output of AWA may
change in future Data ONTAP releases. AWA reports the projected cache
size in capacity. It does not make recommendations regarding the
number of data SSDs required. Please follow the guidelines for
configuring and deploying Flash Pool; that are provided in tools and
collateral documents. These include verifying the platform cache size
maximums and minimum number and maximum number of data SSDs.
### FP AWA Stats End ###Что мы можем понять из этого вывода?
- Read throughput and write throughput: Это максимальные показатели throughput из всех 10-минутных интервалов. Учитывается случайная и последовательная нагрузки.
- Cacheable read and cacheable write: Это показатели из интервала, который имеет максимальные значения cache hit. Причём это может быть интервал отличный от интервала из предыдущего пункта. Flash Pool кэширует все случайные операции чтения на агрегате, то есть Cacheable Read (%) это процент случайного чтения с агрегата. Значение Cacheable Write (%) показывает операции записи, которые могут попасть в Flash Pool при использовании политики по-умолчанию “random-write” (это случайные операции перезаписи). Вообще про работу Flash Pool и доступные политики я сделаю отдельный пост. Когда-нибудь.
- Max projected cache size: Это то, ради чего и запускается AWA — рекомендуемый размер кэша для агрегата. Чем дольше работал AWA, тем выше это значение может быть.
- Summary cache hit rate vs. cache size: Это таблица показывает показатели cache hit при использовании меньшего объема кэша, чем указано в Max projected cache size. Иногда на значение Max projected cache size может влиять нетипичная нагрузка в течение некоторых интервалов. И в таблице можно будет увидеть, что меньшее количество кэша может дать такую же выгоду.
Рекомендую не забывать использовать AWA с новыми только настраиваемыми системами с SSD под Flash Pool. NetApp не даёт возможности удалить диски из агрегатов, в том числе используемые для кэша, без разрушения агрегата. Поэтому, чтобы в будущем не было “мучительно больно” из-за неправильного распределения кэша, лучше разбить диски по агрегатам, а добавление кэша отложить. В течение пары недель собрать статистику с помощью AWA, и на основе этой информации оптимально сконфигурировать Flash Pool.
AWA можно использовать и для сайзинга Flash Cache. Для этого надо обращать внимание только на показатели связанные с чтением, так как Flash Cache работает только как кэш на чтение.
