Ликбез
by olvas

S3-совместимые хранилища: как собрать свой конструктор

В одном из больших кластеров S3 в Точке хранится 110 терабайт полезных данных. Это не много по объёму, но он распределён среди 600+ миллионов файлов. Стоимость работы системы оценивается более чем в миллион рублей в месяц — это с учётом фактора репликации, бэкапов, основной системы хранения и резерва ресурсов. Это пятое место по стоимости среди всех сервисов.

Мы выбрали SeaweedFS, потому что это удобный конструктор, который позволяет загружать файлы любого размера, легко масштабироваться без деградации скорости доступа и надёжно защищать данные от потерь. В статье рассказываю, каким должно быть идеальное S3-хранилище для миллионов файлов, и почему нам не подошли Ceph и Minio.

Где хранить данные

Когда говорим про хранение данных, первое, что приходит в голову — это локальные диски: жёсткие (HDD) и твердотельные (SSD). Ещё есть базы данных и бэкап. Давайте рассмотрим преимущества и недостатки каждого из вариантов.

Локальные диски

Чаще всего для хранения используют рейды (RAID) — это способ обезопасить данные, объединив несколько дисков в один массив. 

Например, в RAID 10 (1+0) есть как минимум четыре диска. Две пары из них создают зеркала (RAID 1) и дублируют данные. Поэтому, если два диска выйдут из строя (из разных зеркал), то данные всё равно останутся в сохранности.

Плюсы локальных дисков:

  • Они очень быстрые.
  • Нет задержек сети.

Минусы: 

  • Физически находятся в одной локации, поэтому есть риск потери данных во время масштабной аварии или катастрофе.
  • Как правило, использование дисков подразумевает наличие файловой системы и её ограничений.

Сетевые диски

Если нужно получить доступ к данным не только локально, но и удалённо, используют сетевые диски. Например, на картинке ниже один из способов организовать такой накопитель.

Плюсы сетевых дисков:

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

Но есть и минусы:

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

Бэкап

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

Плюсы бэкапа: 

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

Минусы бэкапа:

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

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

Базы данных

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

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

Плюсов у баз данных много:

  • Репликация в реальном времени — клиенту не будет возвращён ответ «OK» до тех пор, пока мастер не сделает копию изменений на одну или две реплики.
  • Высокая надёжность хранения: данные синхронизированы, копии хранятся в разных физических локациях, поэтому риск потери информации в случае локальной аварии ниже.
  • Высокая скорость доступа — большая часть горячих данных хранится в оперативной памяти.
  • Есть разные механизмы для ускорения работы, например, индексирование, защита от множественного изменения данных.
  • Высокая скорость чтения — нагрузка на систему на чтение может быть распределена между несколькими репликами.
  • Нет ограничения файловых систем — миллионы записей укомплектовываются, сжимаются и хранятся в нескольких файлах.

Минусы тоже есть:

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

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

Что такое S3 и распределённые хранилища данных

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

И здесь на помощь приходят распределённые системы хранения данных, которые чаще всего скрываются за аббревиатурой S3 (Simple Storage Service). Они взяли себе всё лучшее из всех перечисленных выше подходов к хранению информации. Такие системы изначально спроектированы под хранение цифровых данных большого объема. У каждого модного провайдера сейчас есть собственный сервис, который предоставляется, как дополнительная услуга.

На самом деле, распределённые системы хранения — это тоже не универсальный инструмент, но при этом они: 

  • Подходят практически для любых данных.
  • Позволяют хранить разнородную информацию.
  • Обеспечивают быстрый доступ и высокую сохранность.

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

Преимущества S3

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

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

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

Сравниваем разные S3-совместимые системы хранения

Изначально при выборе системы хранения мы рассматривали несколько вариантов:

  • Minio.
  • Ceph.
  • SeaweedFS.

Сравним важные по нашему опыту характеристики, чтобы понять, в чём между ними разница.

Внешняя мета

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

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

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

Как устроено хранилище меты у SeaweedFS:

  • Хранилище метаданных работает отдельно.
  • Это может быть практически любая база данных со всеми её преимуществами.
  • Путь до файла — это абстракция в базе, на самом деле, файл ищется по ID серверов, так мы частично обходим ограничения файловых систем.
  • Отдельные папки/бакеты можно вынести в отдельные базы данных, или использовать несколько баз одновременно. Это полезно, если один бакет большой или на него приходится большая часть нагрузки.
  • Можно собрать свой конструктор под поставленные задачи.
  • Можно отключить листинг, если он не нужен.
  • Можно хранить огромное количество маленьких файлов и папок внутри базы.
  • Есть преимущества от LIKE, например, поиск по префиксам. Он ускоряет операцию листинга файлов в подпапках и избавляет от необходимости перебирать все вложения.

Хранение данных

У Minio файлы хранятся в виде файлов на файловой системе — с применением erasure coding (EC) для защиты данных. Поведение зависит от файловой системы, а ещё нужен рестарт кластера при добавлении новых дисков.

У Ceph своя сложная структура хранения RADOS, но при этом нужна ребалансировка при добавлении дисков. 

Свой подход к хранилищу чанков у SeaweedFS:

  • Нет привязки к условиям добавления новых дисков (любые типы и объёмы), не нужна ребалансировка всего кластера.
  • Простое устройство волюм-файла.
  • Небольшое число настроек волюм-сервера.
  • Файлы хранятся в «суперблоке», внутри которого лежат чанки данных. Таким образом в один «файл» на файловой системе помещаются миллионы других файлов без аффекта со стороны файловой системы и её механизмов.

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

Запись данных

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

Ceph тоже по умолчанию создаёт несколько реплик. А ещё они предоставляют дополнительные интерфейсы взаимодействия — блочные устройства и сетевую файловую систему (NFS).

У Minio реализовано больше опций, совместимых с S3 API. Но добиться синхронной записи в реплику невозможно, даже если её включить (:

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

С учётом правильно выбранного erasure coding и других настроек репликация фактически не нужна. Поэтому вариант с “Site Replication” — не замена EC. И вариативность в этом плане ограничена.

Работа с дисками

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

У Ceph удаление может быть отложено. При изменениях в дисковом хранилище нужна массовая ребалансировка данных. Это дополнительная нагрузка на диски и сеть.

Нечто среднее реализовано в SeaweedFS:

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

Масштабирование 

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

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

Что можно отметить в работе  SeaweedFS:

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

Как устроен SeaweedFS

SeaweedFS — это opensource продукт, что одновременно плохо и хорошо. Главный плюс для нас — мы сами вносим в него изменения. Минус — их вносят и другие люди, поэтому периодически что-то ломают. 

У SeaweedFS один основной автор — Chris Lu. Именно он принимает решения, как проект будет развиваться дальше. Новые релизы выходят примерно 2 раза в месяц. 

Ещё SeaweedFS написан на Go, который очень любит наша команда инфраструктуры.

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

Путь одного файла выглядит примерно как на рисунке ниже:

  • Запись идёт в две реплики.
  • Волюм-сервера напрямую реплицируют файлы между собой.
  • В конце записи в базу данных заносится информация о новом файле.

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

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

Как выглядят метаданные














































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

Как мы делаем бэкапы

Так как мы считаем, что делать бэкапы важно даже для больших и объёмных систем, расскажу какие варианты реализации резервного копирования есть в распоряжении у SeaweedFS.

Здесь есть много разных вариантов:

  • У каждой базы данных есть собственный механизм создания бэкапов.
  • Можем экспортировать метаданные так, как их видит SeaweedFS, например чтобы заменить базу данных или произвести бэкап отдельных бакетов.
  • Можем копировать волюм-файлы целиком в бэкап (из-за ограничений файловых систем большие файлы перемещаются быстрее, копировать их проще — и суперфайлы, нам в этом помогают).
  • Используем «мгновенный бэкап» — инкрементальный встроенный механизм бэкапа. Когда записываем файл в S3, ещё одна его копия сразу же отправляется на отдельный носитель (дополнительно к записи в две реплики), который тоже потом отправляется в бэкап. Благодаря этому, даже если что-то пошло не так, мы можем быстро восстановить даже самые свежие данные. 

Главные выводы

S3 и распределённые системы хранения — это конструктор из разных программных и архитектурных решений, которые вместе дают все плюсы распределённых систем хранения: 

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

Реализовать этот конструктор и добиться желаемого результата нам позволяет SeaweedFS. Сейчас это активно эксплуатируемый, однако не единственный инструмент в нашем проде. Также для лимитированной выдачи блочных сетевых устройств применяем Ceph. Раньше использовали Gluster, но он плохо показал себя на больших объёмах данных, особенно в сценариях с большим количеством файлов.

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

Делитесь своим опытом в комментариях! Где вы храните данные и с какими сложностями пришлось столкнуться?

Источник: https:/habr.com