[Перевод] Прозрачное облачное многоуровневое хранилище на базе Isilon CloudPools11.07.2016 15:33

Вот уже несколько лет доступна такая возможность, как создание многоуровневого хранилища на базе EMC Isilon. Это подразумевает возможность отправлять данные в конкретные пулы хранения — системы узлов, объединённых по признаку однотипности или плотности размещения. В результате сильно вырастет эффективность хранения данных с точки зрения стоимости.

Можно создать политику, согласно которой все новые данные будут сохраняться в Пуле-1, построенном из быстрых узлов S210.

Время отклика будет очень небольшим, но стоимость окажется выше (более быстрые накопители, процессоры и т.д.). Далее можно создать политику второго уровня, например, «перемещать все данные, к которым не обращались более 30 дней, в Пул-2». Этот комплекс может быть построен из узлов Х410, обладающих большей ёмкостью (36 SATA-дисков) и более высоким временем отклика по сравнению с Пулом-1. Ещё менее востребованные данные можно перемещать уже в Пул-3, построенный из узлов HD400 с очень высокой плотностью хранения — 59 SATA-дисков + по 1 SSD на каждый 4U-модуль, но его время отклика ещё больше, чем у Tier 2. Но поскольку этот уровень предназначен лишь для очень редко востребованных данных, это не сильно повлияет на пользователей.

Перемещение данных на основании политик выполняется в фоновом режиме с помощью движка OneFS. При этом не меняется логическое размещение файлов. То есть можно создать одну папку, файлы в которой находятся в трёх разных хранилищах.

Пулы и уровни хранения

Одни и те же данные могут проходить разные стадии жизненного цикла: сырые данные, необработанные, обработанные, дубликаты, резервная копия, архив. Для каждой стадии характерен свой набор требований по доступности и сохранности данных. В отличие от многих других СХД, в которых разные типы информации хранятся совместно, в Isilon применяются разные уровни хранения (Tier). Для каждого уровня используются определённые политики по разделению, обработке и хранению данных. Такой подход позволяет удешевить хранение информации, находящейся в разных стадиях жизненного цикла, быстрее обрабатывать и эффективнее управлять ею. Эти задачи решаются с помощью уровней хранения, которые, в свою очередь, могут делиться на более узкоспециализированные пулы.

Единая файловая система для всех пулов/уровней хранения.

На сегодняшний день существует несколько видов пулов:

S — быстрые, предназначены для транзакционных расчетов.
X — быстрые, предназначены для потоковых задач.
NL — более медленные, предназначены для создания «тёплых» архивов.
HD — более медленные, предназначены для создания «холодных» архивов.

Также появился пятый вид — облако (внешнее или внутреннее).

Как уже упоминалось, каждый пул формируется из узлов одинакового типа (на самом деле, они могут слегка различаться, но это уже выходит за рамки поста). Если у вас развёрнут очень большой кластер, то вполне целесообразно разделить его на разные уровни хранения. Каждый уровень содержит один или несколько пулов. Но в ряде случаев нужды в таком делении нет. Вполне может возникнуть ситуация, когда ваши политики не будут подразумевать наличие пулов или уровней хранения.

Политики

Политики распределения данных по уровням хранения можно легко настроить с помощью WebUI, CLI или API. При этом в качестве критериев при создании политики можно использовать не только частоту обращения к файлам, но и типы файлов, их размещение, владельца или любой другой атрибут. В пользовательском интерфейсе уже есть заранее настроенные шаблоны, которыми можно воспользоваться. К примеру, шаблон Archive содержит правила, согласно которым более старые данные перемещаются в соответствующее хранилище. А шаблон ExtraProtect помогает настроить более высокий уровень защиты файлов с определёнными значениями атрибутов (например, n+3 вместо n+2). При этом самим WebUI пользоваться очень просто, он интуитивно понятен.

CloudPools — нововведение в OneFS 8.0

Одним из интересных нововведений, появившихся в OneFS 8.0, стал новый тип пула — облачный (Cloud). Теперь с помощью Object API он поддерживает:

Amazon S3
Microsoft Azure
EMC Elastic Cloud Storage
EMC Isilon

Последние два продукта, благодаря поддержке ряда API Object REST, могут быть использованы для создания частного облачного архива. Вероятно, можно ожидать внедрения поддержки других поставщиков облачных хранилищ, например, Google и Virtustream.

С помощью CloudPools можно использовать единую файловую систему для работы с облачным хранилищем.

Безопасность облачного хранилища

Предположим, что вы настроили политику, которая задаёт требования к файлам, которые должны быть перемещены в облако. Например, нужно переместить:

Файлы размером больше 5 Мб → И
Файлы, расположенные в папке /ifs/data/stefan → И
Файлы, которые не запрашивали более трёх месяцев.

Политика будет применять согласно расписанию задач Smartpools. Как и в случае со всеми остальными задачами в OneFS, планирование и контроль исполнения осуществляются движком задач (job engine). Задачам может назначаться приоритетность и время исполнения, а в зависимости от текущей ситуации они могут ставиться на паузу.

Как только запускается Smartpools (например, каждый день в 22:00), он сверяет с текущими политиками все папки и файлы, и перемещает в облако те из них, кто соответствуют прописанным критериям.

В локальной файловой системе хранятся файлы заглушки (stub file), содержащие три типа информации:

Мета-данные файла (время создания, время последнего обращения, размер и т.д.)
«Ссылку» на данные в облаке.
Часть исходных кэшированных данных.

Как уже упоминалось, с точки зрения пользователя или приложения нет никакой разницы между «нормальным» файлом и файлом заглушки. Конечно, при желании можно вычислить, но об этом мы поговорим в другой раз.

Вызов файлов из облачного пула и локального кэша

Когда происходит обращение к файлу заглушки, соответствующий контент извлекается из облака и кэшируется локально, на SSD или HDD. Но эти данные не будут храниться в файловой системе вечно. В противном случае любой пользователь мог бы забить всю локальную файловую систему одними лишь командами просмотра, ведь объём хранилища может в разы превышать объём локальной файловой системы. Поэтому лишь администратор или пользователь с соответствующими привилегиями могут присвоить каким-то данным атрибут постоянного хранения в кэше. Поведение самого кэша можно регулировать с помощью настроек CloudPools. К примеру, можно сказать кластеру, чтобы он:

Кэшировал или не кэшировал локально вызываемые данные.
Использовал механизмы Cache Read Ahead только для данных, к которым разрешён доступ, или для полных файлов.
Хранил данные в кэше в течение определённого времени (от секунды до лет).
С определённой частотой осуществлял отложенную запись в кэш (то есть насколько часто кластер должен записывать в облако данные, модифицированные в локальном кэше).

Срок хранения

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

Срок хранения для инкрементального NDMP-бэкапа и SyncIQ. Это параметр определяет, сколько времени будут храниться данные в облаке после синхронизации с другим хранилищем с помощью SyncIQ, либо после бэкапа, выполненного в рамках инкрементальной NDMP-задачи. По умолчанию срок хранения в данном случае равен 5 годам. То есть после удаления локального файла заглушки его можно восстановить с помощью NDMP или SyncIQ, при этом данные будут доступны в течение указанного периода.
Срок хранения для полного NDMP-бэкапа. Всё то же самое, что и в предыдущем случае, только для полных NDMP-бэкапов.

Заключение

CloudPools — это удобный инструмент, позволяющий создать из горизонтально масштабируемой NAS-системы Isilon прозрачное внешнее многоуровневое хранилище. На данный момент поддерживаются два сторонних облачных сервиса и две внешние системы (Isilon, ECS). Наверняка список поддерживаемых сервисом и систем будет существенно расширен. С точки зрения клиента перемещение данных осуществляется прозрачно, а безопасность обеспечивается благодаря шифрованию с помощью AES-256. Иными словами, с помощью CloudPools можно реализовать масштабируемую мультипротокольную систему с малым временем отклика, пределы роста которой практически не ограничены.

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