Веб сервер под фото. Какую архитектуру хранения выбрать с учетом масштабирования?

Question

[Igor A]

Всем привет!

Есть веб проект, в нем куча фоток.
Нужен совет, как правильно хранить фотки с учетом масштабирования?
Сейчас все фотки валятся в общий раздел веб сервера, места становится все меньше и меньше...
В планах купить машинку под статику, отдельный домен типа my-cdn.com
В nginx создать поддомен fs1.my-cdn.com и туда складывать файлы. Как закончится место еще один сервер fs2.my-cdn.com и т.д. В таблице фоток хранить цифру сервера (или fs1), чтобы понимать на какой машине лежит файл.
В линуксе не силен, поэтому больше ничего на ум не приходит. Веб сервер трудится под debian.

p.s. Буду рад любым ответам. Отмечу всех!:D Только без флуда плз.

Comments

[Александр Смирнов]

Флуда вроде нет, но и ваших комментариев тоже :)

[Igor A]

Александр Смирнов: ответил;) чуть позже отмечу решением, может еще что то дельное напишут;)))

Answer 1

[Александр Александрович]

Не рассматривали подключения хранилищей вроде S3?

Comments

[Александр Смирнов]

Мне кажется, что по цене будет сильно дороже.

[Igor A]

Александр Александрович: Согласен с Александр Смирнов: сторонние сервисы не хочется, да и с долларом не радужные времена. Сегодня 67, завтра 100 р, потом новый гемор обретать в плане переезда. Мне чужого опыта с валютной ипотекой было достаточно)) Это конечно не ипотека, но все же...
Если фоток было на 2-3 терабайта то долго не думал бы...

Answer 2

[Александр Смирнов]

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

Все запросы на доступ к статическим файлам нужно отправлять на этот узел, например, files.example.com. Тот, кто отправлят запрос даже не знает на каком сервере и т.д. находится файл и ему это не нужно знать.

Именно этот узел ведет учет файлов и знает на каком именно сервере у вас находится файл. Ваше приложение (сайт) посылает запрос на узел (files.example.com) на доступ к определенному файлу и этот узел смотрит у себя в базе где именно находится этот файл (на каком сервере и по какому адресу) и в ответ отдает этот адрес, например, srv01.files.example.com/f/405/502.jpg

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

В будущем для надежности можно сделать зеркальные узлы.

Comments

[Igor A]

Отличный совет, спасибо учту и скорее всего так и спроектирую!

Answer 3

[reallord]

Если миграция фото не предполагается, то Ваш вариант вполне надежен. При массовой миграции с сервера на сервер надо будет только сделать UPDATE колонки с названием сервера.

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

Comments

[Igor A]

Перемещаться они будут в крайнем случаем, и то раз в 3-4 года и не массово. А вот балансировщик был бы весьма кстати. Сейчас ручное управление. Какой номер укажу в конфиге, на такой серв и будут заливаться... Это реализовано, но пока не работает, т.к. время не подошло. Хочу изучить этот вопрос, чтобы исключить некоторые ошибки на этапе проектировании

[reallord]

С балансировщиком именно ЗАГРУЗКИ файлов все просто. Выбираете параметр по которому измерять балансировку. Обычно выбирают такие показатели:
- Среднюю нагрузку в IOPs на дисках сервера за 5-10 минут (где меньше, туда пишем)
- Свободное место на дисках сервера (проверка, можно ли туда писать)
- Объем трафика от ширины канала за 1-3-5-10 минут (IOPs может быть мало, места много, но канал забит на 99%)

Эти параметры собираются в таблицу, скриптом.
Раз в несколько минут срабатывает анализатор, который на основании этих данных выставляет вес каждой ноды для заливки файлов.

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

[Igor A]

reallord: понял, спасибо! более менее прояснилось все