Прикладная термодинамика систем хранения данных

Искусство обращения информации в деньги построено на обработке данных систем хранения. При этом совсем не обязательно быть в тренде информационных потоков, чтобы быть успешным. В свое время, главный редактор журнала Wired Крис Андерсон, сформулировал концепцию «длинного хвоста» на примере обращения цифрового контента: суммарный вес продаж товаров редкого спроса соизмерим с объемами продаж модных новинок. Качественный анализ данных не повредит любому бизнесу – так становятся понятнее узкие места обслуживающей инфраструктуры

Не все данные равноценны

Данные рождаются, зреют, активно обращаются, стареют и умирают. Кривая их жизненного пути обычно выглядит как на рис. 1.

Рисунок 1

Коль скоро ценность и востребованность данных со временем меняется, для производительной работы с ними нужна настройка систем хранения под рабочий набор приложений. Одним ценны «горбы», другим – «длинные хвосты». Процесс управления информацией на протяжении ее жизни (information life cycle management, ILM) состоит из анализа нагрузок ввода/вывода, распределения и перемещения данных между устройствами хранения – сообразно бизнес-модели. В связке с ILM рассматривают многоуровневое или иерархическое хранение (tiering), а также управление им, с учетом производительности, доступности данных, цены хранения (hierarchical storage management, HSM).

Пирамида на рис. 2, отражает связь уровней, технологий и объемов хранения. Устаревание информации наглядно описывается в терминах «остывания», а качество управления оценивают способностью устройств хранения динамически поддерживать «теплообмен данных» по всему их объему. Экономика процесса имеет значение.

Рисунок 2

Уровни хранения

Tiering – базовое понятие в проектировании систем хранения. В пирамиде хранения находится место разным типам устройств: энергозависимым и постоянным, на вращающихся поверхностях, NAND-памяти и ленте, с разными интерфейсами доступа. В целом, чем быстрее устройство – тем оно дороже. Слои хранения вводят, исходя из разумного сочетания производительности и цены хранения. Не то чтобы архивы длительного хранения считались свалкой малоценных данных – просто скорость их выдачи по запросу некритична.

Многие годы в постоянных устройствах хранения доминировали диски HDD на вращающихся поверхностях. Ближе к основанию пирамиды использовались емкие SAS NL/SATA HDD со скоростью шпинделя 7.2K rpm, в критических приложениях вершины – FC или SAS 10К/15К HDD. Для снижения задержек отклика (latency) и увеличения числа IOPS (IO Operations per Second) к мощным многоканальным RAID-контроллерам подключали возможно большее количество HDD.

Сейчас в борьбе с задержками и гонке за IOPS используют SSD. Для сравнения, стандартный HDD 15K rpm выдает не больше 220-220 IOPS. Серверные SSD обеспечивают порядка 75K IOPS на чтение и половину того в операциях записи. По индивидуальным задержкам отклика SSD так же значительно превосходят HDD: 50 µs против 10 ms. Никакие RAID-контроллеры, с самыми передовыми алгоритмами оптимизации и политиками кэширования, не способны компенсировать системам на вращающихся дисках такое отставание.

Цена SSD перестала быть сдерживающим фактором – а, особенно, с постепенным отказом от производительной и долговечной, но такой дорогой флэш-памяти SLC – в пользу куда более доступой eMLC/MLC и микросборок на ней. Производительность и сохранность данных обеспечивают свойства контроллеров SSD и избыточное резервирование изнашиваемых ячеек памяти. При нынешних темпах интервенции SSD, через 3-5 лет мы не увидим дисков SAS 15K в системах хранения. Очень может быть, что лет через десять в пирамиде не останется никаких HDD.

Особняком стоит самое быстрое устройство хранения – оперативная память серверов (latency DDR3 составляет порядка 10 ns против 50 µs у SSD, а IOPS – 1M против 35K). Для ОС часть оперативной памяти, назначенная RAM drive (или RAM disk), и выглядит как диск. Как правило, данные копируются c постоянных носителей в энергозависимую RAM для ускорения доступа. Кроме рисков потери данных при намеренных действиях (перезагрузка) или случайных сбоях (потеря питания или крах системы), применение RAM drive лимитировано объемом оперативной памяти серверов.

Расслоение данных

Критерии послойного размещения информации на устройствах не так очевидны, как иерархия самих устройств по их физическим свойствам. Для решения о переносе данных между уровнями хранения нужен мониторинг рабочих нагрузок и учет многих параметров: критичности данных для бизнеса, требований к производительности и доступности. Квалификация данных усложняется, если баз данных несколько, если они содержат глубокие исторические пласты актуальной информации – при этом профиль доступа к данным меняется со временем (Рис 1).

Идут от приложений и структуры ввода/вывода (I/O). Предполагаемый объем хранения и уровень доступности важен, но начинают с производительности. А она привязана к характеристикам I/O систем хранения под нагрузкой и зависит от многих факторов: типов приложений, соотношения операций случайного и последовательного доступа, пропорций чтения и записи, размера блоков данных приложений, последовательности поступления запросов.

Раскладка носителей и типов данных в многоуровневом хранении может выглядеть так:

Время – деньги

Задержки крадут деньги. Масштабы потерь («утраченную выгоду») хорошо иллюстрирует давний опыт Amazon: увеличение задержки отклика серверов на 0.1 секунды приводило к падению продаж на 1%. Даже непосвященному понятна роль задержек в бизнес-моделях, монетизация которых привязана к скорости обслуживания пиковых нагрузок: онлайн-торговле, новостных порталах, процессинге платежей, биллинге SMS-голосований, документообороте, подготовке отчетов, логистике.

Являются ли низкие задержки отклика операционных систем конкурентным преимуществом бизнеса? Однозначно, да. Но только владелец данных в состоянии оценить, в какой именно степени – с учетом затрат на реализацию и сопровождение инфраструктуры, усилий по поддержанию непрерывной работы (или направленных на минимизацию простоев). Риски силового вмешательства в работу систем заставляют бизнес пренебрегать оптимизацией в угоду информационной и физической безопасности. Когда серверы и бизнес-приложения уезжают из страны на западные площадки, меньше всего владельцы думают о задержках обращения к данным.

Метрики производительности I/O

Для оценки производительности СХД мало паспортных показателей IOPS. Вообще говоря, IOPS – абстрактная величина, которая не может служить практической метрикой. Она не привязана к свойствам хостов и приложений, рабочему объему и структуре данных, соотношению чтения/записи. IOPS выполняет скорее маркетинговую функцию в продвижении СХД их производителями. Как правило, критичны низкие задержки (latency) в тракте I/O, и такие (стабильно большие показатели) IOPS, при которых разнотипные операции I/O эти низкие задержки не ухудшают (см. о метриках СХД).

Кэширование служит большим резервом производительности I/O в операциях с произвольной выборкой. Все техники кэширования основаны на использовании интеллектуальных алгоритмов работы с данными. Ускорение работы достигается перемещением «горячих» блоков данных (частого обращения) на более скоростные устройства. В системах хранения между приложением и физической средой хранения много посредников, в тракте I/O каждое звено является потенциальным вкладчиком (см. о многоуровневом кэшировании I/O). В промышленных реализациях пирамидой хранения, как правило, заведуют внешние СХД, с их контроллерами, слоями накопителей и встроенным ПО. В массовых серверах для управления производительностью I/O используют RAID-контроллеры с поддержкой многоуровневого хранения данных или специализированые ОС с цепочками логических устройств хранения на разнотипных носителях.

Производительность промышленных СХД

По определению, системы хранения данных – это комплекс программно-аппаратных решений, прежде всего, для надёжного хранения информационных ресурсов и предоставления гарантированного доступа к ним. В ориентированных на проектные рынки СХД производительность I/O тесно связана с реализацией иерархического подхода к управлению хранением и подгонкой под специализированные приложения. В массивах высокого уровня слоеное хранение появилось давно. Пользовательские данные перемещаются автоматически в фоновом режиме между дисками, дисковыми полками или даже разными СХД различных классов стоимости и производительности. Данные критических приложений копируются на SSD. Уже продаются all-flash СХД – исключительно на одних только SSD. Все производительные устройства снабжены богатым букетом функциональных возможностей. Стоимость управления такими сложными системами в разы превышает стоимость их аппаратной части, поэтому рентабельность их применения для ускорения работы приложений никогда не была приоритетным критерием при покупке.

Аппаратное кэширование в массовых серверах

В погоне за производительностью операционных приложений активность I/O переносят с систем хранения на исполняющие серверы. У многоуровневого хранения (tiering) развитых СХД есть демократичный аналог – SSD-кэширование средствами массовых RAID-контроллеров на шине PCIe, в привычной среде бизнес-приложений. Анализом обращений к дискам, наполнением и динамической коррекцией пула «горячих» данных на SSD занимаются сами RAID-контроллеры. Похожую работу они выполняли и раньше – только в собственном кэше на памяти DRAM. Добавив SSD-буфер перед массивом HDD и распространив на него сходную логику работы с востребованными данными, разработчики контроллеров построили трехуровневую систему обслуживания дискового I/O: (1) небольшой кэш в оперативной памяти контроллера – (2) достаточной емкий и быстрый кэш на энергонезависимой флэш-памяти SSD – (3) основное хранилище на HDD. Интеграция в массивы HDD кэширующих пулов из дискретных SAS/SATA SSD не требует изменения настроек приложений и операционных систем. RAID-контроллеры с SSD-кэшированием представлены на рынке линейками Adaptec 7Q/maxCache 3.0 и LSI MegaRAID CacheCade 2.0 (см. SSD-кэширование в массовых серверах: инструменты Adaptec и LSI).

Рис. 3. Многоуровневое хранение средствами RAID-контроллера
(источник: www.adaptec.com)

Для ускорения работы имеющихся массивов сетевого или прямого доступа LSI предлагает решение Nytro XD. В его основе лежат PCIe SSD семейства LSI Nytro WarpDrive, c показателями latency/IOPS, недостижимыми на сборках из дискретных SSD. Система Nytro XD работает в связке с ОС, используемыми для систем хранения данных – такими как Windows Storage Server 2012 или NexentaStor. Транзакции чтения и записи, проходящие между сервером и хранилищем, отслеживаются и анализируются. Часто запрашиваемые данные загружаются в плату Nytro WarpDrive, которая обслуживает приоритетные операции с данными без обращения к дискам основного массива.

Кэширование в ZFS

ZFS это одновременно файловая система и встроенный менеджер томов, с возможностями RAID, контролем целостности и восстановлением данных, сжатием данных, дедупликацией, записью снэпшотов и пр. Разработана Sun Microsystems в проекте OpenSolaris. ZFS требовательна к процессорной мощности и объему оперативной памяти сервера.

В ZFS есть несколько уровней и механизмов кэширования операций I/O при дисковом хранении. «Горячие» данные размещаются в RAM, «теплые» – на быстрых блочных устройствах постоянного хранения, SSD. «Холодные» данные не кэшируются, оставаясь на HDD. При появлении повторяющихся обращений к старым данным, ZFS автоматически переносит их на SSD-диски или в RAM.

В ZFS всегда включен адаптивный замещающий кэш первого уровня в оперативной памяти (Adaptive Replacement Cache, ARC). В нем сохраняются данные и метаданные, считанные блоками с дискового устройства. Второй уровень кэширования, на SSD – опциональный, их есть два вида: адаптивный заменяющий кэш второго уровня (L2ARC), и запись в целевой журнал (ZFS Intent Log, ZIL). Кэш на чтение L2ARC полезен для хранения таблиц дедупликации и при множественных обращениях к данным хранилища – например, при выгрузке интернет-пользователями популярных изображений и видеофайлов. На заполнение L2ARC может уйти несколько часов (прежде чем данные будут сочтены «теплыми» и стоящими кэширования). При утрате устройства под кэшем L2ARC данные не пропадут – все операции чтения будут выполняться с HDD, пусть и медленнее.

Кэширование записей ZIL – это ведение протокола. Целевой журнал хранит записи системных вызовов, они воспроизводятся заново, если произошёл сбой питания или критическая ошибка, при которой основной пул не подтвердил их выполнение. ZIL может быть использован для ускорения синхронизации записи путем записи лога на несколько SSD. Желательно SSD зеркалировать – их ячейки активно изнашиваются при постоянном протоколировании и растут риски потери части записей.

Как любая открытая система, ZFS требует от администратора навыков, глубокого понимания специфики задач и параметров настроек. Сценарии ее использования в web-серверах, серверах баз данных и файловых серверах, с разным размером блока данных приложений, отличаются между собой, но все они требуют привлечения немалых ресурсов центральных процессоров и оперативной памяти.

Знать и уметь

Мало кто из владельцев информации задумывается об ее операционной коммерческой ценности. И зря. Понимание источников производительности бизнес-модели – залог преимущества над конкурентами. Не нужно становиться Amazon’ом для озарения, что быстрый отклик систем хранения данных влияет на доход. Достаточно заглянуть в свой собственный сервер 1С.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365