Когда проект большой, то используетеся несколько Application Server, что ведет к тому, что загружаемые юзером файлы должны на какой-то отдельный(-ые) файловый(-ые) сервак(-и) загружаться.
Реализация это задачи состоит из нескольких пунктов:

1. Определить сервак, куда файлы грузить. Это может делать самописная пхп-щная функция, которые анализирует севраки на их загруженность и предложит свободный сервак.

2. Собственно загрузить файл на нужный сервак.
Тут я вижу несколько вариантов реализации.
а) уже в форме задавать в action нужный сервак. Тогда файл  сразу же куда надо попадет.
б) загружать сначала на текущий application server, а с него на нужный сервак перегонять файл вследствии. 


3. Сохранить в БД данные о сервере содержащем файл(или содержащих файл, если для load balancing файл на нескольких серверах зеркалируется). Впрочем зерклалирование файла на другие сервера это отдельная процедура, которая должны выполняться уже после того, как файл хотя бы на один сервак загружен.


Итак.. С пунктами 1,3 мне все более-менее понятно. Интересует второй пункт, а именно загрузка файла на нужные сервак. Быть может у кого-то есть идеи, как это наилучшим образом сделать?

Wowa, я бы делал так:
1.
2.а
3

Добавлено через 1 минуту и 5 секунд

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

Вова, существует множество способов. Все, разумеется, зависит от задачи.

Могу рассказать несколько.

1. Твой вариант "А". Думаю, мусолить его не имеет смысла, ввиду очевидности решения.
Резюме: минусов никаких не вижу как и плюсов.

2. Application Server (Upload Center, если угодно).
Итак, схема проста. Мы имеем клиентскую часть (форма), посредством которой происходит загрузка файла на Application Server (AS), которых может быть несколько - в зависимости от нагрузки и т.п.
AS вычисляет (скрипт, демон - не суть важно) какой из серверов файл-помоек достаточно подходит для хранения данных и загружает на него посредством WebDAV, например.

Резюме: из минусов - лишнее звено, с одной стороны. С другой стороны, повышается отказоустойчивость системы при использовании нескольких центров загрузки (или AS). Каким образом? 

Рассмотрим на примере варианта 1 и 2:

Представим ситуацию, когда у нас есть вебморда (FE, с пользовательским интерфейсом) и бэкенд часть, состоящая из AS и файл-помоек (FS), прикрытая балансером.

Один сервер FE - fe1; три сервера AS - as1, as2, as3; 10 серверов FS - fs1-fs10.

На основе предложения 1 при потере сервера fs3, если пользователю уже была сформирована форма на загрузку на 3-й сервер, он уходит в некуда.
На основе предложения 2 мы можем в реальном времени контролировать загрузку на FS. А поскольку AS у нас не один, то и отказоустойчивость данного звена повышена.

3. Предположим, загрузка идет по URL-у /upload/, балансер, при запросе данного URL-a, выбирает в качестве сервера самостоятельный FS из набора backend-ов и отправляет запрос ему. Думаю, дополнять не нужно, что сам сервер прописывает необходимые данные? В отличие от 2-го варианта, этот предполагает что-то большее, помимо легкого сервера для отдачи файлов, например Apache + PHP.

Это вкратце, что первое на ум приходит. Захочешь пообщаться на эту тему - стучи в асю. Все примеры рабочие, в продакшене (более 100 серверов).

Согласен это плюс в этом методе. Но минус - это дополнительный траф на AS и с него. А что если, перед непосредственной загрузкой файла посылать аякс-запрос на AS(или балансер) и определять наименее загруженный FileServer, туда и файл лить?

Добавлено @ 16:27
Насчет твоего третьего варианта: я не понял его отличие от второго.

Посоветую только по поводу первого пункта. На всех серверах запустить демон, который к примеру раз в 5 - 15 минут записывает данные о нагруженности в базу. Далее уже что бы получить менее нагруженный сервер брать данные из базы. Плюс этого метода таков, что не нужно каждый раз делать обход всех серверов на нагруженность.

Opik, идея интересна, но у меня есть мысль имхо еще интереснее:
на каждый из серверов положить пхп-скрипт, который текущую нагрузку выводить будет. Таким обрахом будет достаточно по http опросить сервера и получить нагрузку на текущий момент. Должно работать быстро и никакого коннекта к базе.. Быть может кто-то видит недостатки такого способа, тогда просьба сообщить.

лично я бы предпочёл этот вариант. 

На мой взгляд, если серверов предвидится достаточно большое количество, лучше собирать статистику на каждом сервере раз в определенный промежуток времени и накапливать эти данные в базе. С такими данными удобно работать. Опрашивать же сервера, лишние телодвижения. Хотя в нагрузку к статичным данным, можно еще тест сервера сделать, аля-балансер:-ты_здесь?серверN:-ага_я_тут. Я тебе кажется присылал даже схемку, которая на основе этих данных генерится. 
На основе этих же данных можно и определять сервера для регистрации. Естественно, нужно не забыть флажки offline (сервер сгорел или на ремонте, например) и disabled (запрещена регистрация, сервер не участвует в автоматических процессах и т.п.).


Опять же, все зависит от ситуации.

Это сообщение отредактировал(а) IZ@TOP - 16.3.2009, 13:46

Wowa, 
IZ@TOP, 
Вариант с опросом серверов вживую - обдумывал, но если серверов допустим 10, к каждому открыть свой сокет, считать... это намного дольше, чем просто  достать уже список из базы. а на каждом сервере раз в 5-15 минут записывать данные. от одного такого запроса имхо не убудет.  Пытаться грузить на него, сервер в оффе - ставим отметку что сервер упал и про него забываем, идем к след серверу. Но на том сервере все ещё висит скрипт, который если сервер все таки проснулся - отмечает и загрузку сервера в базу и снимает флаг оффа.

По-моему я об этом уже написал   И мало того, у нас такая система на 90+ серверах функционирует.

Это сообщение отредактировал(а) IZ@TOP - 19.3.2009, 13:24

а какая система стоит? ставь nginx, там это уже реализованно до вас

Nginx upload module имеешь ввиду? Он ведь сохраняет файлы локально и на бэкэнд(который может быть отдельным сервером) передает местонахождение файла. Т.е. все равно пропускает весь трафик через себя, а канал ведь не резиновый.

А если ставить несколько upload-серваков с nginx, то опять проблема балансинга стоит, как в примере выше.