Загрузка больших файлов в кластер серверов

Question

У нас есть кластер из 4 веб-серверов, которые содержат несколько доменов, один из которых содержит довольно много видео. У нас также есть «промежуточный» сервер, на котором мы обычно синхронизируем/загружаем файлы, а затем из них rsync их все через скрипт bash на другие веб-серверы.

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

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

Посмотрел на менеджеров файлов ajax; загрузка через SFTP использовать файловый менеджер для перемещения файлов некоторые супер кнопка синхронизации

Answer 1

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

У вас может быть задание на работу cron в каталоге «Drop box» (или в каталогах), а затем он может запустить скрипт для выполнения репликации для вас.

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

Просто никогда не позволяйте пользователям «выбирать», куда он идет, скорее попросите их рассказать вам «зачем это», а затем у вас есть сценарии «знайте», где все идет и как их получить.

Это довольно простое веб-приложение, которое нужно делать, даже с помощью только одного perl CGI или любого другого. И задняя прокладка также проста.

Ответ комментарий ...

Если у вас есть веб-приложение, выполняющую загрузку в CGI, то вы, как правило, даже не получить «контроль» запроса до после того, как файл был полностью загружен. Вид зависит от того, какую технологию на стороне сервера вы используете. В любом случае легко «знать» веб-приложение, когда файл полностью загружен. Затем ваш процесс синхронизации может основываться исключительно на метаданных, чтобы фактически выполнять работу над файлом, и вы не создаете метаданные до тех пор, пока вы не переместили файл в соответствующую промежуточную область и т. Д.

Если вы просто используете FTP или scp для копирования файлов в промежуточные каталоги, то в решении есть два процесса: два. Первый контролирует входящий каталог, второй фактически копирует файлы.

Первый процесс может просто выглядеть следующим образом:

cd /your/upload/dir 
ls -l > /tmp/newfiles 
comm -12 /tmp/lastfiles /tmp/newfiles > /tmp/samefiles 
filelist=`awk '{print $9}' /tmp/samefiles` 
mv $filelist /your/copy/dir 
mv /tmp/newfiles /tmp/lastfiles 

Это работает так:

• Хватает список текущих файлов в директория входящей загрузки.
• Использует comm (1), чтобы получить файлы с не изменен с момента последнего запуска процесса .
• Использует awk (1) для получения имен неизменных файлов.
• Использует mv (1) , чтобы переместить файлы в ваш «этап» .
• Наконец, он принимает текущий список файлов и делает его последним списком для следующего прогона.

Магия здесь comm (1). 'comm -12 filea fileb' дает вам файл, содержащий строки, которые являются одинаковыми между двумя файлами. Если появится новый файл, тогда его размер изменится по мере его загрузки, поэтому, когда вы запустите 'ls -l' в следующую минуту, это строка не будет соответствовать новой строке - размер (минимально) будет отличаться , Таким образом, comm будет искать файлы, имена которых, имена файлов и размеры не изменились. После того, как у вас есть этот список, остальное довольно просто.

Единственное предположение, что этот процесс заключается в том, что ваши имена файлов не имеют пробелов в них (таким образом awk будет легко работать, чтобы получить имя файла из списка). Если вы разрешаете пробелы, вам понадобится немного более умный механизм для преобразования строки 'ls -l' в имя файла.

Кроме того, «mv $ filelist/your/copy/dir» не допускает пробелов в именах файлов, поэтому его тоже нужно будет изменить (вы можете перевернуть его в awk-скрипт, создав систему(), возможно).

Второй процесс также прост:

cd /your/copy/dir 
for i in * 
do 
    sync $i 
    mv $i /your/file/youve/copied/dir 
done 

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

После синхронизации он перемещает файл в другой каталог. Любые файлы, которые там отображаются, были «синхронизированы» должным образом. Вы также можете просто удалить файл, но я не хочу этого делать. Я бы поместил этот каталог, возможно, в программу «удалить файлы старше недели». Таким образом, если вы столкнулись с проблемой, у вас все еще есть исходные файлы где-нибудь, с которыми вы можете восстановить.

Этот материал довольно прост, но он также надежный.

Пока первый процесс выполняется «медленнее», чем загрузка (т. Е. Если вы запускаете его дважды подряд, вы уверены, что размер файла по крайней мере изменится), тогда время выполнения может быть каждый 1 минуту, каждый час, каждый день, что угодно. Как минимум, он безопасно перезапускается и самовосстанавливается.

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

Если процесс синхронизации «безопасен», вы в итоге просто копируете файлы дважды ... отходы, но обычно безвредны.

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

Это его мясо. Вы также можете использовать комбинацию (используя веб-приложение для загрузки с метаданными и используя процесс синхронизации, выполняемый автоматически через cron).

Вы также можете иметь простую веб-страницу, в которой перечислены все файлы в каталоге/your/copy/dir, чтобы люди могли видеть, были ли их файлы еще синхронизированы. Если файл находится в этом каталоге, он еще не завершил синхронизацию.

Answer 2

Поместите материал в каталог, предназначенный только для загрузки. Затем используйте rsync, чтобы скопировать его на разные серверы. Не беспокойтесь о перемещении файлов где-нибудь позже. Rsync будет использовать размер файла + время модификации, чтобы указать, нужно ли ему копировать файл из вашего Dropbox на другие серверы.

Ваш скрипт

#!/bin/bash 

servers="monkey cow turtle" 

for s in $servers 
do 
    rsync -r /path/to/dropbox $s:/place/to/putit 
done 

, который может быть запущен вручную или запустить хотя хрон. Вы можете заставить его создавать/проверять PID-файл, так что только один из них будет запускаться, ударяя синхронизацию с серверами параллельно, если вы хотите, и т. Д. Если файл был «загружен на полпути» при первом запуске скрипта, он будет завершен второй раз автоматически.