Взгляните на этот список http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_parallel_fault-tolerant_file_systems
и какой вариант лучше всего подходит для хранения большого количества статических файлов мультимедиа (с нормальным размером файла: 10–2 МБ для изображений и 5–500 МБ для видеофайлов) веб-сайта? (среди этих распределенных параллельных отказоустойчивых файловых систем)
Извините, что не отвечаю, но то, что вы спрашиваете, вызывает удивление. Если вам действительно нужна кластерная файловая система, я ожидаю какого-то объяснения того, почему.
Ответ: ничего из вышеперечисленного - используйте «файловую систему», которая не является файловой системой, совместимой с POSIX, а скорее является службой HTTP, ориентированной на хранение, репликацию и избыточность файлов. Примеры включают МогилеFS (самостоятельно, изначально созданный Брэдом Фицпатриком) или Amazon Простая служба хранения (размещенная служба) или BLOB-объекты Windows Azure (.NET, размещенная служба).
Судя по вашим предыдущим вопросам, вы, кажется, только начинаете, то есть с нуля. Если это так, то, вообще говоря, вам лучше купить хранилище файлов как услугу по рыночной цене, чем пытаться создать что-то самостоятельно. Обеспечить доступность и правильную репликацию в большом масштабе сложно.
Я согласен с Джеспером в этом вопросе, лично я бы использовал пару Zeus ZXTM в качестве согласованных кешей перед парой стандартных HTTP-серверов, обслуживаемых с одного общего монтирования NFS / CIFS.
Тем не менее, если вы хотите, чтобы это было так, у меня было много хороших впечатлений от Ibrix.
GlusterFS имеет очень хорошую репутацию, но может оказаться излишним для вашего приложения. Рассматривали ли вы возможность распределения файлов по парам серверов, например
2 ips для static1.yourdomain.com 2 ips для static2.yourdomain.com ...
Всегда два сервера для резервирования. Если какая-либо статическая группа получает слишком много трафика, добавьте в эту группу дополнительные серверы для масштабирования.