Stuart Midgley адаптировал (http://comments.gmane.org/gmane.comp.file-systems.lustre.use...) код распределенной файловой системы Lustre (http://www.lustre.org/) для работы в качестве FUSE модуля (https://mail.clusterfs.com/wikis/lustre/fuse) (файловая система работающая на уровне пользовательского процесса), не требующего для своей работы модификации ядра и позволяющего использовать Lustre в системах отличных от Linux (например, под FreeBSD и MacOS X).URL: http://comments.gmane.org/gmane.comp.file-systems.lustre.use...
Новость: http://www.opennet.me/opennews/art.shtml?num=9835
А кто-нить сравнивал работу существующих распределенных ФС? Laster и Coda, например?
Не думаю. Мало кто этим пользуется. Хотя я бы хотел посмотреть такой обзор.
Я использовал коду на двух компах...
Работает она очень тормазно, это мое субъективное мнение. загрузка ЦП иногда
достигает чуть-ли не придела. Следует пробовать Lustre, по крайней мере, как
они говорят она отлично масштабируется, да и её использует HP в своих storageworks'ах,
а это уже о чем-то говорит.
6 железок из top10 ( http://top500.org/lists/2006/11 ) используют lustre.
есть ограничения, к примеру выше 10к клиентов не очень хорошо чувствует себя.
Но я думаю у 99% юзеров 10к клиентов не будет :)
Во всяком случае сейчас IMHO, это лучшая сетевая FS из существующих.
А что скажете про AFS?
про OpenAFS наверно?
ничего не скажу - на сайте 0 документации по архитектуре, а копать исходники не хочется.
хотя приятно что у OpenAFS есть порт на Win32, что не закончено у люстры.
AFS не совсем сюда - не той породы.
Lustre - кластерная ФС
AFS - сетевая ФС.Если подробнее - то AFS относится примерно к тому классу, в котором сидят NFS, SMB, и win2K3 DFS. Основная их задача - качественный доступ к различным (раскиданным по сети) ресурсам, с соблюдением блокировок и напором на контроль доступа и централизованное управление. Здесь четко прослеживается модель "клиент-сервер" - большинство участников сетовой ФС являются клиентами, а под шары выделяются чаще отдельные серваки. С точки зрения производительности для такой ФС критериями являются пропускная способность сервер-клиент и количество поддерживаемых коннектов. Масштабируется такая ФС вертикально - более шустрым железом. Надежность тоже поддерживается на уровнях ниже сетевой ФС (RAID, репликация средствами ОС и администратором 24/7 на мобильном =)
Кластерных ФС мзвестных негусто - навскидку Lustre, Google FS (+Hadoop), что-то было у IBM.
Отличительная особенность - все участники ФС унифицированы и являются и серверами и клиентами ФС (это имеенно особенности реализации, конечно же можно и настроить для работы как "несколько серверов - много клиентов", но преимуществ в этом случае не получите, скорее наоборот)
Обычный принцип действия - работа на уровне блоков: разбитый на блоки файл "размазывается" по нескольким серверам, при его чтении клиент сам собирает блоки в файл.
Критерии оценки таких ФС - общая пропускная способность ФС кластера (то есть скока гб/с крутится в пределах кластера) и латентность (задержка между запросом файла и его получением). Также тут важна надежность - все блоки реплицируются на уровне ФС, вылет нода не сказывается на работе кластера.
ФС этого класса очень разные. Lustre заточнена под hiperf вычисления с низкой латентностью, посему пользуют что-нить типа InfiniBand и нестандартные MPI. Люстра замонтированая представляет из себя слегка урезaную ext3.
Google FS и Hadoop - вообще с классической точки зрения не ФС, ибо ничего не монтируют а предоставляют RPC API для разработчиков. Рассчитаны они на гигантские объемы информации, работу в основном на чтение большими блоками (в мегабайтах, стандартный блок такой ФС - 32-64Мб) и в очень больших количествах.Также есть shared storage FS - эти нужны при работе нескольких (многих) серверов с внешними дисковыми массивами. Основная задача - обеспечить быструю и правильную блокировку совместного доступа (via SAN, iSCSI, SCSI). Без них фактически каждый сервер должен работать со своим личным выделенным на массиве разделом. Из известных - GFS от RedHat, Oracle Cluster File System, PolyServe и Veritas CFS.
В общем, тут выбор ФС намного сильнее зависит от задачи, по сравнению с выбором между ext3/reiser4 =)
Если где ошибся, поправьте =)
да, некая сборная инфа есть здесь: http://en.wikipedia.org/wiki/List_of_file_systems#Distribute...
>Кластерных ФС мзвестных негусто - навскидку Lustre, Google FS (+Hadoop), что-то было
>у IBM.
>Отличительная особенность - все участники ФС унифицированы и являются и серверами и
>клиентами ФС (это имеенно особенности реализации, конечно же можно и настроить
>для работы как "несколько серверов - много клиентов", но преимуществ в
>этом случае не получите, скорее наоборот)
помоему ты ошибаешся...>Обычный принцип действия - работа на уровне блоков: разбитый на блоки файл
>"размазывается" по нескольким серверам, при его чтении клиент сам собирает блоки
>в файл.
Это Google FS & RedHat GFS.. в люстре оперируют понятием объект.>ФС этого класса очень разные. Lustre заточнена под hiperf вычисления с низкой
>латентностью, посему пользуют что-нить типа InfiniBand и нестандартные MPI. Люстра замонтированая
>представляет из себя слегка урезaную ext3.
ext3 был только для 2.4 ядер, для 2.6 используется ldiskfs которая значительно ближе к ext4.
>Также есть shared storage FS - эти нужны при работе нескольких (многих)
>серверов с внешними дисковыми массивами. Основная задача - обеспечить быструю и
>правильную блокировку совместного доступа (via SAN, iSCSI, SCSI). Без них фактически
>каждый сервер должен работать со своим личным выделенным на массиве разделом.
>Из известных - GFS от RedHat, Oracle Cluster File System, PolyServe
>и Veritas CFS.
RedHat GFS вобще странная FS - раздает raw девайс и пытается рулить блокировками на уровне блоков, без учета логической организации.
спасибо за правку
>>Кластерных ФС мзвестных негусто - навскидку Lustre, Google FS (+Hadoop), что-то было
>>у IBM.
>>Отличительная особенность - все участники ФС унифицированы и являются и серверами и
>>клиентами ФС (это имеенно особенности реализации, конечно же можно и настроить
>>для работы как "несколько серверов - много клиентов", но преимуществ в
>>этом случае не получите, скорее наоборот)
>помоему ты ошибаешся...
да, несколько неверно выразил (привычка к hadoop). Речь больше идет об унификации параллельных oss. Однако в кластерах имеет смысл использовать их же как вычислительные ноды/клиенты.
>>Обычный принцип действия - работа на уровне блоков: разбитый на блоки файл
>>"размазывается" по нескольким серверам, при его чтении клиент сам собирает блоки
>>в файл.
>Это Google FS & RedHat GFS.. в люстре оперируют понятием объект.
Да, так и есть ) хотя разница не столь катастрофична.
>>ФС этого класса очень разные. Lustre заточнена под hiperf вычисления с низкой
>>латентностью, посему пользуют что-нить типа InfiniBand и нестандартные MPI. Люстра замонтированая
>>представляет из себя слегка урезaную ext3.
>ext3 был только для 2.4 ядер, для 2.6 используется ldiskfs которая значительно
>ближе к ext4.
принято
>да, несколько неверно выразил (привычка к hadoop). Речь больше идет об унификации
>параллельных oss. Однако в кластерах имеет смысл использовать их же как
>вычислительные ноды/клиенты.
насколько мне известно в случае lustre такого не делают.>>>Обычный принцип действия - работа на уровне блоков: разбитый на блоки файл
>>>"размазывается" по нескольким серверам, при его чтении клиент сам собирает блоки
>>>в файл.
>>Это Google FS & RedHat GFS.. в люстре оперируют понятием объект.
>Да, так и есть ) хотя разница не столь катастрофична.
достаточно сильная - ибо сказывается на операциях с metadata.
в лучае RedHat GFS ты получаешь практически включенный режим sync на файловой системе - что при числе нодов больше 4-8 дикий тормоз.
А что можете сказать про gfarm ?
Планируем использовать его для распределенного хранения редко изменяемой статики крупного web-портала на FreeBSD.Но пока еще не начали внедрение, возможно стоит попробовать lustre ?
Может кто-нибудь описать плюсы/минусы в сравнении с тем же gfarm ?
К сожалению, люстра и бсд несовместимы.
Вообще, был отличный отзыв о продакшн использовании именно в веб-проекте, под статику (несколько десятков нодов)
Советую самостоятельно оттестироватьа GFarm говорит так:
The major difference from the
Grid Datafarm architecture is that Lustre separates file sys-
tem nodes from clients (or compute nodes). This reflects
the fact that Lustre assumes an operating environment of
large clusters and intra-enterprise high bandwidth connec-
tivity, where moving data to computation makes sense, in
contrast to Gfarm where data may reside distributedly in
wide area, making exploitation of local high bandwidth by
moving computation to data essential.то бишь gfarm изначально позиционирует себя для таковой модели использования:
есть много данных, распределенных по нодам,
нужно их все параллельно обработать. В случае люстры и подобных - compute node сначала фетчит себе данные из кластерной фс, обрабатывает и возвращает обратно (отсюда требования к пропускной способности и латентности)
В случае gfarm - задание по обработке для compute нода попадает благодаря gfarm именно на тот нод, где локально лежит одна из реплик требуемых данных. Соответственно по сети происходит трансфер задания на обработку данных , а не самих данных. (например, http://datafarm.apgrid.org/pdf/GCA3059-xiaohui.pdf, да и вообще тут- http://datafarm.apgrid.org/paper.en.html большинство тем именно parallel computing, а не distributed fs )Касательно статики и веб-использования - там обработки нет никакой, нужно именно фетчить. То есть не та задача, под которую проектировался gfarm (хотя вполне вероятно, что подходит =).
Относительно люстры - она рассчитана именно на такое использование, там несколько релизов назад сделали оптимизацию под "много маленьких файлов" (трабл многих распределенных фс), живет она в кернеле и основана на ext3. Думаю, стоит попробовать =)
>К сожалению, люстра и бсд несовместимы.
1. fuse может работать под BSD и под MacOS X.
2. в свете вылизывания lustre patchless client - есть шанс сделать полноценный клиент (пусть и тормозной, для ускорения нужны некоторые правки в VFS у fbsd) для BSD взяв за основу MacOS порт. С сервером сложнее.
>>К сожалению, люстра и бсд несовместимы.
>1. fuse может работать под BSD и под MacOS X.
>2. в свете вылизывания lustre patchless client - есть шанс сделать полноценный
>клиент (пусть и тормозной, для ускорения нужны некоторые правки в VFS
>у fbsd) для BSD взяв за основу MacOS порт. С сервером
>сложнее.
да, меня опять тянет на унификацию =)
а в роадмапе с поддержкой бсд - грустно.
>>>К сожалению, люстра и бсд несовместимы.
>>1. fuse может работать под BSD и под MacOS X.
>>2. в свете вылизывания lustre patchless client - есть шанс сделать полноценный
>>клиент (пусть и тормозной, для ускорения нужны некоторые правки в VFS
>>у fbsd) для BSD взяв за основу MacOS порт. С сервером
>>сложнее.
>да, меня опять тянет на унификацию =)
>а в роадмапе с поддержкой бсд - грустно.
думаю будут заказы или интуазисты - будет сделано :)
интересно
нужно пробовать
не нужно. по проспектам на грузовых поездах не ездят.
А поставил ли кто-нить люстру под БСД, а точнее под ФриБСД?
Не получается скомпилить lustre-1.5.97.tar.gz.