- PVSM.RU - https://www.pvsm.ru -
Вот уже несколько лет доступна такая возможность, как создание многоуровневого хранилища на базе EMC Isilon. Это подразумевает возможность отправлять данные в конкретные пулы хранения — системы узлов, объединённых по признаку однотипности или плотности размещения. В результате сильно вырастет эффективность хранения данных с точки зрения стоимости.
Можно создать политику, согласно которой все новые данные будут сохраняться в Пуле-1, построенном из быстрых узлов S210.
Время отклика будет очень небольшим, но стоимость окажется выше (более быстрые накопители, процессоры и т.д.). Далее можно создать политику второго уровня, например, «перемещать все данные, к которым не обращались более 30 дней, в Пул-2». Этот комплекс может быть построен из узлов Х410, обладающих большей ёмкостью (36 SATA-дисков) и более высоким временем отклика по сравнению с Пулом-1. Ещё менее востребованные данные можно перемещать уже в Пул-3, построенный из узлов HD400 с очень высокой плотностью хранения — 59 SATA-дисков + по 1 SSD на каждый 4U-модуль, но его время отклика ещё больше, чем у Tier 2. Но поскольку этот уровень предназначен лишь для очень редко востребованных данных, это не сильно повлияет на пользователей.
Перемещение данных на основании политик выполняется в фоновом режиме с помощью движка OneFS. При этом не меняется логическое размещение файлов. То есть можно создать одну папку, файлы в которой находятся в трёх разных хранилищах.
Одни и те же данные могут проходить разные стадии жизненного цикла: сырые данные, необработанные, обработанные, дубликаты, резервная копия, архив. Для каждой стадии характерен свой набор требований по доступности и сохранности данных. В отличие от многих других СХД, в которых разные типы информации хранятся совместно, в Isilon применяются разные уровни хранения (Tier). Для каждого уровня используются определённые политики по разделению, обработке и хранению данных. Такой подход позволяет удешевить хранение информации, находящейся в разных стадиях жизненного цикла, быстрее обрабатывать и эффективнее управлять ею. Эти задачи решаются с помощью уровней хранения, которые, в свою очередь, могут делиться на более узкоспециализированные пулы.
Единая файловая система для всех пулов/уровней хранения.
На сегодняшний день существует несколько видов пулов:
Также появился пятый вид — облако (внешнее или внутреннее).
Как уже упоминалось, каждый пул формируется из узлов одинакового типа (на самом деле, они могут слегка различаться, но это уже выходит за рамки поста). Если у вас развёрнут очень большой кластер, то вполне целесообразно разделить его на разные уровни хранения. Каждый уровень содержит один или несколько пулов. Но в ряде случаев нужды в таком делении нет. Вполне может возникнуть ситуация, когда ваши политики не будут подразумевать наличие пулов или уровней хранения.
Политики распределения данных по уровням хранения можно легко настроить с помощью WebUI, CLI или API. При этом в качестве критериев при создании политики можно использовать не только частоту обращения к файлам, но и типы файлов, их размещение, владельца или любой другой атрибут. В пользовательском интерфейсе уже есть заранее настроенные шаблоны, которыми можно воспользоваться. К примеру, шаблон Archive содержит правила, согласно которым более старые данные перемещаются в соответствующее хранилище. А шаблон ExtraProtect помогает настроить более высокий уровень защиты файлов с определёнными значениями атрибутов (например, n+3 вместо n+2). При этом самим WebUI пользоваться очень просто, он интуитивно понятен.
Одним из интересных нововведений, появившихся в OneFS 8.0, стал новый тип пула — облачный (Cloud). Теперь с помощью Object API он поддерживает:
Последние два продукта, благодаря поддержке ряда API Object REST, могут быть использованы для создания частного облачного архива. Вероятно, можно ожидать внедрения поддержки других поставщиков облачных хранилищ, например, Google и Virtustream [2].
С помощью CloudPools можно использовать единую файловую систему для работы с облачным хранилищем.
Предположим, что вы настроили политику, которая задаёт требования к файлам, которые должны быть перемещены в облако. Например, нужно переместить:
Политика будет применять согласно расписанию задач Smartpools. Как и в случае со всеми остальными задачами в OneFS, планирование и контроль исполнения осуществляются движком задач (job engine). Задачам может назначаться приоритетность и время исполнения, а в зависимости от текущей ситуации они могут ставиться на паузу.
Как только запускается Smartpools (например, каждый день в 22:00), он сверяет с текущими политиками все папки и файлы, и перемещает в облако те из них, кто соответствуют прописанным критериям.
В локальной файловой системе хранятся файлы заглушки (stub file), содержащие три типа информации:
Как уже упоминалось, с точки зрения пользователя или приложения нет никакой разницы между «нормальным» файлом и файлом заглушки. Конечно, при желании можно вычислить, но об этом мы поговорим в другой раз.
Когда происходит обращение к файлу заглушки, соответствующий контент извлекается из облака и кэшируется локально, на SSD или HDD. Но эти данные не будут храниться в файловой системе вечно. В противном случае любой пользователь мог бы забить всю локальную файловую систему одними лишь командами просмотра, ведь объём хранилища может в разы превышать объём локальной файловой системы. Поэтому лишь администратор или пользователь с соответствующими привилегиями могут присвоить каким-то данным атрибут постоянного хранения в кэше. Поведение самого кэша можно регулировать с помощью настроек CloudPools. К примеру, можно сказать кластеру, чтобы он:
Срок хранения — это сколько времени архивные данные будут сохраняться в облаке после удаления файла заглушки. Этот параметр можно настраивать отдельно для каждой политики. По умолчанию срок хранения равен одной неделе, после чего соответствующие данные удаляются. Кроме того, можно настроить:
CloudPools — это удобный инструмент, позволяющий создать из горизонтально масштабируемой NAS-системы Isilon прозрачное внешнее многоуровневое хранилище. На данный момент поддерживаются два сторонних облачных сервиса и две внешние системы (Isilon, ECS). Наверняка список поддерживаемых сервисом и систем будет существенно расширен. С точки зрения клиента перемещение данных осуществляется прозрачно, а безопасность обеспечивается благодаря шифрованию с помощью AES-256. Иными словами, с помощью CloudPools можно реализовать масштабируемую мультипротокольную систему с малым временем отклика, пределы роста которой практически не ограничены.
За рамками этой публикации остались ряд важных вопросов. Например, производительность: что будет с файлами заглушки в ходе бэкапа и репликации? Что насчёт аварийного восстановления, доступа к данным в CloudPools со стороны разных сайтов, постепенного создания CloudPools-системы? Об этом мы напишем в одной из следующих публикаций.
Автор: EMC²
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/oblachny-e-vy-chisleniya/154594
Ссылки в тексте:
[1] EMC Elastic Cloud Storage: http://www.emc.com/storage/ecs/index.htm
[2] Virtustream: http://www.virtustream.com/
[3] Источник: https://habrahabr.ru/post/305392/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.