Современные распределенные объектные/файловые/блочные и key-value хранилища – WEKA (часть 4)

Введение

В исследовании Gartner – Magic Quadrant for Distributed File Systems and Object Storage (Published 19 October 2022 – ID G00760026) WEKA была признана среди лучших по “видению” рынка [1]. В апреле 2023 г. Weka был признана «Выбором клиентов» в 2023 г. в отчете Gartner^® Peer Insights™ Voice of the Customer: Distributed File Systems and Object Storage [2].

WEKA была основана на идее о том, что современные решения для хранения обеспечивают лишь постепенные улучшения по сравнению с устаревшими конструкциями, что позволяет увеличить разрыв между производительностью вычислений и производительностью хранения данных. Хранилище остается узким местом для производительности приложений, а с продолжающейся плотностью вычислений в таких областях, как приложения на основе графических процессоров, это стало еще более проблематичным. На современном гиперконкурентном рынке организациям нужна гибкая инфраструктура; рабочие нагрузки приложений становятся все более сложными, а наборы данных продолжают беспрепятственно расти, что вынуждает предприятия создавать чрезмерно сложные и дорогостоящие системы, снижающие гибкость ИТ. В результате важные бизнес-идеи остаются заблокированными, вне досягаемости лиц, принимающих решения [3].

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

Компания WEKA создала исключительно программное, высокопроизводительное файловое решение для хранения данных, которое отличается высокой масштабируемостью и простотой в развертывании, настройке, управлении и расширении. Философия проектирования файловой системы Weka (WEKA™) заключалась в создании единой архитектуры хранения, которая работает локально или в общедоступном облаке с производительностью массивов на флэш-дисках, простотой и набором функций сетевых хранилищ (NAS), а также масштабируемость и экономичность облака.

Основные характеристики WEKA (рис. 1):

• cамая быстрая в мире файловая система с общим доступом, подтвержденная тестами SPEC SFS 2014 (https://www.weka.io/pressreleases/wekaio-matrix-cements-storage-leadership-groundbreaking-performance-latency-results-spec-sfs-2014/), SPEC Storage 2020 (https://www.spec.org/storage2020/results), IO500 (https://www.weka.io/press-releases/wekaio- places-first-on-io-500-challenge) и STAC (https://www.weka.io/blog/weka-hpe-and-kx-systems-set-17-new-stac-m3-records);
• поддержка bare-metal, контейнерных, виртуальных и облачных (локальных, гибридных, общедоступных) сред;
• возможность развертывания в качестве конвергентной платформы, выделенного устройства хранения или устройства, встроенного в облако;
• гибкий доступ к хранилищу приложений, включая хранилище POSIX, NFS, SMB, S3 и NVIDIA^® GPUDirect^® ;
• настройка нулевой производительности (Zero performance) для одновременной поддержки маленьких и больших файлов со смешанными шаблонами произвольного и последовательного ввода-вывода;
• ввод-вывод 4K на уровне приложений, стабильная задержка менее 250 микросекунд в высокоскоростных сетях, неограниченная производительность случайных операций ввода-вывода — линейное масштабирование в соответствии с размером кластера;
• встроенное автоматизированное многоуровневое распределение для расширения пространства имен от быстрой флэш-памяти до объектного хранилища как локально, так и в облаке;
• надежные функции безопасности, включая шифрование (в состоянии покоя и во время передачи), аутентификация, управление ключами, LDAP;
• полностью распределенные данные и метаданные, чтобы гарантировать отсутствие горячих точек в кластере хранения;
• распределенная отказоустойчивость, которая устраняет узкие места традиционной встроенной защиты данных;
• полная облачная интеграция с облачным разрывом для модели гибридного облака или 100% общедоступного облака;
• доступность в основных облачных гиперскалярах, таких как AWS, GCP, OCI и Azure;
• локальные моментальные снимки и привязка к объекту для резервного копирования, архивирования и аварийного восстановления;
• клонирование файловой системы для быстрой разработки и тестирования рабочих процессов;
• бесперебойные обновления для служб хранения;
• управление через Full GUI, интерфейс командной строки и API.

Рис. 1. Обзор преимуществ WEKA.

Общие проблемы с системами хранения в эпоху облачных вычислений

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

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

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

Проектирование унифицированного решения для хранения данных эпохи облачных вычислений

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

Ограничения, созданные устаревшими проектными ограничениями, побудили основателей WEKA разработать совершенно новую файловую систему, которая обеспечивает производительность массивов на флэш-дисках, простоту масштабируемого NAS и масштабируемость облака в единой архитектуре (рис. 2).

Рис. 2. Подход к проектированию файловой системы WEKA.

Файловая система WEKA, WEKA™, представляет собой чисто программное решение для хранения с простой конструкцией, которое решает проблемы, связанные с традиционными системами хранения. Она работает на любом стандартном серверном оборудовании на базе процессоров AMD или Intel x86 с обычными твердотельными дисками NVMe (SSD), что устраняет необходимость в специализированном оборудовании. Этот подход позволяет воспользоваться преимуществами технологических улучшений без необходимости полной модернизации до архитектуры следующего поколения, включая развертывание в общедоступном облаке.

WEKA — хранение без компромиссов

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

• искусственный интеллект (ИИ) и машинное обучение (МО), включая AIOps и MLOps;
• науки о жизни, включая геномику, крио-ЭМ, фармакометрию (NONMEM, PsN);
• финансовая торговля, включая тестирование на истории, анализ временных рядов и управление рисками;
• поддержка инженерной методологии DevOps;
• электронный дизайн и автоматизация (EDA, Electronic Designand Automation);
• медиа-рендеринг и визуальные эффекты (VFX, visual effects);
• высокопроизводительные вычисления (HPC);
• ускорение GPU-конвейеров.

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

WEKA — это полностью распределенная параллельная файловая система, которая была полностью написана с нуля для обеспечения высочайшей производительности файловых служб за счет использования флэш-памяти NVMe. ПО также включает в себя интегрированную многоуровневую структуру, которая плавно расширяет пространство имен в хранилище объектов на жестком диске (HDD) и обратно без необходимости использования специального ПО для переноса данных или сложных сценариев; все данные находятся в одном пространстве имен для легкого доступа и управления. Интуитивно понятный графический пользовательский интерфейс позволяет одному администратору быстро и легко управлять эксабайтами данных без специального обучения системам хранения.

Уникальная архитектура WEKA, показанная на рис. 3, радикально отличается от устаревших систем хранения, устройств и программно-определяемых хранилищ на основе гипервизора, поскольку она не только преодолевает традиционные ограничения масштабирования хранилища и совместного использования файлов, но и обеспечивает параллельный доступ к файлам через POSIX, NFS, SMB, S3 и GPUDirect Storage. Он предоставляет богатый набор корпоративных функций, включая локальные моментальные снимки и удаленные моментальные снимки в облаке, клоны, автоматическое распределение по уровням, разрыв в облаке, динамическую перебалансировку кластера, мультиарендность частного облака, резервное копирование, шифрование, аутентификацию, управление ключами, группы пользователей, квоты, с рекомендательными, мягкими и жесткими параметрами и многое другое.

Преимущества WEKA:

• высочайшая производительность во всех профилях ввода-вывода — идеально подходит для смешанных рабочих нагрузок с небольшими и большими файлами;
• масштабируемая емкость — начните с 15 ТБ и масштабируйте до сотен петабайт в одном пространстве имен;
• надежная защита — защита данных от угроз или злоумышленников с помощью шифрования и аутентификации;
• гибридное облако — доступ ко всем основным поставщикам облачных услуг для обеспечения гибкости вычислений или работы в облаке;
• резервное копирование — отправляйте резервные копии прямо в частное или общедоступное облако для длительного хранения;
• лучшая экономичность — сочетание флэш-памяти и диска для оптимальной стоимости в любом масштабе.

Рис. 3. WEKA объединяет флэш-память NVMe с облачным хранилищем объектов в одном глобальном пространстве имен.

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

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

Большинство устаревших параллельных файловых систем накладывают программное обеспечение для управления файлами поверх блочного хранилища, создавая многоуровневую архитектуру, которая влияет на производительность. WEKA — это распределенная параллельная файловая система, которая устраняет традиционный уровень блочных томов, управляющий базовыми ресурсами хранения. Эта интегрированная архитектура не имеет ограничений, присущих другим решениям для хранения данных с общим доступом, и обеспечивает эффективную масштабируемость и производительность. На рис. 4 ниже представлен обзор архитектуры программного обеспечения от прикладного уровня до уровня физического постоянного носителя. Основные компоненты WEKA, включая единое пространство имен WEKA и другие функции, такие как виртуальные серверы метаданных (MDS), выполняются в пользовательском пространстве в контейнере Linux (LXC), что эффективно устраняет разделение времени и другие зависимости, зависящие от ядра. Заметным исключением является драйвер ядра WEKA Virtual File System (VFS), который обеспечивает интерфейс файловой системы POSIX для приложений. Использование драйвера ядра обеспечивает значительно более высокую производительность, чем та, которая может быть достигнута с помощью драйвера пользовательского пространства FUSE, и позволяет запускать приложения, требующие полной совместимости с POSIX, в общей системе хранения.

Рис. 4. Архитектура программного хранилища WEKA.

WEKA поддерживает все основные дистрибутивы Linux и использует методы виртуализации и низкоуровневых контейнеров Linux для запуска собственной RTOS (Real-Time Operating System – операционной системы реального времени) в пользовательском пространстве вместе с исходным ядром Linux. WEKA управляет выделенными ресурсами (ядрами ЦП, областями памяти, сетевыми картами и твердотельными накопителями), чтобы обеспечить планирование процессов, управление памятью, а также контролировать ввод-вывод и сетевые стеки. Не полагаясь на ядро Linux, WEKA сводит к минимуму переключение контекста, что приводит к более короткому пути ввода-вывода и предсказуемым низким задержкам. Также есть возможность обновлять серверные службы хранения WEKA независимо от ОС Linux и обновлений клиентского (интерфейсного) клиента WEKA.

Функциональность WEKA, работающая в ее RTOS (рис. 4), состоит из следующих программных компонентов:

• файловые службы (Front End) — управление многопротокольным подключением;
• FileSystemComputeandClustering (BackEnd) — управление распределением данных, защитой данных и службами метаданных файловой системы;
• SSDDriveAgent — трансформация SSD в эффективное сетевое устройство;
• ManagementProcess — управление событиями, интерфейсом командной строки, статистикой и call-home возможностью;
• ObjectConnector — чтение и запись в хранилище объектов.

Основное ПО WEKA в RTOS работает внутри контейнеров LXC, преимуществом которых является улучшенная изоляция от других серверных процессов. ПО WEKA при развертывании контейнеризуется в виде микросервисов: на хост может существовать несколько контейнеров для SMB, NFS, S3 и ядра WEKA. Охватывая несколько контейнеров LXC, WEKA обеспечивает еще больший параллелизм и возможность использовать больше ядер ЦП и оперативной памяти, чем один контейнер LXC. Драйвер WEKA VFS позволяет WEKA поддерживать полную семантику POSIX и использовать очереди без блокировки для ввода-вывода для достижения наилучшей производительности при улучшении взаимодействия. Файловая система WEKA POSIX имеет ту же семантику времени выполнения, что и локальная файловая система Linux (например, Ext4, XFS и другие), позволяя приложениям, которые ранее не могли работать в общем хранилище NFS из-за требований блокировки POSIX, файлов MMAP, ограничений производительности, или другие причины. Эти приложения будут иметь значительно улучшенную производительность по сравнению с локальной файловой системой (рис. 14).

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

Потребление ресурсов часто является проблемой для традиционных программных хранилищ, поскольку эти решения либо используют весь сервер, либо совместно используют общие ресурсы с приложениями. Эти дополнительные накладные расходы на программное обеспечение приводят к задержке и крадут драгоценные циклы ЦП. Для сравнения, WEKA использует только ресурсы, выделенные ей внутри своих контейнеров LXC, что означает, что она может потреблять всего одно ядро сервера и небольшой объем оперативной памяти в общей среде (конвергентная архитектура — приложения и программное обеспечение для хранения данных, совместно использующие один и тот же ресурс, сервер или столько же, сколько все ресурсы сервера (выделенного устройства). В обоих случаях используется один и тот же программный стек.

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

С самого начала WEKA разрабатывалась для решения многих проблем, присущих устаревшим горизонтально масштабируемым решениям NAS. Одним из ключевых соображений при проектировании было создание программной платформы, которая могла бы удовлетворить требования различных групп пользователей внутри организации в масштабе или в многопользовательской среде. Самые популярные масштабируемые файловые системы NAS поддерживают структуру единой файловой системы и единого пространства имен, используя каталоги и системы квот для распределения ресурсов и управления разрешениями. Хотя это решение работало в меньшем масштабе, оно усложняло управление при увеличении количества пользователей и/или каталогов. Полная изоляция групп пользователей требует создания новых файловых систем и пространств имен, что затем создает островки физической памяти для управления. Таким образом, WEKA отличается от других масштабируемых NAS-решений тем, что использует концепцию множества файловых систем в глобальном пространстве имен, которые совместно используют одни и те же физические ресурсы. Каждая файловая система имеет свою собственную «персону» и может быть настроена для предоставления собственных политик моментальных снимков, многоуровневого хранения объектов, организаций, управления доступом на основе ролей (RBAC), квот и многого другого. Файловая система WEKA представляет собой логическую конструкцию, и в отличие от других решений емкость файловой системы можно изменять на лету. Подключенные клиенты могут сразу наблюдать изменение размера файловой системы без необходимости приостанавливать ввод-вывод. Как уже упоминалось, у каждой файловой системы есть выбор уровня для хранилища объектов, и, если это многоуровневая файловая система, соотношение уровня горячего (NVMe) и уровня объекта (HDD) также может быть изменено на лету.

Одна файловая система может поддерживать миллиарды каталогов и триллионы файлов, обеспечивая модель масштабируемости, более похожую на хранилища объектов, чем на системы NAS, и масштабирование каталогов без потери производительности. В настоящее время WEKA поддерживает до 1024 файловых систем и до 24 000 снимков в одном кластере.

Ограничения WEKA:

• до 6,4 трлн файлов или каталогов;
• до 14 эксабайт управляемой емкости в глобальном пространстве имен;
• до 6,4 миллиарда файлов в каталоге;
• до 4 петабайт для одного файла.

Поддерживаемые протоколы

Клиенты с соответствующими учетными данными и привилегиями могут создавать, изменять и читать данные, используя один из следующих протоколов:

• POSIX;
• NVIDIA^® GPUDirect^® Storage ( GDS );
• NFS (сетевая файловая система) v3 и v1;
• SMB (блок сообщений сервера) v2 и v3;
• S3 (простая служба хранения).

ПРИМЕЧАНИЕ. Многие нетрадиционные приложения и системы данных могут использовать возможности POSIX, которые предоставляет WEKA, поскольку он выглядит как локальное монтирование. Одним из примеров этого является HDFS (распределенная файловая система Hadoop). Коннектор Weka POSIX может напрямую подключаться к узлам Hadoop, обеспечивая очень высокую производительность.

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

Серверы хранения WEKA

Серверы хранения WEKA создаются путем установки WEKA на любое стандартное оборудование на базе масштабируемого процессора AMD EPYC^™ или Intel Xeon^™ с соответствующей памятью, процессором ЦП, сетью и твердотельными накопителями NVMe. Для создания кластера, способного выдержать отказ двух серверов, требуется конфигурация из 6 серверов хранения. WEKA работала с ведущими поставщиками оборудования, чтобы создать единый part number, который можно использовать для заказа полной системы хранения, включая лицензию на ПО. Дополнительные сведения о конкретных конфигурациях от Cisco, Dell, HPE, Hitachi Vantara, Lenovo, Penguin и Supermicro, а также AWS доступны на вебсайтах этих поставщиков.

Для всех других платформ каждый хост должен соответствовать следующей минимальной спецификации, приведенной в табл. 1 и 2.

Табл. 1. Минимальные технические характеристики оборудования для масштабируемого сервера на базе процессора Intel.

*WEKA требует архитектуры x8664 с минимум одним процессором с тактовой частотой 2,2 ГГц и 12 ядрами.

Табл. 2. Минимальные технические характеристики оборудования для масштабируемого сервера на базе процессора AMD EPYC^™.

ПРИМЕЧАНИЕ.  Для достижения производительности, указанной в последующих разделах, потребуются сетевые адаптеры 100 Гбит/с или выше.

Интегрированные уровни флэш-памяти и диска для гибридного хранилища

Структура хранилища WEKA состоит из двух отдельных уровней: уровня флэш-памяти на основе NVMe SSD, который обеспечивает высокопроизводительные файловые службы для приложений, и дополнительного уровня хранилища объектов, совместимого с S3, который управляет долгосрочным озером данных (см. рис. 3). Два уровня могут быть физически разделены, но логически служить одним расширенным пространством имен для приложений. WEKA расширяет пространство имен от уровня флэш-памяти NVMe до хранилища объектов, представляя единое глобальное пространство имен, масштабируемое до эксабайтов. Хранилище объектов может быть от любого поставщика, совместимого с S3 API, для локального развертывания или общедоступного облака. Для WEKA требуется только наличие корзины S3, поэтому существующее хранилище объектов можно использовать совместно с WEKA для расширения пространства имен, при этом поддерживая другие приложения в отдельных корзинах. WekaFS использует компоненты возможности хранилища объектов, чтобы обеспечить разрыв в облаке, резервное копирование в облако, аварийное восстановление в другом кластере WekaFS или клонирование файловой системы.

Сеть

Система WEKA поддерживает следующие типы сетевых технологий:

• InfiniBand (IB) HDR и EDR;
• Ethernet — минимум 10 Гбит, рекомендуется 100 Гбит и выше.

Доступная сетевая инфраструктура клиента диктует выбор между ними, поскольку WEKA обеспечивает сравнимую производительность в любой из них. Для работы в сети система WEKA использует не стандартные службы TCP/IP на основе ядра, а собственный сетевой стек, основанный на следующем:

• использование DPDK для отображения сетевого устройства в пользовательском пространстве и использования сетевого устройства без каких-либо переключений контекста и без копирования данных между ядрами. Этот обход стека ядра устраняет потребление ресурсов ядра для сетевых операций и может масштабироваться для работы на нескольких хостах. Он применяется как к внутренним, так и к клиентским хостам и позволяет системе WEKA полностью насыщать до нескольких 200 гигабитных каналов Ethernet или InfiniBand;
• реализация собственного протокола WEKA через UDP, т.е. базовая сеть может включать маршрутизацию между подсетями или любой другой сетевой инфраструктурой, поддерживающей UDP. Клиенты могут находиться в разных подсетях, если они маршрутизируются для доступа к узлам хранения.

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

Для устаревших систем, в которых отсутствует поддержка SRIOV (виртуализация ввода-вывода с одним корнем) и DPDK, WEKA по умолчанию использует обработку в ядре и UDP в качестве транспортного протокола. Этот режим работы обычно называют «режимом UDP» и обычно используется со старым оборудованием, таким как сетевые адаптеры семейства Mellanox CX3.

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

Для сред с поддержкой RDMA, которые распространены в вычислениях с ускорением на GPU, WEKA поддерживает RDMA для InfiniBand и Ethernet, чтобы обеспечить высокую производительность без необходимости выделения ядер для интерфейсных процессов WEKA.

Клиенты приложений подключаются к кластеру хранения WEKA через соединения Ethernet или InfiniBand. Программное обеспечение WEKA поддерживает сети 10GbE, 25GbE, 40GbE, 50GbE, 100GbE, 200GbE Ethernet, а также сети EDR и 200Gb HDR InfiniBand. Для достижения максимальной производительности WEKA рекомендует использовать сетевые каналы со скоростью не менее 100 Гбит/с.

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

WEKA поддерживает сеть VMXNET3 от VMware. Когда клиент WEKA развертывается внутри гостевой ОС в гипервизоре VMware ESX, это гарантирует, что при выполнении vMotion с одного сервера ESX на другой клиент WEKA продолжит оставаться подключенным к хранилищу WEKA.

Список поддерживаемых сетевых карт, которые работают с WEKA, доступен по адресу https://docs.weka.io/support/prerequisites–and–compatibility#networking.

Высокая доступность сети (HA)

WEKA поддерживает сеть высокой доступности (HA), чтобы обеспечить непрерывную работу в случае отказа сетевой карты (NIC) или сетевого коммутатора. HA выполняет аварийное переключение и восстановление после отказа для обеспечения надежности и балансировки нагрузки на обоих интерфейсах и работает как для Ethernet, так и для InfiniBand. Для обеспечения высокой доступности система WEKA должна быть настроена таким образом, чтобы ни один компонент не представлял собой единую точку отказа. Требуется несколько коммутаторов, и хосты должны иметь подключение к каждому коммутатору. Высокая доступность для клиентов достигается за счет реализации двух сетевых интерфейсов на одном клиенте. WEKA также поддерживает протокол управления агрегацией каналов (LACP, Link Aggregation Control Protocol) на вычислительных клиентах в сети Ethernet (режимы 1 и 4) для одного двух-портового сетевого адаптера. Кроме того, WEKA поддерживает аварийное переключение Infiniband на Ethernet в кластере хранения для обеспечения высокой доступности в случае отказа сети Infiniband. Это аварийное переключение не применяется к клиентам, которые часто находятся в сети того или иного типа.

WEKA может легко заполнить полосу пропускания одной сетевой карты (NIC). Для более высокой пропускной способности можно использовать несколько сетевых карт. Использование подхода без LACP устанавливает избыточность, которая позволяет программному обеспечению WEKA использовать два интерфейса для высокой доступности и пропускной способности соответственно.

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

ПРИМЕЧАНИЕ. В отличие от реализаций RoCE, которые требуют настройки управления потоком на основе приоритетов (PFC) в коммутационной матрице, WEKA не требует настройки сети без потерь для поддержки своей реализации NVMe overfabrics и даже может обеспечить такой уровень производительности с низкой задержкой, в общедоступных облачных сетях.

Протоколы

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

• FullPOSIX для поддержки локальной файловой системы;
• NVIDIA GPUDirect Storage (GDS) для ускорения GPU;
• NFS для Linux;
• SMB для Windows;
• S3 для доступа к объектам.

POSIX

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

Клиент WEKA POSIX обеспечивает высочайшую производительность операций ввода-вывода в секунду, пропускную способность и метаданные при минимальной задержке.

NVIDIA GDS

GPUDirect Storage — это протокол, разработанный NVIDIA для повышения пропускной способности и уменьшения задержки между сетевой картой сервера и памятью графического процессора с использованием RDMA. WEKA полностью поддерживает GDS и была проверена NVIDIA, включая эталонную архитектуру на https://www.weka.io/promo/nvidia–ai–reference–architecture/.

NFS

Протокол NFS позволяет удаленным системам получать доступ к файловой системе WEKA из клиента Linux без клиента WEKA. Хотя эта реализация не обеспечивает производительность POSIX клиента WEKA, она обеспечивает простой способ развертывания и совместного использования данных из кластера хранения WEKA.

В настоящее время WEKA поддерживает NFS v3 и NFS v4.1.

SMB

Протокол SMB позволяет удаленным системам подключаться к общим файловым службам из клиента Windows или macOS. В настоящее время WEKA поддерживает SMB v2.x и v3.x. Протокол обеспечивает масштабируемую, отказоустойчивую и распределенную реализацию SMB, поддерживая широкий спектр возможностей SMB, включая:

• аутентификация пользователя через Active Directory (собственный и смешанный режимы);
• отображение POSIX (uid, gid, rid);
• UNIX-расширение;
• подписание SHA 256;
• расширенное пространство идентификатора;
• динамическое кредитование;
• Durableopens для обработки разъединений;
• поддержка символических ссылок;
• доверенные домены;
• шифрование;
• гостевой доступ;
• скрытые ресурсы (Hidden shares);
• ACL SMB;
• преобразование из Windows в POSIX ACL;
• параметры общего доступа, связанные с безопасностью.

S3

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

• Buckets (HEAD/GET/PUT/DEL);
• Bucket Lifecycle (GET/PUT/DEL);
• Bucket Policy (GET/PUT/DEL);
• Bucket Tagging (GET/PUT/DEL);
• Object (GET/PUT/DEL);
• Object Tagging (GET/PUT/DEL);
• Object Multiparts (POST Create/Complete, GET/PUT/DEL, GET Parts).

Кроме того, реализация WEKA S3 поддерживает многопротокольный доступ, TLS, имеет полные журналы аудита S3 и имеет функции уровня корзины, такие как политики, квоты для корзины и правила истечения срока действия для управления жизненным циклом информации. Дополнительная информация: https://docs.weka.io/additional–protocols/s3.

Интерфейсы управления

GUI

WEKA предоставляет три быстрых и простых способа управления файловой системой WEKA: либо через графический интерфейс пользователя (GUI), либо через интерфейс командной строки (CLI), либо через API передачи состояния репрезентации (REST). Функции отчетности, визуализации и общего управления системой доступны с помощью REST API, интерфейса командной строки или интуитивно понятной консоли управления с графическим интерфейсом (см. рис. 5).

Простота «укажи и щелкни» позволяет пользователям быстро выделять новое хранилище; создавать и расширять файловые системы в глобальном пространстве имен, устанавливать политику многоуровневого хранения, защиту данных, шифрование, аутентификацию, разрешения, конфигурацию NFS, SMB и S3, моментальные снимки только для чтения или для чтения и записи, моментальные снимки для объектов и политики качества обслуживания, а также контролировать общее состояние системы. Подробное ведение журнала событий предоставляет пользователям возможность просматривать системные события и состояние с течением времени или детализировать сведения о событиях с точностью до момента времени с помощью функции построения графика временных рядов (рис. 6).

В меню «Системные события» перечислены события, произошедшие в среде WEKA. События, отображаемые в этом окне, также передаются в облачное хранилище WEKA Support Cloud (WEKA Home; https://home.weka.io), чтобы они могли использоваться службой поддержки WEKA для активной помощи вам в случае необходимости или для заблаговременного уведомления вас, когда необходимо принять меры. Графический пользовательский интерфейс WEKA полностью основан на веб-интерфейсе и автономен, что устраняет необходимость в физической установке и обслуживании каких-либо программных ресурсов, и у вас всегда есть доступ к новейшим функциям консоли управления.

Интерфейс командной строки (CLI)

Все системные функции и услуги WEKA могут быть выполнены с помощью команды CLI. Большинство системных команд WEKA являются общесистемными и дают одинаковый результат на всех узлах кластера. Некоторые команды выполняются на определенных узлах, например, управление IP-адресами.

REST API

Все системные функции и услуги WEKA могут выполняться через API веб-сервиса, который соответствует архитектуре RESTful API. Как и в CLI, большинство команд WEKA RESTful являются общесистемными и дают одинаковые результаты на всех узлах кластера. Некоторые команды выполняются на определенных узлах. API представлен через интерфейс Swagger для простоты использования и примеров кода API на нескольких языках программирования. Пример интерфейса Swagger: https://api.docs.weka.io/.

Рис. 5. Пользовательский интерфейс программного обеспечения WEKA Management.

Рис. 6. Диаграммы временных рядов для мониторинга событий.

Адаптивное кэширование

Приложения, особенно с небольшими файлами и большим количеством вызовов метаданных, значительно выигрывают от локального кэша. Данные доступны с очень низкой задержкой, что снижает нагрузку на общую сеть, а также на самовнутреннее хранилище. Файловая система WEKA предоставляет уникальную расширенную возможность кэширования, называемую адаптивным кэшированием, которая позволяет пользователям в полной мере использовать преимущества производительности кэширования данных Linux (кэш страниц) и кэширования метаданных (кэш dentry), обеспечивая при этом полную согласованность в кластере общего хранилища. NFS v3 не поддерживает когерентность, поэтому использование кэширования Linux может привести к несогласованности данных для кэша чтения и возможному повреждению данных для кэша записи. WEKA поддерживает использование кэша страниц Linux, который обычно зарезервирован для хранилища с прямым подключением (DAS) или файловых служб, работающих в блочном хранилище, в общей сетевой файловой системе, сохраняя при этом полную согласованность данных. Интеллектуальная функция адаптивного кэширования заблаговременно информирует любого клиента, который был монопольным пользователем файла (и, следовательно, работал в режиме локального кэша), о том, что другой клиент теперь имеет доступ к набору данных. После установки этого флага клиент может продолжать работу в режиме локального кэша до тех пор, пока файл не будет изменен другим клиентом. Теперь WEKA аннулирует локальный кэш, гарантируя, что оба клиента получают доступ только к самой последней итерации данных. Это обеспечивает максимальную производительность локального кэша, когда это необходимо, и всегда обеспечивает полную согласованность данных.

WEKA предоставляет те же возможности для кэширования метаданных, также известного как Linux dentry cache. Клиент может использовать локальный кэш метаданных для каталога, что значительно снижает задержку. Однако, как только другой клиент получит доступ к тому же каталогу, WEKA гарантирует, что любые изменения каталога от одного клиента сделают недействительными кэшированные метаданные для всех других клиентов, обращающихся к этому каталогу. Возможности кэширования также включают расширенные атрибуты и списки управления доступом (ACL).

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

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

Глобальное пространство имен и расширение 

WEKA управляет всеми данными в системе как частью глобального пространства имен и поддерживает два уровня постоянного хранения в единой гибридной архитектуре — NVMe SSD для активных данных и объектное хранилище на жестком диске/гибридной флэш-памяти для озера данных. Расширение пространства имен до хранилища объектов является необязательным дополнением к глобальному пространству имен и может быть настроено несколькими щелчками мыши в консоли управления. Файл находится во флэш-памяти, пока он активен или пока он не будет перемещен в объектное хранилище на основе предустановленных или определенных пользователем политик. Когда файл помещается в хранилище объектов, исходный файл хранится на уровне флэш-памяти до тех пор, пока физическое пространство не потребуется для новых данных, и, следовательно, действует как кэшированный файл до тех пор, пока не будет перезаписан. Когда данные файла переводятся на уровень хранилища объектов, метаданные файла всегда остаются локально на уровне флэш-памяти. Таким образом, все файлы доступны для приложений в том же расположении, в которое они были записаны, независимо от размещения по уровням, даже если сегмент хранилища объектов находился в общедоступном облаке (локальный уровень флэш-памяти с облачным уровнем объектов будет страдать от потери производительности из-за подключения к глобальной сети и затрат на вход/выход из облака). По мере того, как емкость флэш-системы NVMe расходуется и использование достигает предельного уровня, данные динамически передаются на уровень объектов, а это означает, что не придется беспокоиться о нехватке емкости на уровне флэш-памяти. Это особенно полезно для приложений, требующих интенсивной записи, поскольку вмешательство администратора не требуется. Уровень флэш-памяти и уровень объектов могут масштабироваться независимо друг от друга в зависимости от требуемой емкости использования.

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

“Тонкое” выделение ресурсов (Thin Provisioning)

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

Обновления без прерывания работы

WEKA имеет возможность обновления без ущерба для клиентов. Поскольку WEKA использует контейнеры и наборы процессов внутри этих контейнеров в качестве своей ОС, WEKA может обновлять контейнеры в непрерывном процессе, не вызывая перемонтирования клиентов. Эта возможность в сочетании с отказоустойчивостью схемы защиты данных WEKA позволяет обновлять WEKA «на лету» с минимальными паузами ввода-вывода во время процесса. Клиенты не нужно размонтировать и перемонтировать в процессе обновления.

Интегрированное многоуровневое управление данными

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

Эта интегрированная возможность устраняет необходимость в дополнительном программном обеспечении для управления иерархическим хранилищем (HSM) или многоуровневого хранения данных, которое усложняет и увеличивает стоимость. Побочным продуктом интегрированных функций управления данными является гибкое унифицированное пространство имен, которое можно масштабировать в соответствии с ограничениями емкости вашего поставщика облачных услуг. Список сертифицированных хранилищ объектов можно найти по адресу: https://docs.weka.io/support/pre–requisites–and–compatibility#object–store.

Рис. 7. Интегрированное распределение по уровням для любого хранилища объектов, совместимого с S3 или Swift.

Не существует жесткого и быстрого правила относительно того, сколько данных должно быть на флэш-памяти NVMe по сравнению с хранилищем объектов, но опрос клиентов WEKA показывает, что типичное распределение сейчас составляет около 20% на флэш-памяти (рис. 7). Хорошим практическим правилом является измерение уровня флэш-памяти таким образом, чтобы он содержал обычные рабочие наборы данных для текущих рабочих нагрузок и имел достаточную емкость для предварительной подготовки новых рабочих нагрузок для достижения максимальной производительности.

Миграция данных в WEKA

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

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

Снимки и клоны

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

• снимки только для чтения;
• чтение/запись снимков;
• удаление основного снимка, сохраняя все остальные версии;
• удаление любого снимка, сохраняя предыдущую и более позднюю версии;
• преобразование моментальных снимков “только для чтения” в снимки с “чтение/запись”;
• привязка к объекту (Snap-to-object).

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

Привязка к объекту

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

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

Результатом использования функции привязки к объекту является то, что хранилище объектов содержит полную копию моментального снимка данных, которую можно использовать для восстановления данных в исходном кластере WEKA или в другом кластере WEKA. Вторичный кластер, который монтирует моментальный снимок WEKA snap-to-object, не обязательно должен быть зеркалом первичной системы. Фактически, основная система может иметь 20 хостов хранения в кластере, а вторая система может иметь 6, 10 или 100. Подойдет любой размер кластера. Это делает его идеальным для разрыва облаков. Следовательно, функция привязки к объекту полезна для целого ряда случаев использования, а именно:

– общие варианты использования (локально и в облаке):

• резервное копирование данных в локальное или облачное хранилище объектов: если слишком много аппаратных компонентов в кластере WEKA выходит из строя без возможности восстановления из-за сбоя системы или внешнего события, такого как пожар, землетрясение, наводнение и т. д., снимок, сохраненный в хранилище объектов, можно использовать для повторного создания тех же данных в другом кластере WEKA или для повторного гидратирования в исходный кластер;
• архивация данных: периодическое создание моментальных снимков данных с последующей загрузкой моментального снимка в хранилище объектов или в облако для создания архивной копии данных. Для этой цели WEKA также может поддерживать «более дешевые и глубокие» сервисы хранилища объектов, такие как мгновенный поиск AWS Glacier;
• асинхронное зеркалирование данных: объединение кластера WEKA с хранилищем реплицированных объектов в другом центре обработки данных создаст зеркало данных, которое можно смонтировать во втором кластере WEKA;

– варианты использования только в облаке:

• пауза и перезапуск общедоступного облака: у различных облачных провайдеров WEKA использует вычислительные экземпляры с локальными твердотельными накопителями для создания кластера. В случае неравномерной работы, связанной с конкретным проектом, пользователи могут захотеть выключить или перевести кластер в спящий режим, чтобы сократить расходы. Моментальный снимок можно сохранить в хранилище объектов и повторно увлажнить при необходимости позже;
• защита от сбоя одной зоны доступности: использование функции привязки к объекту позволяет пользователям восстанавливаться после сбоя зоны доступности (AZ). В случае отказа первой зоны доступности, если моментальный снимок WEKA был реплицирован во вторую зону доступности через хранилище объектов, он может быть восстановлен за считанные минуты с помощью кластера WEKA во вторичной зоне доступности;

– пример использования гибридного облака:

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

Защита данных

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

В WEKA отсутствует концепция локальности данных или метаданных, поскольку все данные и метаданные равномерно распределяются по серверам хранения, что повышает масштабируемость, совокупную производительность и отказоустойчивость. С появлением высокоскоростных сетей локальность данных фактически способствует проблемам с производительностью и надежностью, создавая точки доступа к данным и проблемы с масштабируемостью системы. Непосредственно управляя размещением данных на уровне SSD, WEKA может распределять данные по кластеру хранения для оптимального размещения на основе настраиваемых пользователем размеров полос. WEKA использует передовые алгоритмы для определения расположения данных; размещение данных идеально соответствует размерам блоков, используемых базовой флэш-памятью, что повышает производительность и продлевает срок службы SSD. Размеры полосы могут быть установлены на любое значение от 4 до 16, а четность может быть установлена на +2 или +4. На рис. 8 показано размещение данных на твердотельных накопителях в конфигурации 6+2. Минимальный поддерживаемый размер кластера — 6, что позволяет использовать два полных виртуальных резерва для восстановления из конфигурации 4+2. Чем больше кластер WEKA, тем больший размер полосы он может поддерживать и тем выше эффективность хранения и производительность записи.

Рис. 8. Распределение данных WEKA.

Схема защиты данных WEKA

WEKA управляет защитой, поэтому данные всегда в безопасности и доступны:

• настраиваемые уровни защиты данных от 4+2 до 16+4;
• запатентованная распределенная схема защиты данных;
• настраиваемые домены отказа;
• сквозные (Endtoend) контрольные суммы для целостности данных;
• ведение журнала метаданных;
• локальные снимки и клоны;
• снапшот-объект (Snapshot-to-object) для резервного копирования и аварийного восстановления.

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

Схема защиты данных WEKA следует соглашению о данных (N) + четности (от 2 до 4). Уровень защиты данных N+4 уникален с точки зрения облачного хранилища. Многие облачные службы хранения используют схему тройной репликации для защиты данных. Схема защиты данных WEKA обеспечивает значительно лучшую отказоустойчивость, чем тройная репликация, которая защищает только до 2 сбоев, без влияния на дорогое хранилище и пропускную способность. Уровень защиты N + 2 достаточен для большинства производственных сред, будь то конвергентные кластеры (приложение и хранилище используют один и тот же хост) или выделенные устройства. Уровень защиты N+4 рекомендуется для кластеров с большим количеством (сотнями) объединенных кластерных серверов, поскольку сбои или зависания приложений могут повлиять на доступность серверов.

В дополнение к основной защите данных WEKA рекомендует передовые методы обеспечения доступности, такие как серверы с резервными источниками питания, несколько сетевых карт и коммутаторов для резервирования сети и т.д.

Виртуальный (горячий) резерв

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

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

Распределение данных

WEKA использует запатентованную (United States Patent 9448887 – http://www.freepatentsonline.com/9448887.htm) схему кодирования распределенной защиты данных, которая повышает отказоустойчивость по мере увеличения количества серверов в кластере. Он обеспечивает масштабируемость и надежность затирающего кодирования, но без потери производительности. В отличие от устаревших аппаратных и программных RAID и других схем защиты данных, время восстановления WEKA становится быстрее и более устойчивым по мере масштабирования системы, поскольку каждый сервер в кластере участвует в процессе восстановления.

WEKA равномерно распределяет данные и метаданные по логическим корзинам, которые охватывают домены отказа (FD, failure domains). Доменом отказа может быть отдельный сервер хранения, стойка или даже центр обработки данных. В облачных средах WEKA может охватывать зоны доступности (AZ, availability zones).

В отличие от традиционных аппаратных и программных схем защиты данных, WEKA размещает только один сегмент заданной полосы данных внутри любого одного сервера (или FD), поэтому в случае отказа нескольких дисков на одном сервере это все равно будет считаться единичным отказом, домен. Механизм распределения данных всегда чередует домены отказа. Уровень защиты определяется на уровне FD. WEKA обрабатывает сбои на уровне FD, поэтому отдельные или множественные сбои в пределах FD рассматриваются как одиночный сбой. Полосы данных всегда распределяются по разным хостам серверов, стойкам или зонам доступности в зависимости от выбранной отказоустойчивости. Отказоустойчивость WEKA настраивается пользователем для определения допустимого количества сбоев в кластере WEKA для соответствия требованиям уровня обслуживания рабочей нагрузки приложений. Когда происходит сбой, система считает FD единичным сбоем, независимо от того, насколько большой определен домен. Помимо распределения полос на уровне FD, WEKA также обеспечивает рандомизированное размещение данных для повышения производительности и отказоустойчивости. По мере роста размера кластера вероятность аппаратного сбоя пропорционально возрастает, но WEKA преодолевает эту проблему, распределяя полосы случайным образом. Чем больше серверов, тем выше количество случайных комбинаций страйпов, что снижает вероятность двойного отказа. Пример: для размера страйпа 18 (16+2) и размера кластера 20 количество возможных комбинаций страйпов равно 190, однако по мере увеличения размера кластера до 25 количество возможных комбинаций страйпов теперь составляет 480 700. Количество возможных комбинаций чередования основано на следующей формуле, где C — количество серверов в кластере, а S — размер чередования: C!/(S!*(CS)!).

Перестроение WekaFS (WekaFS Rebuilds)

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

WEKA защищает данные на уровне файлов, поэтому ей нужно восстановить только те данные, которые активно хранятся на вышедшем из строя сервере или SSD. Это означает, что время восстановления меньше по сравнению с традиционным решением RAID или файловым сервером, который защищает данные на блочном уровне. Системы на основе RAID-контроллера обычно перестраивают все блоки на затронутом устройстве хранения (SSD/HDD), включая пустые блоки, продлевая перестроение и время воздействия. WEKA нужно восстановить только определенные данные файла, на которые повлиял сбой. Когда политика многоуровневого хранения объектов (tiering-to-object) применяется с файловой системой, еще одним преимуществом является то, что данные, которые уже были распределены по уровням в хранилище объектов, никогда не пострадают от сбоя сервера, поскольку они защищены в хранилище объектов. Кроме того, любые кэшированные данные (данные, которые были привязаны к объекту, но остаются на уровне флэш-памяти до тех пор, пока не будут признаны недействительными) также не нуждаются в перестроении, что ограничивает приоритет восстановления данными, которые находятся только на уровне флэш-памяти.

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

Power-Fail и сквозная защита данных

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

WEKA предоставляет дополнительные возможности обеспечения целостности данных, защищая от потери данных из-за сбоев питания. Когда запись подтверждается обратно клиенту, она надежно защищена от сбоев сервера или сбоя питания в центре обработки данных благодаря процессу ведения журнала. Инновационная структура данных и алгоритмы WEKA позволяют восстановиться после сбоя питания в центре обработки данных за считанные минуты, поскольку нет необходимости выполнять полную проверку целостности файловой системы (FSCK, file system consistency check). Для большинства других файловых систем время восстановления процесса FSCK пропорционально размеру восстановленной файловой системы. В крупномасштабных развертываниях это восстановление может занять дни или недели.

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

WEKA активно отслеживает и управляет производительностью, отказоустойчивостью и состоянием емкости кластера WEKA. Это позволяет системе рассчитывать уровни использования (производительность и емкость) хостов для автоматического и прозрачного перераспределения данных по кластеру для предотвращения горячих точек.

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

Интеграция контейнерного хранилища

Container Storage Interface (CSI) — это стандарт, разработанный для предоставления и управления общим файловым хранилищем для контейнерных рабочих нагрузок. Плагин WEKA CSI для Kubernetes обеспечивает интерфейс между логическими томами в среде Kubernetes (Persistent Volumes, PV) и хранилищем, позволяя клиентам развертывать клиенты WEKA без сохранения состояния для подключения хранилища к соответствующему контейнеру. Плагин CSI предоставляет том модуля Kubernetes либо через постоянный том (администратором), либо его можно динамически выделить с помощью утверждения постоянного тома (PVC, Persistent Volume Claim). Эта функция упрощает процесс перемещения контейнерных рабочих нагрузок в облако или обмена данными между несколькими кластерами Kubernetes. Плагин CSI также поддерживает использование квот, чтобы помочь управлять потреблением пространства для контейнерных приложений.

Мультитенантные организации

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

Квоты мощности

Существует множество способов, с помощью которых WEKA управляет использованием мощностей в организациях:

• квоты на уровне организации позволяют группам управлять своими файловыми системами и емкостью. WEKA поддерживает до 64 организаций;
• емкость на уровне файловой системы позволяет различным проектам или отделам иметь собственную выделенную емкость. Файловая система WEKA поддерживает до 1024 файловых систем в одном пространстве имен хранилища;
• квоты на уровне каталогов предоставляют квоту для каждого каталога проекта, что полезно, когда имеется много проектов в одной файловой системе. Квоты могут быть установлены на рекомендательном уровне, как жесткие квоты или как мягкие квоты.

Качество обслуживания

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

Аутентификация и контроль доступа

WEKA предоставляет услуги аутентификации на уровне пользователя и на уровне клиент-сервер, чтобы подтвердить, что пользователь или клиент имеет возможность просматривать и получать доступ к данным. WEKA допускает различные режимы аутентифицированного монтирования, такие как “только чтение” или “чтение-запись”, и это определяется на уровне файловой системы.

Аутентифицированные монтирования определяются на уровне организации и шифруются с помощью ключа шифрования. Только клиенты с правильным ключом могут получить доступ к аутентифицированным точкам монтирования. Эта методология повышает безопасность, резко ограничивая доступ к определенным подмножествам организации и ограничивая доступ к клиентам с соответствующим ключом шифрования. WEKA поддерживает следующее:

• LDAP (LightweightDirectoryAccessProtocol, облегченный протокол доступа к каталогам) — сетевой протокол, предоставляющий службы каталогов на различных платформах;
• ActiveDirectory, реализация MicrosoftLDAP, служба каталогов, которая может хранить информацию о сетевых ресурсах. В основном он используется для аутентификации пользователей и групп, которые хотят присоединиться к кластеру.

WEKA также предлагает управление доступом на основе ролей (RBAC, Role-BasedAccessControl), предоставляя пользователям и администраторам различные уровни привилегий. Некоторым пользователям могут быть предоставлены полные права доступа, в то время как другие имеют права только на чтение.

Каждый пользователь системы WEKA имеет одну из следующих определенных ролей:

Администратор кластера: пользователь с дополнительными привилегиями по сравнению с обычными пользователями. К ним от носятся возможности:

• создание новых пользователей;
• удаление существующих пользователей;
• изменение паролей пользователей;
• установление ролей пользователей;
• управление конфигурациями LDAP;
• управление организациями.

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

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

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

• создавать новых пользователей;
• удалять существующих пользователей;
• изменять пароли пользователей;
• устанавливать роли пользователей;
• управлять конфигурацией LDAP организации.

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

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

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

• может войти в систему, чтобы получить токен доступа;
• может изменить свой пароль;
• не может получить доступ к пользовательскому интерфейсу или запустить другую команду CLI/API.

Read-only: пользователь с правами только для чтения.

S3:  пользователь для запуска команд S3 и API. Этот пользователь может работать в рамках привязанной к нему политики S3 IAM.

Шифрование в полете (In-Flight) и в состоянии покоя (At-Rest)

WEKA обеспечивает полное сквозное шифрование от клиента до решения для хранения объектов, что делает ее самой надежной за шифрованной файловой системой из доступных на рынке. Шифрование задается на уровне файловой системы при создании файловой системы, поэтому некоторые файловые системы, которые считаются критическими, могут быть зашифрованы, а другие нет. Когда файлы зашифрованы, это означает, что даже если холодные блоки, лежащие в основе файла, будут отправлены на уровень хранилища объектов, данные останутся зашифрованными. Решение WEKA для шифрования защищает от кражи физических носителей, низкоуровневого взлома прошивки SSD и перехвата пакетов в сети. Данные файла шифруются с помощью ключа шифрования XTSAES, соответствующего стандарту FIPS 1403 уровня 1, с длиной ключа 512 бит.

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

Ротация ключей и управление ключами

WEKA поддерживает любую систему управления ключами (KMS, key management system), которая совместима с KMIP (Key Management Interoperability Protocol, протокол взаимодействия управления ключами) 1.2 и выше, а также собственным API Hashicorp Vault. Кластерные ключи меняются с помощью KMS, ключи файловой системы могут меняться с помощью KMS и повторно шифроваться с помощью нового главного ключа KMS, а файловые ключи могут меняться путем копирования файла.

Данные файла в хранилище объектов также шифруются. При загрузке привязки к объекту в хранилище объектов, помимо других параметров файловой системы, ключ файловой системы включается и шифруется с помощью специального кластерного ключа, «относящегося к резервной копии», который доступен через KMS и используется для всех привязок, резервное копирование и восстановление объектов. Когда WEKA отправляет снимок в хранилище объектов, данные полностью защищены и могут быть аутентифицированы только через систему KMS.

Облачное автоматическое масштабирование

Для облачных приложений автоматическое масштабирование обеспечивает полную гибкость облачной эластичности, позволяя динамически увеличивать или уменьшать ресурсы в зависимости от производительности или требований пользователя. WEKA теперь поддерживает группы автоматического масштабирования EC2 в AWS, чтобы обеспечить автоматическое масштабирование кластера в периоды пиковой нагрузки и автоматическое масштабирование, когда оно не требуется. Для Google Cloud Platform (GCP) автоматическое масштабирование выполняется с помощью облачных функций, которые запускаются terraform. Oracle Cloud Infrastructure (OCI) и Microsoft Azure используют другие настраиваемые интеграции от WEKA для возможностей автоматического масштабирования. В дополнение к этому, thin provisioning файловых систем вместе с автоматическим масштабированием позволяет автоматически увеличивать доступную емкость в файловых системах при расширении кластера и автоматически уменьшать ее по мере необходимости при уменьшении масштаба кластера.

Гибкие варианты развертывания (локально и в облаке)

Независимо от того, работают ли приложения на «голом железе» для повышения производительности, в виртуальной или контейнерной среде для простоты развертывания и отказоустойчивости или полностью в общедоступном облаке для масштабируемости и эластичности по требованию, WEKA — это единое бескомпромиссное решение для хранения данных, обеспечивающее свободу что бы выбрать среду, наиболее подходящую для вашего приложения, исходя из производительности, масштаба и экономичности. Клиенты WEKA могут поддерживать пустые, виртуализированные, контейнерные и облачные среды (рис. 9).

WEKA обеспечивает ведущую в отрасли гибкость, поддерживая чрезвычайно широкий спектр операционных сред и моделей развертывания. Он работает на стандартных серверах на базе x86 с использованием сетевых адаптеров Ethernet или InfiniBand и готовых твердо тельных накопителей NVMe. WEKA Storage может работать как на «голом железе», так и в одобренных облачных средах.

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

Рис. 9. Лучшая в отрасли гибкость для поддержки операционной среды.

Конвернеция

В конвергентном развертывании (рис. 10) WEKA интегрируется в стандартные серверы приложений на базе процессоров AMD или Intel x86 или экземпляры публичного облака. Объединение ресурсов хранения и вычислений с приложениями и данными в единый строительный блок позволяет получить высоко оптимизированное решение для центра обработки данных для различных рабочих нагрузок. Эта модель развертывания дает возможность создавать интегрированные решения на основе приложений с большей экономичностью, устраняя необходимость во внешнем хранилище, уменьшая занимаемую аппаратным обеспечением и потребляемую мощность при одновременном повышении производительности, доступности и емкости. WEKA выделяет ресурсы хранения и использует только ресурсы в своем контейнере, а остальные ресурсы доступны приложениям. Эта модель развертывания популярна для кластеров серверов GPU с локальными устройствами NVMe.

Рис. 10. WEKA в конвергентном режиме с вычислительными ресурсами и хранилищем в одной инфраструктуре.

Выделенный сервер хранения

WEKA можно настроить как выделенный сервер хранения (рис. 11), когда все ресурсы системы выделены для служб хранения, а приложения выполняются в отдельной вычислительной инфраструктуре. Этот режим наиболее популярен среди клиентов, поскольку он гарантирует, что сбои в работе приложений не повлияют на службы хранения.

Рис. 11. Выделенный сервер хранения с отдельной вычислительной инфраструктурой и инфраструктурой хранения.

Собственное общедоступное облако

Google Cloud Storage, объектное хранилище Oracle и большие двоичные объекты Azure. Если вы хотите выполнить пакетную передачу данных или перенести их в облако, вы можете использовать функцию WEKA snapshot-to-object для перемещения данных. Для повышения отказоустойчивости WEKA также поддерживает объединение зон доступности в общедоступном облаке. На рис. 12 показано типичное развертывание WEKA в общедоступном облаке AWS. Для GCP, OCI и Azure это будет выглядеть примерно так, но с другой терминологией для вычислительных серверов и серверов хранения.

Производительность в облаке зависит от количества устройств NVMe в кластере WEKA, а также от скорости сети.

Рис. 12. WEKA в общедоступном облаке AWS.

Производительность WEKA

До сих пор ИТ-организации могли достигать своих целей производительности для файловых приложений, только запуская их в локальной файловой системе, также известной как хранилище с прямым подключением (DAS), или предоставляя их через том All-Flash Array (AFA). Если общий доступ к набору данных требуется нескольким клиентам, производительность серьезно снижается из-за ограничений производительности Linux NFS или Windows SMB. WEKA обеспечивает важные преимущества в производительности по сравнению с этим подходом. Наша общая файловая система, совместимая с POSIX, использует инновационный протокол для предоставления семантики на основе файлов, которая обладает всеми преимуществами локального кэширования хранилища с прямым подключением и преимуществами совместного использования NFS или SMB. В результате WEKA позволяет запускать любую рабочую нагрузку в сетевой файловой системе с такой же или большей производительностью, чем может предложить DAS. Этот, в сочетании с чрезвычайно малой задержкой операций ввода-вывода 4K для приложения делают необходимость использования томов AFA для локальной файловой системы устаревшей. На следующей диаграмме (рис. 13) показана фактическая производительность WEKA в производственной среде со 100-гигабитной сетью по сравнению с All-flash NAS и локальным хранилищем с прямым подключением. WEKA работала в 3 раза быстрее, чем локальное хранилище, и в 10 раз быстрее, чем флэш-хранилище на основе NFS. Удвоение пропускной способности сети до 200 Гбит приведет к двукратному увеличению пропускной способности клиента, 6кратному повышению производительности локальной файловой системы и 20-кратному повышению производительности NFS.

Производительность Weka была публично задокументирована в нескольких проверенных отраслевых тестах. WEKA установила рекорд самой производительной файловой системы на Supercomputing 2019, заняв первое место в общем зачете и лучшую производительность метаданных. WEKA установила отраслевые рекорды в тестах SPEC 2014 и SPEC Storage 2020 (https://www.spec.org/storage2020/results/) во всех основных тестах пакета, а WEKA установила несколько рекордов в тесте STAC M3 (https://www.stacresearch.com/news/KDB210507) для финансовой аналитики.

Рис. 13. Производительность WEKA по сравнению с локальным NVMe и All- Flash.

Standard Performance Evaluation Corporation: SPEC.org

Тест SPEC SFS^® 2014 — это версия набора тестов Standard Performance Evaluation Corporation, измеряющая пропускную способность файлового сервера и время отклика, и обеспечивающая стандартизированный метод сравнения производительности на платформах разных поставщиков. WEKA занимает лидирующие позиции в области баз данных, инфраструктуры виртуальных рабочих столов (VDI), автоматизации проектирования электроники (EDA) и сбора видеоданных (VDA), с небольшим отрывом в разработке программного обеспечения.

На рис. 14 показана производительность WEKA для баз данных. WEKA поддерживала 4480 баз данных, что в 2 раза больше, чем у следующей ближайшей отправки, при общем времени отклика 340 мкс, https://www.spec.org/sfs2014/results/sfs2014database.html.

Рис. 15 демонстрирует сверхнизкую задержку WEKA. В то время как NetApp AFF A800 поддерживал на 8% больше сборок, чем WEKA, задержка для WEKA составила 260 микросекунд по сравнению с 830 микросекундами для NetApp. Другими словами, WEKA может выполнить в 3 раза больше сборок программного обеспечения, чем NetApp, за то же время, https://www.spec.org/sfs2014/results/sfs2014swbuild.html.

Рис. 14. Производительность WEKA для баз данных.

Рис. 15. WEKA поддерживает сборки 5700 с задержкой 260 мкс.

Масштабирование производительности

Чтобы продемонстрировать линейное масштабирование производительности WEKA, мы провели тестирование на Amazon Web Services, чтобы показать, как WEKA масштабируется от минимальной конфигурации из 6 серверов хранения до сотен серверов хранения. Рис. 16 демонстрирует идеальное линейное масштабирование, измеренное на WEKA. Производительность измерялась для сетевых каналов 10 Гбит, поэтому она не является репрезентативной для производительности, которую WEKA может обеспечить в сетях 100 Гбит или 200 Гбит. Скорее, эти цифры следует рассматривать для линейной масштабируемости файловой системы.

Рис. 16. Идеальное линейное масштабирование производительности по мере роста.

Чтобы понять производительность WEKA в общедоступном облаке AWS, на рис. 17 показаны производительность 4K IOP и пропускная способность WEKA на инстансах i3 с сетью 100 Гбит/с. WEKA достигла скорости более 100 ГБ/с и 5 миллионов операций ввода-вывода в секунду с задержкой в 250 микросекунд, используя всего 16 серверов хранения. Плоский график задержки показывает, что за масштабирование не взимается штраф, а удвоение ресурсов сервера хранения приводит к удвоению производительности операций ввода-вывода.

Рис. 17. Производительность WEKA на AWS.

Производительность для хранилища GPU

WEKA — идеальная файловая система для рабочих нагрузок с интенсивным использованием графического процессора. Компания WEKA разработала эталонную архитектуру для системы графического процессора NVIDIA^® DGX-1^™. Тестирование FIO обеспечивает базовую оценку возможностей ввода-вывода эталонной архитектуры. Тест производительности был проведен с одной системой DGX-1, чтобы установить производительность, которую WEKA может обеспечить с минимальной конфигурацией оборудования на одном 100-гигабитном канале InfiniBand с хостом. На рис. 18 показано, что WEKA способна полностью заполнить 100-гигабитный канал, обеспечив пиковую скорость чтения 10,8 Гбайт/с для одной системы DGX-1. Измерение производительности операций ввода вывода в секунду показывает, что WEKA доставила более 250 000 операций ввода-вывода в одну систему DGX-1 по одному сетевому каналу со скоростью 100 Гбит/с.

Рис. 18. Производительность системы с одним графическим процессором NVIDIA DGX-1 по сетевому каналу 100 Гбит/с.

Следующий набор тестов производительности измеряет способность WEKA масштабироваться от одного сервера GPU до нескольких серверов GPU. На рис. 19 показано, как компания WEKA обеспечила идеальное линейное масштабирование от 1 системы NVIDIA DGX-1 до 9 систем NVIDIA DGX-1. Каждый NVIDIA DGX-1 имел 8 графических процессоров, что в сумме позволяет увеличить число графических процессоров до 72 Tesla V100. Последний набор тестов производительности (рис. 20) измеряет способность WEKA обеспечивать производительность одного сервера с графическим процессором, использующего GPUDirect Storage. WEKA увеличила производительность одного графического сервера NVIDIA DGX-2™ с одного 100-гигабитного канала EDR до 8 каналов EDR с идеальным линейным масштабированием, насыщая пропускную способность сети.

Рис. 19. Масштабирование производительности от системы с одним GPU до систем с 9 GPU.

Рис. 20. Масштабирование производительности внутри одного GPUсервера NVIDIA DGX-2 с GPUDirect Storage.

Производительность в облаке

Еще одним доказательством способности WEKA масштабироваться и обеспечивать высочайшую производительность в облаке является тестирование, проведенное в Oracle Cloud Infrastructure. Как показано на рис. 21, было выполнено два тестовых прогона FIO на кластерах из 80 серверов и 373 серверов. Достигнутые результаты были значительно выше, чем обычно ожидалось в облачных средах: почти 2 ТБ/с при чтении и 1 ТБ/с при записи, а также 17 млн операций чтения и 12 млн операций записи, все с задержкой менее 200 микросекунд. Между полосой пропускания FIO и тестовыми прогонами FIO IOP не требовалось никаких различий в настройке. Подробнее – https://www.weka.io/blog/oracle-oci/.

Рис. 21. Производительность в масштабе с использованием WEKA в Oracle Cloud Infrastructure.

Пример развертывания Weka [4, 5]

Решение Lenovo High Performance File System Solution с WEKA Data Platform — это программно-определяемое хранилище (SDS), которое сочетает в себе ведущие в отрасли серверы Lenovo ThinkSystem с сверхвысокопроизводительной гибридной облачной платформой данных WEKA. Это решение создано для приложений с интенсивным использованием данных, таких как рабочие нагрузки искусственного интеллекта, машинного обучения и высокопроизводительных вычислений, помогая ускорить получение информации и сократить связанные с этим расходы.

Конфигурация монтирования клиента

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

На рис. 22 показано влияние конфигурации подключенного клиента 100 GbE с использованием 0, 1 или 2 выделенных ядер. Аналогичное поведение (хотя и с более высокой производительностью) можно увидеть при использовании сетей 200 GbE или HDR InfiniBand.

Из рис. 22 видно, что использование выделенных клиентских ядер повышает производительность клиента WEKA. Выбор 1 или 2 выделенных ядер будет зависеть от пропускной способности клиентской сети и требований к вводу-выводу рабочей нагрузки клиента. Как правило, 2 клиентских ядра дают хороший выбор после того, как ядра выделены для клиента WEKA, они недоступны для использования в вычислительных приложениях, работающих в клиентской системе. Однако, учитывая, что в современных высокопроизводительных системах обычно используются ЦП с большим числом ядер, потребность в выделении ядер для производительности ввода-вывода вряд ли станет проблемой в целом. При использовании клиента WEKA со SLURM в качестве планировщика HPC необходимо сообщить SLURM, что эти ядра больше не доступны для вычислительной работы на клиенте.

Рис. 22. Влияние выделенных ядер на производительность одного узла.

Сетевая конфигурация

Программное обеспечение WEKA может использовать несколько сетевых адаптеров на сервере с максимальной производительностью, наблюдаемой при использовании адаптеров с поддержкой RDMA. В решении Lenovo EveryScale WEKA Storage рекомендуются адаптеры NVIDIA Networking VPI. Эти устройства поддерживаются WEKA, а также рекомендуются для использования в клиентских системах, обращающихся к системе хранения.

При монтировании системы хранения важно, чтобы имя адаптера с поддержкой RDMA было передано в параметры монтирования клиента WEKA. Точно также адаптеры должны быть подключены к контейнерам WEKA, работающим на серверах хранения. В настоящее время WEKA поддерживает не более 2 адаптеров RDMA на серверах хранения. Для максимальной производительности при использовании с сервером Lenovo ThinkSystem SR630 V2 их следует размещать в слотах 1 и 3. Это гарантирует, что один адаптер подключен к каждому домену NUMA в пределах сервер.

Если с WEKA используется серверная часть объекта или требуется многопротокольный доступ (например, NFS, SMB или Object), можно использовать третий адаптер, установленный в слоте 2, для обеспечения выделенного сетевого подключения для этих служб.

Производительность хранилища

С кластером из шести узлов, использующим Lenovo ThinkSystem SR630 V2 и использующим HDR InfiniBand в качестве межсоединения, можно ожидать, что производительность достигнет 5,1 миллиона операций ввода-вывода в секунду при чтении и до 228 ГБ/с производительности при потоковом чтении.

Конфигурация сервера WEKA

Сервер Lenovo ThinkSystem SR630 V2 представляет собой двухпроцессорную платформу. Разработка производительности в Центре инноваций Lenovo HPC показала, что производительность можно значительно повысить, используя многоконтейнерные серверные части с WEKA. В этой конфигурации на сервер развернуто два контейнера WEKA, каждому из которых выделено 15 ядер. При распределении дисков NVMe в Lenovo ThinkSystem SR630 V2 важно, чтобы идентификаторы ядер сопоставлялись с контейнером, а диски, подключенные к узлу NUMA, также сопоставлялись с этими ядрами.

Если используется конфигурация с одним контейнером или не учитывается распределение ядер и дисков, маловероятно, что можно будет достичь максимальной производительности системы. Профессиональные услуги Lenovo доступны для развертывания и настройки системы хранения Lenovo EveryScale WEKA. Настройка выделения ядер для интерфейсных и вычислительных ядер требует тщательного рассмотрения, поскольку выбор этих значений влияет на производительность метаданных и многопротокольного доступа, а точная конфигурация будет зависеть от развертывания клиента.

Объем потоковой передачи данных

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

Этот график не предназначен для демонстрации максимальной производительности системы, но используется для демонстрации влияния изменения размера передачи/ввода-выводов при выполнении потокового чтения или записи в решении Lenovo EveryScale WEKA Storage.

Рис. 23. Влияние изменения размера передачи на потоковый ввод-вывод.

Производительность потоковой передачи одного узла

Как и во многих параллельных файловых системах, для достижения максимальной производительности одного клиента необходимо увеличить количество потоков в клиентской системе, прежде чем будет достигнута максимальная производительность. На рис. 24 показано, как будет масштабироваться увеличение количества потоков при использовании IOR на одном клиенте. В приведенных выше тестах для демонстрации общего масштабирования используется одна итерация IOR. При использовании нескольких итераций линия, скорее всего, будет выглядеть менее «ухабистой». В дополнение к высокой производительности потоковой передачи данных, WEKA также обеспечивает отличную производительность случайного 4K.

Рис. 24. Масштабирование производительности одного узла с увеличением количества потоков.

На рис. 25 показана производительность системы хранения при увеличении количества клиентских узлов, при этом на каждом узле выполняется 30 потоков. График показывает, что операции произвольного чтения 4K хорошо масштабируются по мере увеличения количества клиентских узлов. Хотя на графике показана совокупная случайная пропускная способность 4K, обычно это тест на привязку «IOPS», который показывает, что WEKA способна обеспечить высокую производительность IOPS.

Рис. 25. Случайные операции ввода-вывода 4K.

Минимальная рекомендуемая конфигурация

В табл.3 указана минимальная рекомендуемая конфигурация для Lenovo Storage Solution с Weka Data Platform [5].

Табл. 3. Минимально рекомендуемая конфигурация.

1. 4+2 stripe size with one configured hot spare. Configurations may vary based upon tiering customer network configuration. Please speak with your Lenovo representative for solution guidance appropriate to your environment.
2. N+4 is available only for a cluster with 14 or more servers
3. Performance estimates are for a 6server cluster on a 200Gb network

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

[1]  Magic Quadrant for Distributed File Systems and Object Storage. Published 19 October 2022 – https://www.purestorage.com/resources/gartner-magic-quadrant-distributed-file-systems-object-storage.html.

[2]  2023 Gartner Peer Insights Voice of the Customer: Distributed File Systems and Object Storage – https://www.weka.io/lp/weka-named-a-2023-customers-choice-by-gartner-peer-insights/.

[3]  WekaFS Architecture. January 2023 White Paper – https://www.weka.io/resources/whitepaper/wekaio-architectural-white-paper/, https://www.weka.io/wpcontent/uploads/resources/2023/03/weka-architecture-white-paper.pdf.

[4]  Lenovo EveryScale Design Architecture for WEKA Storage. Planning / Implementation. Published 27 Feb 2023 – https://lenovopress.lenovo.com/lp1700-lenov-oeveryscale-design-architecture-for-weka-storage.

[5]  Lenovo High Performance File System Solution with WEKA Data Platform. Solution Brief. Published 7 Feb 2023 – https://lenovopress.lenovo.com/lp1691-lenovo-high-performance-file-system-solution-with-weka-data-platform.

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

Отслеживать