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