Горизонтальная масштабируемость статики?

Question

[Аркадий]

Интересует вопрос, продумываю архитектуру.


Имеется несколько серверов для раздачи статики, s1. s2. s3 — например. Есть сервер с бэкендом (main) на котором крутится сам сайт и демон собирающий картинки с интернета (или же эти картинки загружаются пользователями).


На каждом из серверов s1, s2… «висит» некий демон слушающий TCP порт и принимающий статику, у которого есть две команды put и delete.


Пользователь загружает картинку на сервер (main), далее сервер выбирает (как? хеш имени файла? от ID пользователя?) сервер и трех и загружает на него картинку командой «put file.png» в ответ получая полный путь «success /2/4/file.png» который теперь доступен как s1.hostname.com/2/3/file.png


Плюс можно сделать синхронизацию s1, s2, s4 через rsync между собой (например если один из них отвалится, но как будет выглядеть смена сервера у файлов на main?)


Насколько это криво, велосипедно, etc… какие подводные камни?

Answer 1

[archibaldtelepov]

А может, стоит использовать
www.mongodb.org/display/DOCS/GridFS
или
www.danga.com/mogilefs/

может, ну его, самодельный велик?

Answer 2

[max_rip]

А не лучше серверу статики сделать один домен, а разделять нагрузку между самими серверами через ДНС или каким либо другим способом. В таком случае места на серверах будет заниматься больше, но все это станет более прозрачно для основного сервера.

Comments

[Аркадий]

А как туда загружать контент? Так-же по выдачи ДНС? Ведь может получится так что при загрузке получили один сервер а при запросе пользователю отдало другой, но синхронизироваться еще не успели.

[max_rip]

Загружать на все через ваш put, разве что дожидаться ответа с адресом не надо, а формировать путь самостоятельно. Какой смысл сильно делить статику. В вашем случае чисто гипотетически запросы клиента могут выпасть все на один сервер и профита вы от этого не получите.
Ну синхронизировать можно и через rcsync, но нагрузка на винты будет постоянная. Смысла не вижу в таком. Проще поставить сервис который будет контролировать распределение статики между зеркалами.

Answer 3

[Maxim Avanov]

www.ioremap.net/projects/elliptics

Answer 4

[Пума Тайланд]

Сделайте простой шардинг с перекрытием.

Answer 5

[Wott]

со статикой на отдельном домене, точнее то для чего это делается, есть 2 ньюанса
1. количество запросов на домен должно быть <= 8
2. загрузка сервера

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

Если же говорить про загрузку сервера, то можно пользовать шардинг, но возможно CDN будет эффективнее, хотя это тоже шардинг :)

Загрузку же пользовательской графики надо делать на основной сервер — мастер, и после уже с него шарить на группу серверов в соответствии с шардингом. Можно иметь мастера в группе или общего — надо смотреть как будет лучше. Но чем проще — тем лучше.