Здравствуйте. Планируется проект, в котором пользователи могут загружать огромное количество различных изображений. Допустим я выделил для этих целей отдельный сервер с поддоменом st.site.com, через некоторое время этот сервер становится узким местом, в том плане, что на нём просто заканчивается свободное место жесткого диска и вертикальное масштабирование уже достигло потолка. Допустим я принимаю решение использовать горизонтальное масштабирование и добавляю еще один сервер для хранения статики.

Вопрос, как это может выглядеть на практике? Новый сервер для статики вешается на новый ip с новым поддоменом, например st1.site.com или как?

Как это реализовано в соц.сетях, например в VK?

Я так понимаю, что там фотографии грузятся на разные сервера, например на cs608726.vk.me(95.142.196.123) и cs608727.vk.me(95.142.196.124). То есть получается, что VK постоянно наращивает объемы свободного места под медиа-контент путем добавления всё новых серверов с новыми названиями поддоменов. Правильно ли понимаю?

Как я вижу реализацию подобного механизма. Есть таблица (например mysql или redis какой-нибудь неважно) со списком всех контент-серверов проекта. Когда пользователь хочет загрузить картинку (или другой медиа-контент), то рандомно (или по какому-то алгоритму) выбирается одна из записей этой таблицы с названием поддомена данного сервера, после чего происходит загрузка этого медиа-контента на данный сервер и вставка в базу данных информации об этом изображении, где в одном из полей и указывается на какой сервер оно было загружено. А чтобы отобразить медиа-контент на странице, получаем из базы данных имя сервера куда было загружено изображение и строим путь до него. Скажите, примерно такой подход применяется на сайтах с огромным количеством медиа-контента или какой-то совершенно иной?

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

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

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

vagrand, хорошо, а скажи реально ли сделать вот так.

Скрипт генерирует html-страницу, в которой есть картинки описанные например так <img src="/uploads/blablabla.jpg", соответственно браузер делает запрос к фронтенд-серверу nginx с урлом /uploads/blablabla.jpg, чтобы получить эту картинку, но такой картинки именно на этом сервере с php-скриптами не существует, у нас просто настроен nginx так, что он распознает этот урл и передает управление в location, который делает проксирование к нужному контент-серверу с этой картинкой возвращая её клиенту.

Вот например директива proxy_next_upstream позволяет определить в каких случаях передать запрос следующему серверу. т.е. указав proxy_next_upstream http_404 мы говорим, что если контент-сервер отвечает, что у него нет такой картинки, то мы опрашиваем следующий и так пока не найдем.

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

Возможно же так сделать?

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

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.