scality ring что это
Решения хранения для Scality
С помощью решений HPE для Scality вы сможете легко управлять данными в любом масштабе. Конструктивно экологичная объектная система хранения с адаптивным управлением данными предприятия.
Объектная система хранения данных от ЦОД до облака и периферии
Решения HPE для Scality поддерживают отдел обслуживания ИТ-инфраструктуры, разработчиков приложений и специалистов DevOps и помогает выполнять как стандартные, так и новые рабочие задачи, от ЦОД до периферии и в нескольких облаках.
+ Развернуть
Решения HPE для Scality
Идеально подходит для современных архивов, хранилищ контента, озер данных, а также будущих облачных решений, ИИ/МО, аналитики и приложений in-memory. Решения объектной системы хранения HPE для адаптивного управления данными предприятия Scality сочетаются с гибридными хранилищами объктов, поддерживающими облачные технологии и S3 API, и гибкими файловыми службами. Кроме того, HPE GreenLake для СХД позволяет использовать модель облачных услуг везде, где находятся приложения и данные.
Подготовьтесь к решению задач будущего с помощью объектной СХД
Культура ИТ и подходы ИТ-администраторов к управлению базовой инфраструктуры данных фундаментально меняются в связи с распространением облачных приложений и необходимости в обеспечении универсального доступа к данным независимо от того, где они находятся, а также смещением фокуса в сторону предоставления услуг.
Объектные системы хранения на периферии
До настоящего времени полное использование объектной системы хранения на периферии затруднялось невозможностью простого управления данными от периферии до ЦОД и облака, а также отсутствием возможностей корпоративного класса.
quality:quality=95/image.orig | @+SM and @2x => bounded-resize:width=490
quality:quality=95/image.orig | @+MD => bounded-resize:width=680/image.orig | @+MD and @2x => bounded-resize:width=680/image.orig» data-src-base=»/content/dam/hpe/shared-publishing/images-norend/0xx/0512006-16-9.jpg.hpetransform/» alt=»Быстрое получение объектов без потерь»>
Быстрое получение объектов без потерь
Многие годы объектные системы хранения применялись в основном для вторичных рабочих задач. Однако старые объектные системы хранения больше не подходят для облачной эпохи. Нужен новый подход!
Объектная система хранения для микросервисов и Kubernetes
Переход на приложения в виде микросервисов в облачной среде требует адаптируемости, портативности и эффективности, которые не может обеспечить традиционная объектная система хранения. Быстрый доступ к данным независимо от места их нахождения является важным для облачных приложений нового поколения, интенсивно работающих с данными, например машинного обучения, искусственного интеллекту, бизнес-аналитики и анализа, а также приложений, выполняемых в памяти, в которых обработка данных все чаще происходит на периферии. Более того, с распространением Kubernetes как стандарта и платформы портативного развертывания приложений и инфраструктуры фундаментально меняется подход к развертыванию СХД.
Решения HPE для Scality ARTESCA предлагают новую легкую платформу объектной системы хранения, которая меняет подход к управлению и предоставлению данных в облачном мире. Владельцы приложений и специалисты DevOps могут легко управлять хранилищами данных отовсюду, при этом им не нужно становится экспертами в области СХД.
Обзор принципов работы объектной системы на периферии
При использовании решений HPE для Scality ARTESCA вы можете начать всего с одного сервера с объектной системой хранения корпоративного класса за пределами ЦОД со встроенными инструментами для федеративного управления данными, предоставляющими единый обзор и контроль данных в нескольких облаках, управление рабочими процессами, API и поиск метаданных, определяемый пользователями, а также комплексный анализ СХД.
HPE и Scality теперь предоставляют возможность развертывать то же самое объектное хранилище корпоративного класса с интуитивным управлением, начиная от основных ЦОД и до периферийных систем. Эти решения являются адаптивными и устойчивыми, они готовы к использованию на будущих платформах и поддерживать дальнейшие технологические разработки.
Обзор высокопроизводительных объектных систем хранения и средств управления
Решения HPE Solutions для Scality ARTESCA предлагают системы хранения данных, ориентированные на современные приложения, которые построены на объектной системе хранения с использованием платформ на основе накопителей NVMe и обеспечивают производительность, необходимую для самых ресурсоемких рабочих задач, связанных с интенсивной обработкой данных.
Контейнерная архитектура подходит для экосистемы Kubernetes, что является непреложным требованием для облачных приложений, и позволяет специалистам в области приложений и DevOps управлять данными объектов без предварительного получения глубоких знаний в области СХД.
Все это предлагается в виде облачной услуги в рамках HPE GreenLake, что обеспечивает возможность динамического масштабирования, упрощение управления ИТ, а также гибкую модель оплаты по факту использования.
Как электронные архивы медицинской информации помогут эффективнее диагностировать заболевания
По прогнозам IDC, к 2025 году общий объем данных, хранящихся в организациях здравоохранения, вырастет до 2,3 зеттабайт, причем на долю различных медицинских снимков будет приходиться до 80-90% используемой емкости систем хранения. О том, насколько важно эффективное хранение медицинских снимков, говорит следующий пример.
В отделении диагностики одной из больниц в городе Тусон (штат Аризона) для анализов маммографии (диагностики рака женской молочной железы на основе рентгеновских снимков, ультразвукового обследования и МРТ) за один рабочий день выполняется до 40 рентгеновских снимков, два-четыре снимка – с помощью МРТ, а также два-пять – биопсии. В 80% случаев для интерпретации результатов маммографии используются старые снимки пациента, полученные два года назад и ранее, а в сложных случаях могут понадобиться снимки, сделанные 10 лет назад. Для быстрого извлечения старых снимков из архива используется цифровая больничная система PACS (Picture Archiving And Communication System).
Использование старых снимков, хранящихся в PACS, существенно уменьшает риск ошибки при диагностике злокачественных опухолей и избавляет пациентов с доброкачественной опухолью от необходимости снова делать маммографию и даже биопсию только для того, чтобы убедиться, что их опухоль не является злокачественной. В то же время сравнение со старыми снимками снижает риск ошибочной интерпретации снимков злокачественных опухолей и позволяет оперативно назначить пациенту соответствующее лечение патологии и дополнительные анализы.
Особенности долговременного хранения архивов медицинских снимков
Какой же должна быть идеальная система хранения, которая используется в качестве системы хранения для PACS? Очевидно, что с учетом большого размера медицинских снимков она должна обладать высокой масштабируемостью, чтобы в ней можно было сохранять результаты анализов каждого пациента, накопленные за несколько десятков лет. Второе требование – обеспечение быстрого поиска и извлечения данных из архива, без чего невозможно использование старых снимков для интерпретации результатов новых обследований.
Наконец, при хранении медицинских снимков требуется полностью исключить возможность «утечки» данных, потери и случайного или преднамеренного удаления или порчи. Особенностью хранения данных в PACS являются относительно скромные требования к производительности ввода/вывода: очевидно, что результаты анализов записываются в архив только один раз и никогда не изменяются, а запросы на извлечение этих данных из архива может направлять только ограниченный круг пользователей. Данные о конкретном пациенте обычно запрашиваются не чаще одного раза в год.
Традиционные СХД корпоративного класса не подходят для PACS прежде всего из-за слишком высокой стоимости хранения данных, которая во многом обусловлена ненужной для архивов медицинских снимков высокой производительностью при обслуживании транзакционных приложений, а более дешевые системы хранения начального уровня не обладают требуемой для архивов PACS масштабируемостью.
Возможно, лучшее решение для хранения медицинских снимков
Основным решением для хранения медицинских снимков и другого неструктурированного контента в организациях здравоохранения является использование файловых и объектных СХД, обладающих высокой масштабируемостью и низкой стоимостью хранения одного гигабайта. Одним из лидеров этого сегмента рынка систем хранения является компания Scality, продвигающая свое программно-определяемое хранилище Scality RING. Первая версия Scality RING вышла в 2010 году. Это – горизонтально-масштабируемое решение (scale-out), использующее связи peer-to-peer и распределенную архитектуру shared-nothing, которое развертывается на стандартных серверах x86. Scality RING поддерживает протоколы доступа к объектным данным S3 и Swift, API-интерфейсы simple HTTP и файловый доступ. В прошлом году Scality удалось в два раза увеличить число инсталляций своих систем в здравоохранении.
Программное обеспечение Scality RING разворачивается на кластере, состоящем в минимальной конфигурации из трех узлов хранения, и реализует набор интеллектуальных сервисов доступа к данным, а также защиты данных и системного управления. На верхнем уровне размещаются масштабируемые сервисы доступа к данным (коннекторы), которые обеспечивают предоставление данных приложениям по протоколам SMB, NFS и S3, а также супервизор для централизованного управления и мониторинга состояния системы. Коннекторы обычно инсталлируют непосредственно на узлы хранения, но их можно развернуть и на выделенных серверах.
Средний уровень хранилища Scality RING – это распределенная виртуальная файловая система с несколькими механизмами защиты данных, процессами самоизлечения системы и сервисами системного управления и мониторинга. Нижний уровень стека – это распределенный уровень хранения, который образуют виртуальные узлы хранения и демоны процессов ввода/вывода, которые абстрагируют физические серверы хранения и интерфейсы дисков.
Сердцем уровня хранения является масштабируемое распределенное объектное хранилище key-value на основе второго поколения протокола маршрутизации peer-to-peer. Маршрутизация обеспечивает эффективное горизонтальное масштабирование хранения и поиск по очень большому числу узлов. Программное обеспечение этих сервисов хранения развертывается на всех серверах, обладающих необходимой вычислительной мощностью и емкостью дисковой подсистемы. Серверы (узлы), на которых развертывается ПО Scality RING, соединяются стандартной сетевой фабрикой на базе IP, например, использующей 10/25/40/100 Gigabit Ethernet.
Scality RING включает следующие программные компоненты: серверы-коннекторы, распределенную СУБД MESA для хранения метаданных, узлы хранения, демоны ввода/вывода и web-портал управления. MESA обеспечивает индексацию объектов и управление метаданными, используемыми на уровне абстрагирования файловой системы Scality Scale-out file system (SOFS).
Коннекторы Scality RING обеспечивают доступ приложений к хранимым на серверах данным. Они поддерживают многие протоколы доступа к данным, включая объектный Amazon Web Services (AWS) S3 на базе стандарта Representational State Transfer (REST), а также файловые протоколы NFS, SMB и FUSE. Одно приложение может одновременно использовать несколько коннекторов RING для доступа к данным, если нужно горизонтально масштабировать ввод/вывод или параллельно обслуживать много пользователей.
Узел хранения – это виртуальный процесс, который отвечает за объекты, связанные с выделенной ему частью распределенной хеш-таблицы ключей (keyspace) RING. Демоны узлов хранения (так называемые bizoid) обеспечивают неизменность данных, хранящихся на диске в низкоуровневой локальной файловой системе. На одном физическом сервере (хосте) развертывается шесть виртуальных узлов хранения. Каждый biziod – это экземпляр низкоуровневого процесса, управляющий операциями ввода/вывода на конкретном физическом диске и поддерживающий соответствие ключей объекта адресам конкретных объектов на этом диске.
Для обеспечения высокой готовности объектного хранилища (до 14 девяток) в Scality RING вместо классической технологии RAID применяются различные механизмы защиты данных, оптимизированные для распределенных систем, в том числе локальная и территориально-распределенная репликация и механизм помехоустойчивого кодирования erasure coding, причем можно комбинировать репликацию с erasure coding в одном коннекторе. При хранении небольших объектов (размером до 60 Кбайт) более эффективным по стоимости решением защиты является репликация, а для крупных – erasure coding, при котором не нужно реплицировать большие наборы данных. При репликации используются шесть уровней класса сервиса Class of Service (CoS) от 0 до 5, что соответствует сохранению 3-5 реплик объекта, причем все реплики хранятся на разных дисках.
В случае использования erasure coding применяется механизм исправления ошибок Reed-Solomon, при котором вместо хранения нескольких реплик объекта он разбивается на «куски данных» (data chunks), которые записываются вместе с кодами (кусками) четности (parity chunks). Эти куски распределяются по узлам RING, и по ним можно восстановить данные при выходе из строя одного или нескольких узлов. Также высокая отказоустойчивость RING обеспечивается за счет архитектуры share-nothing, в которой нет главного («мастер») узла, отказ которого может привести к отказу всей системы.
Экосистема Scality RING
Хотя Scality RING можно развернуть на любых серверах стандартной архитектуры x86, аналитическое агентство Gartner в своем «магическом квадранте» Magic Quadrant for Distributed File Systems and Object Storage отмечает, что при его внедрении требуется тщательный выбор оборудования и детальная проработка проекта, а также глубокое погружение ИТ-специалистов заказчика в технологии Scality.
Компания Hewlett Packard Enterprise, являющаяся стратегическим партнером Scality с 2014 г., предлагает в качестве аппаратной платформы совместного решения для программно-определяемого объектного хранилища Scality RING две модели серверных систем из серии HPE Apollo 4000 Gen10, которые были разработаны специально для аналитики Больших Данных, файловых и объектных хранилищ: HPE Apollo 4200, обеспечивающую сверхвысокую плотность хранения (до 392 Тбайт в корпусе высотой 2U, вмещающем 28 полноразмерных диска LFF или 54 2,5-дюймовых накопителей SFF), и рассчитанную на гипермасштабирование емкости HPE Apollo 4510 на базе шасси 4U (68 полноразмерных дисков на шасси, более 9 петабайт в стандартной серверной стойке 42U).
Обе модели HPE Apollo 4000 Gen10 позволяют гибко подобрать конфигурацию дисковой подсистемы в соответствии с конкретными требованиями к производительности и емкости узла хранения и поддерживают хорошо знакомые пользователям серверов HPE ProLiant средства удаленного управления серверами HPE iLO 5, которые помогают быстро развернуть большое количество узлов хранения Scality RING и эффективно управлять ими.
Совместное решение НРЕ и Scality позиционируется как глобальное хранилище неструктурированных данных (включая и архивы), когда большая пропускная способность и емкость намного более важны, чем минимальные задержки при доступе к хранимым данным. Оно масштабируется до нескольких тысяч узлов хранения и доступа к данным, обеспечивая хранение сотен петабайт данных и триллионов объектов в одном пространстве имен.
Для дополнительной защиты хранимой информации можно использовать различные пакеты программ резервного копирования, поскольку Scality сертифицировала свое облачное хранилище на совместимость с продуктами VEEAM, Commvault, Microfocus Data Protector, Cloudera, MAPR и WEKA.IO, а применение Scality RING в здравоохранении в качестве архива медицинских снимков обеспечивает сертификация на совместимость с PACS-системами Fujifilm, GE Healthcare, Philips и ряда других вендоров.
Примеры внедрений Scality Ring в здравоохранении
В настоящее время только во Франции более десятка крупнейших больниц используют для хранения архивов медицинских снимков хранилище Scality Ring емкостью от 400 Тбайт до 6 Пбайт. Например, крупная совместная инсталляция НРЕ и Scality реализована в Assistance Publique Hôpitaux de Marseille (AP-HM), которая объединяет четыре марсельские больницы с 3400 койками и является третьей по размеру во Франции. В больницах AP-HM работает 2 тысяч врачей и еще 8500 других медицинских работников.
До 2011 г. в AP-HM для хранения снимков PACS использовалась система EMC Centera. К этому времени общий объем медицинских снимков был 60 Тбайт, но для защиты данных их реплицировали, поэтому они занимали 120 Тбайт емкости. Каждый год больничная PACS генерировала еще 20 Тбайт новых снимков. В 2011 г. AP-HM заменила Centera на NAS-систему и к 2017 г. объем снимков вырос до 320 Тбайт, а темпы роста увеличились до 40 Тбайт в год. Поскольку у NAS заканчивалась гарантия, и емкости этой СХД уже не хватало из-за быстрого роста объемов данных, руководство больниц AP-HM решило снова провести замену.
При выборе новой СХД требовалось обеспечить совместимость со всеми используемыми в больницах приложениями, в том числе поддержку файловых протоколов CIFS и NFS, масштабирование свыше нескольких петабайт, надежную защиту и безопасность данных. AP-HM выбрала НРЕ и Scality RING и построила распределенный по трем дата-центрам кластер RING из шести серверов хранения HPE Apollo 4510, а также двух серверов HPE ProLiant DL360, на которых хранятся СУБД метаданных META. В качестве основных приложений используется PACS-система Carestream от GE Healthcare, в которую записываются снимки, полученные в результате радиологических исследований, и архив геномики. Резервное копирование медицинских снимков и других данных выполняется с помощью программного обеспечения Commvault.
Доступность Scality Ring в России
Компании HPE и Scality накопили обширный опыт реализации совместных проектов. При внедрении Scality RING в медицинских учреждениях в России на помощь заказчику готовы прийти сертифицированные инженеры из московского офиса НРЕ.
По программе Factory Express компания HPE поставляет предконфигурированные в соответствии с требованиями заказчика Apollo 4000 Gen10 для быстрого развертывания кластера Scality RING, а также предлагает базовые эталонные конфигурации (Reference Architecture) этих серверных систем для кластера RING. Также с мая прошлого года HPE поставляет стартовый пакет Base Bundle из серверов Apollo 4200 Gen10 с начальной емкостью 240 Тбайт и предустановленным ПО Scality RING. Для развертывания Base Bundle нужно только задать скорость сети и требуемую емкость хранилища.
SCALITY RING
Manage petabytes of data on-prem and in the cloud
Protecting data at scale is a challenging task that RING approaches through comprehensive experience working in the world’s largest companies. The distributed architecture is redundant without bottlenecks to scale out to dozens of petabytes of capacity in a single system. Data is protected at the highest levels, even against data center outages through industry-leading geo-distribution.
RING supports your company’s transformation from legacy to new cloud-based applications with data management and storage that scales organically to dozens of petabytes and beyond. Adapting to multiple applications, workloads and performance profiles makes RING the ideal solution for your digital business.
Enterprise-grade data durability, self-healing, availability, security, encryption and multi-tenancy makes RING the trusted foundation of your enterprise cloud data services.
Access provided from both file (NFS, SMB) and object (S3) based applications eliminates storage silos, forklift upgrades and data migrations, greatly reducing operational costs. Single-system view allows administrators to easily manage multiple petabytes without additional time burden, thereby simplifying tasks and reducing operating expenses.
Принципы организации объектных хранилищ
Наш коллега недавно написал об архитектуре объектного S3-хранилища Mail.ru Cloud Storage. Теперь мы переводим хорошую статью об общих особенностях и ограничениях объектных хранилищ.
Объектные хранилища более масштабируемые, отказоустойчивые и надежные, чем параллельные файловые системы, кроме того, у них ошеломляющая пропускная способность для некоторых рабочих нагрузок. Такие характеристики производительности достигаются за счет отказа от файлов и каталогов.
В отличие от файловых систем, объектные хранилища не поддерживают вызовы ввода-вывода POSIX: открытие, закрытие, чтение, запись и поиск файла. Вместо этого у них только две основные операции: PUT и GET.
Ключевые особенности объектных хранилищ
Поскольку у объектного хранилища всего несколько доступных операций, появляются важные ограничения:
Эта нарочитая простота приводит к ряду ценных последствий в контексте высокопроизводительных вычислений:
Обратите внимание, что во многих реализациях объектных хранилищ к неизменяемости объектов подходят с некоторой гибкостью. Например, режим доступа только с добавлением по-прежнему устраняет узкие места блокировки, улучшая при этом полезность хранилища.
Ограничения объектных хранилищ
Простота организации объектного хранилища делает его масштабируемым, но также ограничивает его функциональность:
Поскольку объектное хранилище не пытается сохранить совместимость с POSIX, реализации шлюзов — удобные места для хранения метаданных объектов, превосходящие те, что традиционно предоставлялись ACL POSIX и NFSv4.
Например, S3 API предоставляет средства для связывания произвольных пар ключ-значение с объектами в качестве определяемых пользователем метаданных. А WOS DDN — запрашивать базу метаданных объектов, чтобы выбрать все объекты, соответствующие критериям запроса.
На базе объектных хранилищ можно построить и гораздо более сложные интерфейсы. Большинство параллельных файловых систем, включая Lustre, Panasas и BeeGFS, построены на концепциях, вытекающих из объектного хранилища. Они идут на компромиссы во внешнем и внутреннем интерфейсе, чтобы сбалансировать масштабируемость с производительностью и удобством использования. Но такая гибкость обеспечивается за счет построения поверх объектно-ориентированных, а не блочных, представлений данных.
Хотя отделение пользовательского интерфейса от базового объектного представления данных обеспечивает гибкость, не все такие шлюзы — шлюзы с двойным доступом. Двойной (или, например, тройной) доступ позволяет получать доступ к одним и тем же данным через несколько интерфейсов. Например, записывать объект с помощью PUT, но читать его обратно, как если бы это был файл. Шлюзы с двойным доступом стараются делать согласованными, однако, возможна ситуация, когда после записи данных они не сразу видны через все интерфейсы.
Реализации объектных хранилищ
Хотя принципы организации объектного хранилища достаточно просты, конкретные продукты отличаются. В частности, для обеспечения устойчивости, масштабируемости и производительности могут использоваться различные способы перемещения данных при получении запроса PUT или GET.
ShellStore: простейший пример
В этом разделе я хочу проиллюстрировать простоту базового хранилища объектов с помощью ShellStore Яна Киркера. Оно представляет собой хотя и безумную, но удивительно лаконичную реализацию объектного хранилища. Прелесть в том, что он демонстрирует основные тонкости работы хранилища с помощью простого bash.
DDN WOS
DDN WOS создавали как высокопроизводительное масштабируемое объектное хранилище, ориентированное на рынок высокопроизводительных систем хранения. Поскольку DDN WOS создавали с нуля, его конструкция проста, разумна и учитывает недостатки дизайна более ранних продуктов.
Простота WOS делает его отличной моделью для иллюстрации того, как в целом работают объектные хранилища. WOS используют очень крупные компании (например, считается, что на нем работает Siri), оно имеет такие примечательные особенности:
Openstack Swift
OpenStack Swift — одна из первых крупных реализаций объектного хранилища корпоративного уровня с открытым исходным кодом. Это то, что сегодня стоит за многими частными облаками. Но поскольку хранилище писали давно, в его архитектуре много неоптимальных решений:
RedHat/Inktank Ceph
Ceph использует детерминированный хэш, называемый CRUSH, который позволяет клиентам напрямую связываться с серверами хранилища объектов. Искать местоположение объекта для каждой операции чтения или записи не нужно.
Общая схема потока данных
Объекты сопоставляются с группами размещения с помощью простой хеш-функции. Группы размещения (PG) — логические абстракции. Через хэш CRUSH они сопоставляются с демонами хранения объектов, которые владеют коллекциями физических дисков.
CRUSH уникален тем, что позволяет добавлять дополнительные OSD без перестройки всей структуры карты объект-PG-OSD. Переназначать на недавно добавленные OSD нужно только часть групп размещения, что обеспечивает гибкую масштабируемость и отказоустойчивость.
Группы размещения содержат собственные политики устойчивости объектов, а алгоритм CRUSH позволяет физически реплицировать объекты и географически распределять их по нескольким OSD.
Ceph реализует политику устойчивости на стороне сервера, так что клиент, выполняющий PUT или GET объекта, общается только с одним OSD. После помещения объекта в OSD этот OSD отвечает за его репликацию в другие OSD, выполнение сегментирования, кодирования стиранием и распределения закодированных сегментов. Хорошее описание (с диаграммами) путей данных репликации и кодирования стиранием Ceph опубликовали в Intel.
Ещё несколько ресурсов с информацией об архитектуре Ceph:
Scality RING
Я почти ничего не знаю о Scality RING. Но эта платформа быстро проникает в сферу High-Performance Computing и используется в Национальной лаборатории Лос-Аламоса, которая ведет разработки в области ядерного вооружения.
Scality RING — исключительно программный продукт (в отличие от DDN WOS), который работает на любом оборудовании. У него есть все стандартные шлюзовые интерфейсы (S3, NFS / CIFS и REST, называемые «коннекторами»), кодирование со стиранием и масштабируемый дизайн. Кажется, он основан на детерминированном хеш-коде, который отображает данные на определенный узел хранения в кластере. Все узлы хранения — одноранговые, и с помощью внутренней одноранговой передачи любой узел может отвечать на запросы данных, хранящихся на любом другом узле.
Некоторые архитектурные детали и ссылки на конкретные патенты — в презентации Scality RING.
Другие продукты
Хочу рассказать еще о нескольких платформах объектного хранения. Правда, они менее актуальны для индустрии высокопроизводительных вычислений из-за их направленности или особенностей проектирования.
NetApp StorageGRID
Платформа хранения объектов StorageGRID от NetApp появилась после покупки компании Bycast. StorageGRID в основном используют в бизнесе, связанном с хранением медицинских записей. NetApp особо не рассказывает о StorageGRID, и, насколько я могу судить, отметить нечего, кроме использования Cassandra в качестве прокси-базы данных для отслеживания индексов объектов.
Cleversafe
Cleversafe — платформа для хранения объектов, ориентированная на корпоративный рынок и обладающая исключительной надежностью. Они продают программный продукт, но по своеобразной модели.
Кластеры Cleversafe нельзя легко масштабировать, поскольку вы должны заранее купить все узлы хранения объектов (sliceStors). Всё, что вы можете — увеличивать емкость каждого узла хранения. Заполните до предела емкость каждого узла — придется покупать новый кластер. Такой подход нормален для организаций, которые масштабируются целыми стойками, но менее практичен за пределами высокопроизводительных центров HPC. Среди известных клиентов Cleversafe — Shutterfly.
Cleversafe не так функциональна, как другие платформы хранения объектов (если судить по последней инструкции, которую я читал). Она предоставляет несколько интерфейсов REST («устройств доступа»), включая S3, Swift и HDFS. Но доступ на основе NFS/CIFS осуществляется сторонними приложениями поверх S3/Swift. Впрочем, крупные компании часто пишут собственное ПО для работы с S3, так что это небольшое препятствие при масштабировании.
Периферийные технологии
Представленные ниже решения хоть и не являются строго платформами объектного хранения, дополняют или отражают дух объектных хранилищ.
iRODS: объектное хранилище без объектов или хранилища
iRODS обеспечивает уровень шлюза объектного хранилища без хранилища объектов под ним. Он способен превратить набор файловых систем во что-то, похожее на хранилище объектов, отказавшись от соответствия POSIX в пользу более гибкого и ориентированного на метаданные интерфейса. Однако iRODS предназначен для управления данными, а не для высокой производительности.
MarFS: POSIX-интерфейс к объектному хранилищу
MarFS — платформа, разработанная в Национальной лаборатории Лос-Аламоса. Предоставляет интерфейс для объектного хранилища, включающий знакомые операции POSIX. В отличие от шлюза, который находится перед хранилищем объектов, MarFS предоставляет интерфейс непосредственно на клиентских узлах и прозрачно транслирует операции POSIX в вызовы API, понятные хранилищу объектов.
Спроектированная как легкая, модульная и масштабируемая, MarFS во многом выполняет те же функции, что, например, клиент llite, сопоставляя вызовы POSIX на клиенте хранилища, с вызовами, понятными базовому представлению данных Lustre.
В текущей реализации, которую используют в LANL, — файловая система GPFS для хранения метаданных, которые обычная файловая система POSIX будет предоставлять своим пользователям. Вместо того чтобы хранить данные в GPFS, все файлы в этой индекс-системе являются заглушками — они не содержат данных, но имеют владельца, разрешения и другие атрибуты POSIX-объектов, которые они представляют.
Сами же данные находятся в хранилище объектов (предоставляемом Scality в реализации LANL), а демон MarFS FUSE на каждом клиенте хранилища использует файловую индекс-систему GPFS для связывания вызовов ввода-вывода POSIX с данными, находящимися в хранилище объектов.
Поскольку он подключает клиентов хранилища напрямую к хранилищу объектов, а не действует как шлюз, MarFS предоставляет только подмножество операций ввода-вывода POSIX. В частности, поскольку базовые данные хранятся как неизменяемые объекты, MarFS не позволяет пользователям перезаписывать данные, которые уже существуют.
Посмотрите презентацию MarFS на MSST 2016, чтобы узнать больше.