Распределенные файловые системы. Технологический обзор. Продуктовый обзор

Файловая система (file system) — это способ организации, хранения и именования данных на носителях информации в компьютерах. Файловые системы используются также в другом электронном оборудовании: в цифровых фотоаппаратах и диктофонах, в мобильных телефонах, и т. п.

Распределенные файловые системы (distributed file system) работают сразу на многих компьютерах (серверах) с репликацией для защиты от сбоев. Иногда «распределенными» также называют сетевые файловые системы, тем самым показывая, что распределенные файловые системы имеют больше возможностей, чем обычная передача данных по сети. Носители СХД, связанные с распределенными файловыми системами, могут (и даже должны) быть распределены между многими компьютерными системами.

Определения

Существует также понятие «кластерная файловая система». Различия между всеми этими терминами (сетевая, распределенная, кластерная) немного расплывчаты. Поэтому сначала нужно определить, что такое сетевая, кластерная и распределенная система.

• Сетевая система (Network) содержит один сервер или его аналог в любом виде, в т. ч. виртуальном, с обслуживающимися им компьютерами в локальной сети.
• Кластерная система (Cluster) содержит несколько серверов в общей сети.
• Распределенная система (Distributed) содержит несколько серверов, объединенных по глобальной сети WAN (Wide area Network).

С таким определением, например, NFSv3 можно отнести к сетевой файловой системе (network file system). GFS2 – это кластерная файловая система. GlusterFS – это распределенная файловая система. NFSv4, в свою очередь, это некий гибрид между сетевой файловой системой, но с поддержкой нескольких серверов, внедренных в нее.

Сумятицу иногда вносит то, что иногда вкладывается разный смысл в понятие «распределенный» (distributed). Здесь надо понимать, что «распределенность» должна присутствовать не только между серверами (тогда это кластер) в локальной сети, но также и между местоположениями этих серверов в глобальной сети (WAN), со всеми присущими ей особенностями. А именно: большими задержками и низкой надежностью соединений.

• Распределенные файловые системы

Распределенные (в таком определении) файловые системы состоят из нескольких географически разнесенных серверов, соединенных по модели sharing nothing, где каждый активный сервер имеет собственную СХД. Кроме того, распределенные файловые системы делятся на два типа: параллельные системы (Parallel file systems) и полностью параллельные файловые системы (Fully parallel file systems).

• Параллельные файловые системы

Так называются системы, которые предоставляют параллельный доступ к их серверам хранения для каждого клиента. Это позволяет устранить «узкие места» одного сервера по всем параметрам: IOPS, полоса, ограничения вычислительной способности процессора и кэш-памяти. Такие системы используются в высокопроизводительных компьютерных системах и бизнес-приложениях, например, в информационных системах фондовых бирж, Примеры: pNFS, Lustre.

Сравнение между сетевой и распределенной файловой системой на примере Lustre (источник: https://www.atipa.com/lustre-parallel-storage)

• Полностью параллельные файловые системы

Полностью параллельными такие системы называются в том случае, когда не только данные, но и метаданные (различные индексы и пр.), также распределяются параллельно между всеми клиентами. Примеры таких систем – OrangeFS и Ceph.

Соотношения между сетевыми системами (Network), кластерными системами (Cluster), распределенными (Distributed), а также параллельными (Parallel) и полностью параллельными системами (Fully parallel) могут быть представлены следующим образом.

Соотношения между видами и типами распределенных (distributed file system) файловых систем (источник: lvee.org/en/abstracts/33)

С какой целью создавались распределенные файловые системы и какие задачи они решают

Во-первых, как уже указывалось, они нужны для защиты от сбоев и облегчения масштабирования СХД. Большое значение имеет API (Application Programming Interface), который они обеспечивают. Это значит, что каждое приложение, скрипт или библиотека стандартных подпрограмм, написанные в течение последних нескольких десятков лет, могут использовать распределенную файловую систему без коррекций их кода, без процедур импорта и экспорта данных. Даже такие решения, как SQL, не могут сравниться с универсальностью и простотой API распределенных файловых систем.

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

При производстве анимационных фильмов модели сцен и рендерные части в процессе производства почти всегда централизованно хранятся в распределенной файловой системе.

Виртуальные «блочные устройства» в облаке на самом деле часто являются файлами в распределенной файловой системе.

Системы распределенных вычислений в крупных научных лабораториях, таких как ЦЕРН, часто состоящие из более чем 100 тысяч процессоров, используют распределенные файловые системы для хранения данных экспериментов и результатов их обработки.

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

Как пример можно было бы привести неудачу широко рекламировавшейся в свое время услуги «интернет-телевидения» (IPTV). Для того, чтобы ей воспользоваться, нужно было провести ряд сетевых настроек, которые любому IT-шнику могут показаться элементарными (например, «маска подсети» и пр.), но для простого обывателя они являлись отпугивающим фактором, несмотря на возможность смотреть «100 фильмов за 100 рублей в месяц». В результате эта услуга, что называется, «не пошла». Распределенные файловые системы с удобным интерфейсом как раз и помогают решить эти проблемы. Пример – любой популярный видеохостинг, либо пакет онлайн-телевидения от интернет-провайдера (например, «ОнЛайм» от Ростелекома).

Для различных предприятий и организаций распределенные файловые системы помогут решить проблемы управления данными и снизить стоимость хранения данных.

Распределенные файловые системы – кто они?

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

• NFS
• ZFS
• GFS
• IBM Spectrum Scale (бывш. GPFS)
• VMFS
• OpenAFS
• GlusterFS
• IBM JFS
• HDFS
• Coda
• HekaFS
• Apple Xsan
• Ceph
• LeoFS
• Lustre
• MooseFS
• TahoeLAFS
• XtreemFS

Продуктовый обзор

ZFS, IBM GPFS (Spectrum Scale), Ceph, Lustre

ZFS

Файловая система ZFS была разработана в 2001 году в компании Sun Microsystems, приобретенной компанией Oracle в 2010 году. Аббревиатура ZFS означала «Zettabyte File System» (файловая система для объемов зеттабайт). Однако в настоящее время ZFS может хранить данные много большего объема.

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

ZFS от Oracle и открытая система OpenZFS пошли разными путями, с тех пор, как Oracle закрыл проект OpenSolaris. OpenZFS — это общий проект, объединяющий разработчиков и компаний, которые используют файловую систему ZFS и работают над ее совершенствованием, чтобы сделать ZFS более широко используемым продуктом с открытым исходным кодом.

Некоторые теоретические пределы параметров, заложенные при проектировании ZFS:

• 248 — количество снимков (snapshot) в любой файловой системе (2 × 1014);
• 248 — количество файлов в любой индивидуальной файловой системе (2 × 1014);
• 256 зеттабайт (1021 байт) — максимальный размер файловой системы;
• 16 эксабайт (264 байт) — максимальный размер одного файла;
• 16 эксабайт (264 байт) — максимальный размер любого атрибута;
• 3 × 1023 петабайт — максимальный размер любого пула хранения (zpool);
• 256 — количество атрибутов файла (фактически ограничивается 248 на количество файлов в файловой системе ZFS);
• 256 — количество файлов в каталоге (ограничено количеством файлов в файловой системе ZFS: 248);
• 264 — количество устройств в любом пуле;
• 264 — количество пулов в системе;
• 264 — число файловых систем в одном пуле;
• 255 байт — максимальная длина имени файла (не полного имени, а относительно родительской папки);
• 255 байт — максимальная длина полного имени хранилища данных (файловой системы, тома, снимка, общего ресурса и т. д.).

Функции ZFS

ZFS обладает рядом полезных функций:

• Разделение СХД на пулы (Pooled storage);
• Копирование при записи (Copy-on-write);
• Снапшоты (Snapshots) системы;
• Верификация целостности данных и автоматическое исправление данных;
• Собственная технология резевирования RAID-Z;
• Автоматическая замена на запасной диск (Hot spare);
• Максимальный размер файла 16 эксабайт;
• Объем хранения 256 квадриллионов зеттабайт.

Хранение в пулах (Pooled storage)

В отличие от большинства файловых систем, ZFS объединяет функции файловой системы и менеджера томов (volume manager). Это означает, что ZFS может создавать файловую систему, которая будет простираться по многим группам накопителей ZVOL или пулам. Более того, можно добавлять емкость в пул простым добавлением нового накопителя. ZFS сама выполнит партицию и форматирование нового накопителя.

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

В пулах можно легко создавать файловые системы (области хранения данных) для каждого приложения и предмета использования.

Копирование при записи (Copy-on-write)

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

Снапшоты (Snapshots)

Copy-on-write закладывает основу для другой функции ZFS: моментальных снимков системы (снапшотов). ZFS использует для отслеживания изменений в системе.

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

Если файл удаляется, то ссылка на него в снапшоте тоже удаляется. Поэтому снапшоты в основном предназначены для отслеживания изменений в файлах, а не для добавления или создания файлов.

Снапшоты могут устанавливаться в режим read-only (только чтение), чтобы восстановить прежнюю версию файла. Также можно сделать откат «живой» системы на предыдущий снапшот. При этом будут потеряны только те изменения, которые были сделаны после момента этого снапшота.

Верификация целостности данных и автоматическое восстановление данных

При любой записи данных в ZFS создается контрольная сумма (checksum). При считывании данных, происходит сверка с этой контрольной суммой. Если проверка показывает расхождение с контрольной суммой, то ZFS устраняет ошибку считывания.

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

Верификация целостности и автоматическое восстановление данных в ZFS

RAID-Z

ZFS может создавать RAID-массивы без необходимости использования дополнительного программного или аппаратного обеспечения. Поэтому неудивительно, что ZFS имеет собственный вариант RAID: RAID-Z.

RAID-Z представляет собой вариант RAID-5, котором предусмотрены средства преодоления ошибки write hole error, присущей RAID-5, когда данные и информация о паритете становятся не соответствующими друг другу после случайного перезапуска системы.

RAID-Z имеет три уровня: RAID-Z1, в котором нужно по крайней мере два диска для хранения и один для паритета; RAID-Z2, который требует по крайней мере двух дисков для хранения и двух для паритета; RAID-Z3 требует по крайней мере двух дисков для хранения и трех для паритета.

Добавление дисков в пул RAID-Z делается попарно.

Автоматическая замена на запасной диск (Hot spare)

В пуле хранения, сконфигурированном с запасным диском, отказавший диск автоматически заменяется запасным.

Автоматическая замена дисков при отказе

Один и тот же диск может быть запасным для нескольких пулов сразу.

При создании ZFS преследовалась цель сделать их «последним словом» в файловых системах. Во времена, когда большинство файловых систем были 64-битными, создатели ZFS решили, что лучше сразу заложить адресное пространство на 128 бит для будущего развития. Это означает, что ZFS имеет емкость в 16 миллиардов раз большую емкость, чем 32- или 64-битные системы. Создатель ZFS Джефф Бонвик (Jeff Bonwick), характеризуя величину этой емкости, сказал, что система в полной конфигурации с такой емкостью потребует для электропитания энергию, достаточную, чтобы вскипятить все океаны в мире.

IBM Spectrum Scale

Объем создаваемых, хранимых и анализируемых данных в мире возрастает экспоненциально. Часто требуется анализировать информацию быстрее конкурентов, причем в условиях роста собственной IT-инфраструктуры.

Файловая система в СХД организации должна поддерживать как большие данные (Big Data), так и традиционные приложения. IBM Spectrum Scale™ решает широкий спектр задач, и представляет собой высокопроизводительное решение для управления данными со встроенными функциями архивирования и аналитики.

IBM Spectrum Scale – это универсальная программно-конфигурируемая система хранения корпоративного класса, которая работает со многими типами носителей и автоматически переводит данные с уровня на уровень в зависимости от частоты их использования, обеспечивая отказоустойчивость, масштабируемость и управляемость.

Это решение, созданное на основе файловой системы IBM General Parallel File System (GPFS), способно масштабировать емкость и производительность для аналитических систем, репозиториев контента и других задач.

Когнитивные механизмы IBM умеют распределять данные среди различных устройств хранения, тем самым оптимизируя использование доступной емкости, упрощая администрирование и обеспечивая высокую производительность. IBM Spectrum Scale поддерживает глобального пространства имен с универсальным доступом, которое объединяет современные средства для работы с файлами, размещенных в сетевых файловых системах (NFS), блочные хранилища и серверы со встроенными хранилищами данных большого объема. Файловая система IBM Spectrum Scale может использоваться для работы с файлами (POSIX, NFS, CIFS), объектами (S3, SWIFT) и распределенной файловой системой Hadoop (HDFS) при решении задач анализа больших данных на месте хранения.

Задачи и возможности IBM Spectrum Scale.

Свойства IBM Spectrum Scale

Хорошая масштабируемость, которая позволяет обеспечивать максимальную пропускную способность и минимальные задержки при доступе.

Аналитика с учетом данных, позволяющая автоматически переносить данные на оптимальный уровень хранения (флеш, диск, кластер, лента), что позволяет до 90 % снизить расходы на архивирование данных.

Автоматическое размещение данных по уровням в файловой системе IBM Spectrum Scale

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

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

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

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

Интеллектуальное кэширование данных, технология Active File Management (AFM) распространяет глобальное пространство имен Spectrum Scale за пределы географических границ, обеспечивая высокую производительность при чтении и записи данных и автоматическое управление пространством имен. Данные записываются или изменяются локально и в других местах эти данные получают с минимальной задержкой.

Графический интерфейс IBM Spectrum Scale GUI обеспечивает простое администрирование объемов данных уровня петабайт различных типов: файловых, объектных или блочных.

IBM Spectrum Scale – это хорошо зарекомендовавшее себя масштабируемое решение по администрированию данных, которое ранее называлось GPFS (General Parallel File System). Начиная с версии 4.1, это решение называется Spectrum Scale. Однако версии до 4.1 будут поддерживаться под старым названием GPFS.

Основные характеристики

• Практически неограниченный объем хранения данных до нескольких йоттабайт и до девяти квинтиллионов файлов.
• Высокая производительность более 400 ГБ/с, и одновременный доступ к общим наборам данных из нескольких доменов пользователей.
• Программно-конфигурируемая СХД, которая позволяет:
  • масштабирование на относительно недорогом коммерчески доступном оборудовании COTS (Commercial Of The Shelf), при обеспечении возможностей управления хранением данных с их высокой доступностью;
  • использование любых комбинаций носителей: флеш-накопителей, дисков и лент;
  • использование различных моделей кластеров, которые включает SAN (storage area networks), Network Shared Disk и кластеры Shared Nothing;
  • добавление емкости без влияния на работу запущенных приложений.
• Интегрированное средство управления жизненным циклом информации ILM (information lifecycle management) автоматически перемещает данные в соответствии с установленными политиками хранения. Это помогает значительно снизить операционные затраты.
• Глобальный доступ к данным независимо от географического местоположения и наличия ненадежных соединений через глобальную сеть WAN (Wide Area Network).
• Доказанная надежность использования для наиболее распространенных коммерческих приложений.
• Защита данных от большинства уязвимостей систем безопасности, неавторизованного доступа или потери, кражи или неправильной утилизации, за счет встроенного шифрования и безопасного стирания.

Применения

Spectrum Scale используется уже более 15 лет во многих отраслях экономики во всем мире, и в таких областях, требовательных к объему и производительности обработки данных, как:

• Инженерный дизайн;
• Медиа и СМИ (радио и ТВ, контент-провайдеры);
• Нефтегаз: обработка и аналитика данных сейсморазведки;
• Умные города: видеонаблюдение и видеоаналитика;
• Автомобили: краштесты, системы помощи водителю и беспилотные автомобили;
• Оборона и авиация (запись полетных данных);
• Архивация спутниковых изображений;
• Телеком: хранение данных вызовов CDR (Call detail records);
• Банкинг и финансовый сектор: отчетность, обработка чековых данных;
• Бизнес-аналитика (Business intelligence);
• Поиск и сопоставление нужной информации в массивах данных (Data mining);
• Научные исследования;
• Когнитивные приложения интернета вещей, такие как IBM Watson™.

Функциональные возможности

• Увеличение эффективности использования ресурсов за счет объединения в пулы изолированных ранее ресурсов.
• Интеллектуальное использование ресурсов и автоматизация администрирования СХД снижает стоимость хранения и повышает операционную эффективность, возможности автоматизации политик уровневого хранения.
• Разнообразные возможности конфигурации для оптимизации производительности, гибкости и надежности, устранения отказов типа single point-of-failure, а также автоматизации операций для быстрой замены отказавшего диска или устранения сбоя сервера.
• Катастрофоустойчивость за счет возможности работы на множестве распределенных сайтов, подключенных к локальному кластеру Spectrum Scale (Disaster Recovery).
• Кросс-платформенное решение, которое может работать на многих операционных системах. Кластеры Spectrum Scale можно создавать на узлах AIX, Linux и Windows server, причем в одной системе могут работать все три ОС (а также на IBM System Z®).
• Оперативность реакции на события и появление новых требований, быстрое развертывание необходимых ресурсов.

Основные компоненты системы

• Кластер (Cluster). Кластер состоит из нескольких узлов, а также общих сетевых дисков NSD (network shared disks). Он может быть сконфигурирован в серверном репозитории (конфигурационной базе данных), где хранятся файлы конфигурации кластера. При конфигурации кластеру должен быть назначен первичный и вторичный сервер. Начиная с версии 4.1, используется новый тип репозитория, который называется «конфигурационный репозиторий кластера» CCR (Cluster Configuration Repository). Здесь автоматически поддерживаются конфигурационные файлы для всех узлов.
• Узел (Node). Узел – это любой сервер, на котором установлено ПО Spectrum Scale, с прямым или сетевым доступом к другому узлу. В зависимости от типа доступа, каждый узел может иметь различную роль внутри кластера.
• Менеджер кластера (Cluster manager). Узел менеджера кластера отвечает за правильность операций на всех узлах и всего узла в целом. Он выполняет следующие задачи:
  • Мониторинг выделения дисков
  • Обнаружение ошибок и восстановление при отказе узла внутри кластера
  • Определение кворума узлов и разрешение на старт домену Spectrum Scale и продолжение использования файловой системы
  • Обработка информации о конфигурации и информирование узлов в удаленных кластерах об изменениях конфигурации
  • Выбор узла для менеджера файловой системы.
• Менеджер файловой системы (File system manager). Этот менеджер поддерживает информацию о доступности дисков в файловой системе. В большом кластере для менеджера файловой системы может понадобиться отдельный узел. Менеджер файловой системы выполняет следующие функции:
  • Управляет конфигурацией файловой системы;
  • Управляет выделением дискового пространства;
  • Управляет конфигурациями квот;
  • Поддерживает сервисы безопасности.
• Общий сетевой диск (NSD, Network shared disk). Используется для глобального пространства имен и доступа к данным кластера. Если все узлы не имеют прямого подключения к дискам (например, в среде SAN), то NSD должен быть определен как первичный сервер, причем рекомендуется, чтобы вторичный сервер тоже был определен. Затем ввод-вывод производится через сетевое подключение сервера NSD, который выполняет ввод-вывод от имени запрашивающего узла. Даже если все NSD подключены к дискам, рекомендуется определять серверы NSD, чтобы в случае потери доступа первичного сервера к физическим дискам существовал запасной маршрут.
• Пул накопителей (Storage pool). Это комплект NSD, использующихся для партиции пространства хранения, по принципу общих параметров, таких как производительность, доступность в местной сети и надежность. Использование пулов накопителей в Spectrum Scale позволяет группировать устройства хранения по параметрам производительности, локальности или надежности внутри файловой системы.
• Блок (Block). Блок – это наибольший элемент для операций ввода-вывода и выделения дискового пространства в файловой системе Spectrum Scale. Размер блока указывается при создании файловой системы и определяет полосу пропускания при распределении данных по дискам. Spectrum Scale поддерживает размер блока от 16 Кбайт до 16 Мбайт. По умолчанию размер блока составляет 256 Кбайт в предыдущей версии GPFS и 64 Кбайт при использовании Spectrum Scale в версии 4.1.0.4. Spectrum Scale допускает различные размеры блоков для метаданных и самих данных, если диски для данных и метаданных разделены.
• Чанк (Chunk). Термин «чанк» относится к функции оптимизации размещения файла File Placement Optimizer (FPO) файловой системы Spectrum Scale. Чанк – это логическая группа блоков, которая ведет себя как один большой блок. Множитель блоков в группе (block group factor) используется FPпри определении числа блоков, образующих чанки на дисках, присоединенных к узлу. Затем чанк предписывается всем доступным дискам внутри узла. Размер чанка определяется умножением размера блока на множитель блоков группы. Этот множитель может лежать в пределах от 1 до 1024. Значение множителя по умолчанию равно 1, с целью совместимости со стандартными файловыми системами Spectrum Scale. Установка размера блока в 1 МБ и множителя блоков группы в 128 дает в результате размер чанка 128 МБ.
• Группа отказа (Failure group). Группа отказа – это набор дисков, образующих общую точку отказа (common point of failure). То есть любой отказ в такой группе дисков может вызвать одновременную недоступность их всех. При создании многочисленных реплик определенного блока Spectrum Scale использует информацию о группах отказов, чтобы обеспечить то, что никакие две парные реплики блоков данных не будут размещаться в одной и той же группе отказа. Группа отказа может быть определена как набор до трех чисел, разделенных запятыми, которая дает возможность определить топологию группы.
• Мета-узел (Metanode). Узел, обрабатывающий метаданные, которые также называются «модификациями блока директории» (directory block updates).
• Метаданные (Metadata). Содержит информацию о конфигурации определенного кластера и данные, не относящиеся к пользователю (non-user data).
• Узел приложений (Application node). Монтирует файловую систему Spectrum Scale и запускает пользовательские приложения, получающие доступ к файловой системе.
• Кворумный узел (Quorum nodes). Это узлы, поддерживающие активность кластера Spectrum Scale. Есть два типа узлов кворума кластера:
  • Node quorum, где кластер поддерживается рабочим, когда доступны большинство узлов кворума.
  • Node quorum with tiebreaker disks, где кластеры активны при хотя бы одном кворумном узле и он имеет доступ к дискам, которые определены как tiebreaker disks.

Три NSD, определенные как диски tiebreaker disk для кворумных узлов (источник: IBM)

• Топология кластера. Топологию IBM Spectrum Scale можно гибко конфигурировать под различные решения для пользователя. Четыре основных типовых конфигурации Spectrum Scale, используемых в зависимости от местоположения приложений на узлах кластера:
  • Приложения, работающие только на NSD клиентов Spectrum Scale
  • Приложения, работающие на узлах с СХД с прямым подключением
  • Приложения, работающие на серверах с подключенными NSD
  • Приложения, работающие на кластере FP(File Placement Optimizer)

Три редакции Spectrum Scale

Есть три разных редакции (Edition) Spectrum Scale:

• Express Edition: базовая функциональность Spectrum Scale.
• Standard Edition: технический эквивалент GPFS 3.5, включает базовые функции, а также Information Lifecycle Management, Active File Management и Clustered NFS.
• Advanced Edition: к функциям Standard Edition добавлена функция шифрования.

Совместимость

Spectrum Scale (Express и Standard) для ОС Windows systems поддерживается на следующих версиях:

• Windows Server 2008 x64 (SP2);
• Windows Server 2008 R2;
• Windows Server 2012 (Datacenter and Standard);
• Windows Server 2012 R2 (Datacenter and Standard);
• Windows 7 (версии Enterprise и Ultimate editions) x64, SP1;
• Windows 8.1 (версия Enterprise) как кластерах с гетерогенными узлами (на Windows и не на Windows), так и гомогенными узлами (только на Windows).

Важно: Редакция Spectrum Scale Advanced Edition не поддерживается на

Windows или с функцией Active File Management.

Spectrum Scale для ОС Linux на серверах IBM Power поддерживается для следующих дистрибуций Linux:

• Red Hat Enterprise Linux (RHEL) 6.2 или более поздних;
• SUSE Linux Enterprise Server (SLES) 11 SP2 или более поздних;
• Ubuntu 14.04.1 или более поздних.

Spectrum Scale для ОС Linux на серверах x86 поддерживается для следующих дистрибуций Linux:

• Red Hat Enterprise Linux (RHEL) 6.2 или более поздних;
• SUSE Linux Enterprise Server (SLES) 11 SP2 или более поздних;
• Debian Linux версии 6 или 7;
• Ubuntu 14.04.1 или более поздних.

ОС Linux поддерживается на следующих редакциях Spectrum Scale:

• Express Edition;
• Standard Edition;
• Advanced Edition.

Ceph

Ceph – распределенная масштабируемая система хранения с дизайном без единой точки отказа (single point of failure). Система разрабатывалась как открытый проект с файловой системой высокой масштабируемости до уровня эксабайт (по некоторым данным, даже выше) и рассчитанная на работу на стандартном коммерчески доступном серверном оборудовании COTS (Commercial Off The Shelf). Ceph приобретает все бóльшую популярность в облачных системах хранения данных.

В Ceph не используется корпоративная модель лицензирования и в ней нет ни одного набора функций «только для предприятий». С различными релизами Ceph можно ознакомиться здесь: https://ceph.com/category/releases/. Ceph входит в ядро открытой ОС Linux.

Архитектура Ceph

Основные принципы построения Ceph:

• Масштабируемость всех компонентов
• Отсутствие единой точки отказа
• Использование открытого ПО (Linux)
• Использование стандартного оборудования COTS (Commercial Off The Shelf)
• Автономность в управлении компонентами.

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

Архитектура кластера СХД Ceph

Термины Ceph

• FUSE (File System in User Space) – файловая система в области пользователя.
• RADOS (Reliable Autonomic Distributed Object Store) — распределенная объектная СХД файловой системы Ceph, состоящая из автономных узлов хранения.
• RADOS Pool — несколько OSD, объединенных общим набором правил, например, политикой репликации. Представляет собой плоское (без подкаталогов) пространство имен для объектов.
• OSD (Object Storage Daemon) — процесс, обслуживающий каждый диск в RADOS-кластере.
• PG (Placement Group) — логическая группа, которая объединяет несколько объектов.
• CRUSH — алгоритм выбора места размещения объектов на OSD в RADOS-кластере.
• MON – ПО для мониторинга Ceph.
• MGR – ПО для администрирования Ceph, которое собирает информацию о состоянии со всего кластера в одном месте.
• MDS – ПО для метаданных Ceph (metadata software).
• LIBRADOS – библиотека, позволяющая приложениям обращаться непосредственно к RADOS с использованием языков C, C++, Java, Ruby, PHP.
• RADOGW (RADOS Gateway) — шлюз с API-интерфейсом REST между пользовательским приложением.
• RBD (RADOS Block Device), надежное и полностью распределенное блочное устройство с клиентом на ядре Linux и драйвером KVM (Kernel-based Virtual Machine).
• Ceph FS – (Ceph File System) файловая система, совместимая с переносимым интерфейсом операционных систем POSIX (Portable Operating System Interface), который представляет собой набор стандартов, описывающих интерфейсы между операционной системой и прикладной программой, с клиентом ядра Linux и поддержкой FUSE.

Архитектура файловой системы Ceph (источник: docs.ceph.com)

Применения Ceph

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

Интерфейс Ceph FS (источник: suse.tech)

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

Ceph – это решение на базе открытого ПО (open source) как альтернатива коммерческим и частным решениям облачных систем и услуг хранения данных, которая хорошо подходит для образовательных и научных организаций.

Например, ряд университетов Австралии построили совместную распределенную программно-конфигурируемую СХД на основе файловой системы Ceph.

Применение Ceph FS для единой сети университетов Австралии (источник: https://indico.cern.ch/)

Самый крупный заказчик Ceph – это Центр ядерных исследований CERN в Швейцарии, который использует объектную программно-конфигурируемую СХД на базе распределенной файловой системы Ceph для хранения и обработки огромных массивов данных (уровня петабайт) научных экспериментов, проводимых на адронном коллайдере.

Однако, как показывает опыт, Ceph может хорошо устанавливаться и запускаться даже на кластере из трех компьютеров с пулом хранения в несколько Терабайт.

Результаты тестирования показывают, что CephFS работает так же или превосходит распределенную файловую систему Hadoop (HDFS) для анализа больших данных. Это дает возможность разворачивать кластеры Hadoop с различными приложениями на базе одной файловой системы без деградации характеристик или производительности. Более того, динамическая масштабируемость ресурсов вычислений и хранения может быть применена и для специфических приложений Hadoop.

Lustre

Lustre – это кластерная архитектура для СХД, центральным элементом которой является файловая система Lustre, работающая на ОС Linux и обеспечивающая POSIX-интерфейс для файловой системы UNIX.

Распределенная архитектура СХД Lustre используется для различных видов кластеров: например, для кластеров высокопроизводительных вычислений HPC (high-performance computing) в мировом масштабе, в состав которых может входить до нескольких десятков подчиненных кластеров. Каждый из них в состоянии содержать десятки тысяч клиентских систем с объемами данных уровня петабайт и с пропускной способностью уровня ГБ/с.

Применения Lustre

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

Lustre лучше всего подходит для сценариев, когда требуется больше емкости, чем есть в одном сервере. Хотя, есть много применений, когда Lustre работает лучше других систем на одном сервере.

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

Характеристики Lustre

Lustre может быть развернута на самых разнообразных конфигурациях, которые могут хорошо масштабироваться.

Таблица 1. Параметры файловой системы Lustre

Компоненты Lustre

Базовая конфигурация компонентов Lustre показана на рисунке.

Базовая конфигурация компонентов Lustre

• Сервер метаданных MDS (Metadata Server). Благодаря MDS метаданные, хранимые в одном или больше MDT, доступны для клиентов Lustre. Каждый MDS управляет именами и директориями в файловой системе (системах) Lustre и обеспечивает запросы сети на обработку одного или более местных MDT.
• Целевой узел метаданных MDT (Metadata Targets). Каждая файловая система имеет по крайней мере один MDT. Он хранит метаданные (имена файлов, директории, разрешения и форматы файлов) в СХД, которая присоединена к MDS. MDT на одном целевом узле хранения может быть доступен для многих серверов MDS, хотя только один MDS может иметь доступ к этому MDT в какой-то момент времени. Если этот MDS отказывает, то резервный MDS берет на себя обслуживание MDT и делает его доступным для клиентов. Такая операция называется MDS failover.

В распределенной среде пространства имен DNE (Distributed Namespace Environment) поддерживаются множество MDT. Кроме того, первичный MDT, который содержит корневой каталог файловой системы (filesystem root), может добавлять дополнительные узлы MDS, каждый со своими MDT, и таким образом поддерживать деревья субдиректорий в файловой системе.

Начиная с версии Lustre 2.8 DNE также позволяет файловой системе распределять файлы по многим узлам MDT. Директория, которая распределена на множество MDT, называется striped directory («располосованная директория»).

• Сервер объектного хранения OSS (Object Storage Servers). OSS управляет операциями ввода-вывода данных и сетевых запросов для одного или больше OST. Обычно, сервер OSS обслуживает от двух до восьми OST, объемом до 16 TiB каждый. Типичная конфигурация – MDT на отдельном узле, два или больше OST на каждом узле OSS и клиент на каждом из множества серверных узлов.
• Целевой узел объектного хранения OST (Object Storage Target) пользовательские файлы сохраняются в одном или более объектах. Каждый объект сохраняется на отдельном узле OST файловой системы Lustre. Пользователь может конфигурировать число объектов на файл и может оптимизировать производительность под рабочую нагрузку.
• Клиенты Lustre. Клиенты Lustre – это узлы серверов, систем визуализации или рабочих станций, на которых работает клиентское ПО Lustre.

Масштабирование емкости и производительности Lustre может делаться добавлением OSS и OST (источник: http://wiki.lustre.org)

Клиентское ПО Lustre обеспечивает интерфейс между виртуальной файловой системой Linux и серверами Lustre. Оно включает клиент управления MGC (management client) и множество клиентов объектного хранения OSC (object storage clients), каждый из которых соответствует каждому OST в файловой системе.

Логический том объекта LOV (logical object volume) агрегирует клиентов OSC, чтобы обеспечить прозрачный доступ через все узлы объектного хранения OST. Таким образом, каждый клиент с установленной файловой системой Lustre может видеть единое, когерентное и синхронизированное пространство имен. Множество клиентов могут записывать и просматривать разную информацию в одном и том же файле одновременно.

Логический том метаданных LMV (logical metadata volume) агрегирует целевые узлы метаданных MDТ, чтобы доступ ко всем MDT делался точно также, как LOV поступает для доступа к файлу. Это позволяет клиенту видеть дерево директорий на многих MDT единое, когерентное пространство имен и «располосованные» директории (striped directories) доступны пользователям и приложениям как единая видимая директория.

С точки зрения пользователя

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

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

К сожалению, многие распределенные файловые системы построены на фиксированных ссылках (hardwired references) на точки монтирования отдельных файловых систем пользователей и приложений. Менять эти ссылки достаточно сложно.

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

Если нужно, единая точка монтирования для Lustre может быть задана административно, путем монтирования файловой системы Lustre в одинаковой директории на каждой клиентской системе, но это не является обязательным требованием.