ОФФ/2

Санч, если не затруднит - отпиши в мыло tim2k@rambler.ru - есть вопросы по сабжу и не только :)

поясните плиз кто-нибудь, зачем это нужно? Пытаюсь понять, но мысль топчется на пустом месте.

>Авторы надеются, что система может масштабироваться до ~ 100 узлов и производительность будет расти линейно

Мда интересно каким макаром они линейности попытаются добиться, а может сразу квадратично будет расти :)

> поясните плиз кто-нибудь, зачем это нужно? Пытаюсь понять, но мысль топчется на пустом месте.

для больших файловых серверов

>для больших файловых серверов

c SMB протоколом ??? Интересно было бы взглянуть на один из таких гигантов. Лично мне не ясна цель samba cluster.

>Лично мне не ясна цель samba cluster.

+1. Я тоже не воткнул.

Круто. На "HA" очевидно кладётся большой болт, и всё идёт на "HP", а о том как всё глючит и разваливается авторы предпочитают молчать.

Хмм.. В любом случае, довольно интересный проэкт.

> c SMB протоколом ??? Интересно было бы взглянуть на один из таких гигантов. Лично мне не ясна цель samba cluster.

да, а что тут такого?

Ничего. Просто дай IP такого сервера :) Ы?

66.249.93.104

Хотя я не до конца уверен ;)

nmap 66.249.93.104

Interesting ports on ug-in-f104.google.com (66.249.93.104):
Not shown: 1693 filtered ports
PORT STATE SERVICE
80/tcp open http
113/tcp closed auth
179/tcp closed bgp
443/tcp open https

Нет там нифига :)

И чем это будет отличаться если я раздам PVFS или GlusterFS раздел по SMB на N линков ? По любому оно упрётся в пропускную способность сети.

> И чем это будет отличаться если я раздам PVFS или GlusterFS раздел > по SMB на N линков ? По любому оно упрётся в пропускную способность > сети.

http://abbra.livejournal.com/80754.html

comment by lm

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

Тем, что это просто не будет работать для случаев, когда M клиентов открывают одни и те же файлы через N серверов.

Ну по ссылке написано, что n+1 узел работает быстрее чем n, при n=1..N
где N достаточно большое. Единственно, в чем ожидается падение производительности - операции блокировки.

Поправочка

>Тем, что это просто не будет работать для случаев, когда M клиентов открывают одни и те же файлы через N серверов.

А если на узлах по самбе, которые раздают общий стораж ? ;)

PS: Судя по тестам на IB, самба - зло ;) Получить 30.0 Mbytes/sec на 10Гигабитном линке надо уметь ;)

> PS: Судя по тестам на IB, самба - зло ;) Получить 30.0 Mbytes/sec на 10Гигабитном линке надо уметь ;)

а позвольте. у вас на одной машине она быстрее отдает? я вообще сомневаюсь что на простом писюке, с обычным Hdd, она выдаст более 50Mbyte/sec , добавьте сюда (отнимите) самбу + блокировки на файлы.

>а позвольте. у вас на одной машине она быстрее отдает?

_Она_ это кто ? Самбу не использую.

PVFS2 отдаёт в ширину линка _клиента_ ... На езернет-гигабите 100Мб/сек на IB не пробовал

Будет время могу потестировать и на IB

PS: В тесте говорилось именно о IB или я чего не понял в написанном в lj ... опять же встречный вопрос (даже 2)

1) как много "простых писюков" имеют IB линк ?

2) В чём смысл отдавать файлы по IB максимальная длина шланга у которого 17м ?

привет Ss, мне надо /home перенести на сказёвый рейд под какую-нибудь сетевую FS, клиенты будут на фронт-ендах и рабочих нодах двух подкластеров (на них просто две разные ОСи - федора5 и SLC4), как там PVFS2 в смысле надёжности и поддержки POSIX? GFS от красносшляпых вроде достаточно надёжна и гибка (файлы даже mmap'ить безопасно можно), но не нравится мне повышенная сложность администрирования и привязка к редхату. Один раздел с данными на том же рейде уже подмонтирован на ноды под NFS и достаточно регулярно на клиентах я вижу ошибки вида "can't stat...", конфигурация опять же либо под консистенси либо под производительность, в общем не нравится мне NFS. Что-нибудь посоветуешь?

>как там PVFS2 в смысле надёжности и поддержки POSIX?

Есть некоторые проблемы именно с mmap (не поддерживается PROT_WRITE,MAP_SHARED) ... из еще замеченых косячков клиент прилично грузит систему при чтении/записи больших файлов (~10%)

>GFS от красносшляпых вроде достаточно надёжна и гибка (файлы даже mmap'ить безопасно можно), но не нравится мне повышенная сложность администрирования и привязка к редхату.

Никаких особых бонусов от раздачи единичного рейда по PVFS2 думаю не будет Она имеет смысл при "размазывании" стоража по нодам и использовании её _внутри_ кластера. GFS в данном случае ничуть не хуже как минимум.

>Один раздел с данными на том же рейде уже подмонтирован на ноды под NFS и достаточно регулярно на клиентах я вижу ошибки вида "can't stat...", конфигурация опять же либо под консистенси либо под производительность, в общем не нравится мне NFS.

При такой конфигурации это неизбежно. В FS поверх другой FS это всегда возможно (у меня такое наблюдалось в NFS поверх PVFS2, CIFS поверх MFS, MFS поверх CIFS) Самое надёжное это NFS поверх локальной FS на рейде (jfs,xfs,ext3) или распределённая FS внутри кластера (PVFS2,GlusterFS,GPFS)

PS: Я сейчас соединил старый и новый кластеры следующим образом:

У нового 2 сети, "быстрая" - IB и "медленная" - GigE у старого только GigE.

GigE старого и нового кластеров завязаны в одну сетку и по ней роздана PVFS2 на все узлы, но на управляющем узле нового кластера PBQ "видит" только "новый" кластер. Насколько такая конфигурация живуча еще нужно будет пробовать.

мерси за консистентный ответ :)

> Никаких особых бонусов от раздачи единичного рейда по PVFS2 думаю не будет Она имеет смысл при "размазывании" стоража по нодам и использовании её _внутри_ кластера. GFS в данном случае ничуть не хуже как минимум.

> При такой конфигурации это неизбежно. В FS поверх другой FS это всегда возможно (у меня такое наблюдалось в NFS поверх PVFS2, CIFS поверх MFS, MFS поверх CIFS) Самое надёжное это NFS поверх локальной FS на рейде (jfs,xfs,ext3) или распределённая FS внутри кластера (PVFS2,GlusterFS,GPFS)

именно при такой конфигурации (NFS поверх локальной FS на рейде) я и вижу ошибки, а включение опций повышающих надёжность серьёзно снижает производительность (в тестах найденных через гугл на порядок и хуже)

на страничке в вики http://en.wikipedia.org/wiki/List_of_file_systems GFS вместе с GPFS отнесли к shared disk ФС, у которых есть серверы и клиенты обёдинённые SAN'ом, почему-то GPFS не отнесли в группу параллельных ФС как PVFS и Lustre, хотя на машинах из top500 она ставит рекорды производительности.

В авторах GlusterFS большинство индусы http://www.gluster.org/core-team.php, ничего не имею против этих конкретно, второй суперкомп из top500 в LLNL с GlusterFS это круто, но отдавать самое дорогое (ФС) в руки програмёров в тюрбанах и халатах как-то стрёмно :)

> на страничке в вики http://en.wikipedia.org/wiki/List_of_file_systems GFS вместе с GPFS отнесли к shared disk ФС, у которых есть серверы и клиенты обёдинённые SAN'ом, почему-то GPFS не отнесли в группу параллельных ФС как PVFS и Lustre, хотя на машинах из top500 она ставит рекорды производительности.

http://en.wikipedia.org/wiki/Global_File_System

"...GFS has no disconnected operating mode, and no client or server roles. All nodes in a GFS cluster are peers."

забавно, что ФС подобные GFS якобы не имеют клиентов и серверов, хотя роль shared block storage явно выделена и при его поломке "не-клиенты" ощущают это в полную силу, в отличие от distributed fault-tolerant ФС с репликацией данных, где как раз есть и клиенты и серверы, причём хосты могут одновременно выполнять обе роли, сплошное заморачивание головы ;)