Lustre - кластерная ФС, AFS - сетевая ФС.<p>Если подробнее - то AFS относится примерно к тому классу, в котором сидят NFS, SMB, и win2K3 DFS. Основная их задача - качественный доступ к различным (раскиданным по сети) ресурсам, с соблюдением блокировок и напором на контроль доступа и централизованное управление. Здесь четко прослеживается модель "клиент-сервер" - большинство участников сетовой ФС являются клиентами, а под шары выделяются чаще отдельные серваки. С точки зрения производительности для такой ФС критериями являются пропускная способность сервер-клиент и количество поддерживаемых коннектов. Масштабируется такая ФС вертикально - более шустрым железом. Надежность тоже поддерживается на уровнях ниже сетевой ФС (RAID, репликация средствами ОС и администратором 24/7 на мобильном =)
<p>Кластерных ФС известно негусто - навскидку Lustre, Google FS (+Hadoop), что-то было у IBM.
<p>Отличительная особенность - все участники ФС унифицированы и являются и серверами и клиентами ФС (это именно особенности реализации, конечно же можно и настроить для работы как "несколько серверов - много клиентов", но преимуществ в этом случае не получите, скорее наоборот)
<p>Обычный принцип действия - работа на уровне блоков: разбитый на блоки файл "размазывается" по нескольким серверам, при его чтении клиент сам собирает блоки в файл. (<a href="http://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi?az=show_thread&om=36689&forum=vsluhforumID3&omm=13">Комментарий Алексея</a>: Это Google FS & RedHat GFS.. в люстре оперируют понятием объект).
<p>Критерии оценки таких ФС - общая пропускная способность ФС кластера (то есть сколько гб/с крутится в пределах кластера) и латентность (задержка между запросом файла и его получением). Также тут важна надежность - все блоки реплицируются на уровне ФС, вылет нода не сказывается на работе кластера.
<p>ФС этого класса очень разные. Lustre заточена под hiperf вычисления с низкой латентностью, посему пользуют что-нить типа InfiniBand и нестандартные MPI. Lustre замонтированая представляет из себя слегка урезaную ext3 для 2.4 ядер, для 2.6 используется ldiskfs которая значительно ближе к ext4.
<p>Google FS и Hadoop - вообще с классической точки зрения не ФС, ибо ничего не монтируют а предоставляют RPC API для разработчиков. Рассчитаны они на гигантские объемы информации, работу в основном на чтение большими блоками (в мегабайтах, стандартный блок такой ФС - 32-64Мб) и в очень больших количествах.
<p>Также есть shared storage FS - эти нужны при работе нескольких (многих) серверов с внешними дисковыми массивами. Основная задача - обеспечить быструю и правильную блокировку совместного доступа (via SAN, iSCSI, SCSI). Без них фактически каждый сервер должен работать со своим личным выделенным на массиве разделом. Из известных - GFS от RedHat, Oracle Cluster File System, PolyServe и Veritas CFS.
<p>RedHat GFS - раздает raw девайс и пытается управлять блокировками на уровне блоков, без учета логической организации.
<p>gfarm изначально позиционирует себя для таковой модели использования: есть много данных, распределенных по нодам,
нужно их все параллельно обработать. В случае люстры и подобных - compute node сначала фетчит себе данные из кластерной фс, обрабатывает и возвращает обратно (отсюда требования к пропускной способности и латентности). В случае gfarm - задание по обработке для compute нода попадает благодаря gfarm именно на тот нод, где локально лежит одна из реплик требуемых данных. Соответственно по сети происходит трансфер задания на обработку данных , а не самих данных. (например, <a href="http://datafarm.apgrid.org/pdf/GCA3059-xiaohui.pdf">здесь</a>, да и вообще <a href="http://datafarm.apgrid.org/paper.en.html">тут</a>- большинство тем именно parallel computing, а не distributed fs).
<p>Некая сборная информация есть <a href="http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems">в wikipedia</a>.
URL: http://www.opennet.dev/openforum/vsluhforumID3/36689.html#11
Обсуждается: http://www.opennet.dev/tips/info/1382.shtml