Я не знаю, как обеспечить отказоустойчивое решение при обслуживании загруженных файлов.
У меня есть один балансировщик нагрузки с двумя серверами (webserver1, webserver2) в качестве узлов, на обоих запущен Apache2, и база данных, доступная для обоих узлов, но не для WAN.
В конечном итоге веб-серверы должны быть масштабированы, а база данных сегментирована.
В настоящее время я запускаю запланированный rsync от webserver2 к webserver1, webserver1 является главным, файлы которого распространяются на webserver2. В настоящее время есть только два сервера, хотя это предназначено для масштабирования.
У меня есть три каталога в моем веб-приложении, которые должны использоваться для файлов, сгенерированных пользователями, которые загружаются как на веб-сервер1, так и на веб-сервер2 (это исключения для операции rsync).
В настоящее время у меня есть 3 общих ресурса NFS, доступных с веб-сервера1, указанные общие ресурсы монтируются веб-сервером2.
Я новичок в области распределенной архитектуры, но из того, что я вижу, решение NFS приводит к единственной точке отказа - я изменил вес в балансировщике нагрузки, чтобы убедиться, что веб-сервер2 получает больше трафика, поэтому нагрузка на webserver1 не должна быть выше.
У меня больше нет бюджета, чтобы тратить на какие-либо облачные решения (например, Amazon S3), поэтому мой единственный выход - предоставить бесплатное программное решение.
Есть ли жизнеспособные программные решения? Моим наивысшим приоритетом является устранение единой точки отказа при минимальной нагрузке на сервер.
О репликации данных между изолированными файловыми системами можно многое сказать с точки зрения производительности и устойчивости. Что именно не так с вашей текущей настройкой?
Я бы держался подальше от общих файловых систем (GFS2, OCFS и т. Д.). Они не дают очень хорошей производительности. Репликационная файловая система, такая как Lustre или AFS, предлагает разумный компромисс между производительностью и функциональностью для такого рода ролей.
Есть ли причина, по которой вы хотите хранить данные в файловой системе? Кластер NoSQL db может быть намного проще. И, конечно же, есть HDFS.
DRBD в мастере / мастере покроет большинство ваших потребностей, у него нет высоких накладных расходов, и любой сервер может писать или читать и будет работать без присутствия другого.
Приступить к работе немного сложно, но это решение, которое соответствует большинству, если не всем вашим требованиям.
В этой ситуации мне нравится использовать выделенные серверы NFS ... Опасения по поводу единой точки отказа можно компенсировать определенными проектными решениями ...
Если инфраструктура виртуализирована, у меня будет пара виртуальных балансировщиков нагрузки (или один аппаратный LB), уровень веб-серверов, БД (возможно) и внутреннее хранилище. Это хранилище может быть предоставлено виртуальным сервером NFS, автономным физическим устройством, NAS и т. Д. Я редко использую кластерные файловые системы.
Не похоже, что вы находитесь в таком масштабе, когда это должно быть проблемой. Я понимаю мотивацию к планированию большего масштаба, но нет действительно что-то не так с тем, что вы делаете. Впрочем, экспорт NFS тоже не должен так негативно сказаться на производительности сервера ...
Похоже, вы ищете что-то вроде МогилеFS. Это распределенный реплицированный файловый ресурс на основе webdav. Имейте в виду, что это несовместимо с POSIX, и ваше приложение должно быть «осведомленным о могиле». Он был создан для обмена изображениями для веб-сайтов.