Конфигурация DRBD+OCFS2: производительность

ocfs2 полный шлак на совместном доступе к одному файлу.

Да мне и не нужен реально совместный доступ, нужно просто чтобы при необходимости точная копия виртуального диска была и на второй ноде. Собственно, только одна нода запускает виртуалку, а вторая тупо получает апдейты виртуального жёсткого диска. Ну а когда какая-то нода падает, её виртуалки можно запустить на второй ноде. И всё бы хорошо, кабы не хотелось мне ко всему прочему масштабировать производительность и делать Live Migration виртуалок с одной ноды на другую. А так можно было бы обойтись DRBD в режиме Primary/Secondary. Сейчас это Primary/Primary.

Цитируем DRVTiny

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

Надо доку прочитать и осмыслить. А потом юзать.

Подозреваю, что ты расшарил блочное устройство по сетке, отформатил его например в ext3 и замутил glusterfs абсолютно без понимания происходящего.

это при том, что производительность гигабитной сети почти равна производительности дискового массива!

SANDesignRusEng_1.0.pdf

Кстати, по поводу Glusterfs: может, её всё-таки стоит запускать поверх GFS/OCFS2, а не general fs?

Нет, RTFM.

OCFS2 и GFS юзай в ахрипоследнюю очередь, ибо вероятность отказа последних на порядок выше, чем у гластера+usualFS.

Цитируем DRVTiny

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

1. Делаешь на двух нодах директории, например /u01/phys

2. поднимаешь демоны гластера, в конфигах glusterfsd.vol указываешь простой шаринг /u01/phys

3. Делаешь client-side-репликацию через взаимное монтирование по GlusterFS с транслятором cluster/replication

4. работаешь с этим всем делом через примонтированные директории.

Цитируем DRVTiny

поделитесь советами по улучшению производительности DRBD

И забыл сказать: DRBD в твоём случае избыточен, да и затрахаешься ты с ocfs2/gfs2 в случае отказа.

Дык конфиги гластера привёл уже в этой теме:
http://www.linux.org.ru/forum/admin/4542867?lastmod=1265883267379
Именно так и сделал, как вы советуете. И вроде работает оно, но уже на двух системах виртуальных после миграции ломалась файловая система. Причём ломается она не полностью, а так, словно в процессе миграции что-то сломалось, именно в тот злополучный момент. Возможно, фигня в том, что пока оперативная память виртуалки перекачивается по сети, сама виртуалка живёт и ей хоть бы хны. При этом в итоге кешированные в памяти структуры ФС меняется синхронно с дисковой версией, меняются себе они меняются... и вдруг, по окончании перетаскивания оперативки, они... бабах, и становятся outdated: кешированные структуры фс в памяти становятся старше, чем версия на диске, хотя может быть только наоборот сточки зрения ОСи. Операционная система в результате считает, что это файловая система повреждена, а не её структуры данных. Отсюда и начинается дикая свистопляска: сначала на диск пишется устаревшая таблица инодов и/или журнал, перезаписывая актуальные, а потом ОС видит, что по этой «новой» таблице получается какая-то откровенная хрень, перемонтирует файловую систему в read only, а в дальнейшем активно предлагает её лечить.
Я использую Proxmox... может, в этом всё дело? Так-то я тоже не видал, чтобы GlusterFS сама по себе ломалась.
То есть без Live migration виртуалок всё работает как надо!
А значит: либо при Live Migration память неверно переезжает, либо виртуальный диск на исходной ноде и на целевой ноде не совпадают. В первом случае это косяк Proxmox, вто втором - очевидно, это будет всё-таки вина кластерной прослойки, потому как файлы просто обязаны быть идентичны на двух нодах в любой момент времени.

>SANDesignRusEng_1.0.pdf

а это как такое нагуглить?

Эх, молодёжь :).

http://www.brocade.com/downloads/documents/books/SANDesignRusEng_v1.0.pdf

Народ, помогите, я уже на DRBD не корячу OCFS2, сделал внутри DRBD обычный LVM, внутри которого логический том = виртуальный жёсткий диск. А производительность этой хреновины как была ниже плинтуса, так и осталась, what the... ??? Тут хоть у кого-нибудь эта фиговина работает БЫСТРО (ну хотя бы 20 Мб/сек). Glusterfs тоже не летает, но работает во много раз быстрее, это просто нонсенс какой-то!! Ведь DRBD собирается на более низком уровне (блочного утсройства, а не файловой системы), чем GlusterFS и должен бы работать быстрее, вместо этого я имею какие-то дикие тормоза при соверенно незагруженном гигабитном канале (пересылаются через него какие-то мелкие IP-пакеты в бешенном количестве), диске и памяти!

http://habrahabr.ru/blogs/hi/50143/
Может это поможет:
Затем на второй ноде (тк рядом лежит сайт и надо будет его заливать на новый раздел)
#drbdadm — --overwrite-data-of-peer primary drbd0
и перезапускаем
#/etc/init.d/drbd restart
перезапуск нужен чтобы сервис нормально стартовал и взял настройки из конфига, ибо по умолчанию скорость синхронизации достатоно низкая…