Поскольку спрос на масштабируемое, отказоустойчивое хранилище растет, многие организации обращаются к платформам с открытым исходным кодом, таким как Ceph и MinIO. Обе системы поддерживают стирающее кодирование (Erasure Coding) — метод уменьшения расходов на хранение в сравнении с традиционной репликации.
Однако эти оба решения различаются в проектировании, операционных требованиях и использовании. Эти различия решают как каждая платформа работает, масштабируется и потребляет ресурсы в производственной среде. Поскольку архитектурные решения лежат в основе реализации таких функций, как избыточное кодирование и обработка метаданных, мы начнем с обзора внутренней структуры каждой платформы
Архитектурный дизайн и сложность
Внутренняя структура платформы хранения определяет, насколько эффективно она может управлять данными, распределять рабочую нагрузку и восстанавливаться после сбоев. Архитектура также напрямую влияет на то, сколько вычислительных ресурсов и памяти необходимо просто для поддержания работы системы.
Ceph — это универсальная платформа распределенного хранения, поддерживающая объектное, блочное и файловое хранилище. Ее архитектура включает в себя несколько подсистем:
- Демоны Ceph OSD управляют объектным хранилищем на диске,
- Узлы MON (Monitor) обрабатывают кворум кластера и метаданные,
- Демоны MGR (Manager) предоставляют метрики и оркестровку,
- MDS (серверы метаданных) необходимы для файлового хранилища через CephFS.
Эта многоуровневая структура обеспечивает Ceph значительную гибкость, но вносит операционную сложность. Каждый компонент потребляет системные ресурсы и увеличивает сетевые и координационные издержки.
MinIO — это специализированная система объектного хранения, разработанная как легкая и производительная. Она развертывается как единый двоичный файл и изначально поддерживает API S3. Она не предоставляет блочное или файловое хранилище POSIX. Ее архитектура минимальна, и она ориентирована на масштабируемость за счет горизонтального распределения без необходимости использования отдельных управляющих демонов.
Эти архитектурные решения влияют не только на производительность и масштабируемость, но и определяют, как реализуются и управляются механизмы защиты данных, такие как избыточное кодирование. В следующем разделе рассматриваются различия между Ceph и MinIO в их подходе к стирающему кодированию — основной функции обеспечения надежности в распределенном хранилище.
Подходы к стираемому кодированию
Избыточное кодирование (EC) — это метод защиты данных, используемый в современных системах хранения. Вместо копирования полных реплик EC разделяет данные на фрагменты, добавляет блоки четности и распределяет их по узлам. Это обеспечивает надежность с меньшими накладными расходами на хранение, но способ реализации EC влияет на производительность, скорость восстановления, а также на использование процессоров и памяти.
Оба решения для хранения используют стирающее кодирование для повышения надежности данных при минимизации накладных расходов на хранение, но их реализации довольно разные.
Избыточное кодирование Ceph интегрировано в уровень RADOS и тесно связано с его механизмами управления объектами и репликации. Ceph позволяет администраторам определять профили EC с различными конфигурациями данных/четности и поддерживает детальные политики размещения данных с помощью карт CRUSH.
Хотя это дает операторам контроль над макетом данных и доменами сбоев, это увеличивает обработку метаданных и координацию между узлами, особенно во время восстановления или перебалансировки. Стирающее кодирование MinIO предназначено для рабочих нагрузок, ориентированных на потоковую передачу и пропускную способность. Оно работает в соответствии с операциями ввода-вывода и минимизирует поиск метаданных. Каждый узел знает о конфигурации EC, и данные равномерно распределяются по всем дискам и узлам.
Целостность данных и очистка
Помимо стирающего кодирования, механизмы целостности данных также различаются. Ceph включает процесс очистки, который активно сканирует хранимые данные для обнаружения и исправления битовых ошибок или скрытых повреждений. Эта фоновая операция обеспечивает долгосрочную надежность, особенно в больших или устаревающих кластерах.
MinIO, напротив, не выполняет активную очистку. Он полагается исключительно на избыточное кодирование и контрольные суммы для каждого объекта во время операций чтения/записи. Хотя это обеспечивает достаточную защиту для многих рабочих нагрузок, это может не выявить скрытые ошибки, если только к затронутым объектам не будет получен доступ.
Управление метаданными
Метаданные в системах хранения включают информацию о том, где находятся данные, как они защищены, когда они были записаны и т. д. Эффективное управление метаданными имеет решающее значение для производительности и масштабируемости, особенно по мере роста объема данных.
MinIO хранит метаданные объектов непосредственно в файловой системе вместе с данными объекта. Это снижает сложность и накладные расходы на ввод-вывод, но ограничивает некоторые расширенные функции метаданных. Ceph хранит метаданные объектов в выделенных узлах MON и картах объектов, что позволяет использовать расширенные функции, такие как пользовательское размещение данных и подробный мониторинг, — ценой увеличения требований к хранилищу и памяти.
Сравнение аппаратных ресурсов: практический пример
Командам, занимающимся инфраструктурой хранения, необходимо планировать емкость не только в терабайтах, но и с точки зрения того, сколько оборудования требуется, включая диски, ЦП, ОЗУ и сеть. Архитектурные различия и различия в стирающем кодировании приводят к значительным различиям в том, сколько требуется необработанной емкости и вычислительных ресурсов.
Чтобы понять, как архитектура преобразуется в потребности в оборудовании, рассмотрим следующее определение размера для кластера, предназначенного для 1 PB полезного хранилища с использованием стирающего кодирования.
Хотя MinIO требует немного больше необработанной емкости и общего объема ЦП/ОЗУ в этом примере, эти цифры зависят от профилей EC, размера диска и плотности сервера.
Конфигурация Ceph предполагает отдельные узлы мониторинга. Конструкция MinIO не требует выделенных служб управляющей плоскости, что может упростить конструкцию кластера и снизить накладные расходы на управление в некоторых сценариях.
Варианты использования и компромиссы
Выбор между Ceph и MinIO во многом зависит от варианта использования, опыта команды и целей инфраструктуры. Объектное хранилище для конвейеров аналитики имеет совершенно иные потребности, чем многопротокольное хранилище для сред виртуальных машин.
Лицензирование и доступ к исходному коду
И Ceph, и MinIO имеют открытый исходный код, но они следуют разным моделям лицензирования, что может повлиять на стратегию развертывания, особенно для коммерческого использования или поставщиков SaaS.
Ceph лицензируется в соответствии с LGPLv2.1, предлагая полный доступ к исходному коду без коммерческих ограничений. Он широко используется в корпоративных и облачных средах, включая коммерческие продукты. С FishOS Ceph организации также могут выбрать коммерческую лицензию, получив экспертную поддержку, а также дополнительные разработки и функции. MinIO использует AGPLv3, более ограничительную лицензию, которая требует раскрытия кода при использовании для предоставления услуг по сети. Коммерческое использование, особенно в предложениях SaaS, может потребовать отдельную коммерческую лицензию от MinIO, Inc.
Выбор между MinIO и Ceph — это не столько вопрос о том, что «лучше», сколько о том, что требуется вашей рабочей нагрузке и структуре команды.
- Ceph подходит организациям, которые ищут унифицированный многопротокольный уровень хранения с глубокой интеграцией и расширенным управлением.
- MinIO лучше подходит для рабочих нагрузок только с объектами, особенно там, где приоритетами являются простота, производительность и совместимость с облачными технологиями.
То, как каждая система обрабатывает стирающее кодирование, метаданные, очистку и оркестровку, влияет не только на потребности в необработанном оборудовании, но и на операционные издержки и сложность системы.
Прежде чем принимать решение, важно смоделировать свои требования к хранилищу, понять свой профиль стирающего кодирования и оценить операционные компромиссы — особенно с точки зрения управления кластером, настройки производительности и лицензионных обязательств.