Введение

Компания Panasas (http://www.panasas.com/) была образована в 1999 г., а первые ее продукты были отгружены 2004 г. В настоящее время Panasas позиционирует себя на рынке современных НРС-хранилищ с объектным доступом к данным и поддержкой смешанных HPC/AI/ML/DL/HPDA-нагрузок на базе параллельной файловой системы PanFS.

PanFS развертывается на готовом к использованию серийном оборудовании (COTS, commodity off-the-shelf) Panasas ActiveStor^® Ultra HPC, представляет собой полностью интегрированное решение для хранения данных и, по заявлениям компании, обеспечивает наилучшую производительность в любой ценовой категории.

Среди других основных преимуществ своих решений, которые продвигает Panasas – простота установки и низкая стоимость их обслуживания, а также их высокая надежность по сравнению с другими разработками [1] (рис. 1):

• наем/обучение экспертов по системам хранения данных. Файловые системы Lustre, GPFS и BeeGFS требуют специальных знаний в области хранения данных, поиск и сохранение которых обходится дорого. Параллельная файловая система Panasas PanFS представляет собой простое решение, не требующее глубоких технических навыков для постоянного администрирования;
• время и стоимость установки системы хранения данных. Согласно опросу, в 56% случаев установка заняла несколько недель. Системы Panasas обычно устанавливаются за один день;
• время и затраты на настройку и оптимизацию. Не требуя трудоемкой и трудоемкой настройки/перенастройки для поддержания максимальной производительности, Panasas PanFS балансирует и оптимизирует каждую часть системы хранения данных — ЦП, сетевую карту, DRAM и носители данных — обеспечивая стабильную и предсказуемую производительность. для различных рабочих нагрузок, независимо от сложности, без необходимости ручной настройки или реконфигурации;
• время и стоимость администрирования. 60% сайтов требуют более одного выделенного человека для управления хранилищем. Для управления решением хранения данных Panasas обычно требуется только один администратор, работающий неполный рабочий день, независимо от масштаба;
• время простоя системы – 42% респондентов опроса сообщили о еженедельных или ежемесячных простоях. Установки Panasas продемонстрировали отсутствие незапланированных простоев в течение 8 лет.

Рис. 1. Сравнение Panasas ActiveStor с другими разработками [1].

Помимо хороших показателей стоимости за единицу производительности, на что обращает внимание разработчик, СХД Panasas могут масштабироваться до более 1500 узлов хранения и до более 150 директор-узлов, поддерживая при этом практически линейное увеличение производительности [5]. Среди других особенностей PanFS:

• файловая система Panasas использует параллельный и избыточный доступ к объектным устройствам хранения данных (OSD, object storage devices);
• файловый RAID;
• распределенное управление метаданными;
• согласованное клиентское кэширование;
• поддержка служб блокировки файлов и внутреннее управление кластером для обеспечения масштабируемой, отказоустойчивой и высокопроизводительной распределенной файловой системы;
• кластерный дизайн системы хранения и использование управляемого клиентом RAID обеспечивают масштабируемую производительность для множества одновременных клиентов файловой системы за счет параллельного доступа к файловым данным, которые распределяются по узлам хранения OSD;
• восстановление RAID выполняется параллельно кластерными менеджерами метаданных, а декластеризованное размещение данных обеспечивает масштабируемую скорость восстановления RAID по мере увеличения размера системы хранения.

 

Panasas разработала расширение для управления параллельным доступом к файлам в NFS, которое позже было интегрировано в Parallel NFS (pNFS), часть спецификации NFS версии 4.1, опубликованной Internet Engineering Task Force (IETF, https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) как RFC 5661 в январе 2010 г. pNFS описал способ, с помощью которого протокол NFS обрабатывает запросы файлов к нескольким серверам или устройствам хранения одновременно, вместо последовательной обработки запросов (https://en.wikipedia.org/wiki/Panasas).

Panasas поддерживает протоколы доступа к данным DirectFlow, NFS, Parallel NFS и Server Message Block (также известный как CIFS) для интеграции в существующие локальные сети. Блейд-серверы Panasas управляют метаданными, предоставляя данные клиентам DirectFlow, NFS и CIFS. Системы Panasas обеспечивают хранение и управление данными для высокопроизводительных приложений в области биологических наук, энергетики, средств массовой информации и развлечений, производства, государственного и исследовательского секторов.

Линейка продуктов ActiveStor — это устройство с параллельной файловой системой, которое объединяет гибридное оборудование хранения данных (HDD– и SSD-накопители), параллельную файловую систему PanFS, собственный протокол доступа к данным DirectFlow и стандартные сетевые протоколы NFS и CIFS. DirectFlow — это протокол параллельного доступа к данным, разработанный Panasas для ActiveStor. DirectFlow позволяет избежать узких мест протокольного ввода-вывода за счет прямого и параллельного доступа к хранилищу Panasas. Первоначально DirectFlow поддерживался в Linux, а в апреле 2016 года был расширен для поддержки MacOS от Apple.

Panasas ActiveStor Director (ASD-200) работает на базе PanFS и контролирует многие аспекты общего решения хранения, включая семантику файловой системы, управление пространством имен, распределение и согласованность пользовательских данных на узлах хранения, работоспособность системы, восстановление после сбоев и функциональность шлюза [3]. ASD-200 представляет собой корпус высотой 2U, содержащий до четырех узлов ActiveStor Director. Он обратно и вперед совместим со всей линейкой узлов хранения ActiveStor. ASD-200 в полной мере использует преимущества новейших технологий, таких как два сетевых порта 25GbE для передачи данных с высокой пропускной способностью и технология энергонезависимых двухканальных модулей памяти (NVDIMM) для постоянного хранения данных со сверхнизкой задержкой.

Panasas создала кластерную файловую систему PanFS как единый пул хранения в глобальном пространстве имен файлов для поддержки нескольких приложений и рабочих процессов в одной системе хранения. В PanFS 7.0 добавлена операционная основа FreeBSD и графический интерфейс, который поддерживает асинхронное push-уведомление об изменениях в системе без взаимодействия с пользователем.

В августе 2020 года Panasas анонсировала новую версию PanFS с технологией динамического ускорения данных (Dynamic Data Acceleration, DDA), которая автоматически настраивает хранилище для небольших файлов и смешанных рабочих нагрузок. PanFS с DDA избавляет системного администратора от сложностей и ручного вмешательства при управлении многоуровневыми системами хранения HPC, максимизируя эффективность всех носителей данных в единой системе с полной производительностью, которая автоматически адаптируется к изменяющимся размерам файлов и рабочим нагрузкам. В этой интегрированной системе NVMe SSD хранят метаданные, SSD с малой задержкой хранят небольшие файлы, а большие файлы хранятся на недорогих жестких дисках с высокой пропускной способностью. Динамически управляя перемещением файлов между SSD и HDD и максимально используя весь потенциал NVMe, PanFS обеспечивает максимально возможную производительность для рабочих процессов HPC и AI.

В “классических” СХД данные по уровням, как правило, распределяются на основе частоты обращения к данным и часто требуют ручной настройки для компенсации конкретных характеристик и изменений рабочей нагрузки. Такой подход к объединению различных уровней для достижения производительности приводит к сложности и нестабильности производительности, а также увеличивает общие затраты. PanFS с DDA автоматически адаптируется к изменяющимся размерам файлов и рабочим нагрузкам без настройки или ручного вмешательства, обеспечивая стабильное и быстрое решение для хранения данных HPC с общей производительностью.

В мае 2023 г. Panasas^® объявила [2] о выпуске своей новой платформы ActiveStor^® Ultra Edge, решения для хранения данных HPC и AI/ML, предназначенного для периферийных вычислительных сред. Платформа Panasas ActiveStor Ultra Edge занимает меньше места и имеет более низкую стоимость входа, что делает ее хорошим выбором для организаций, развертывающих приложения HPC и AI/ML в удаленных местах, ближе к местам генерации данных, для улучшения процесса принятия решений в реальном времени.

По данным IDC Worldwide Edge Spending Guide (https://www.idc.com/getdoc.jsp?containerId=prUS50386323), глобальные расходы на периферийные вычисления в 2023 году достигнут $208 млрд, что на 13,1% больше, чем в 2022 году. Организациям, развертывающим периферийные приложения HPC и AI/ML, потребуется более высокая производительность и надежность системы на периферии. ActiveStor Ultra Edge предлагает надежное, компактное и высокопроизводительное решение по конкурентоспособной цене, которое позволяет организациям масштабироваться и идти в ногу с растущими требованиями обработки данных в реальном времени.

ActiveStor Ultra Edge — это дополнение к портфолио Panasas ActiveStor, предназначенное для удовлетворения растущих потребностей в данных в современной экосистеме HPC, которая включает в себя традиционные приложения HPC наряду с обработкой AI/ML, а также технологиями облачных и периферийных вычислений. Механизм данных Panasas PanFS^® обеспечивает бесконечно масштабируемую емкость и производительность хранилища в системе Ultra Edge малого форм-фактора для удовлетворения разнообразных потребностей периферийных вычислений в различных отраслях.

Механизм обработки данных Panasas PanFS вместе с пакетом обеспечения видимости и перемещения данных PanView™ и PanMove™ решает проблемы расположения данных, обеспечивая при этом лучшую в отрасли простоту и улучшенную защиту от сбоев дисков, узлов и площадок. От стирающего кодирования до запатентованной защиты RAID на уровне файлов — Panasas обеспечивает надежность и простоту использования корпоративного уровня для высокопроизводительного параллельного хранилища на периферии, что позволяет организациям быстрее принимать обоснованные решения для повышения операционной эффективности.

Масштабируемая производительность PanFS, адаптированная к современным нагрузкам

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

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

Система хранения Panasas представляет собой специализированный кластер хранения, который рассчитан на поддержку нескольких тысяч клиентов и емкость хранилища, превышающую петабайт. Уникальными аспектами системы Panasas являются использование пофайлового управляемого клиентом RAID и его параллельная перестройка, обработка различных классов метаданных (блочных, файловых, системных) и блейд-оборудование на основе commodity-оборудования со встроенным ИБП.

В файловой системе PanFS работают три компонента: узлы-директора (ранее – manager node), узлы хранения и драйвер клиента DirectFlow (рис. 2). Директорные узлы и узлы хранения представляют собой компьютерные системы, предназначенные для запуска программного обеспечения PanFS, и вместе они составляют устройство Panasas ActiveStor^®. Драйвер клиента DirectFlow — это загружаемый программный модуль, который работает на вычислительных серверах Linux («клиенты») и взаимодействует с узлами директорами и узлами хранения для чтения и записи файлов, хранящихся в PanFS. Любое администрирование происходит через графический интерфейс или интерфейс командной строки, работающий на управляющем узле. Отсутствует необходимость взаимодействовать с узлами хранения или драйвером клиента DirectFlow — за это отвечают узлы-директора [5].

Рис. 2. PanFS параллелельная файловая система [5].

Все узлы-директора и узлы хранения работают вместе, создавая единое пространство имен файловой системы, которое называется «областью» (“realm”). Все вычислительные серверы Linux, на которых работают клиенты DirectFlow, имеющие доступ к области, не считаются частью этой области, а считаются клиентами.

Разделение плоскостей управления и данных

PanFS явно отделяет «плоскость управления» от «плоскости данных»:

• узлы-директора в PanFS являются ядром плоскости управления. Они обрабатывают метаданные файловой системы (например, каталоги, атрибуты файлов и т. д.), координируют действия узлов хранения и драйверов клиента DirectFlow для доступа к файлам, управляют членством и статусом в кластере хранения PanFS, а также контролируют все процессы восстановления после сбоев и данные. Надежность операций. Директорные узлы – это простые стандартные вычислительные серверы с высокоскоростным сетевым подключением, значительной емкостью DRAM и памятью NVDIMM для журналов транзакций;
• узлы хранения в PanFS являются ядром плоскости данных. Они являются единственной частью общей архитектуры, в которой хранятся данные или метаданные. Хотя узлы-директора обслуживают и изменяют метаданные файловой системы, они используют узлы хранения для их хранения. Узлы хранения — это стандартные системы, но мы выбрали эти модели из-за их тщательно сбалансированной аппаратной архитектуры с точки зрения емкости жестких дисков, твердотельных накопителей, NVMe и DRAM, мощности ЦП, пропускной способности сети и т.д.;
• драйвер клиента DirectFlow — это загружаемая реализация файловой системы, устанавливаемая на вычислительные серверы и используемая прикладными программами, как и любая другая файловая система. Он работает с узлами-директорами и узлами хранения, обеспечивая полностью совместимое с POSIX и согласованное с кэшем поведение файловой системы из единого пространства имен на всех серверах вычислительного кластера. Поддерживаются все популярные дистрибутивы и версии Linux.

Линейное масштабирование узлов управления и хранения

PanFS масштабирует как узлы-директора, так и узлы хранения. Для повышения производительности обработки метаданных можно добавить больше узлов-директоров. Для увеличения емкости или производительности хранилища можно добавить больше узлов хранения.

В горизонтально масштабируемых системах хранения данных, та ких как PanFS, просто не существует максимальной производительности или максимальной емкости. Чтобы добиться большей производительности или большей емкости, просто добавьте еще несколько узлов. PanFS была разработана для обеспечения линейного масштабирования: например, добавление на 50% дополнительных узлов хранения обеспечит на 50% больше производительности и на 50% больше емкости.

Производительность применяющихся смешанных нагрузках

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

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

Параллельные и прямые передачи данных от клиента

PanFS — это параллельная файловая система, которая обеспечивает на несколько порядков большую пропускную способность, чем стандартные протоколы NFS или SMB/CIFS. Каждый файл, хранящийся в PanFS, индивидуально распределяется по множеству узлов хранения, что позволяет параллельно читать и записывать каждый компонент файла, повышая производительность доступа к каждому файлу.

PanFS также представляет собой файловую систему прямого доступа, которая позволяет вычислительному серверу напрямую связываться по сети со всеми узлами хранения. Типичные корпоративные продукты направляют доступ к файлам через «головные узлы», на которых работает NFS или SMB/CIFS, а затем через внутреннюю сеть к другим узлам, содержащим жесткие диски или твердотельные накопители, на которых хранится файл. Очевидно, что это может создать узкие места, когда трафик данных накапливается на головных узлах, а также приведет к дополнительным затратам на отдельную серверную сеть. Напротив, для каждого файла, к которому приложение хочет получить доступ, клиент DirectFlow на вычислительном сервере будет напрямую обращаться по сети ко всем узлам хранения, на которых хранятся данные этого файла. Узлы-директора являются внеполосными, что обеспечивает гораздо более эффективную архитектуру, менее подверженную возникновению горячих точек, узких мест и т.д.

Карты файлов, параллелизм и стирающее кодирование (Erasure Coding)

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

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

Полная семантика POSIX с когерентностью кэша

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

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

Управление данными: тома, снимки и квоты

По крайней мере, один том должен быть создан в корне пространства имен файловой системы PanFS, но рекомендуется использовать несколько томов. Хотя каждый том является отдельной единицей административного контроля, все они разделяют общую область (“realm”). Например, каждый том может иметь свой набор значений квот для каждого пользователя или расписание создания снимков. Каждый том представляет собой обычное дерево каталогов в пространстве имен PanFS, за исключением того, что жесткие ссылки, пересекающие один том и другой, не поддерживаются.

Снимки по томам – это удобный способ обеспечить восстановление предыдущих версий файлов под руководством пользователя без участия системного администратора. Доступ к ним осуществляется через типичный скрытый и синтетический подкаталог «.snapshots» в каждом каталоге пространства имен.

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

Безопасность данных: ACL, SELinux и шифрование при хранении

PanFS поддерживает две функции, которые предотвращают несанкционированный доступ к данным, когда область находится в сети, ACL (Access Control Lists) и SELinux, а также еще одну, которая предотвращает несанкционированный доступ к данным, когда область находится в автономном режиме, шифрование при хранении. Функции шифрования при хранении и безопасности данных SELinux появились в PanFS версии 9.

PanFS поддерживает списки контроля доступа (ACL) для каждого файла и каталога в дополнение к традиционному идентификатору пользователя Linux, идентификатору группы и битам режима, таким как «joe dev -rwxr-xr-x». Списки ACL PanFS полностью совместимы со списками ACL Windows, с управлением учетными записями на основе ActiveDirectory и LDAP и обеспечивают детальный контроль над тем, какие учетные записи пользователей могут выполнять какие операции над каждым файлом или каталогом.

Запуск SELinux на клиентских системах, которые обращаются к PanFS через DirectFlow, обеспечивает реализованный в ядре набор обязательных элементов управления доступом, которые ограничивают пользовательские программы и системные службы минимальным уровнем доступа к файлам и данным, который им требуется. PanFS интегрирует метку безопасности selinux (selinux security label), которая включена в структуру индексного дескриптора PanFS, что приводит к почти нулевой добавленной задержке доступа при использовании SELinux. Это реализует политики многоуровневой безопасности, которая позволяет пользователям и данным с разными уровнями безопасности и отсеками использовать одни и те же вычислительные ресурсы и ресурсы хранения.

Все узлы хранения данных Panasas используют стандартные диски с самошифрованием (SED, self-encrypting drives), которые реализуют утвержденные NIST аппаратные алгоритмы шифрования AES-256, встроенные в каждый диск. Эти диски специально разработаны таким образом, чтобы шифрование не снижало производительность. PanFS позволяет без прерывания работы включать и отключать шифрование при хранении и менять ключи диска по команде, а также криптографическое стирание для безопасного перепрофилирования хранилища без риска раскрытия предыдущих данных.

Управление ключами передается на аутсорсинг через протокол взаимодействия управления ключами (KMIP, Key Management Interoperability Protocol) хорошо зарекомендовавшим себя и проверенным решениям по управлению ключами кибербезопасности, которые обеспечивают централизованное и упрощенное управление ключами. Во время обычного выполнения PanFS периодически проверяет, что сервер KMIP жив и здоров и содержит все нужные ключи, и выдает предупреждение в случае возникновения каких-либо проблем.

Линейка продуктов Panasas ActiveStor [3]

Panasas предлагает линейку готовых к использованию систем устройств под названием ActiveStor, работающих на базе операционной системы PanFS. ActiveStor включает портфель систем хранения данных: ActiveStor Flash, ActiveStor Ultra Edge, ActiveStor Ultra XL, ActiveStor Ultra, ActiveStor Director и ActiveStor ASR-400.

ActiveStor Flash

ActiveStor Flash (ASF-100) — это высокопроизводительное флэш-устройство хранения данных, построенное на сбалансированной аппаратной платформе, выбранной из-за форм-фактора высокой плотности, процессора AMD EPYC и поддержки твердотельных накопителей NVMe. Оно обеспечивает высокую производительность временного хранилища, расширенную поддержку учебных проектов по искусственному интеллекту и машинному обучению и более высокую плотность стоек. ActiveStor Flash дополняет устройства хранения данных ActiveStor Ultra и ActiveStor Ultra XL, обеспечивая более высокий уровень производительности.

ActiveStor Ultra Edge

ActiveStor Ultra Edge (ASU-100E) — это высокопроизводительное устройство хранения данных небольшого форм-фактора с гибкими возможностями конфигурации и бесконечными возможностями масштабирования. ActiveStor Ultra Edge с PanFS обеспечивает лучшую в отрасли производительность смешанных рабочих нагрузок HPC и AI/ML для современных приложений HPC там, где вам это необходимо, например в основных и удаленных центрах обработки данных, колокейшн-площадках и периферийных местах высокопроизводительных вычислений. ActiveStor Ultra Edge обеспечивает производительность, надежность, простоту и гибкость в компактном и недорогом устройстве начального уровня.

ActiveStor Ultra XL

ActiveStor Ultra XL (ASU-100XL) — это устройство хранения данных большой емкости, способное обеспечить 5,76 ПБ в одной стойке высотой 42U. Это решение для параллельной файловой системы с лучшим в отрасли соотношением цены и ТБ и является идеальным выбором для высокопроизводительных приложений, использующих большие файлы и более холодные рабочие нагрузки с наборами данных, таких как сейсмическая разведка ресурсов, производство, а также средства массовой информации и развлечения.

ActiveStor Ultra Storage Node (ASU-100) – хранилище объектов

Узлы хранения в PanFS представляют собой сложнейшие объектные устройства хранения данных (OSD, Object Storage Devices), которые позволяют получать те же архитектурные преимущества масштабирования и отсутствия общего доступа, что и любое хранилище объектов. Определение объекта, используемое в OSD Panasas, основано на стандартном определении объектов интерфейса малых компьютерных систем (SCSI), а не на определении объектов Amazon S3.

PanFS использует объекты для хранения файлов POSIX, но делает это иначе, чем обычно используются объекты S3 для хранения файлов. Вместо хранения каждого файла в объекте, PanFS распределяет большой файл POSIX по набору объектов-компонентов и добавляет в эту полосу дополнительные объекты-компоненты, которые хранят значения защиты данных P и Q стирающего кодирования N+2. Использование нескольких объектов в файле POSIX позволяет чередовать файл, что является одним из источников производительности параллельной файловой системы.

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

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

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

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

При первой настройке BladeSet в PanFS он выделяет настраиваемый объем свободного пространства на всех узлах хранения в этом BladeSet для реконструкций. Когда PanFS реконструирует недостающие объекты-компоненты, он записывает их в свободное пространство на случайно выбранных узлах хранения в том же BladeSet. В результате во время реконструкции PanFS использует общую пропускную способность записи всех узлов хранения в этом BladeSet.

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

Объект — это контейнер для данных и атрибутов; он аналогичен индексному узлу в традиционной реализации файловой системы UNIX. Специализированные узлы хранения, называемые устройствами хранения объектов (OSD, object storage device), хранят объекты в локальной файловой системе OSDFS. Объектный интерфейс обращается к объектам в двухуровневом пространстве имен (идентификатор раздела/идентификатор объекта, partition ID/object ID). Протокол OSD обеспечивает побайтовый доступ к данным, манипулирование атрибутами, создание и удаление объектов и ряд других специализированных операций (на момент 2008 г. использовался транспорт iSCSI для передачи команд OSD).

Файловая система Panasas развертывается поверх хранилища объектов. Каждый файл разделен на два или более объектов для обеспечения избыточности и доступа с высокой пропускной способностью. Семантика файловой системы реализуется узлами-директоров (Director Nodes, ранее – менеджеры метаданных), которые опосредуют доступ к объектам от клиентов файловой системы. Клиенты получают доступ к хранилищу объектов, используя протокол iSCSI/OSD для операций чтения и записи. Операции ввода-вывода выполняются напрямую и параллельно узлам хранения, минуя диспетчеры метаданных. Клиенты взаимодействуют с диспетчерами внеполосных метаданных через RPC, чтобы получить возможности доступа и информацию о местоположении для объектов, в которых хранятся файлы.

Атрибуты объектов используются для хранения атрибутов на уровне файлов, а каталоги реализованы с объектами, в которых хранятся сопоставления имени с идентификатором объекта. Таким образом, метаданные файловой системы хранятся в самом хранилище объектов, а не в отдельной базе данных или какой-либо другой форме хранения на узлах метаданных.

Корпус ASU-100 представляет собой четырехузловое шасси высотой 4U, монтируемое в 19-дюймовую стойку. Корпус поставляется полностью укомплектованным четырьмя узлами ASU-100 на корпус (рис. 3), что обеспечивает общую емкость HDD до 384 ТБ, SSD SATA до 30,72 ТБ и SSD M.2 NVMe емкостью до 15,36 ТБ. Каждый корпус также включает в себя четыре резервных источника питания титанового уровня с энергоэффективностью 96% (http://panasas.com/products/activestorultra).

Рис. 3. Panasas ActiveStor Ultra Storage Node (ASU-100) с четырьмя узлами хранения (вверху) и вид сверху (внизу).

Узел ASU-100 — это серверный узел, на котором работает параллельная файловая система PanFS. Конструкция узла была выбрана с учетом его форм-фактора, доступности дисков, а также общего качества и надежности.

ASU-100 поддерживает четыре уровня хранения данных:

• DRAM используется в качестве кэша с чрезвычайно низкой задержкой для последних считанных или записанных данных и метаданных;
• модули NVDIMM представляют собой тип хранилища с наименьшей задержкой и используются для хранения журналов транзакций метаданных и пользовательских данных;
• SSDM.2 NVMe обеспечивают доступ к базе данных метаданных с малой задержкой и высокую пропускную способность;
• SSD SATA обеспечивают экономичное хранилище с высокой пропускной способностью и позволяют хранить небольшие компоненты;
• HDD обеспечивают хранение данных с высокой пропускной способностью при низкой стоимости и используются для хранения крупных объектов-компонентов.

 

Узел ASU-100 имеет сбалансированную архитектуру, ориентированную на хранилище смешанных файлов, включая мощность ЦП, емкость DRAM, диски с самошифрованием (SED), производительность дисков и пропускную способность сети. Емкость жестких дисков и SSD SATA может различаться и определяется номером заказанной модели ASU-100.

ActiveStor^® Director 200 (ASD-200)

ActiveStor^® Director 200 (ASD-200) — это узел управления метаданными Panasas^® и плоскость управления для высокопроизводительного решения хранения данных ActiveStor. ASD-200 построен на аппаратном обеспечении отраслевого стандарта, выбранном из-за его тщательно сбалансированной аппаратной архитектуры, которая обеспечивает независимое масштабирование и отвечает требованиям приложений с интенсивным использованием метаданных в производстве, медико-биологических науках, энергетике, финансовых услугах, научных кругах и правительстве.

Директорные узлы ASD-200 работают на базе PanFS^®, параллельной файловой системы Panasas, и контролируют многие аспекты общего решения хранения, включая семантику файловой системы, управление пространством имен, распределение и согласованность пользовательских данных на узлах хранения, работоспособность системы, восстановление после сбоев, и функциональность шлюза.

Директорный корпус ASD-200 представляет собой 4-узловое шасси высотой 2U, 19 дюймов, монтируемое в стойку, как показано на рис. 4. Каждый корпус может вмещать до четырех директорных узлов ASD-200 и включает в себя резервные источники питания.

Рис. 4. Panasas ActiveStor^® Director 200 (ASD-200).

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

Службы метаданных PanFS, работающие на узлах ASD-200, реализуют всю семантику файловой системы и управляют сегментированием данных по узлам хранения. Они контролируют операции распределенной файловой системы, такие как согласованность метаданных на уровне файлов и объектов, согласованность кэша клиента, возможность восстановления после прерываний клиентского ввода-вывода, операции узла хранения и безопасный многопользовательский доступ к файлам. Администраторы хранилища могут легко создавать тома в глобальном пространстве имен PanFS для управления иерархией каталогов и файлов, которые совместно используют общие пулы емкости хранилища. Квоты емкости для каждого пользователя могут быть определены на уровне тома. Каждый том имеет набор служб управления для управления квотами и моментальными снимками этого тома. Этот тип секционирования позволяет легко линейно масштабировать производительность метаданных.

Директорные узлы ASD-200 легко интегрируются в растущую гетерогенную среду благодаря высокопроизводительной поддержке протокола DirectFlow для Linux и поддержке нескольких протоколов для NFS и SMB.

Директора ASD-200 обеспечивают масштабируемый доступ для клиентских систем через службы «шлюза» протокола NFS или SMB. Узлы-директора делают это, не находясь на пути к данным. Используя эти шлюзовые решения, пользователи могут легко управлять файлами, созданными в средах Windows. Аутентификация пользователей управляется с помощью различных опций, включая Active Directory и облегченный протокол доступа к каталогам (LDAP).

Защита данных в операционной среде PanFS рассчитывается для каждого файла, а не для каждого диска или внутри группы RAID, как в других архитектурах. Директора ASD-200 также обеспечивают дополнительный уровень защиты данных, называемый расширенной доступностью файловой системы (EFSA, Extended File System Availability), для пространства имен, иерархии каталогов и имен файлов. В крайне маловероятном случае возникновения ошибок, которые не могут быть устранены стирающим кодом, система знает, какие файлы были затронуты и изолированы, а какие файлы не были затронуты.

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

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

В отличие от решений с открытым исходным кодом и даже коммерческих альтернатив от поставщиков широкого портфолио, Panasas предлагает своевременную поддержку мирового класса на уровнях L1–L4 (http://panasas.com/products/activestor–director).

ActiveStor ASR-400

Panasas ActiveStor ASR-400 обеспечивает масштабируемое высокопроизводительное подключение InfiniBand к системам хранения данных Panasas ActiveStor на базе Ethernet. С добавлением узлов ASR-400 система Panasas получает масштабируемые, отказоустойчивые сетевые пути с высокой пропускной способностью для вычислительных кластеров, использующих InfiniBand.

Узел ASR-400 — это сервер, который имеет сетевые интерфейсы Ethernet и InfiniBand и настроен для маршрутизации IP-трафика между двумя сетевыми интерфейсами. В корпусе ASR-400 можно сконфигурировать до четырех узлов, обеспечивая экономичное высокопроизводительное соединение InfiniBand с малой задержкой и системой Panasas ActiveStor.

Системные ограничения и требования

Общие ограничения и требования к файловой системе PanFS и системе хранения ActiveStor Ultra представлены в табл. 1.

Табл. 1. Ограничения и требования к файловой системе PanFS и системе хранения ActiveStor Ultra.

Компоненты системного ПО

Основными программными подсистемами являются система хранения объектов OSDFS, диспетчер метаданных файловой системы Panasas, клиент файловой системы Panasas, шлюз NFS/CIFS и общая система управления кластером:

• клиент Panasas представляет собой устанавливаемый модуль ядра, работающий внутри ядра Linux. Модуль ядра реализует стандартный интерфейс VFS, так что клиентские хосты могут монтировать файловую систему и использовать интерфейс POSIX для системы хранения. Не требуются никакие исправления для запуска ядра Linux4 или 2.6 (и более поздние версии), было протестировано более 200 вариантов Linux;
• каждый узел кластера хранения работает на общей платформе, основанной на FreeBSD, с дополнительными службами для обеспечения мониторинга оборудования, управления конфигурацией и общего контроля;
• узлы хранения используют специализированную локальную-файловую систему (OSDFS), которая реализует примитивы хранения объектов. Они реализуют набор команд iSCSI target и OSD. Хранилище объектов OSDFS и процессор команд iSCSI target/OSD являются модулями ядра. OSDFS связана с традиционными проблемами файловой системы блочного уровня, такими как эффективное использование дискового манипулятора, управление носителями (т.е. обработка ошибок), высокая пропускная способность, а также интерфейс OSD;
• менеджер кластера (SysMgr) поддерживает глобальную конфигурацию и управляет другими службами и узлами в кластере хранения. Существует связанное приложение управления, которое предоставляет как интерфейс командной строки (CLI), так и интерфейс HTML (GUI). Это все приложения пользовательского уровня, которые работают на подмножестве узлов менеджера. Менеджер кластера занимается членством в кластере хранения, обнаружением сбоев, управлением конфигурацией и общим контролем таких операций, как обновление программного обеспечения и перезагрузка системы;
• менеджер метаданных Panasas (PanFS) реализует семантику файловой системы и управляет чередованием данных на устройствах хранения объектов. Это приложение уровня пользователя, которое запускается на каждом узле менеджера. Диспетчер метаданных занимается проблемами распределенной файловой системы, такими как безопасный многопользовательский доступ, поддержка согласованных метаданных на уровне файлов и объектов, когерентность клиентского кэша и восстановление после сбоев клиента, узла хранения и сервера метаданных. Отказоустойчивость основана на локальном журнале транзакций, который реплицируется в резервную копию на другом управляющем узле;
• службы NFS и CIFS обеспечивают доступ к файловой системе для хостов, которые не могут использовать устанавливаемый клиент файловой системы Linux. Служба NFS – это настроенная версия стандартного NFSсервера FreeBSD, работающая внутри ядра. Служба CIFS основана на Samba и работает на уровне пользователя. В свою очередь, эти службы используют локальный экземпляр клиента файловой системы, работающий внутри ядра FreeBSD. Эти службы шлюза работают на каждом узле менеджера, чтобы обеспечить кластерную службу NFS и CIFS.

 

Пакет ПО Panasas PanFS

Программный пакет Panasas PanFS (рис. 4а) представляет собой семейство программного обеспечения, построенное на основе файловой системы PanFS.

Рис. 4а. Пакет ПО PanFS.

Помимо самого PanFS, в пакет входит ПО для мобильности и защиты данных, видимости и анализа данных, PanFS и управления областями, а также функции безопасности (табл. 1а).

Табл. 1а. Компоненты Panasas PanFS ПО.

Решения PanMove сочетают в себе простоту и функциональность для решения проблем мобильности данных в центре обработки данных, на периферии и в облаке. PanMove предоставляет масштабируемое и надежное решение для параллельной репликации данных на стороне клиента с современными функциями параллельной синхронизации, а также функциями плавного копирования, перемещения и синхронизации для перемещения данных между устройствами хранения данных ActiveStor на базе PanFS, между устройствами ActiveStor и облако, включая поддержку AWS, Azure и Google Cloud, а также между устройствами Panasas и локальным и облачным объектным хранилищем S3.

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

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

Panasas PanActive Manager

Система хранения Panasas ActiveStor Ultra представляет собой единый объект, которым вы управляете с помощью одного графического пользовательского интерфейса (GUI) или интерфейса командной строки (CLI), независимо от того, сколько корпусов ActiveStor вы интегрируете в нее. Благодаря единой точке управления, интуитивно понятному интерфейсу и множеству автоматизированных функций управления предприятием Panasas PanActive Manager позволяет легко управлять хранилищами объемом от сотен терабайт до сотен петабайт. Достаточно одного ИТ-администратора.

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

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

Управление хранилищем

Panasas предоставляет два механизма для управления пространством имен и емкостью: BladeSet и тома.

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

Том — это логический механизм, поддерево общей структуры системных каталогов. Корневой том верхнего уровня только для чтения («/»), под которым монтируются все остальные тома, а во время установки создается том/home. Все остальные тома создаются пользователем на определенном блейд-сете, до 3600 на область.

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

При планировании конфигурации тома необходимо учитывать:

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

 

RAID и стирающее кодирование (Erasure Coding)

Вместо того, чтобы полагаться на аппаратные RAID-контроллеры, которые защищают данные на уровне диска и вычисляют RAID на самих дисках, архитектура Panasas PanFS использует пофайловый распределенный программный RAID с использованием кодов стирания, т.е. пофайловое кодирование стирания, а не аппаратный RAID. Файлы в одном и том же наборе блейд-серверов, томе и даже каталоге могут иметь разные уровни RAID/кода стирания. Файл можно рассматривать как один виртуальный объект, разделенный на несколько объектов-компонентов.

PanFS использует объекты для хранения файлов POSIX иначе, чем объекты S3, которые обычно используются для хранения файлов. Вместо того, чтобы хранить каждый файл в объекте, PanFS распределяет большой файл POSIX по набору объектов-компонентов и добавляет в этот страйп дополнительные объекты-компоненты, которые хранят значения защиты данных P и Q стирающего кодирования N+2. Использование нескольких объектов в одном файле POSIX обеспечивает чередование файлов, что является одним из источников производительности параллельной файловой системы [5].

Пользователям доступны три уровня RAID: RAID 6, RAID 5 и RAID 10:

• RAID 6 — это RAID по умолчанию для всех томов, поскольку он обеспечивает баланс между производительностью, нагрузкой и защитой RAID;
• тома RAID 5 оптимизированы с точки зрения производительности и емкости;
• тома RAID 10 сочетают в себе чередование и зеркалирование, обеспечивая высокую производительность для приложений, выполняющих небольшие произвольные записи, и в то же время обеспечивая устойчивость к сбою одного диска.

 

Можно смешивать уровни RAID и любую структуру томов в одном блейд-сете, при этом статус доступности каждого тома оценивается независимо.

Традиционные задачи управления хранилищем включают в себя разделение доступного пространства хранения на LUN (т.е. логические единицы, которые представляют собой один или несколько дисков, или подмножество массива RAID), назначение владения LUN различным хостам, настройку параметров RAID, создание файловых систем или баз данных на LUN и подключение клиентов к правильному серверу для их хранения. Это может быть трудоемким сценарием. Архитектура Panasas предоставляет упрощенную модель управления хранилищем, которая снижает нагрузку на администратора хранилища и позволяет одному администратору управлять системами размером в сотни терабайт.

Система хранения Panasas представляет собой файловую систему с интерфейсом POSIX и скрывает большую часть сложностей управления хранением. Клиенты имеют единую точку монтирования для всей системы. Файл /etc/fstab ссылается на диспетчер кластера, и из него клиент узнает расположение экземпляров службы метаданных. Администратор может добавить хранилище, пока система подключена к сети, а новые ресурсы обнаруживаются автоматически.

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

Том — это иерархия каталогов, которая имеет ограничение квоты и назначается определенному набору блейд-сетов. Квоту можно изменить в любое время, и емкость не выделяется для тома до тех пор, пока он не будет использован, поэтому несколько томов конкурируют за место в своем BladeSet и увеличиваются по требованию. Файлы в этих томах распределены между всеми модулями StorageBlade в BladeSet.

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

Каждый том управляется одним менеджером метаданных. Разделение ответственности за управление метаданными по границам томов (т.е. по деревьям каталогов) было сделано в первую очередь для упрощения реализации. Предполагается, что администраторы будут вводить тома (например, деревья квот) по своим собственным причинам, и это обеспечит легкую естественную границу. Реализация проверки восстановления файловой системы также упрощена; каждый том проверяется независимо (и, по возможности, параллельно), и ошибки в одном томе не влияют на доступность других томов. Наконец, клиенты обходят диспетчер метаданных во время операций чтения и записи, поэтому нагрузка на диспетчер метаданных уже на порядок меньше, чем у традиционного файлового сервера, хранящего такое же количество файлов. Это снижает важность тонкой балансировки нагрузки метаданных. Тем не менее, неравномерное использование тома может привести к неравномерному использованию диспетчера метаданных. Протокол позволяет диспетчеру метаданных перенаправлять клиента другому диспетчеру для распределения нагрузки.

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

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

Схема управления хранилищем отражает компромисс между преимуществами управления производительностью и емкостью большого пула хранения, требованиями администратора к резервному копированию и восстановлению и сложностью реализации. На практике клиенты используют наборы BladeSet размером от одной полки до более чем 20 полок, при этом самый большой производственный набор Bladeset включает около 50 полок или 500 модулей StorageBlade и 50 модулей DirectorBlade. Однако наиболее распространенные размеры варьируются от 5 до 10 полок.

Автоматическая балансировка емкости

Дисбаланс емкости возникает при расширении BladeSet (т.е. при добавлении новых пустых узлов хранения), объединении двух BladeSet и замене узла хранения после сбоя. В последнем случае дисбаланс является результатом нашей перестройки RAID, которая использует резервную емкость на каждом узле хранения, а не выделяет конкретный узел «горячего резерва». Это обеспечивает лучшую пропускную способность во время восстановления, но заставляет систему иметь новый пустой узел хранения после замены вышедшего из строя узла хранения. Система автоматически балансирует используемую емкость между узлами хранения в BladeSet, используя два механизма: пассивную балансировку и активную балансировку.

Пассивная балансировка изменяет вероятность того, что узел хранения будет использоваться для нового компонента файла, в зависимости от его доступной емкости. Это вступает в силу при создании файлов и увеличении размера их чередования для включения большего количества узлов хранения. Активная балансировка выполняется путем перемещения существующего объекта компонента с одного узла хранения на другой и обновления карты хранилища для затронутого файла. Во время передачи файл прозрачно помечается уровнем управления хранилищем как доступный только для чтения, а балансировщик емкости пропускает файлы, которые активно записываются. Таким образом, балансировка емкости прозрачна для клиентов файловой системы.

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

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

Первоначально отдавалось предпочтение крупным объектам для активной балансировки, потому что это более эффективно. Обновление карты хранилища требует затрат на каждый файл, поэтому более эффективно переместить один объект-компонент размером 1 ГБ, чем 1000 объектов-компонентов размером 1 МБ. Однако рассмотрим систему, в которой относительно мало больших файлов с широким чередованием и множество других мелких файлов. При расширении с N до N+M узлов хранения (например, с 50 до 60) должна ли система балансировать емкость, перемещая несколько крупных объектов или перемещая множество мелких объектов? Если большие файлы являются горячими, будет ошибкой отдавать предпочтение им, потому что новые узлы хранения могут получить не пропорциональное количество горячих объектов. Мы обнаружили, что выбор однородной случайной выборки объектов из исходных лезвий был лучшим способом избежать смещения и непреднамеренных горячих точек, даже если это означает перемещение множества мелких объектов для балансировки емкости.

Объектный RAID и реконструкция

Защита от потери объекта данных или всего узла хранения обеспечивается путем чередования файлов между объектами, хранящимися на разных узлах хранения, с использованием отказоустойчивого алгоритма чередования, такого как RAID-1 или RAID-5.  Небольшие файлы зеркально отображаются на двух объектах, а файлы большего размера распределяются более широко, чтобы обеспечить более высокую пропускную способность и меньшую нагрузку на емкость из-за информации о четности. Пофайловая компоновка RAID означает, что информация о четности для разных файлов не смешивается и легко позволяет разным файлам использовать разные схемы RAID рядом друг с другом. Это свойство и механизмы безопасности протокола OSD позволяют обеспечить контроль доступа к файлам, даже когда клиенты напрямую обращаются к узлам хранения. Это также позволяет использовать, пожалуй, самый новый аспект нашей системы — управляемый клиентом RAID. То есть клиенты несут ответственность за вычисление и запись четности. Механизм безопасности OSD также позволяет нескольким менеджерам метаданных управлять объектами на одном и том же устройстве хранения без жесткой координации или вмешательства друг друга.

Кодирование стирания N+2, реализуемое PanFS, защищает от двух одновременных сбоев в пределах любого данного BladeSet без потери данных. Более двух сбоев в области могут быть автоматически и прозрачно восстановлены, если в любой момент времени в любом заданном наборе BladeSet имеется не более двух вышедших из строя узлов хранения.

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

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

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

Управляемый клиентом пофайловый RAID имеет четыре преимущества для крупномасштабных систем хранения. Во-первых, за счет того, что клиенты вычисляют четность для своих собственных данных, возможности XOR системы возрастают по мере увеличения числа клиентов. Была измерена обработка XOR во время загрузки пропускной способности при потоковой записи на уровне 7% ЦП клиента, а остальная часть ушла на стек OSD/iSCSI/TCP/IP и другие накладные расходы файловой системы. Перемещение вычисления XOR из системы хранения в клиента требует некоторой дополнительной работы для обработки сбоев. Клиенты несут ответственность за создание хороших данных и их хорошее соответствие. Поскольку уравнение RAID относится к файлам, ошибочный клиент может повредить только свои собственные данные. Однако, если во время записи происходит сбой клиента, диспетчер метаданных будет очищать четность, чтобы убедиться, что уравнение четности правильное.

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

В-третьих, защита RAID для каждого файла позволяет менеджерам метаданных восстанавливать файлы параллельно. Хотя параллельная перестройка теоретически возможна в блочном RAID, она редко реализуется. Это связано с тем, что диски принадлежат одному RAID-контроллеру даже в двухпортовых конфигурациях. Большие системы хранения имеют несколько RAID-контроллеров, которые не связаны между собой. Поскольку набор команд SCSI Block не обеспечивает детализированных операций синхронизации, нескольким RAID-контроллерам сложно координировать сложную операцию, такую как оперативная перестройка, без внешней связи. Даже если бы они могли, без подключения к дискам в затронутой группе четности другие контроллеры RAID не смогли бы помочь. Даже в конфигурации с высокой доступностью каждый диск обычно подключается только к двум разным RAID-контроллерам, что ограничивает потенциальное ускорение до 2x.

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

Четвертое преимущество пофайлового RAID заключается в том, что неустранимые сбои могут быть ограничены отдельными файлами. Наиболее часто встречающийся сценарий двойного сбоя в RAID-5 — это неисправимая ошибка чтения (т.е. увеличение дефекта носителя) во время восстановления вышедшего из строя устройства хранения. Второе устройство хранения по-прежнему работоспособно, но ему не удалось прочитать сектор, что предотвращает восстановление потерянного сектора с первого диска и, возможно, всей полосы или LUN, в зависимости от конструкции RAID-контроллера. В блочном RAID сложно или невозможно на прямую сопоставить любые потерянные сектора со структурами данных файловой системы более высокого уровня, поэтому для обнаружения и устранения повреждений потребуется полная проверка файловой системы и сканирование носителя. Более типичный ответ — полностью провалить перестроение. Контроллеры RAID контролируют диски, пытаясь устранить дефекты носителей и избежать этого плохого сценария, и система Panasas также выполняет очистку носителей. Однако с дисками SATA большой емкости вероятность обнаружения дефекта носителя на диске B при восстановлении диска A по-прежнему значительна. При файловом RAID-5 такой двойной сбой означает, что потерян только один файл, и конкретный файл можно легко идентифицировать и сообщить об этом администратору. В то время как блочные системы RAID были вынуждены внедрять RAID-6 (то есть отказоустойчивые схемы, обрабатывающие два сбоя), мы смогли развернуть высоконадежные системы RAID-5 с большими высокопроизводительными пулами хранения.

Производительность ввода/вывода RAID

На рис. 5 представлена диаграмма пропускной способности потоковой передачи iozone [Iozone] из кластера, состоящего из 100 клиентов, по сравнению с кластерами хранения из 1, 2, 4 и 8 полок. Каждый клиент запускал два экземпляра iozone для записи и чтения файла размером 4 ГБ с размером записи 64 КБ (следует обратить внимание, что ось X не является линейной; имеется скачок от 160 потоков ввода-вывода к 200; детали аппаратного обеспечения – [4]).

Рис. 5. Пропускная способность потоковой передачи IOzone, МБ/с.

Есть два основных результата. Во-первых, производительность увеличивается линейно по мере увеличения размера системы хранения. Во-вторых, производительность записи увеличивается и остается неизменной по мере увеличения числа клиентов, а производительность чтения падает по мере увеличения числа клиентов. Кривые производительности записи демонстрируют масштабируемость производительности. Система с одной полкой обеспечивала скорость около 330 МБ/с, система с двумя полками — около 640 МБ/с, система с четырьмя полками — около 1280 МБ/с, а система с восемью полками — около 2500 МБ/с. Это соответствует коэффициенту масштабирования, составляющему 95% от линейного. В другом эксперименте система с 30 полками показала скорость чтения чуть более 10 ГБ/с при пропускной способности на полку 330 МБ/с.

Такие результаты зависят от адекватной пропускной способности сети между клиентами и узлами хранения. Им также требуется двухуровневый шаблон RAID с чередованием для больших файлов, чтобы избежать перегрузки сети. Для большого файла система выделяет группы четности от 8 до 11 узлов хранения до тех пор, пока не будут использованы все доступные узлы хранения. Приблизительно 1 ГБ данных (2000 полос) хранится в каждой группе контроля четности перед переходом к следующей. Когда все группы контроля четности использованы, файл снова возвращается к первой группе. Система автоматически выбирает размер группы четности таким образом, чтобы целое их число помещалось на доступные узлы хранения с наименьшим неиспользуемым остатком. Двухуровневый шаблон RAID концентрирует операции ввода-вывода на небольшом количестве узлов хранения, но при этом позволяет расширять большие файлы, чтобы охватить весь набор узлов хранения. Каждый файл имеет свое собственное сопоставление групп четности с узлами хранения, что распределяет нагрузку и уменьшает количество горячих точек.

Разница между масштабированием чтения и записи связана с тем, как OSDFS записывает данные. Он выполняет отложенное выделение блоков для новых данных, чтобы их можно было эффективно группировать и записывать. Таким образом, новые данные и связанные с ними метаданные (т.е. непрямые блоки) передаются в следующее доступное свободное пространство, что приводит к высокоэффективному использованию плеча диска. Операции чтения, напротив, должны стремиться получить свои данные, потому что наборы данных создаются слишком большими, чтобы поместиться в любой кэш. Хотя OSDFS выполняет упреждающее чтение с учетом объектов, по мере увеличения числа одновременных потоков чтения становится все труднее оптимизировать рабочую нагрузку, поскольку объем буферизации упреждающего чтения, доступный для каждого потока, уменьшается.

На рис. 6 представлена диаграмма производительности iozone для смешанных (т.е. чтения и записи) произвольных операций ввода-вывода с файлом размером 4 ГБ с разными размерами передачи и разным количеством клиентов. У каждого клиента есть свой собственный файл, поэтому размер рабочего набора увеличивается с увеличением количества клиентов. Изменялись два параметра: объем памяти модулей StorageBlade и размер передачи ввода-вывода. Вертикальная ось показывает пропускную способность системы хранения, а на диаграмме сравниваются различные конфигурации при увеличении числа клиентов с 1 до 6. Результаты показывают, что больший размер кэшей в модулях StorageBlade может значительно повысить производительность случайного ввода-вывода небольшими блоками.

Рис. 6. Смешанный произвольный ввод-вывод, МБ/с.

Были протестировали две разные аппаратные конфигурации: модули StorageBlade с 512 МБ памяти (обозначены как «.5GB$») и с 2 ГБ памяти (обозначены как «2GB$»). В каждом случае в системе было по 9 модулей StorageBlade, поэтому общий объем памяти на модулях StorageBlade составил 4,5 ГБ и 18 ГБ соответственно. Используются два разных размера передачи: 64 КБ соответствует размеру блока страйпа, а 4 КБ — базовому размеру блока OSDFS. Очевидно, что конфигурация с большей памятью способна кэшировать большую часть или весь рабочий набор при небольшом количестве клиентов. Поскольку количество клиентов увеличивается настолько, что размер рабочего набора значительно превышает размер кэша, разница в размере кэша будет иметь меньшее значение. Пропускная способность при случайном вводе-выводе размером 4 КБ очень низкая из-за недостаточного кэша. Один клиент получает примерно 1,1 МБ/сек, или около 280 операций по 4 КБ/сек, а скорость с четырьмя клиентами падает до 700 КБ/сек, или около 175 операций/сек. Для записи 4 КБ и 64 КБ в смешанной рабочей нагрузке требуется четыре операции OSD для завершения обновления RAID-5 до полной полосы (два чтения, две записи). Кроме того, мы наблюдали дополнительный трафик ввода-вывода между кэшем клиента и экранным меню из-за оптимизаций упреждающего чтения и сбора записи, которые включены по умолчанию для оптимизации рабочих нагрузок потоковой передачи. Тест iozone выполняет 1 млн операций ввода-вывода от каждого клиента в случае блока размером 4 КБ и файла размером 4 ГБ, поэтому мы решили не запускать его с 5 и 6 клиентами в конфигурации кэша 512 МБ просто потому, что он выполнялся слишком долго.

Производительность восстановления RAID

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

Пропускная способность восстановления — это скорость, с которой восстановленные данные записываются в систему при восстановлении узла хранения. Система должна читать в N раз больше, чем записывает, в зависимости от ширины группы четности RAID, поэтому общая пропускная способность СХД в несколько раз превышает скорость перестроения. Более узкая группа четности RAID требует меньшего количества операций чтения и XOR для восстановления, что приведет к более высокой пропускной способности восстановления. Однако это также приводит к увеличению нагрузки на данные четности и может ограничить пропускную способность во время обычного ввода-вывода. Таким образом, выбор размера группы четности RAID представляет собой компромисс между накладными расходами на емкость, производительностью в оперативном режиме и производительностью восстановления.

Понять декластеризацию легче с помощью изображения. На рис. 7 каждая группа четности имеет 4 элемента, которые обозначены буквами, расположенными в каждом запоминающем устройстве. Они распределены по 8 устройствам хранения данных. Соотношение между размером группы четности и доступными устройствами хранения — это коэффициент декластеризации, который в этом примере равен 1/2. На рис. 7 заглавные буквы обозначают те группы четности, которые совместно используют второй узел хранения. Если второе устройство хранения выйдет из строя, системе придется прочитать оставшиеся члены своих групп четности, чтобы восстановить утраченные элементы. Можно видеть, что другие элементы этих групп четности занимают около половины каждого другого устройства хранения.

Рис. 7. Декластеризованные паритетные группы.

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

Декластеризация означает, что для восстановления требуется чтение подмножества каждого устройства, при этом пропорция примерно равна коэффициенту декластеризации. Общий объем прочитанных данных одинаков с декластеризацией и без нее, но при декластеризации он распределяется по большему количеству устройств. При записи реконструированных элементов два элемента одной группы четности не могут находиться на одном узле хранения. Декластеризация оставляет множество устройств хранения данных доступными для восстановленного элемента четности, а рандомизированное размещение группы четности каждого файла позволяет системе распределить операции ввода-вывода записи по всему хранилищу. Таким образом, декластеризация групп четности RAID обладает важным свойством: фиксированный объем операций ввода-вывода при перестроении распределяется по большему количеству устройств хранения.

Наличие пофайлового RAID позволяет системе Panasas разделить работу между доступными модулями DirectorBlade, назначая разные файлы разным модулям DirectorBlade. Это разделение является динамическим с простой моделью «главный/рабочий», в которой службы метаданных становятся доступными в качестве рабочих, а каждая служба метаданных выступает в качестве главного для томов, которые она реализует. Выполняя пересборку параллельно на всех модулях DirectorBlade, система может применить большую пропускную способность XOR и использовать дополнительную пропускную способность ввода-вывода, полученную при декластеризации.

На рис. 8 показана производительность восстановления при увеличении размера кластера хранения данных с 1 модуля DirectorBlade и 10 модулей StorageBlade до 12 модулей DirectorBlade и 120 модулей StorageBlade. На каждой полке установлен 1 модуль DirectorBlade (Xeon 1,6 ГГц) и 10 модулей StorageBlade. В этом эксперименте система была заполнена файлами размером 100 МБ или файлами размером 1 ГБ, и каждый символ на диаграмме представляет собой отдельный тест. Коэффициент декластеризации находится в диапазоне от 0,9 до 0,075, а результирующая полоса пропускания реконструкции находится в диапазоне от 10 МБ/с до 120 МБ/с. Декластеризация и параллельная перестройка дают почти линейное увеличение производительности перестроения по мере увеличения размера системы.

Рис. 8. RAID Rebuild (МБ/с) vs. Sysytem Size.

Снижение производительности на 8 и 10 полках связано с более широким размером полосы. Система автоматически выбирает ширину полосы от 8 до 11, максимально увеличивая количество используемых узлов хранения, оставляя при этом хотя бы одно свободное место. Например, в системе с одной полкой, состоящей из 10 модулей StorageBlade и 1 распределенного резервного хранилища, система будет использовать полосу шириной 9. Распределенный резервный ресурс позволяет продолжить реконструкцию без замены вышедшего из строя узла хранения; карта хранилища каждого файла пропускает по крайней мере один доступный узел хранения, создавая виртуальное резервное местоположение для этого файла, которое можно использовать для хранения восстановленной копии вышедшего из строя компонента. Каждый файл имеет свое собственное запасное местоположение, которое распределяет запасные части по всему Bladeset. Система резервирует емкость на каждом узле хранения для возможности реконструкции. При наличии 80 узлов хранения и 1 распределенного резерва система выбирает ширину полосы 11, чтобы поместилось 7 групп четности, оставляя 3 неиспользуемых узла хранения. Ширина 10 не может быть использована, поскольку не будет неиспользуемых узлов хранения. В табл. 2 указан размер группы четности (т.е. ширина полосы) в зависимости от размера пула хранения.

Узлы хранения	Ширина группы	Группы
10	9	1
20	9	2
40	9	4
60	8	7
80	11	7
100	11	9
120	9	13

Табл. 2. Размер группы четности.

Вариативность результата с 12 полками возникла в результате запусков, в которых использовались файлы размером 1 ГБ и несколько томов. В этом тесте количество файлов, затронутых сбоем узла хранения, существенно различалось в зависимости от тома, поскольку на каждом узле хранения использовалось только 30 ГБ пространства, а каждому диспетчеру метаданных приходилось восстанавливать только от 25 до 40 файлов. Существует небольшая задержка между моментом, когда менеджер метаданных завершает свой собственный том, и моментом, когда он начинает работать с другими менеджерами метаданных; в результате не все менеджеры метаданных используются полностью к концу перестройки. При восстановлении почти полного StorageBlade эта задержка незначительна, но в наших тестах она была достаточно большой, чтобы повлиять на результаты. Поскольку мы вычисляем пропускную способность, измеряя общее время восстановления и разделяя его на объем восстановленных данных, из-за неравномерного использования результаты становятся меньше.

На рис. 9 показано влияние ширины группы четности RAID на скорость восстановления. Если полоса четности имеет ширину 6, то считываются 5 уцелевших элементов для повторного вычисления недостающего 6-го элемента. Если полоса четности имеет ширину всего 3, то для повторного вычисления недостающего элемента считываются только 2 оставшихся элемента. Несмотря на то, что операции чтения могут выполняться параллельно, при чтении требуется большая пропускная способность памяти, а с более широкой полосой выполняется больше операций XOR. Поэтому более узкие полосы четности перестраиваются быстрее. Эксперимент это подтверждает.

Рис. 9. RAID Rebuild MB/sec vs Stripe Width.

Были измерены две системы. В одной было три модуля DB-100 DirectorBlade и 8 модулей SB-500a-XC StorageBlade. Максимальная ширина полосы в этой конфигурации равна 7, что позволяет использовать запасной. Другая система имела четыре модуля DirectorBlade DB-100a и 18 модулей StorageBlade SB-500a-XC на двух полках. Максимальная ширина полосы в этой конфигурации составляла 8. Пропускная способность восстановления увеличивается с более узкими полосами, поскольку системе приходится считывать меньше данных для восстановления того же объема. Результаты также показывают, что наличие большего количества модулей DirectorBlade увеличивает скорость восстановления. Это связано с тем, что существует больше «механизмов реконструкции», которые могут лучше использовать полосу пропускания, доступную в системе. Эти результаты показывают, что производительность восстановления больших систем, показанных на рис. 8, может быть намного выше при использовании двух модулей DirectorBlade на полку, что более чем в два раза превышает показанную производительность, поскольку в этих результатах использовались более старые модули DirectorBlade первого поколения.

Управление метаданными

В системе Panasas есть несколько видов метаданных. К ним относятся сопоставление идентификаторов объектов с наборами адресов блоков, сопоставление файлов с наборами объектов, атрибуты файловой системы, такие как списки управления доступом и владельцы, информация о пространстве имен файловой системы (т.е. каталоги) и информация о конфигурации/управлении самим кластером хранения. Одним из подходов может быть выбор общего механизма, например, реляционной базы данных, и хранение всей этой информации с использованием этого средства. Это переносит вопросы масштабируемости, надежности и производительности с системы хранения на систему базы данных. Однако это усложняет оптимизацию хранилища метаданных с учетом уникальных требований каждого типа метаданных. Поэтому были предоставлены конкретные реализации для каждого типа метаданных. Этот подход распределяет управление метаданными между объектными устройствами хранения и менеджерами метаданных, чтобы обеспечить масштабируемую производительность управления метаданными, а также позволяет выбрать лучший механизм для каждого типа метаданных.

Метаданные на уровне блоков

Метаданные на уровне блоков управляются внутри OSDFS файловой системы, оптимизированной для хранения объектов. OSDFS использует схему размещения плавающих блоков, в которой данные, указатели блоков и дескрипторы объектов объединяются в большие операции записи. Буфер записи защищен встроенным ИБП и сбрасывается на диск при сбое питания или системной панике. Алгоритмы распределения блоков аналогичны алгоритмам WAFL и LFS, хотя в отличие от LFS здесь нет средства очистки, сжимающего свободное пространство. Фрагментация была проблемой в ранних версиях OSDFS, в которых использовался распределитель блоков первого соответствия, но эта проблема была значительно смягчена в более поздних версиях, в которых использовался модифицированный распределитель блоков наилучшего соответствия.

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

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

Метаданные на уровне файла

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

Помните проблему «горячих точек», возникающую из-за смещения создаваемого файла в сторону пустого сменного лезвия? Это связано с тем, что первые два объекта компонента хранят атрибуты уровня файла, поэтому они видят больше трафика Set Attributes и Get Attributes, чем остальные компоненты. Файлы всегда сначала зеркально отражаются на этих первых двух компонентах хранения атрибутов, поэтому смещение при создании файла создавало горячую точку метаданных.

Имена файлов реализуются в каталогах, подобных традиционным файловым системам UNIX. Каталоги — это специальные файлы, в которых хранится массив записей каталога. Запись каталога идентифицирует файл с кортежем <serviceID, разделаID, objectID>, а также включает два поля <osdID>, которые являются подсказками о местонахождении компонентов, хранящих атрибуты. Идентификатор раздела/идентификатор объекта — это двухуровневая схема нумерации объектов интерфейса OSD, и мы используем раздел для каждого тома. Каталоги зеркалируются (RAID-1) в двух объектах, что позволяет эффективно выполнять небольшие операции записи, связанные с обновлениями каталогов.

Клиентам разрешено читать, кэшировать и анализировать каталоги, или они могут использовать RPC поиска к менеджеру метаданных для преобразования имени в кортеж <serviceID, разделID, objectID> и подсказки местоположения <osdID>. ServiceID предоставляет подсказку о диспетчере метаданных для файла, хотя клиенты могут быть перенаправлены к диспетчеру метаданных, который в данный момент управляет файлом.   Подсказка osdID может устареть, если реконструкция или активная балансировка перемещают объект. Если обе подсказки osdID не работают, диспетчер метаданных должен выполнить многоадресную рассылку GetAttributes к узлам хранения в BladeSet, чтобы найти объект. Идентификатор раздела и идентификатор объекта одинаковы на каждом узле хранения, на котором хранится компонент файла, поэтому этот метод всегда будет работать. Как только файл обнаружен, менеджер метаданных автоматически обновляет сохраненные подсказки в каталоге, позволяя будущим доступам пропустить этот шаг.

Для файловых операций может потребоваться несколько объектных операций. На рис. 10 показаны этапы создания файла. Диспетчер метаданных ведет локальный журнал для записи выполняемых действий, чтобы он мог восстанавливаться после сбоев объектов и сбоев менеджера метаданных, возникающих при обновлении нескольких объектов. Например, создание файла — довольно сложная задача, требующая обновления родительского каталога, а также создания нового файла. Есть 2 операции Create OSD для создания первых двух компонентов файла и 2 операции записи OSD, по одной для каждой реплики родительского каталога. В целях оптимизации производительности сервер метаданных также предоставляет клиенту доступ для чтения и записи к файлу и возвращает соответствующие возможности клиенту как часть результатов FileCreate. Сервер записывает эти возможности записи для поддержки восстановления после ошибок в случае сбоя клиента во время записи файла. Следует обратить внимание, что обновление каталога (шаг 7) происходит после ответа, поэтому многие обновления каталога можно объединить в пакет. Отложенное обновление защищено записью журнала операций, которая удаляется на шаге 8 после успешного обновления каталога.

Рис. 10. Создание файла.

Менеджер метаданных ведет журнал операций, в котором фиксируются создание объекта и текущие обновления каталога. Эта запись журнала удаляется после завершения операции. Если служба метаданных выходит из строя и перезапускается или событие сбоя перемещает службу метаданных на другой узел менеджера, то журнал операций обрабатывается, чтобы определить, какие операции были активны во время сбоя. Менеджер метаданных повторяет операции вперед или назад, чтобы обеспечить согласованность хранилища объектов. Если ответ на операцию не был сгенерирован, операция откатывается. Если ответ был сгенерирован, но ожидающие операции еще не выполнены (например, обновления каталога), то операция повторяется. Возможность записи сохраняется в журнале caplog, поэтому при запуске сервера метаданных он знает, какие из его файлов заняты. В дополнение к возможности «совмещенной» записи, возвращаемой FileCreate, клиент также может выполнить RPC StartWrite, чтобы получить отдельную возможность записи. Запись журнала ограничения удаляется, когда клиент снимает ограничение на запись через RPC EndWrite.  Если клиент сообщает об ошибке во время ввода-вывода, то создается запись в журнале восстановления и файл назначается для восстановления. Возможности чтения и записи кэшируются клиентом посредством нескольких системных вызовов, что еще больше снижает трафик сервера метаданных.

В нашей реализации журнала используется быстрый (обновление 3 мкс) механизм журнала в памяти, который сохраняется на диск при выключении системы, сбое питания и сбоях программного обеспечения, включая панику ядра. В конфигурациях с аварийным переключением этот журнал синхронно отображается в памяти удаленного узла через протокол с малой задержкой (обновление 90 мкс через Gigabit Ethernet). Сбои программного обеспечения обычно устраняются путем перезагрузки и восстановления из локальных журналов. Если из-за аппаратного сбоя или зависания ОС модуль DirectorBlade отключается, его резервная копия берет на себя управление и восстанавливается из реплики журнала.

Если журналы невозможно восстановить или резервная копия отсутствовала, возможно, в результате сбоя хранилище распределенных объектов оказалось в несогласованном состоянии (например, частично созданный файл). Эти несоответствия обнаруживаются и допускаются в ходе нормальной эксплуатации. В некоторых случаях система может восстановить объект во время операции открытия файла. В других случаях система просто изолирует подозрительные объекты, и они могут быть исправлены позже с помощью (автономной) функции проверки восстановления файловой системы, которая проверяет хранилище объектов, исправляя несоответствия и перемещая текущие операции вперед или назад. Дополнительный процесс восстановления выполняется со скоростью около 800 файлов в секунду и может выполняться параллельно на нескольких томах на разных модулях DirectorBlade.

Сочетание быстрой регистрации в памяти с резервным питанием, репликации журналов на удаленный узел, хранения метаданных об объектах и процесса автономного восстановления является надежной точкой проектирования. Ведение журнала в памяти возможно благодаря встроенному ИБП, который позволяет нам безопасно выключать нашу систему. Удаленное резервное копирование защищает от полного аппаратного сбоя модуля DirectorBlade. Однако в любом сложном продукте опасность представляют сбои в программном обеспечении. Наш менеджер метаданных работает как приложение пользовательского уровня, поэтому его можно прозрачно закрыть и перезапустить, а затем восстановить на основе его журналов. Шлюз NFS, использующий резидентный клиент ядра, может быть источником паники ядра. Большинство из них представляли собой «чистые» паники ядра, когда система могла сохранять содержимое журнала в памяти. Наконец, если ничего не помогает, мы знаем, что можем запустить процесс восстановления, который вернет файловую систему в согласованное состояние. Приятно осознавать, что все менеджеры метаданных могут остановиться и загореться, а мы все равно можем восстановить систему хранения, поскольку все метаданные файлов постоянно находятся на самих узлах хранения.

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

Мы измерили производительность метаданных с помощью приложения Metarates [Metarates]. Это приложение MPI, которое координирует доступ к файловой системе со стороны нескольких клиентов. На рис. 11 показана производительность Create и Utime для пятнадцати клиентов Xeon с частотой 2,4 ГГц по сравнению с одним модулем DirectorBlade. Операция Create создает пустой файл, и каждый клиент работает в своем собственном каталоге. Операция Utime устанавливает атрибуты отметки времени в файле. Результаты представлены для протокола Panasas DirectFLOW (DF) и протокола NFS, который использует клиент шлюза в модуле DirectorBlade.

Рис. 11. Пропускная способность Metarates (операций в секунду).

Были измерены две разные модели DirectorBlade: DB100 и DB100a. Был также измерен сервер NFS под управлением Linux с локально подключенным RAID-массивом.

Протокол Panasas работает лучше в Utime, чем NFS, из-за способа управления атрибутами на клиентах. Клиент Panasas может надежно кэшировать атрибуты благодаря протоколу обратного вызова от менеджеров метаданных Panasas с отслеживанием состояния. Клиентам NFS необходимо повторно проверить свой кэш с помощью операции GetAttr, прежде чем они смогут завершить SetAttr, поэтому они выполняют в два раза больше серверных операций для завершения операции Utime, и, следовательно, пропускная способность клиента снижается.

В тесте Linux NFS файловый сервер выполняет синхронную запись на диск во время операций CREATE и SETATTR, как того требует пункт стабильного хранилища стандарта NFSv3 [Pawlowski94], с явным влиянием на производительность. В системе Panasas записи буферизуются в защищенной памяти модулей StorageBlade. Обновления передаются в виде журнала, а время работы не связано с дисковым вводом-выводом. Наш алгоритм создания очень надежен: записи журнала размещаются в двух модулях DirectorBlade, а объекты создаются в двух модулях StorageBlade до того, как операция возвращается клиенту. Задержка для одного создания составляет около 2 мс.

Некоторые серверы NFS оптимизируют процесс Create, регистрируя их в NVRAM и немедленно возвращая данные. В системе Panasas этого не делается, поскольку клиенты должны иметь возможность осуществлять запись непосредственно в узлы хранения после того, как операция Create возвращается из менеджера метаданных. Хотя рассматривалось предоставление клиентам возможности создания в качестве оптимизации, удалось избежать дополнительную сложность, которую это добавляет к протоколу. Менеджер метаданных Panasas создает объекты в хранилище перед возвратом клиенту.

На рис. 12 показана производительность Create и Utime по мере увеличения числа клиентов. Эти операции включают операции ввода-вывода для модулей StorageBlade. Create выполняет два создания объекта и две записи в родительский каталог. Utime устанавливает атрибуты для двух объектов. DirectorBlade и полка соответствуют «DB-100» на первой диаграмме. Модуль DirectorBlade с частотой 2,4 ГГц приближается к насыщению со скоростью 840 созданий/сек и 2000 времени использования/сек с 15 клиентами.

Рис. 12. Metarates Create и Utime ops/sec.

На рис. 13 показана производительность Stat. В тесте один клиент создает все файлы, а затем все клиенты выполняют свои операции статистики. Первый клиент всегда обращается к своему кэшу и, следовательно, получает 45 000 операций статистики в секунду. Остальные клиенты получают от 1200 до 2000 операций в секунду, поскольку их операции включают в себя двусторонний обход сервера. На графике показана «совокупная пропускная способность» Metarates, которая получается путем умножения самого медленного клиента на общее количество клиентов. Этот показатель может показаться несправедливым, но он отражает эффективную пропускную способность для приложений MPI с барьерной синхронизацией. Например, из двух клиентов один работал со скоростью 1777 операций в секунду, а другой — со скоростью 45 288 операций в секунду, а совокупная скорость составляет 3554 операции в секунду.

Рис. 13. Metarates Stat ops/sec.

Метаданные системного уровня

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

Каждый системный менеджер поддерживает локальную базу данных вне системы хранения объектов. Была использована Berkeley DB для хранения таблиц, представляющих системную модель. Различные экземпляры системного менеджера являются членами набора репликации, который использует протокол частичного парламента Лампорта (PTP) для принятия решений и обновления информации о конфигурации. Кластеры настраиваются с одним, тремя или пятью системными администраторами, так что кворум голосования имеет нечетное число, а сетевой раздел приводит к отключению меньшинства системных менеджеров.

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

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

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

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

Была измерена простая транзакция PTP, которая обновляет запись в базе данных конфигурации, с помощью простой тестовой программы, выполняющей 1000 таких операций. Стоимость обновления, включающая RPC для системного менеджера, раунд голосования PTP и обновление BDB для одной таблицы, составляет около 7 мс для наших модулей DirectorBlade с частотой 2,4 ГГц. В этих затратах преобладает синхронная запись на диск при обновлении BDB. Была включена синхронная запись на диск, несмотря на ИБП, чтобы база данных конфигурации системы была высоконадежной. Стоимость удваивается до 14 мс при наличии набора репликации из 2, 3, 4 или 5 участников из-за дополнительного обновления таблицы, выполняемого реализацией PTP. Президент кворума PTP выполняет RPC параллельно с членами кворума, поэтому при таких масштабах репликации нет разницы в производительности между двумя или пятью членами набора репликации.

Следует обратить внимание, что существует разница в два или три порядка между журналированием, выполняемым менеджером метаданных файловой системы, и транзакцией голосования, выполняемой менеджером кластера. Обновление журнала в памяти составляет 3 микросекунды или 90 микросекунд, чтобы отразить это во всей сети. Цикл голосования PTP и обновление базы данных BDB занимают от 7 до 14 миллисекунд. Эти различные механизмы позволяют нам иметь очень надежную систему управления кластером и очень высокопроизводительную файловую систему.

Связанные разработки (на момент 2008 г. [4])

Основными файловыми системами, которые используются в высокопроизводительных вычислительных кластерах, являются файловые системы Panasas, Lustre, GPFS и PVFS2. Lustre имеет общую архитектуру, аналогичную Panasas. Lustre использует относительно большие серверы хранения объектов (ОSS-серверы и хранилища объектов OST) и могут использовать простое чередование по OST, но без балансировки активной мощности или дополнительной информации о четности. PVS2 также выполняет простое чередование между узлами хранения без избыточности. GPFS и Lustre полагаются на блочные RAID-контроллеры для обработки сбоев дисков, тогда как PVS2 обычно использует локальные файловые системы на вычислительных узлах.

Кластерные системы NFS включают Isilon, NetApp GX и PolyServe. Эти системы NFS имеют ограниченную масштабируемость, поскольку каждый клиент должен направлять свои запросы через одну точку доступа, которая затем пересылает запросы узлам, владеющим данными. Параллельное расширение NFS, которое станет частью NFSv4.1, может помочь этим системам преодолеть это ограничение. Экспорт Panasas NFS из модулей DirectorBlade имеет характеристики, аналогичные этим системам.

Файловые системы SAN (например, CXFS, [IBRIX], MPSFi, Oracle OCFS2, GFS2, ADIC StorNext) имеют нестандартные клиенты, узел менеджера метаданных и блочно-ориентированы. Они произошли от файловых систем с одним хостом за счет внедрения диспетчера блоков или сервера метаданных. Управление блоками обычно является пределом масштабируемости, поскольку менеджеру метаданных приходится отслеживать миллиарды блоков в системе любого размера.

GPFS также является файловой системой SAN, но ее схема распределенного управления блокировками и использование больших блоков (от 256 КБ до 4 МБ) помогают масштабировать ее для поддержки более крупных кластеров. GPFS использует централизованный менеджер токенов, который делегирует детальные блокировки блоков, индексных дескрипторов, атрибутов и записей каталога. Делегирование блокировки позволяет первому клиенту, получившему доступ к ресурсу, стать для него менеджером блокировки, что распределяет нагрузку по управлению метаданными. Однако существуют рабочие нагрузки, которые приводят к значительному объему трафика между владельцами блокировок и менеджером токенов, когда система согласовывает владение блокировками. Узлы могут быть как клиентами, так и серверами, хотя в больших системах обычно имеется большее количество узлов, предназначенных только для клиентов, и подмножество узлов, управляющих хранилищем. Службы отказоустойчивы благодаря протоколам аварийного переключения и двухпортовому портированию дисков.

Существует несколько исследовательских проектов, изучающих хранилище объектов, включая Ceph и Usra Minor. Эти системы имеют немного разную семантику объектов и собственные протоколы. Usra Minor предоставляет управление версиями как основное свойство своих объектов. Ceph использует схему распределения на основе хэша, а его объектные серверы распространяют реплики друг другу (т.е. имеется избыточность, но нет чередования). Lustre использует протокол распределенного менеджера блокировок, в котором клиенты, ОСС и менеджер метаданных — все участвуют. Объектная модель Panasas основана на стандартном наборе команд iSCSI/OSD, который, как ожидается, станет частью обычных устройств хранения данных следующего поколения.

Распределение серверов данных для увеличения пропускной способности оценивалось в нескольких исследовательских системах. В файловой системе Zebra клиенты генерировали поток данных, содержащий журнал их записей во многие файлы. Этот поток журналов был распределен по серверам, и был создан компонент четности, позволяющий выполнить восстановление. Этот подход объединяет информацию о четности для всех файлов в журнале, что не позволяет настраивать конфигурации RAID для каждого файла. Параллельная файловая система Cheops была наложена на NASD и обеспечивала пофайловое чередование, но не пофайловый RAID. Isilon распределяет файлы по своим узлам хранения и использует RAID и кодирование Рида-Соломана для защиты от потери объектов. Однако производительность Isilon ограничена интерфейсом NFS. Система RAIF отображает файл в несколько файловых систем и позволяет чередование. Это выполняется стекируемой файловой системой на клиенте. Однако не описывается, как обрабатывать обновления общих файлов несколькими клиентами. Lustre использует простое чередование RAID0 по серверам объектного хранения и зависит от RAID внутри сервера для восстановления после сбоев дисков, а также отработки отказа и двухпортовых дисков между серверами для обработки сбоев сервера. Последние версии NetApp-GX могут распределять файлы и тома по узлам хранения. Он также предоставляет средства для миграции (т.е. копирования) наборов файлов между серверами для смещения нагрузки, а также имеет возможность настраивать реплики тома, доступные только для чтения, для распределения нагрузки — функции, аналогичные тем, которые представлены в AFS. Подход Panasas к чередованию специально разработан для обеспечения производительности, которая масштабируется для поддержки очень больших систем с тысячами активных клиентов, совместно использующих один и тот же набор файлов.

Google FS — это файловая система пользовательского уровня, реализованная в библиотеках для конкретных приложений. Google FS использует репликацию для обеспечения отказоустойчивости, поэтому она может допустить потерю узла хранения. Клиенты отвечают за отправку данных в реплики, а затем за уведомление менеджера метаданных о завершении обновлений. Google FS предоставляет семантику добавления для конкретного приложения для поддержки одновременных обновлений. Panasas имеет полностью сериализованные обновления для обеспечения семантики POSIX и еще один режим параллельной записи, который оптимизирует чередующиеся, пошаговые шаблоны записи в один файл от множества одновременно работающих клиентов.

Из этих систем только Panasas, Isilon, Google и Ceph используют избыточные данные на разных узлах хранения для восстановления после сбоев дисков. В других системах используются RAID-контроллеры или программный RAID внутри узла хранения, либо вообще отсутствует избыточность. Другим отличием является разделение управления метаданными между узлами. Panasas разделяет владение по деревьям файлов, что позволяет нескольким менеджерам метаданных управлять всей системой. Большинство других систем имеют единый менеджер метаданных, включая Lustre, IBRIX и другие файловые системы SAN. GPFS имеет гибридную схему с одним менеджером токенов, который может делегировать ответственность за метаданные. Ceph использует детальную схему хеширования для распределения владения метаданными.

Пример развертывания референсной архитектуры Panasas и NVIDIA

Эталонная архитектура Panasas + NVIDIA HPC предоставляет проект для вычислительных кластеров на базе NVIDIA Spectrum Ethernet и NVIDIA Quantum InfiniBand, полнофункциональную конфигурацию систем хранения Panasas ActiveStor Ultra, сетевые соединения, межсоединения, программное обеспечение и компоненты управления, которые интегрированы, протестированы и поддерживаются [3].

Эталонная архитектура HPC Panasas + NVIDIA предназначена для удовлетворения потребностей современных высокопроизводительных вычислений, от небольших рабочих групп до крупнейших суперкомпьютерных кластеров, а также для основных, удаленных и периферийных центров обработки данных. Используя сетевую инфраструктуру NVIDIA, клиентские вычислительные узлы на базе CPU и GPU могут получить доступ к решению хранения данных Panasas ActiveStor с помощью драйвера клиента Panasas DirectFlow® через NVIDIA Spectrum™ Ethernet и фабрики на базе Quantum InfiniBand® (IB) или протоколы NFS и SMB/CIFS.

Эталонная архитектура HPC (рис. 14), предназначена для вычислительного кластера на базе Ethernet. Базовые компоненты этой архитектуры включают узлы Panasas ActiveStor Director и Storage, драйверы Panasas DirectFlow Client на вычислительных серверах Linux, Ethernet-коммутаторы NVIDIA Spectrum™ и межсоединения NVIDIA.

Рис. 14. Эталонная HPCархитектура Panasas + NVIDIA для вычислительного кластера на базе Ethernet.

Эталонная архитектура HPC расширена для вычислительного кластера на базе NVIDIA Quantum InfiniBand (рис. 15). Дополнительные базовые компоненты включают переключатели NVIDIA Quantum и Panasas ActiveStor ASR-400.

Рис. 15. Эталонная HPC-архитектура Panasas + NVIDIA для вычислительного кластера на базе NVIDIA Quantum InfiniBand.

Эталонный проект Ethernet

Компоненты, использованные в эталонном проекте полной стойки с использованием модулей Panasas ActiveStor Director и Panasas ActiveStor Ultra с вычислительным кластером NVIDIA Spectrum на базе Ethernet, описаны в табл. 3.

Табл. 3. Компоненты эталонного проекта полной стойки с использованием модулей Panasas ActiveStor Director и Panasas ActiveStor Ultra с вычислительным кластером NVIDIA Spectrum на базе Ethernet.

Полная стойка из восьми корпусов хранения данных Panasas ActiveStor Ultra обеспечивает емкость хранения от 890 ТБ до 3,32 ПБ для хранения необработанных данных и 61,4 ТБ для хранения метаданных.

Топология сети эталонного дизайна для полной стойки (рис. 16) демонстрирует сетевую топологию без единой точки отказа для установки Panasas + NVIDIA HPC ActiveStor Ultra для полной стойки.

Рис. 16. Сетевой дизайн для Full Rack Panasas + NVIDIA HPC ActiveStor Ultra.

Заключение

Рынок HPC растет со среднегодовым темпом 5,5% и, по прогнозам, к 2030 году превысит $64,66 млрд (https://www.globenewswire.com/en/news–release/2022/04/04/2415844/0/en/High–Performance–Computing–Market–Size–to–Surpass–USD-64-65-Bn–by-2030.html). Конвергенция корпоративных и высокопроизводительных вычислений обусловлена отраслями, где решение сложных задач в режиме реального времени является одновременно необходимостью и конкурентным преимуществом. Другие области применения систем HPC включают сокращение циклов разработки продуктов и запуск промышленных приложений с интенсивным использованием данных для конкретных рабочих нагрузок и проектов. В любом случае упрощение сложных сред данных HPC и искусственного интеллекта с помощью простого, надежного и гибкого решения для хранения данных HPC предоставляет этим предприятиям уникальную возможность оставаться на шаг впереди.

Однако, несмотря на важность конвергенции HPC и AI-приложений, часто эти проекты терпят неудачу при масштабировании. IDC сообщила, что, хотя значение ИИ для предприятий растет, большинство проектов ИИ терпят неудачу из-за неадекватной или нецелевой инфраструктуры (https://www.idc.com/getdoc.jsp?containerId=prUS48870422).

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

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

Источники, доп. ресурсы

[1]  Only Panasas Mitigates the Full Range of HPC Storage Operational Challenges. Bob Murphy | May 7, 2020 – https://www.panasas.com/blog/only-panasas-mitigates-the-full-range-of-hpc-storage-operational-challenges/.

[2]  Panasas Pushes HPC Storage to the Edge with New ActiveStor Ultra Edge Platform. May 22, 2023 – https://www.panasas.com/press/panasas-pushes-hpc-storage-to-the-edge-with-new-activestor-ultra-edge-platform/.

[3]  HPC Reference Architecture. White Paper. Curtis Anderson, Panasas; Mark Thomson, Panasas; Richio Aikawa, Panasas; Jeff Shao, NVIDIA; Reggie Reynolds, NVIDIA. May 2023 – https://www.panasas.com/resources/whitepapers/panasas-nvidia-hpc-reference-architecture/.

[4]  Scalable Performance of the Panasas Parallel File System, Brent Welch, Marc Unangst, Zainul Abbasi, Garth Gibson, Brian Mueller, Jason Small, Jim Zelenka, Bin Zhou. February 2629, 2008. 6-th USENIX Conference on File and Storage Technolo gies – https://www.usenix.org/conference/fast-08/scalable-performance-panasas-parallel-file-system.

[5]  The PanFS Data Engine Architecture. WHITE PAPER – https://www.panasas.com/resources/whitepapers/panfs-9-architectural-white-paper/.

[6]  Object Storage Technology – https://www.snia.org/educational-library/object-storage-technology-2013.

Авторы: Гантимуров А.П., Калашник А.Г.

Отслеживать