S3 Storage. Объектное хранилище

NAS. Сетевые хранилища
1

Самохостятам привет!

В этой теме Вы найдете:

  • что такое S3?(базовую информацию)
  • ссылки на полезные видео по тематике
  • кому стоит обратить внимание на объектные хранилища?
  • как развернуть самому? проекты для самохостинга S3 хранилища?
  • open-source проекты поддерживающие S3

Уверен, что у Вас будет чем дополнить, так что смело рассказывайте о Вашем опыте использования объектных хранилищ, какие вы себе арендуете или развернули?
Для каких приложений используете?

Ну и само собой - чуть позже будет ролик на эту тему + отдельные видео по вариантам локального запуска s3

s3storage2
s3storage21280×720 180 KB

1. Что такое S3 ?

S3 (Simple Storage Service) — это облачное объектное хранилище, предназначенное для хранения неограниченного объема неструктурированных данных(файлов, изображений, видео, бэкапов). Данные размещаются в контейнерах (бакетах) как самостоятельные объекты с уникальными ключами, доступ к которым осуществляется через API, что обеспечивает высокую масштабируемость и надежность.

2. Полезные ссылки

3. Кому может быть интересно объектное хранилище?

  • Вам нужно временное большое хранилище, нет смысла покупать диски
  • Вы разработчик(огромное кол-во бизнесов и проектов испольует именно S3)
    при этом Вы можете развернуть тестовый стенд, чтобы проверять s3 api локально, не платя за операции облачному провайдеру
  • Вы энтузиаст изучающий технологии

4. Можно ли развернуть себе дома?

Да, есть проекты, которые позвляют развернуть S3 api supported, но стоит помнить, что поддержка S3 API не делает из Вашего хранилища на одной ноде - AWS S3 =)
Более развернуто - поговорим в видео

5. Какие open-source проекты поддерживают S3?

  • :white_check_mark: Proxmox Backup Server(PBS)
  • :white_check_mark: Rclone
  • :white_check_mark: Restic
  • :white_check_mark: Duplicity
  • :white_check_mark: Discourse
  • :white_check_mark: Nextcloud | Both Primary Storage and External Storage are supported
  • :white_check_mark: Coolify
  • :white_check_mark: Dokploy
  • :white_check_mark: Peertube | Supported website endpoint, proxifying private videos - unsupported
  • :white_check_mark: Mastodon | Natively supported
  • :white_check_mark: Matrix | Tested with synapse-s3-storage-provider
  • :white_check_mark: ejabberd | mod_s3_upload
  • :white_check_mark: Ente | Natively supported
  • :red_question_mark:Pixelfed | Natively supported
  • :white_check_mark: Pleroma | Natively supported
  • :white_check_mark: Lemmy | Supported with pict-rs
  • :red_question_mark:Funkwhale | Not yet tested
  • :red_question_mark:Misskey | Not yet tested
  • :red_question_mark:Prismo | Not yet tested
  • :red_question_mark:Owncloud OCIS | Not yet tested
  • :white_check_mark: Hugo | Publishing logic is integrated in the tool
  • :white_check_mark: Publii | Require a correctly configured s3 vhost endpoint
  • :white_check_mark: Generic Static Site Generator | Works for Jekyll, Zola, Gatsby, Pelican, etc.
2

Еще бы на этот проект посмотреть

По виду функционала не очень много, но зато быстро

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

Когда стоит использовать S3

  1. Есть сервис, например, чат или база знаний или форум, база данных весит не очень много и может спокойно хоститься на виртуалке с фиксированным диском. Увеличение диска сложное или дорогое - подключаем облачное S3 хранилище для пользовательских файлов, картинок, аттачей и платим только за то, что реально было загружено.
  2. Файлов оооочень много, масштабируемость и надежность обычных дисков ограничена, мы добавляем уровень абстракции в виде S3, который сам шардирует, реплицирует, дублирует
  3. Программный обмен файлами между разными сервисами - пользователь отправил форму с аттачем, сервис антивирусной проверки проверил файл, заявка пошла обрабатываться в CRM - все эти системы работают с файлом по ID, доступ к шаре по самбе тут выглядит очень костыльным, хранение в БД и API, по сути, является аналогом S3, но менее эффективным. Либо 2 сценарий использования: BigData, это когда у нас есть набор данных в S3 бакете, а потом мы берем аналитический софт и “натравливаем” на эти данные, либо можем обучать ИИ модели на основе датасетов в S3
  4. Для K8S и 12 factor app где персистентность данных в рамках пода очень сомнительна, горизонтальное масштабирование больное, надежность низкая
  5. Когда есть очень крутое хранилище с разными политиками, ACL и CDN. Например, можно настроить хранение файлов на очень быстром NVME, быстром SSD, медленном HDD или очень медленном ленточном накопителе. При этом, интерфейс доступа будет одинаков, можно хранить новые файлы на быстром хранилище, т.к. к ним будет чаще доступ (по статистике), а через месяц/полгода/год перемещать в условный архив, где вероятность запроса документа крайне мала.
  6. Если требуются прям крутые фишки S3, например, получение прямого доступа к файлу по ссылке или загрузка файла по ссылке. Но это для высоконагруженных систем, когда ваш бэкенд обрабатывает сотни запросов в секунду и вместо того, чтобы принимать файл от пользователя и грузить его в хранилище можно сгенерировать ссылку и отдать клиенту, браузер загрузит файл в хранилище самостоятельно и проинформирует об этом бэкенд. Ну т.е. тут должна быть поддержка как на бэке,так и на фронте.
  7. В плане бэкапов у меня есть опыт скриптового бэкапирования сервисов и заливки дампа в облачное S3 хранилище. Тогда при потере сервера бэкап остается, а на вопрос “можешь скинуть мне дамп базы данных для локального разворачивания?” я отвечаю “нет, там есть перс. данные” или “да, перс. данных нет, поэтому, вот ссылка на скачивание ночного дампа из облака и вот пароль, ссылка действует в течение часа”

Минусы S3 и когда не стоит использовать

  1. Надо понимать, что это еще один уровень абстракции, лишние операции не добавляют IOPS хранилищу. Если у вас миник с 1 NVME диском и вы хотите развернуть на нем форум, то развернутый на нем же S3 для хранения файлов форума не даст профита, но увеличит нагрузку и размер хранилища т.к. будет доп обработка и хранение метаданных, на маленьких файлах многие S3 хранилиза сильно деградируют. Если у вас 1 диск на сервере, то с S3 он закончится раньше, чем без него, а масштабироваться некуда.
  2. В плане облачных S3 хранилищ, исходя из 1 пункта, пользователь платит за загрузку файла, хранение файла, получение списка файлов, получение файла, удаление файла. При частом запросе файлов из бакета в том же AWS рекомендуется подключать более дешевый CDN, который скачивает к себе файл из S3 за условный рубль, а потом отдает пользователям с локального датацентра за копейку. Тот же PBS хоть и умеет работать с S3, но все равно использует локальный кеш для быстрого доступа к файлам и, по слухам, оооочень активно взаимодействует с S3 хранилищем, что может привести к выставлению огромных счетов за использование API
  3. Надо понимать, что S3 хранит все равно файлы на диске, но при этом еще и их метаданные в БД, а это значит, что у нас становится больше точек отказа. S3 это не волшебная пуля и не даст надежности просто после установки, но он позволит легче реализовать доступ к отказоустойчивой системе, которую вы построили самостоятельно.

Из этой же серии

  • RAID это про отказоустойчивость дисков, а не про безопасность данных и бэкапирование
  • LVM это про удобную нарезку, а не про отказоустойчивость
  • SAAS и AWS like это про удобство и какую-то надежность (за которую отвечаете не вы), а не про дешевизну
  • Self-hosted это не бесплатно, а плата собственным временем, электроэнергией, оборудованием вместо перевода денег кому-то
3

Полезный комментарий YouTube зрителя

4

еще один полезный вопрос\ответ зрителей YouTube

5

еще один способ применения и комментарий реальной эксплуатации

6

Тут таки стоит разделять 2 понятия и согласен с одним из комментаторов, что слишком много облаков было.

В рамках самохостинга надо подразумевать 2 независимые задачи, и в видео они были как-то переплетены и размазаны (то рассказывается про AWS, то про проблемы minio, то опять про облачные решения)

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

  1. Использование облачного S3 для разгрузки/бэкапироания хоум лабы - тут мы говорим только про то, что есть такие сервисы, они предоставляют такие функции по таким ценам и мы используем их для бэкапа своей лабы, например, для 1 в 3-2-1 бэкапировании
    1.1. Раздача ISO файлов/картинок
    1.2. Создание бэкапов
    1.3. Хранение фоток и аттачей

  2. Развертывание S3 хранилища в своей лабе для использования в приложениях. Тут мы ни слова не говорим про AWS и селектел, а сразу берем и устанавливаем S3 хранилища у себя
    2.1. Обмен файлами между внутренними сервисами
    2.2. Stateless сервисы: например, разворачиваем в кубере stateless форум, файлы храним в S3 хранилище, базу данных в отдельном Managed Database. Statefull в кубере работает не очень хорошо и не надежно + часто хранилище персистентное хранилище выделяется сразу

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

7

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

Хостинг статических сайтов

У себя на github приводил пример gitlab pipeline для загрузки билда на s3.

Работает так: собираем фронтенд, статический сайт по типу gitbook, заливаем его на s3 облако, в идеале перед ним ставим CDN для снижения количества запросов (можно даже CloudFlare)

Микроконтент

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

Холодные бэкапы

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

В качестве хранилища файлов для приватных облаков

Таки интерфейс доступа к S3 файлам не очень то крут. Можно развернуть что-то типа cloudreve на минимальном сервере (он если без семантического поиска, очень легкий) с хранением файлов на S3, тогда мы получим относительно дешевое приватное облако неограниченного объема и оплатой за фактически потребленные ресурсы

Для синхронизации Obsidian базы знаний

Я писал про мои плагины и там есть плагин синхронизации через S3 бакет, что дешевле и стабильней, чем поднимать свой сервер

Облачное бэкапирование

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

Хранение логов

Тот же AWS может хранить логи в S3 бакете для удобного доступа к ним из одного места. Но… это опять же на минималках, может есть смысл рассмотреть ELK или Victoria Logs

Облачные функции и облачная обработка

Если чуть расширить область применения облачного S3, то провайдеры типа AWS, GCP позволяют писать облачные функции, это когда код выполняется на общих серверах с оплатой за время выполнения. Я встречал примеры когда, например, мы создаем 2 бакета, пишем функцию, которая берет файл из одного бакета, обрабатывает его и выгружает в другой бакет. Так работают всякие конвертеры файлов и прочие обработчики. Можно прям повесить запуск функции на добавление нового файла. Суть в том, что мы платим только за факт вызова и если это происходит не очень часто и обработка не очень сложная, то это будет намного дешевле, чем аренда выделенного или виртуального сервера.

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

Заключение

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