The OpenNET Project: Обзор сетевых и кластерных ФС: Lustre, GFS, AFS, GFarm

Обзор сетевых и кластерных ФС: Lustre, GFS, AFS, GFarm	[исправить]
Lustre - кластерная ФС, AFS - сетевая ФС. Если подробнее - то AFS относится примерно к тому классу, в котором сидят NFS, SMB, и win2K3 DFS. Основная их задача - качественный доступ к различным (раскиданным по сети) ресурсам, с соблюдением блокировок и напором на контроль доступа и централизованное управление. Здесь четко прослеживается модель "клиент-сервер" - большинство участников сетовой ФС являются клиентами, а под шары выделяются чаще отдельные серваки. С точки зрения производительности для такой ФС критериями являются пропускная способность сервер-клиент и количество поддерживаемых коннектов. Масштабируется такая ФС вертикально - более шустрым железом. Надежность тоже поддерживается на уровнях ниже сетевой ФС (RAID, репликация средствами ОС и администратором 24/7 на мобильном =) Кластерных ФС известно негусто - навскидку Lustre, Google FS (+Hadoop), что-то было у IBM. Отличительная особенность - все участники ФС унифицированы и являются и серверами и клиентами ФС (это именно особенности реализации, конечно же можно и настроить для работы как "несколько серверов - много клиентов", но преимуществ в этом случае не получите, скорее наоборот) Обычный принцип действия - работа на уровне блоков: разбитый на блоки файл "размазывается" по нескольким серверам, при его чтении клиент сам собирает блоки в файл. (Комментарий Алексея: Это Google FS & RedHat GFS.. в люстре оперируют понятием объект). Критерии оценки таких ФС - общая пропускная способность ФС кластера (то есть сколько гб/с крутится в пределах кластера) и латентность (задержка между запросом файла и его получением). Также тут важна надежность - все блоки реплицируются на уровне ФС, вылет нода не сказывается на работе кластера. ФС этого класса очень разные. Lustre заточена под hiperf вычисления с низкой латентностью, посему пользуют что-нить типа InfiniBand и нестандартные MPI. Lustre замонтированая представляет из себя слегка урезaную ext3 для 2.4 ядер, для 2.6 используется ldiskfs которая значительно ближе к ext4. Google FS и Hadoop - вообще с классической точки зрения не ФС, ибо ничего не монтируют а предоставляют RPC API для разработчиков. Рассчитаны они на гигантские объемы информации, работу в основном на чтение большими блоками (в мегабайтах, стандартный блок такой ФС - 32-64Мб) и в очень больших количествах. Также есть shared storage FS - эти нужны при работе нескольких (многих) серверов с внешними дисковыми массивами. Основная задача - обеспечить быструю и правильную блокировку совместного доступа (via SAN, iSCSI, SCSI). Без них фактически каждый сервер должен работать со своим личным выделенным на массиве разделом. Из известных - GFS от RedHat, Oracle Cluster File System, PolyServe и Veritas CFS. RedHat GFS - раздает raw девайс и пытается управлять блокировками на уровне блоков, без учета логической организации. gfarm изначально позиционирует себя для таковой модели использования: есть много данных, распределенных по нодам, нужно их все параллельно обработать. В случае люстры и подобных - compute node сначала фетчит себе данные из кластерной фс, обрабатывает и возвращает обратно (отсюда требования к пропускной способности и латентности). В случае gfarm - задание по обработке для compute нода попадает благодаря gfarm именно на тот нод, где локально лежит одна из реплик требуемых данных. Соответственно по сети происходит трансфер задания на обработку данных , а не самих данных. (например, здесь, да и вообще тут- большинство тем именно parallel computing, а не distributed fs). Некая сборная информация есть в wikipedia.


14.02.2007 , Автор: johnjoy , Источник: https://www.opennet.ru/openforum/vsl... Ключи: fs, disk, cluster, distributed
Раздел: Корень / Администратору / Система / Кластерные технологии

Обсуждение

[ Линейный режим | Показать все | RSS ]

1.1, anganar (?), 23:47, 14/02/2007 [ответить] [﹢﹢﹢] [ · · · ]

+/–

> RedHat GFS - раздает raw девайс и пытается управлять блокировками на уровне блоков, без учета логической организации.

Давайте все же уточним. Работа с блоками происходит в фоне, незаметно для клиентов.

А наружу видна POSIX-совместимая ФС, с которой можно работать привычными средствами без каких-либо дополнительных шаманств.
(mount -t gfs -o acl /dev/vg01/lvo10 /gfs_mount и вперед)

2.2, Аноним (2), 10:38, 15/02/2007 [^] [^^] [^^^] [ответить]	+/–
агу-агу. только попробуй на ней запустить какой-нить metadata intesive load, ну типа несколько клиентов создают/удаляют файлы в одном каталоге. тут-то она и отсосет чудовищно чмокая. а так-то POXIS, да ;)

3.3, anganar (?), 12:06, 15/02/2007 [^] [^^] [^^^] [ответить]	+/–
Уважаемый Аноним, а это к чему вообще было сказано? :-) Я вроде про интерфейс и тулзы, а Вы про производительность. ;-) Но раз уж заговорили. С чем сравнивали? Результаты тестов есть? Просто я работал только с GFS. Если есть осмысленные сравнения с чем-нибудь еще, было бы очень интересно посмотреть.

4.4, Аноним (2), 17:08, 15/02/2007 [^] [^^] [^^^] [ответить]	+/–
а мне пофиг, говорю только, что корявый дизайн у этой GFS. сравнений тоже никаких не нужно - почитайте как оно работает и что будет если две ноды одновременно модифицируют каталог.

4.5, johnjoy (??), 19:52, 16/02/2007 [^] [^^] [^^^] [ответить]	+/–
Опубликовали незаметно =) у GFS есть одно неоспоримое преимущество - она РАБОТАЕТ и денег не стоит. Конечно, если есть возможность имеет смысл покупать polyserve или veritas на худой конец. Однако среди бесплатных решений у GFS альтернатив не наблюдается.

5.7, Аноним (2), 10:08, 17/02/2007 [^] [^^] [^^^] [ответить]	+/–
http://www.clusterfs.com/download.html -- тоже не стоит денег. и работает на кучке кластеров из top10. на которых никакими polyserve/veritas/gfs не пахнет.

6.8, johnjoy (??), 14:55, 17/02/2007 [^] [^^] [^^^] [ответить]	+/–
прошу прощения, Вы поверх какого массива люстру запускали? а можно узнать конфигурацию Вашей RDBMS, запущенной поверх люстры? сильно быстро работает? очень хочется приобщиться к мудрости

7.9, Аноним (2), 21:00, 18/02/2007 [^] [^^] [^^^] [ответить]	+/–
ну да, ну да ... RDMBS ... только для этого кластерные fs и нужны, ага.

7.10, Аноним (2), 21:06, 19/02/2007 [^] [^^] [^^^] [ответить]	+/–
поверх DDN, слышали про такие?

7.13, _umka_ (ok), 10:08, 22/02/2007 [^] [^^] [^^^] [ответить]

+/–

>прошу прощения, Вы поверх какого массива люстру запускали? а можно узнать конфигурацию
>Вашей RDBMS, запущенной поверх люстры? сильно быстро работает?
>очень хочется приобщиться к мудрости
RDBMS как правило хотят raw storage для хранения данных и внутри делают свою FS - этого люстра не предоставляет. да и любая FS тут не нужна - тут нужно тупое разделение блоков причем механизм блокировок как правило тут свой, опять же dlm тут не нужны, там они свои.
мне кажется для вашей задачи будет лучше drbd или аналогии.

По части скорости.
Последние тесты на кластерах показывают скорость 80Gbyte/s для записи и 120Gbyte/s для чтения.
некоторые данные по бечмаркам и количеству активных пользоватей есть в
http://www.lustre.org/docs/selecting-a-cfs.pdf
хотя это больше рекламный буклет.

по части массив я сказал - от 150-200T это те которые я знаю, говорили еще о 1P - но реальных подтверждений я не видел.
Работа на кластерах IBM BlueGine/L, Cray XT3 (XT4). (тут раньше правильно заметили почти все из top10 так или иначе связано с люстрой).

4.6, johnjoy (??), 19:56, 16/02/2007 [^] [^^] [^^^] [ответить]	+/–
а, ну OCFS(2) еще, но а) специфика - точили под БД оракла и б) по отзывам (полгода-год назад) производительность на уровне того же GFS

2.12, _umka_ (ok), 09:56, 22/02/2007 [^] [^^] [^^^] [ответить]

+/–

в люстре тоже самое.
mount -t lustre 172.20.2.20@tcp:/lustre /mnt/lustre2
-o acl по желанию.

По части массивов на которых работает люстра.. Судя по отчетам LLNL у них используется не менее 200T в стораджах, японцы заявляли о 1P в storage array при миниум 2000 активных клиентов.

Осталось спросить - на сколькоих клиентах и насколько больших массивах вы тестирования GFS?

1.11, liks (??), 15:51, 21/02/2007 [ответить] [﹢﹢﹢] [ · · · ]	+/–
По-моему какой-то набросок текста "ни о чем". Тот кто работает с кластерами, тот должен знать о существовании всех перечисленных ФС. Кто не работает - тому и не надо :) Лучше бы подробно сравнили реализации и производительность раз времени дофика!

1.14, smartcgi (?), 19:12, 26/02/2007 [ответить] [﹢﹢﹢] [ · · · ]

+/–

Никто не подскажет одну вещь.
У нас есть кластер на GFS + SAN + fabric switch

LA довольно большой на больших скоростях.

Если поставить IPoIB для интерфейсов где идет обмен локами, насколько это может существенно поднять производительность?
сейчас ping между серваками - 90ums. У IB вроде ~5-10ums?

thx

1.15, geekkoo (ok), 08:37, 01/04/2007 [ответить] [﹢﹢﹢] [ · · · ]

+/–

Ужас. Какая-то каша.

>AFS - сетевая ФС.

>Если подробнее - то AFS относится примерно к тому >классу, в котором сидят NFS, SMB, и win2K3 DFS.

Очень грубо. На самом деле AFS (+ Coda, а также мертвая Intermezzo) это так называемые распределеннные FS, они где-то между сетевыми FS и кластерными (хотя ЕМНИП для OpenAFS есть соответствующие патчи, превращающие ее в кластерную FS). Распределенные FS предлагают в том или ином виде fail-over и балансировку нагрузки между серверами + действительно централизованный контроль за хранилищем данных (пусть оно и размазано по нескольким серверам). В отличии от SMB/NFS понятия "шар" там нет - хранилище данных форматируется специально и сервер/клиент физически разнесены (в Coda это обязательное требование).

Кластерные FS занимают совсем другую нишу. Автор, кстати, забыл упомянуть еще довольно известную кластерную систему PVFS/PVFS2. Насколько я себе представляю, под кластерными FS обычно понимают "параллельные" системы, что-то вроде сетевого RAID-а, где файл может быть физически размазан по нескольким дискам. Стандарт MPI (и следовательно MPI-enabled программы) позволяют одновременно писать и читать файлы с нескольких серверов. Для не-MPI программ особой разницы по сравнению с обычными сетевыми FS нет. Кроме того, в отличии от сетвых и распределенных FS для кластерных FS безопасность, шифрование и аутентификация не столь важны, поскольку кластер обычно пространственно локализован, "человечку посередине" туда сложно пробраться.

Добавить комментарий