"раздача" ftp сервера?
Есть ли FTP-сервер, который ведет себя как "передний конец распределения" для нескольких других серверов? Так что, когда я загружаю файл, он принимает содержимое, помещает их на весь список других FTP-серверов и (что важно) не подтверждает успешность загрузки, пока она не будет на всех других серверах?
В качестве альтернативы, если он мог бы подождать, пока (скажем) rsync реплицирует загруженный файл на все другие серверы, прежде чем возвращать успех (или, в более общем смысле, дождаться завершения какой-либо внешней команды, прежде чем возвращать успех).
Фон:
У нас есть приложение, которое загружает файлы в репозиторий (используя ftp или sftp), а затем сразу же дает команду устройству загрузить файл (через http).
Нам нужно, чтобы репозиторий был сбалансированным по нагрузке / высокодоступным / устойчивым. Наши корпоративные стандарты хостинга не разрешают совместное хранение.
Что мы делаем с другими связанными приложениями, так это имеем несколько серверов ftp / http и вручную загружаем файлы на все из них, прежде чем сообщить приложению (а затем и устройству) об их использовании. Балансировщик нагрузки распределяет запросы на загрузку. Это работает, потому что эти приложения не выполняют загрузку, вместо этого мы настраиваем их на использование URL-адресов ранее загруженных файлов. Проблемное приложение не делает этого, оно выполняет загрузку самостоятельно.
Мы могли бы использовать rsync или подобное для репликации файлов, загруженных проблемным приложением на несколько серверов, но использование этих файлов происходит немедленно, поэтому они могут не реплицироваться на другие серверы при получении запроса на них. Приложение не может быть настроено на задержку здесь.
Но если ftp-сервер не вернется, пока файл не будет реплицирован (либо самим сервером, выполняющим всю репликацию / загрузку на другие серверы, либо ожидающим завершения внешней команды), приложение не сообщит устройство, чтобы использовать файлы, пока мы не знали, что они были везде. И все это будет работать.
Любые указатели на подходящие серверы? Другие идеи для решения проблемы? (изменение приложения невозможно в сроки, к сожалению)
2 ответа
Если вам нужно использовать FTP, вы можете написать скрипт (возможно, программу Python или на любом языке, который предлагает удобную библиотеку FTP), который ваша программа загрузки запускает сразу после завершения загрузки на "главный" сервер. Этот скрипт будет сканировать FTP-сайты, которые должны быть реплицированы, и не будет выходить, пока не увидит эти файлы. На главном сервере у вас будет другой сценарий, который отслеживает файловую систему (например, с помощью inotify Linux), и когда он видит новые или измененные файлы, он загружает их на подчиненные серверы.
Кроме того, вы можете использовать реплицированную файловую систему. Это перемещает проблему с самодельного набора сценариев на уровне приложений на уровень, предназначенный для репликации файлов. Проверьте Tahoe-LAFS. Я цитирую соответствующее предложение:
Пользователи полагаются на серверы хранения для доступности. Зашифрованный текст кодируется при стирании в N долей, распределенных как минимум на H различных серверах хранения (значение по умолчанию для N равно 10, а для H - 7), так что его можно восстановить с любого K из этих серверов (значение по умолчанию K равно 3). Поэтому только сбой серверов H-K+1 (по умолчанию 5) может сделать данные недоступными.
Я думаю, что истинный ответ "нет". Вы просите больше, чем обеспечивает протокол FTP. Если клиент отправляет сегмент TCP, а сервер говорит: "Я получил", клиент отправляет следующий. Когда все они получены, передача завершена. В существующем протоколе нет никакой ловушки для сервера, который говорит: "Пожалуйста, подождите, пока я вознюсь".
Если вы изменили FTP-сервер таким образом, чтобы он замедлял TCP ACK до тех пор, пока он не записал байты повсюду, вы можете получить то, что хотите, но я боюсь, что вы также можете превратить свои передачи в еще большее количество обходов, чем необходимо, из-за к TCP раздвижное окно.
По сути, вы запрашиваете двухфазную фиксацию для операции передачи файлов внутри FTP, а этого не существует.
Возможно, вы могли бы вместо этого взглянуть на виртуализированную / реплицированную систему хранения, как предложено выше.