За кулисами холодного хранения C14
Scaleway Elements C14 Cold Storage — это класс хранения в хранилище объектов Scaleway S3, созданный для архивирования данных при низких затратах. Это не продукт сам по себе, а скорее расширение нашего объектного хранилища, к которому нельзя получить доступ без S3 API.
В этой статье мы рассмотрим, как родился этот проект и как он разрабатывался, а также некоторые технические идеи о нем.
С чего все началось
В 2016 году Scaleway Dedibox запустил продукт для архивации: C14 Classic, все еще доступный. Продукт был очень аппаратно-ориентированным, в основном построен на двух основных аспектах:
Конкурентные диски SMR
Материнские платы, изготовленные внутри, могут включать / выключать диски по требованию с помощью матрицы дерева шин SATA.
Со стороны API C14 Classic был построен как хранилище: один открывает хранилище, помещает в него данные, а затем закрывает хранилище (архивирует его). Основным недостатком этого дизайна было то, что вам нужно было разархивировать весь архив, чтобы получить доступ к одному файлу в нем. Другими словами, чтобы получить доступ к файлу размером 1 ГБ в архиве объемом 40 ТБ, сначала необходимо разархивировать 40 ТБ.
Основной проблемой этого дизайна были «внешние интерфейсы данных», другими словами, большие серверы, которые хранили неархивированные данные. Как вы можете себе представить, несколько клиентов, у которых нет нескольких хранилищ в несколько терабайт, могут сравнительно быстро заполнить сервер, тем самым блокируя использование этой службы другими клиентами.
В 2019 году было разработано внутреннее Proof of Concept (PoC), чтобы продемонстрировать, что мы смогли использовать аппаратное обеспечение C14 Classic с новым Scaleway Object Storage. Конечно, были ограничения, но PoC был очень убедительным. Действительно, аппаратное обеспечение C14 Classic было стабильным, и продукт оказался надежным с твердым SLA. Кроме того, это также позволило нам использовать 40 ПБ оборудования C14, которое уже было в производстве.
В результате были приложены огромные усилия для превращения PoC в готовый к производству проект. Год спустя бета-версия C14 Cold Storage родилась в Scaleway.
Прежде всего, проект должен был использоваться с S3 API. В результате нам понадобился стандартный способ доступа к API. Много патчей были развернуты на нашем S3
шлюзы для обеспечения соответствия классу Amazon S3 Glacier Storage.
Нам также пришлось начать работу над полным двигателем жизненного цикла, так как эта функция требуется для Scaleway Elements C14 Cold Storage.
Учимся на наших классических ошибках C14
Опираясь на 3 года, мы узнали кое-что об архивировании данных, что работает, а что нет. Основная цель заключалась в создании C14 Cold Storage на основе оптимизации чтения, а не оптимизации записи. Мы также решили использовать файловые системы на SMR-дисках, поскольку за эти 3 года в ядре Linux было сделано много исправлений для оптимизации взаимодействия файловых систем с SMR.
диски.
Обзор архитектуры
blog.scaleway.com/2020/behind-the-scenes-c14-cold-storage/
В этой статье мы рассмотрим, как родился этот проект и как он разрабатывался, а также некоторые технические идеи о нем.
С чего все началось
В 2016 году Scaleway Dedibox запустил продукт для архивации: C14 Classic, все еще доступный. Продукт был очень аппаратно-ориентированным, в основном построен на двух основных аспектах:
Конкурентные диски SMR
Материнские платы, изготовленные внутри, могут включать / выключать диски по требованию с помощью матрицы дерева шин SATA.
Со стороны API C14 Classic был построен как хранилище: один открывает хранилище, помещает в него данные, а затем закрывает хранилище (архивирует его). Основным недостатком этого дизайна было то, что вам нужно было разархивировать весь архив, чтобы получить доступ к одному файлу в нем. Другими словами, чтобы получить доступ к файлу размером 1 ГБ в архиве объемом 40 ТБ, сначала необходимо разархивировать 40 ТБ.
Основной проблемой этого дизайна были «внешние интерфейсы данных», другими словами, большие серверы, которые хранили неархивированные данные. Как вы можете себе представить, несколько клиентов, у которых нет нескольких хранилищ в несколько терабайт, могут сравнительно быстро заполнить сервер, тем самым блокируя использование этой службы другими клиентами.
В 2019 году было разработано внутреннее Proof of Concept (PoC), чтобы продемонстрировать, что мы смогли использовать аппаратное обеспечение C14 Classic с новым Scaleway Object Storage. Конечно, были ограничения, но PoC был очень убедительным. Действительно, аппаратное обеспечение C14 Classic было стабильным, и продукт оказался надежным с твердым SLA. Кроме того, это также позволило нам использовать 40 ПБ оборудования C14, которое уже было в производстве.
В результате были приложены огромные усилия для превращения PoC в готовый к производству проект. Год спустя бета-версия C14 Cold Storage родилась в Scaleway.
Прежде всего, проект должен был использоваться с S3 API. В результате нам понадобился стандартный способ доступа к API. Много патчей были развернуты на нашем S3
шлюзы для обеспечения соответствия классу Amazon S3 Glacier Storage.
Нам также пришлось начать работу над полным двигателем жизненного цикла, так как эта функция требуется для Scaleway Elements C14 Cold Storage.
Учимся на наших классических ошибках C14
Опираясь на 3 года, мы узнали кое-что об архивировании данных, что работает, а что нет. Основная цель заключалась в создании C14 Cold Storage на основе оптимизации чтения, а не оптимизации записи. Мы также решили использовать файловые системы на SMR-дисках, поскольку за эти 3 года в ядре Linux было сделано много исправлений для оптимизации взаимодействия файловых систем с SMR.
диски.
Обзор архитектуры
blog.scaleway.com/2020/behind-the-scenes-c14-cold-storage/
