GFS

Или лучше строить отдельное хранилище SAN/iSCSI/GFS2?
В процессе работы им необходимо обращаться к общим файлам (rw)

К каким именно файлам? Учитите, что в линуксе открытие файлов происходит обычно без блокировки, поэтому если два приложения одновременно откроют файл, то будет жопа (можно обойти через LD_PRELOAD и открытие с блокировкой, но тогда другое приложение будет ждать до закрытия). Если rw не критичный и не частый, то можно даже через lsyncd сделать, если

насколько это загрузит сеть и CPU каждого

Ну это смотря сколько у Вас IO для этих файлов. Если Вы логи пишите, то почти нисколько. В любом случае, можно воткнуть ещё сетевух в сервера.

Или лучше строить отдельное хранилище SAN/iSCSI/GFS2?

Если Вы не планируете использовать DRBD для отказоустойчивости, то для трёх серверов лучше будет NFS выбрать. Учтите, что для кластерных ФС нужно ещё и фенсинг выполнять, плюс там есть проблемы с проигрыванием логов (если нода упала, то у неё есть собственный журнал ФС и пока его не «проиграют» другие ноды могут не получить доступа к файлу при ситуациях создания файла или изменения его размера, или если используется журналирование данных). Ещё можно в сторону GlusterFS посмотреть, но лучше на NFS остановиться и lsyncd-репликации на резервный NAS. Потому что если у Вас нет опыта работы с распределенными/кластерными ФС, то Вы их не сможете нормально в продакшен впихнуть.

Если очень интересно, могу предложить свои услуги (от расширенных консультаций по конкретной архитектуре до реализации) на коммерческой основе.

Ну это смотря сколько у Вас IO для этих файлов. Если Вы логи пишите, то почти нисколько. В любом случае, можно воткнуть ещё сетевух в сервера.

Сетевых карт воткнуть нельзя! Выбор в общем то сделан - GFS. Вопрос был в том, сколько сетевых и процессорных ресурсов съедает обслуживание ФС. От этого и выбор конфигурации - либо отдельное хранилище, либо «локальное».

Если Вы не планируете использовать DRBD для отказоустойчивости ...

А GFS для чего? )

Выбор в общем то сделан - GFS.

Лучше выбрать NFS+lsyncd.

А GFS для чего? )

Вы, видимо, не ознакомились с документацией. Кластерные (но не распределенные) файловые системы вообще не занимаются вопросами отказоустойчивости (мало того, в них выход из строя ноды - это не рядовое событые, которое требует фенсинга и часто проигрывания логов), они занимаются предоставлением кластеру возможность работать с ФС поверх одного блочного устройства. Если это блочное устройство перестанет работать (либо не будет линка к нему), то ФС тоже перестанет работать. Т.е. блочное устройство, как хранилище, является единой точнок отказа.

Соответственно, для отказоустойчивости нужно использовать DRBD либо в режиме мультимастера, либо iSCSI-пулы и миграцию. Нормально настроить и то и другое весьма проблематично.

И да: как будет делаться фенсинг? Через умные розетки, УПСы, через SNMP свитча или IPMI серверов? Если у Вас нет возможности гарантированно отсечь сервер от SAN-сети, то использовать кластерную ФС нельзя.

Кластерные (но не распределенные) файловые системы вообще не занимаются вопросами отказоустойчивости

Не понял вас. Вы хотите сказать, что gfs2 не распределенная ФС?

Если это блочное устройство перестанет работать (либо не будет линка к нему), то ФС тоже перестанет работать. Т.е. блочное устройство, как хранилище, является единой точнок отказа.

Как одного??? И если каким то образом оно одно(!), как в этом случае поможет NFS?

Не понял вас. Вы хотите сказать, что gfs2 не распределенная ФС?

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

Как одного??? И если каким то образом оно одно(!), как в этом случае поможет NFS?

Так. Все компьютеры с кластерной ФС должны видеть единый для всех них /dev/sdX (причём эта возможность организуется не кластерной ФС, а FC, iSCSI, SAS net, DRBD или др. технологиями). Кластерная ФС обеспечивает только монтировние этого блочного на нескольких компьютерах с блокировками и непротиворечимым доступом (ну а также запускает фенсинг и т.д.).

как в этом случае поможет NFS?

Никак. Просто Вы поднимите рабочее решение. А вот через lsyncd будет производиться периодическая репликация на резервный NFS-сервер, чтобы можно было на него перейти в случае сбоя основного.

без обид, но мне кажется вы сами что-то путаете ... )) Такая файловая система разворачивается на нескольких блочных устройствах (а не одном). А перечисленные вами FC, iSCSI - это способы доступа к такой файловой системе.

NFS в случае одного блочного устройства - такая-же бесполезность ...

не путай gfs2 с ceph

В чем путаю?

https://access.redhat.com/documentation/ru-RU/Red_Hat_Enterprise_Linux/6/html...

без обид, но мне кажется вы сами что-то путаете

Без обид, но мне кажется, что Вы до сих пор не прочитали документацию. Я GFS2 запускал в говнопродакшене, а OCFS2 тестил, поэтому я прекрасно знаю о чём говорю.

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

Если Вы имеете в виду объединение нескольких устройств в одно через cLVM, то да. Но для файловой системы это - всё-равно одно устройство, в нём нет репликации и оно должно предоставляться всем хостам иной технологией.

NFS в случае одного блочного устройства - такая-же бесполезность

Почему? У Вас через lsyncd будет репликация на резервный сервер. Для большинства задач этого более чем достаточно, и Вы точно не выстрелите себе в ноги, как в случае с GFS2overDRBD.

Картинку посмотрите, если непонятно: http://www.admin-magazin.de/Online-Artikel/Red-Hats-Global-File-System-GFS2 . Для особо тупых: GNBD - это средство экспорта блочных устройств по сети, типа iSCSI. В первом сценарии показан обычный вариант через SAN. Там, где указано несколько дисков, подразумевается, что они объединяются в один через cLVM.

я так понял, вы сами только что прочитали )) Вот, что вы писали:

Так. Все компьютеры с кластерной ФС должны видеть единый для всех них /dev/sdX (причём эта возможность организуется не кластерной ФС, а FC, iSCSI, SAS net, DRBD или др. технологиями). Кластерная ФС обеспечивает только монтировние этого блочного на нескольких компьютерах с блокировками и непротиворечимым доступом (ну а также запускает фенсинг и т.д.).

1) Все компьютеры должны видеть не /dev/sdX а друг-друга!
2) Блочное устройство в данном случае - это абстракция (все данные которого "размазаны" по нодам кластера)! В RH создается с помощью CLVM (вижу, прочли)!
3) FC, iSCSI это способы доступа к такому блочному устройству.
4) DRBD, это вообще - репликация данных (с какого ее приплели вместе с iSCSI, FC? )) ). Причем репликация только 2 дисков!

Ну вижу. на оскорбления перешли. Ок. Для тупых совет, прежде, чем советовать и тем более предлагать услуги за деньги, нужно что-то знать! А не нести пургу, а потом бежать читать ;)

а вообще, читайте вопрос, который я задавал ...

ой-ой-ой ... )) Только сейчас вник ...

Если Вы имеете в виду объединение нескольких устройств в одно через cLVM, то да. Но для файловой системы это - всё-равно одно устройство, в нём нет репликации и оно должно предоставляться всем хостам иной технологией.

Вы вообще предмет понимаете? Для чего создватся такая файловая система!? )) Это и придумано для создания «дисков»! Какая репликация, если ваша файловая система и так хранит всю информацию на нескольких серверах (для того и создана + для распределение нагрузки)

Почему? У Вас через lsyncd будет репликация на резервный сервер. Для большинства задач этого более чем достаточно, и Вы точно не выстрелите себе в ноги, как в случае с GFS2overDRBD.

Какой второй сервер, если вы писали об одном блочном устройстве (=один сервер). Причем рассматриваете всерьез развертывание GFS не таком диске ))) Для чего она нужна на одном диске???

Ну вижу. на оскорбления перешли. Ок. Для тупых совет, прежде, чем советовать и тем более предлагать услуги за деньги, нужно что-то знать! А не нести пургу, а потом бежать читать ;)

Для очень тупых совет: прочтите, ***ть, уже документацию! cLVM/LVM2 cluster - это просто менеджер томов для кластерной конфигурации, который атомарно изменяет конфигурацию томов на всех нодах (пример, если Вы хотите расширить LV или создать, или добавить PV в VG). Но не предоставляет никаких возможностей «размазывания данных».

1) Все компьютеры должны видеть не /dev/sdX а друг-друга!

НЕТ ЖЕ! Они должны видеть друг друга по IP и иметь общее блочное устройство (shared storage), например, одни и тот же том iSCSI.

4) DRBD, это вообще - репликация данных (с какого ее приплели вместе с iSCSI, FC? )) ). Причем репликация только 2 дисков!

Да. Там есть возможность репликации в режиме master-master. Тогда у Вас на друх нодах будет /dev/drbd0. Можно сделать на большее количество нод в последних версиях.
Если Вы хотите, чтобы при вылете хранилища у Вас не наеб***** ФС, то нужна репликация, т.к. блочное устройство ОДНО.

Если Вы мне не верите, то прочитайте любой туториал по GFS2.
Например:
http://anandmpandit.blogspot.ru/2011/07/how-to-setup-cluster-environment-gfs2...
http://www.golinuxhub.com/2014/02/configure-red-hat-cluster-using-vmware.html

Или википедию: https://en.wikipedia.org/wiki/GFS2
«GFS2 is a shared disk file system». Для тупых: GFS2 - это файловая система для общего диска.
И https://en.wikipedia.org/wiki/Clustered_file_system

Вы путаете кластерные системы с распределенными, ещё раз повторюсь. Вот список распределенных ФС: https://ru.wikipedia.org/wiki/Список_файловых_систем#.D0.A0.D0.B0.D1.81.D0.BF...

Для тупых совет, прежде, чем советовать и тем более предлагать услуги за деньги, нужно что-то знать!

Это Вы сами себе можете адресовать. Вам и другой пользователей написал, что Вы путаете gfs2 с ceph (распределенной ФС).

Какая репликация, если ваша файловая система и так хранит всю информацию на нескольких серверах (для того и создана + для распределение нагрузки)

Ещё раз повторюсь: прочитайте википедию. Кластерные ФС вообще ничего не хранят на серверах, подразумевается, что хранилище внешнее и единое (типа дискового массива, подключенного по FC ко всем серверам). Они нужны только того, чтобы несколько компьютеров могли использовать единую ФС на одном блочном устройстве. Вам нужна распределенная ФС.

для распределение нагрузки

Распределения нагрузки кластерные ФС вообще никакого не предусматривают, т.к. данные хранятся только в одном физическом хранилище (в случае репликации она реализуется внешними технологиями и не распределяет запросы).

Какой второй сервер, если вы писали об одном блочном устройстве (=один сервер). Причем рассматриваете всерьез развертывание GFS не таком диске ))) Для чего она нужна на одном диске???

Второй сервер - это сервер с репликой данных, который предоставляет резевное блочное устройство с копией данных основного. Реализуется внешней технологией типа netapp metrocluster или DRBD.

Для чего она нужна на одном диске???

Не на одном физическом диске. В стандартном случаете GFS2 строится так: покупается FC-карты, FC-свитч и FC-хранище с дисками (которое аппаратно организует кэширование и RAID-массив). Далее всё это соединяется FC-оптикой и все сервера видят /dev/sdX, которое является массивом на FC-хранище. После этого поднимается cLVM поверх /dev/sdX, а поверх него - GFS2. На самих серверах данные вообще не хранятся. IP-сеть используется GFS2 и cLVM для огранизации блокировок и обновления метаданных в кластере. Данные по IP-сети вообще не передаются (если, конечно, Вы не экспортируете из хранилища блочное устройство через IP-сеть).

NFS я рекомендовал потому, что Вы явно не разбираетесь в вопросе. Могу поспорить на 200$, что если Вы поднимите GFS2 на разных нодах с разными дисками и без DRBD/аналога, то ничего работать не будет.

а вообще, читайте вопрос, который я задавал ...

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

слушайте, вы уже повеселили меня. Не стоит продолжать ))) Троллинг не поможет ... Разгребать дурь по второму кругу не собираюсь Я понял уровень вашей компетенции, не стоит опускать его еще ниже. Остыньте ;)

P.S. И еще, сами воспользуйтесь советом - читайте оригинальную документацию, а не википедию ... ))

Ок, отпишитесь после (не)удачной настройки.

Расслабтесь, не нужно с ним спорить, видно же , что человек твердолобый, при этом ничего не понимающий. Подождите чутка, пусть запустит свой gfs в продакшен и прозреет. Опять же на лор прибежит:-)

а давно вы gfs крутили? Интересно мнение как оно вам и под какие задачи? я его крутил лет 5 назад на несильной нагрузке, кажись ок было.

Учитите, что в линуксе открытие файлов происходит обычно без блокировки

...в нераспределенных ФС

а давно вы gfs крутили? Интересно мнение как оно вам и под какие задачи? я его крутил лет 5 назад на несильной нагрузке, кажись ок было.

Давно. Везде пишут, что лучше юзать ocfs2, если не нужны редки фитчи gfs2 ( можете посмотреть графики http://www.slideshare.net/gpaterno1/filesystem-comparison-nfs-gfs2-ocfs2 http://www.slideshare.net/gpaterno1/filesystem-comparison-nfs-gfs2-ocfs2 ). Вполне нормально, настраивается и поддерживается куда проще, чем любая распределенная ФС, но намного сложнее NFS. Кластерные ФС нужны, когда очень много IO (несколько гигабит или десятков гигабит на сервер), когда нужен очень быстрый доступ к мелким файлам в кластере. Если таких задач нет, то можно пустить NFSoverRDMAoverIB и забить, особенно, если Вы не собираетесь кучу дисков с разных FC-полок собирать, а у Вас тупо одно физическое хранилище. Под задачи виртуализации оно вообще не катит, лучше использовать cLVM-пулы, gluster или NFS.

Если у Вас задача хранить кучу редкоизменяемых данных с репликацией и распределением нагрузки, то лучше использовать какую-либо БД ключ-значение, либо Ceph (можно и частоизменяемые данные), либо XtreemFS (удобно для геораспределенных данных), либо вообще использовать lsyncd (помесь rsync и inotify, отслеживает VFS-события и ставить файлы в очередь на синхронизацию rsync'ом. Шикарная вещь для работы с конфигами или статикой).

Базы данных (в режиме shared disk cluster) лучше использовать поверх их собственных volume manager'ов (oracle ASM) или поверх LVM-томов (postgresql и mysql это умеют).

Из практических применений можно привести аналитику, научные вычисления. Ещё раз повторюсь, что кластерные ФС - это не HA, для них выход ноды из строя не рядовое событие. Для больших подобных кластеров нужно использовать LustreFS.

И да: поскольку для кластерных ФС важна латентность в сети, то при множественных блокировках имеет смысл с 1/10GbE на IB 20/40G перейти из-за более низких задержкек у IB.