Под прессом петабайта

Данные неоднородны. Отличаются их происхождение, свойства, востребованность. Где это возможно, данные раскладывают по устройствам разной производительности (емкости, доступности, стоимости). А где нет? Самая большая проблема крупных компаний и центров обработки данных - взрывной рост неструктурированных данных. Ими не просто управлять, архивировать или удалять - они принадлежат множеству людей и приложений.  Значительная часть данных неактивна и занимает место безо всякой цели. То, что владельцы считают цифровыми активами, на деле – пассивы. Тариф хранения един для всех.

Дальше - больше. Раздувание первичных хранилищ отражается на системах резервного копирования. За бэкап смеси важных данных и неактивных данных отвечают одни и те же политики. Полное резервное копирование просаживает производительность клиентских серверов, сетей и хранилищ. В итоге, забота о пассивах расходует место, требует все более мощных серверов и быстрых сетей – множит затраты.

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

Метаданные, блендеры, настройки помола

Решение проблемы неструктурированных данных начинается с признания того, что проблема существует. Что трудно найти нужные файлы, а значительная часть вычислительных, сетевых ресурсов и дискового пространства уходит на хранение, репликацию и резервное копирование неактивных данных.

Смягчает задачу использование интегрированного поиска с помощью расширенных метаданных, «данных о данных».  Метаданные содержат сведения о сопутствующих признаках и свойствах, позволяя автоматически искать и управлять выборками данных в информационных потоках. Рабочие нагрузки имеют дело с файлами, каждый из которых генерирует метаданные. И хорошо генерируют. По данным поставщиков файловых систем, на метаданные приходится до 80% всех операций ввода-вывода. Привычные системы хранения упираются в потолок возможностей не потому, что некуда подключать полки расширения, а потому что не обеспечивают производительность и управляемость под смешанными нагрузками.

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

SSD-кэширование

Данные редкого обращения - «холодные». Таких в архивах большинство.  Чем чаще к данным обращаются, тем они «теплее».  В системах хранения используют SSD-кэширование — как буфер между инициаторами и основным массивом. «Популярные» блоки перемещаются на SSD и будут читаться с меньшей задержкой. Получив же запрос на запись, система размещает блоки данных на других SSD. Благодаря быстрым носителям, оповещение инициаторов об успешной транзакции происходит с минимальными  задержками. По мере заполнения кэша система постепенно переносит данные в основное хранилище.

Объем SSD-кэша ограничен, в каждой системе хранения существуют свои алгоритмы, какие блоки данных вытеснять и по какому принципу делать замещение. Например, в кэш чтения обычно копируются блоки данных повторного обращения. А в кэш записи попадают все случайные запросы на запись, у которых размер блока меньше устанавливаемого параметра, скажем, 32KB. Отсюда понятно, зачем под кэш записи программно-определяемых систем нужны SSD с большим ресурсом и быстрым откликом.

Подробнее про алгоритмы вытеснения и принципы обмена данными с основным хранилищем можно прочесть тут. SSD-кэширование дополняет HDD-массивы: механические диски успешно справляются с последовательными нагрузками, но пасуют перед случайным доступом – и тогда их принимают на себя SSD,  где позволяет управляющая логика хранилища. Объем SDD-кэша при этом составляет около 5–10% от емкости основной дисковой подсистемы.

Системы, которые используют SSD-кэш вместе с HDD-дисками - гибридные. Кабы речь не шла о сотнях терабайт данных, хватало бы хранилищ all-flash. А так приходится ставить СХД на смеси носителей под широкий спектр задач и нагрузок. Цена имеет значение.

Уплотнение данных

Снизить накладные расходы на хранение информации помогает сжатие массива данных (компрессия) с устранением избыточных копий (дедупликация). Но не всем и не всегда.  «Мифология дедупликации» твердо говорит только об одном: просадка производительности на массиве гарантирована, а облегчение – нет. Большие вычислительные ресурсы отвлекаются независимо от метода и уровня детализации (файлы – блоки - байты). Даже если ваша система хранения с дедупликацией может хранить десять копий в месте, достаточном для хранения одной копии, вы все равно заплатите, тем или иным способом.

Файлы, блоки, объекты

Привычное файловое хранение построено на иерархических каталогах: данные хранятся в файлах, те - в папках, для доступа к данным нужен точный путь. Блочные хранилища обращаются к данным по табличным адресам блоков. Объектные хранилища связывают данные с причастными метаданными в объекты, размещают их «где-то» и обращаются к ним по уникальному указателю. Сильная сторона объектного хранения - хорошая масштабируемость по объему.

Управление адресацией данных (и метаданными) определяет применимость системы хранения в большей степени, чем ее вычислительная мощность или физические носители.  Ошибки выбора СХД приводит к умножению проблем с масштабированием емкости.

Может, уйти в облако?

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

Цена выхода

 Стоимость вывода данных - ключевой параметр для одобрения или ветирования переноса хранения в облако. Прежде чем туда переходить, проверьте исходящие тарифы облачных провайдеров. Размещение данных и приложений в облаке (вход) стоит недорого. Зато цена вывода, перемещения данных в другую область (выход), может неприятно удивить. От поставщика к поставщику цены  меняются не сильно. Вот тарифы основных операторов:

В ожидании петабайта

Петабайт умеренно активных данных хранят на механических дисках. Под трафик метаданных и кэширование содержательных запросов используют SSD. На этом заканчивается общее емких систем хранения. Дальше их дороги расходятся – сообразно обстоятельствам и паттернам обслуживаемых данных. Первичен не выбор СХД, а анализ приложений. В программно-определяемом мире хранения любая функциональность – как уплотнение данных или их согласованное перемещение между уровнями хранения (например, остывающих данных в объектные хранилища) – не является козырем или обязательным требованием. Есть вызовы бизнес-логики, есть программные модели работы с данными, есть цена решения.

Если нет представления о трафике данных, не поможет никакой Ceph.