Строим емкое производительное ZFS-хранилище

06.08.2020 | Хранилища

ZFS – продвинутая файловая система и менеджер дисков в одном лице, набор инструментов для создания систем хранения данных и управления ими. Достоинства ZFS многократно и подробно описаны.

Пройдя через корпоративные поглощения, расщепление сообществ и портирование на различные платформы, ZFS по сей день является основой многодисковых топологий. Она уникальна охватом: от программных сборок «для дома» до монументальных реализаций вроде Oracle ZFS Storage Appliance. Наш интерес лежит  посередине: силами ПО и оптимизацией начинки повысить продуктивность емкой системы хранения.

Примером коммерческой ОС на ZFS может служить Open-E JovianDSS. Спросите, зачем платить кому-то, если есть платформы с открытым исходным кодом? Затем, чтобы использовать чужой многолетний опыт выжимания производительности, упростить настройку, избежать зависимости от «настройщика» и получить доступ к расширенной функциональности – как кластеризация хранения.

Емкость

Когда ZFS создавалась, не было SSD, не было NVMe. Речь шла о надежном хранении больших объемов данных  на механических дисках. Появление твердотельных накопителей добавило средств управления производительностью, но складируют объемные данные по-прежнему на HDD.

Внутренняя топология хранилищ на механических дисках одинакова. Не надо воспринимать системы хранения как монолитные устройства. При всех отличиях их контроллеров и внешних интерфейсов, дисковых корзин и экспандеров, сам HDD-массив – это набор дисков, адреcуемый по SAS. Он может быть частью моноблочной СХД, а может - автономным контейнером, JBOD, подключаемым по SAS к управляющему хосту.

В отличие от монолитных СХД, модульные системы хранения построены на отделении «голов» от «тел».  Для емких ZFS–хранилищ такой раскрой особенно актуален: за всю логику, производительность и сетевое взаимодействие отвечают управляющие серверы, за объем хранения и его масштабирование – JBOD на HDD. Сами JBOD не влияют на управление данными, их задача – обеспечить постоянный доступ к HDD и комфортные условия их эксплуатации (в противостоянии двум основным врагам механических дисков, вибрации и перегреву). Масштабируют хранение, последовательно заполняя JBOD дисками, а когда полна коробочка, каскадным или параллельным подключением нескольких JBOD к хостам.

Производительность

Закройщик хранилища ZFS работает с пулами хранения (zpool), виртуальными устройствами (vdev) и реальными устройствами (device). Пулы собираются из виртуальных устройств, а те – из  реальных.  Выбор дисков и стратегии монтирования влияет на производительность. Имеют значение сетевые интерфейсы и протоколы доступа. Рекомендации по настройке пулов известны.

Мы остановимся на таких источниках продуктивности систем хранения ZFS как оперативная память и SSD. Две основные характеристики производительности ввода/вывода – IOPS и Throughput. Объединения HDD в состоянии обеспечить высокую пропускную способность, но больших IOPS от механических дисков не добьешься, интенсивную нагрузку I/O надо парировать SSD. Дело усугубляется фрагментацией данных на дисках. ZFS относится к классу систем COW (copy-on-write), новая информация записывается не по старому месту, а в новый блок, вместе с указателями. Это позволяет отслеживать изменения и откатываться на прошлые состояния данных в случае сбоев. Это же создает определенные проблемы: скорость записи в ZFS привязана к запасу свободных смежных блоков. По мере заполнения пула остаток тает, данные фрагментируются, а показатели IOPS записи произвольного доступа становятся важнее потенциальной пропускной способности потоковой записи. Чем меньше свободного места на дисках, тем больше времени уходит на транзакции. При 50% заполнения емкости HDD уже можно увидеть замедление.  На рубеже 80% пора бить тревогу  и добавлять свободное дисковое пространство.

ARC, L2ARC, ZIL, SLOG

Кеширование чтения ARC (Adaptive Replacement Cache) переносит в RAM копии недавно прочитанных блоков. На производительность записи кеш чтения ARC напрямую не влияет, хотя быстродействие может немного вырасти из-за того, что с дисков снимается часть нагрузки чтения. Второй уровень ARC или L2ARC является расширением ARC на SSD – они дешевле оперативной памяти. Вытесняемый из ARC файл перемещается в L2ARC.

Все запросы на запись попадают в RAM. Есть две основные категории операций записи — синхронные (sync) и асинхронные (async). В большинстве рабочих нагрузок запись асинхронная. Файловая система собирает все обращения, синхронные и асинхронные, в транзакционные группы TXG и порциями сбрасывает на диски, потоком, уменьшая фрагментацию данных. С точки зрения клиента асинхронная запись  - очень быстрый процесс: попадание запроса в скоростную оперативную память сервера хранения равносильно записи на его диски (хотя в действительности данные TXG переносятся в основное хранилище с задержкой - по умолчанию,  каждые пять секунд).

В любой момент данные должны быть состоятельны. Всегда есть риск, что при аварии по питанию энергозависимая память потеряет агрегат TXG, что повлечет рассогласование данных. На помощь приходит механизм синхронной записи, пусть и за счет дополнительных затрат.

Синхронные запросы пишутся сразу на постоянные носители. Когда от клиента приходит запрос на синхронную запись, он попадает в TXG вместе с асинхронными, но сервер не даст подтверждения его успешного завершения, пока не запишет его в журнал ZIL (ZFS intention Log), вместе с метаданными. Под журнал по умолчанию выделяется часть основного пула в хранилище. Очевидно, держать ZIL на HDD нежелательно, из-за их медленного отклика.

ZIL размещают на отдельном от основного устройстве хранения– SLOG (двух SSD в зеркале). Выбирают SSD c минимальными задержками, максимальной производительностью произвольного доступа и большим ресурсом перезаписи. ZFS оперативно вносит синхронные записи в журнал ZIL и оставляет их же в RAM. Оттуда,  в составе агрегатов TXG они сбрасываются в хранилище вместе с обычными асинхронными запросами на запись. В нормальном режиме работы ZIL записывается и никогда больше не читается. Если происходит сбой ZFS, данные и метаданные считываются из ZIL при перезапуске и импорте пула, объединяются в группы TXG и заново фиксируются в первичном хранилище. 

 

 

В среде с большим количеством синхронных записей, SLOG косвенно ускоряет асинхронную запись и некешированное чтение – ведь выгрузка записей ZIL в отдельное устройство с быстрым откликом означает меньшую конкуренцию за IOPS на основном массиве.

Временной промежуток между сбросами данных TXG в основное хранилище невелик, следовательно, под ZIL/SLOG нужны совсем небольшие SSD. Зато они - важный объект погони за производительностью.

Коротко о главном

Сколько ставить  оперативной памяти в управляющий сервер, зависит от общего объема хранения, плана кеширования, (не)использования дедупликации. Без нее нормой считается 1-2GB оперативной памяти на 1TB данных. С ней – вдвое больше. Под L2ARC советуют выделять примерно пятикратный объем RAM, например, 256GB LARC2 при 64GB RAM. Емкость носителей SLOG под ZIL можно оценить, исходя из пропускной способности сетевых интерфейсов, объема данных, которые они потенциально могут принять за пять секунд. Это считаные гигабайты.

Подведем итоги

ARC кеширует операции чтения в RAM. Оттуда они вытесняются в L2ARC на SSD – при ротации данных, либо конкурирующими за оперативную память приложениями. ARC и L2ARC содержат обновляемые копии данных основного хранилища, как и положено кеш-памяти.

ZIL не является кешем записи. Это область на постоянных носителях, выделяемая под журнал операций синхронной записи – те не могут считаться выполненными, просто попав в энергозависимую RAM. По умолчанию, ZIL размещается на основном хранилище. Все в один голос рекомендуют добавить в систему пару SSD под SLOG – вспомогательное хранилище малой емкости, но с быстрым откликом. SLOG позволяет поднять производительность. Однако, первичная его задача – помочь восстановить данные, которые без него были бы утеряны после сбоев питания.

Практическое воплощение

Специализированные ОС, как Open-E JovianDSS, превращают стандартные платформы в серверы хранения под критичные приложения: тяжеловесные базы данных, VDI или раздачу медийного контента. Функциональность обеспечивает программное обеспечение, производительность и подгонку хранилища под сетевое окружение – аппаратная база и следование описанным принципам. Погоня за емкостью и производительностью в модульном подходе естественным образом раскладывается на оптимизацию «тел» и «голов» по отдельности – благо одно к другому подключается стандартным SAS и не связывает свободу действий.

Емкое «тело»

Образцовым можно считать семейство Western Digital Ultrastar Data60 JBOD на 60 HDD. Они продаются сразу со всеми дисками (NL SAS емкостью от 4 до 18TB) или частично заполненные - с 24 дисками из 60. Постепенное добавление дисков в JBOD, а затем подключение следующего JBOD дает поэтапное масштабирование хранения.

Механическим дискам в специализированных JBOD комфортно - они качественно гасят наведенные вибрации и держат рабочую температуру внутри на добрый десяток градусов ниже, чем стандартные серверные корпуса под большое количество дисков. Меньше тряска и температура – дольше жизнь HDD. Все подсистемы и пути к дискам дублированы. Большое количество портов SAS позволяет подключить JBOD к нескольким хостам, а при необходимости – зонировать его. По умолчанию все HDD видны всем инициаторам, подключенным к любому из внешних портов. Можно сгруппировать диски в зоны, а зоны приписать определенным портам. Каждый диск зоны будет виден только этот порт, и только хосту, подключенному к нему. Таблица разрешений правится через интерфейс командной строки CLI. 

 Производительная «голова»

В области «тела» все более-менее консервативно: стандарт SAS стабилен, разве что помалу растет емкость дисков. На уровне «головы» есть широкое поле для творчества - ведь под ZFS можно использовать любые платформы, типы подключений внутренних носителей и внешних сетевых интерфейсов.

Пример удобной базы - ASUS RS500A-E10-R12 под один процессор AMD EPYC 7xx2. Потенциал вычислительной мощности (до 64 ядер CPU, до 2TB RAM) позволяет обслуживать хранилища масштаба петабайта. В такой сервер можно поставить до 12 х U.2 (2.5” NVMe) SSD c горячей заменой накопителей и подключить периферию PCIe Gen4 – например, карты 200 Gigabit Ethernet.

Предположим, мы решили начать с хранения полутора сотен терабайт с перспективой расширения. В качестве основого хранилища подойдет WD Ultrastar Data60 24 (60) x 8TB. Если не задействовать дедупликацию, ему достаточно управляющего сервера с 16-ядерным AMD EPYC 7302P и 256GB RAM. Под L2ARC хватит двух Western Digital Ultrastar SN640 U.2 SSDs емкостью 960GB (зеркалировать носители под кеш чтения необязательно). Под ZIL/SLOG поставим пару Intel Optane P4801x емкостью 100GB. Для подключения JBOD в сервере есть SAS HBA с внешними портами, LSI 9300-8e или 9305-16e.

 Intel Optane на памяти 3D XPoint превосходит NAND SSD по всем параметрам: скорости отклика, IOPS (особенно, при малой глубине очереди запросов), пропускной способности, ресурсу. На 100GB Intel Optane P4801x можно записать 10.9 петабайт данных (60 DWPD). И это недорогой SSD - из-за его малой емкости (а нам большего и не надо).

Такая система хранения производительна и масштабируема по емкости: добавлением HDD в JBOD, RAM в сервер, SSD в L2ARC сервера.

All-flash

В управляющей «голове» сконцентрированы средства повышения производительности хранения: многоядерные CPU, многоканальная память, диски NVMе (на памяти NAND и на памяти 3D XPoint – кому что), скоростная периферия. Если надо обеспечить максимальную продуктивность на объеме хранения в несколько десятков терабайт, можно обойтись просто массивом all-flash, без всяких JBOD и механических дисков. Первичным хранилищем послужит десяток U.2 (емкостью от 480GB до 7.68TB), L2ARC в варианте all-flash вообще не нужен – чтение с основного массива и так быстрое. ZIL/SLOG нужен. Получившемуся 1U-монстру еще пойди, найди конкурента.