Мы добавляем в наше веб-приложение функцию, в которой загруженные файлы (на серверы приложений) обрабатываются фоновыми работниками (другими машинами).
Природа приложения означает, что эти файлы хранятся определенное время. Код, выполняемый на рабочем месте, знает, когда файлы становятся неактуальными, и должен удалить файл в это время.
Моим инстинктом было попросить наших системных администраторов создать общую папку с помощью NFS. Любой веб-сервер может сохранить файл в NFS, и любой работник может поднять его, чтобы работать с ним. Работа по сигнализации и хореографии осуществляется через данные в общем экземпляре Redis.
Про NFS мне сказали:
Обычно в таких случаях мы направляем все запросы загрузки на один веб-сервер. Сервер, который обрабатывает загрузки, запишет файлы в каталог, например / data / shared / uploads, который затем синхронизируется в режиме «только для чтения» со всеми другими серверами.
Похоже, им не нравится NFS. Я спросил, в чем были проблемы. Мне сказали:
Что касается NFS или любой другой совместно используемой файловой системы, проблема всегда одна и та же - возникает единственная точка отказа. Мало того, он также тесно связывает все серверы вместе. Проблемы с одним сервером могут повлиять на другие, что лишает возможности балансировки нагрузки и разъединения.
В настоящее время мы находимся в таком масштабе, когда у нас есть несколько веб-серверов и рабочих, но все еще одни экземпляры БД и Redis. Итак, у нас уже есть единые точки отказа, с которыми мы тесно связаны.
Является ли NFS настолько проблематичным, что приведенные выше аргументы верны?
Это зависит.
Конечно, NFS требует надежного файлового сервера, по крайней мере, для hard монтирует. С другой стороны, вы можете указать soft монтируется, и тогда удаленная файловая система становится ненадежной, но не блокирующей. Как и в случае любого хорошего инструмента, вам нужно решить, чего вы от него хотите и сможет ли он выполнить; это скажет вам, уместно ли это использовать.
Так: что вы хотите, чтобы произошло с вашим приложением, когда центральный файловый сервер недоступен? Если важно, чтобы все рабочие видели одинаковое представление об общем пространстве, тогда hard монтирования - правильный путь: если файловый сервер не работает, все должен прекрати работать. Любой обходной путь, который кэширует локально, чтобы избежать отказа файлового сервера, может привести к проблемам с некогерентностью кеша. Если вы выберете этот путь, обратите внимание, что разные люди делают (дорогие, но отличные) высокодоступные и высокопроизводительные NFS-серверы; если ваше приложение станет большим успехом, вы можете добавить одно из них, чтобы увеличить время безотказной работы и масштабирование.
Если, с другой стороны, когерентность кеша не является проблемой и достаточно, чтобы работники видели приблизительно правильную версию FS, тогда вам нужна FS, которая кэширует локально. Сама по себе NFS в этом не разбирается; их подход с централизованной загрузкой и периодической синхронизацией с локальным кэшем только для чтения является одним из примеров.
Если, с другой стороны, рабочие могут продолжать работу без просмотра центральной FS, когда она не работает, тогда soft крепления вполне могут быть тем, что вы хотите. После того, как вы восстановите FS, вы можете перезагрузить воркеры.
NFS по своей сути не является нестабильным или ненадежным. Как и любой хороший инструмент, он делает то, что обещал. По моему опыту, большинство проблем возникает из-за того, что люди не внимательно читают пакет перед его развертыванием; большинство хороших инструментов не расширяются автоматически, чтобы делать то, для чего они не были предназначены, хотя часто вы можете пытать их, чтобы они соответствовали. Определите, что вам нужно, и решите, подходит ли вам NFS.
Фон NFS
NFS хорош, пока работает, но имеет много проблем, поскольку NFS - это протокол, которому 31 год. Конечно, есть новые версии, которые что-то исправляют, но приносят с собой другие проблемы.
Основная проблема в том, как отказывает NFS. Поскольку и клиент, и сервер NFS основаны на ядре, большинство сбоев NFS приводят к перезагрузке всего сервера. В soft В режиме любой операции fs (чтение / запись / mkdir / ...) может произойти сбой в середине чего-либо, и не все приложения могут с этим справиться. По этой причине много раз NFS запускается в hard mode, что означает, что эти операции могут зависать вечно (накапливая все больше и больше зависающих процессов). Причины сбоя - это, например, короткие временные отключения сети, ошибки конфигурации и т. Д. Также вместо того, чтобы терпеть неудачу, он может все замедлить.
Если вы выбираете NFS по какой-либо причине, вам следует использовать его в режиме TCP, так как в UDP более 1 Гбит / с очень вероятно повреждение данных быстрее (страница руководства также предупреждает об этом).
Другие варианты
Что я бы посоветовал - если вам действительно не нужна NFS, не используйте ее. Я не знаю ни одного из ТОП-сайтов (FB, Google, ...), которые использовали бы NFS, поскольку обычно для Интернета есть более эффективные способы достижения этого.
Решение с синхронизацией, упомянутое в самом вопросе, нормально, обычно вы можете жить с задержкой в несколько секунд. Вы можете, например, передать файл загрузчику (который ожидает, что он будет активным) с веб-сервера, на который он был загружен. Таким образом, он видит это мгновенно, а другие пользователи увидят это через 1 минуту после запуска задания синхронизации.
Другое решение - хранить файлы в базе данных, которую при необходимости можно реплицировать. Или используйте какое-нибудь распределенное хранилище, например Amazon S3.
В вашем примере вы также можете хранить файлы на веб-серверах в защищенной папке, и работники будут получать их через HTTP, когда они хотят их обработать. Будет таблица базы данных с информацией о файлах и их местонахождении.