NBD (Network Block Devices) в качестве SAN

Нет.
Да, но зачем тогда nbd?
Да, но блин усточивость внушает сомнения

> Да, но зачем тогда nbd?

Не совсем понял. nbd будет раздавать винты клиентам. А GFS будет обеспечивать корректную работу такой конфигурации. Прощще всего конечно использовать все nbd на одном сервере и раздавать файлы на нем по nfs, но в данном случае возникает двойной сетевой трафик.

> Да, но блин усточивость внушает сомнения

Устойчивость чего вызывает сомнение? nbd+lvm у меня уже используется, но только в монопольном режиме без раздачи по нескольким клиентам.

>Не совсем понял. nbd будет раздавать винты клиентам. А GFS будет обеспечивать корректную работу такой конфигурации. Прощще всего конечно использовать все nbd на одном сервере и раздавать файлы на нем по nfs, но в данном случае возникает двойной сетевой трафик.

Так GFS же может своими средствами преоставлять ФС клиентам. Или storage у тебя принципиально не должен сам GFS иметь?

>Устойчивость чего вызывает сомнение? nbd+lvm у меня уже используется, но только в монопольном режиме без раздачи по нескольким клиентам.

Чего угодно поверх nbd. он сам по себе стремен, но не дай бог еще уровень абстракции поверх -- в случае сбоя кто собирать будет кости?

> Так GFS же может своими средствами преоставлять ФС клиентам. Или storage у тебя принципиально не должен сам GFS иметь?

Хм. Когда я ее изучал, я у нее таких возможностей не заметил.

Вот ситуация. У меня в локалке есть куча серверов с винтами и мне нужно получить единое хранилище состоящие из этих винтов. Это средствами GFS делается?

Неважно, кто будет раздавать блочное устройство по сети - хоть NBD, хоть ENBD, хоть iSCSI. Главное, чтобы этот протокол был рассчитан на одновременное использование (не делал лишнего кеширования и отложенной записи).

Но NBD пользоваться сильно не рекомендуется - оно очень плохо отрабатывает сетевые проблемы. Как минимум ENBD, а лучше всё-таки iSCSI попробовать.

Сверху такого блочного устройства, насколько я понимаю, может быть, по сути, любая кластерная файловая система - GFS, OCFS (лучше OCFS2), ещё были каких-то парочка...

Я точно знаю примеры использования iSCSI+OCFS2, они подробно описаны на околооракловых ресурсах.

А вообще это уже не SAN, это NAS... :)

Ну естественно, что для очень уж серьёзных применений такую конструкцию использовать нельзя - латентность блочных сетевых устройств на порядок, а то и на два выше, чем у обычных SCSI или FiberChannel-устройств (зато цена на порядок, а то и на два - ниже).

С iscsi я задолбался бороться. :( Пока enbd мне представляется наиболее реальным вариантом.

> Возможно-ли при подключении nbd винта на разные клиенты
> использовать его на всех для записи/чтения, например, поставив на
> него файловую систему GFS?
Может и опоздал но ответ будет ДА. В GFS для nbd есть даже реализация fenced.
Только рекомендуется использовать не nbd а другую реализацию, читай
http://www.redhat.com/docs/manuals/csgfs/browse/rh-cs-en/index.html

Сам я использую ISCSI и пока в тестовом режиме GFS.

Вы исполььзуете iscsi target железный или софтовый? В данном варианте меня больше всего интересует нагрузка на проц. Что-то мне подсказывает что без спец. железа она будет очень высокой.

Попробовал enbd скомпилить под свое ядро. При загрузке модуля kernel panic. Нафиг такую надежность!

Сейчас тестирую поведение nbd девайсов при обрыве связи. На периодах в несколько минут операции на клиенте с этим разделом замирают. При этом по top видно i/o waiting под 100%. Когда связь восстанавливается, через небольшое время все отмирает и корректно продолжает работать дальше. Если время побольше - тогда да. С lvm происходит сбой и фс монтируется только для чтения. Мне кажеться что это не настолько смертельно что-бы вообще отказываться от nbd.

Использую две ISCSI QLogiq 4010c, до этого экпериментировал на софтовом.
По глючности разница как небо и земля :)

Про нагрузку: тормозов на софтовой реализации не замечал,
процессор стандартный P4 3.00GHz с кешем 2Мб.
Основная бага, при выдергивании шнурка выпадал в кернел паник.

тебе нужен gnbd или iscsi. на остальное забей ибо глючность и кривость обеспечены и гарантируются производителем