1.2, VecH (ok), 20:13, 15/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А как можно автоматизировать процесс синхронизации в случае выключения одного из серверов и возобновления его работы?
| |
|
2.3, VecH (ok), 20:14, 15/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
И что будет если разместить там базу MySQL/PostreeSQL ?
| |
|
3.5, EveryonE (ok), 23:55, 15/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>И что будет если разместить там базу MySQL/PostreeSQL ?
при запуске второй БД файл окажется залочен.
| |
|
4.7, Sw00p aka Jerom (?), 10:01, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
вот вот и ваще мускул рекомендует не ставить базу на НФС лайк Фс
а сам гластер это полное ГЭ для продакшена не годится
| |
|
5.9, Аноним (-), 10:42, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
Аргументы?
(не, в самом деле интересно про грабли, ибо серьезно думаю над.)
| |
|
6.14, Sw00p aka Jerom (?), 13:09, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Аргументы?
>
>(не, в самом деле интересно про грабли, ибо серьезно думаю над.)
читаем коммент номер 8 (внизу)
я ещё не говорю про производительность
пс: если хотите использовать гластер как НФС то лучше сразу использовать саму НФс ФС
а так я пробовал вариант когда все ноды реплицируются (все мастера - любое изменения на любой ноде реплицируются на остальные ноды) и это всё жутко тормозило и тормозило горизонтально
если две мастер-мастер ноды то это ещё ничего а когда подключил 4 бля это был ужас листинг директории чутьли не 5 секунд выполнялся
| |
|
5.10, VecH (ok), 10:48, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>вот вот и ваще мускул рекомендует не ставить базу на НФС лайк
>Фс
>
>а сам гластер это полное ГЭ для продакшена не годится
А в какую сторону посмотреть для продакшен ?
| |
|
6.11, EveryonE (ok), 12:17, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>вот вот и ваще мускул рекомендует не ставить базу на НФС лайк
>>Фс
>>
>>а сам гластер это полное ГЭ для продакшена не годится
>
>А в какую сторону посмотреть для продакшен ?
в цель какая - отказоустойчивость?
| |
|
7.12, VecH (ok), 12:25, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>>вот вот и ваще мускул рекомендует не ставить базу на НФС лайк
>>>Фс
>>>
>>>а сам гластер это полное ГЭ для продакшена не годится
>>
>>А в какую сторону посмотреть для продакшен ?
>
>в цель какая - отказоустойчивость?
отказоустойчивость и полная сохранность данных при выходе из строя любого из хранилищ
скоростные характеристики тут второстепенное
железные райды уже стоят
| |
|
6.13, Sw00p aka Jerom (?), 13:05, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
для продакшена советую либо GPFS либо LustreFS если нужна распределённая шаред ФС
правда люстра хоть и используется на многих супер кластерах я её считаю сырой
| |
|
7.19, Аноним (-), 22:13, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
А что скажете насчет drbd+oсf2 ?
для последующего экспорта в nfs и чтоб все жило при отказе одной из нод
| |
|
|
|
|
|
2.4, Антон (??), 20:25, 15/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А как можно автоматизировать процесс синхронизации в случае выключения одного из серверов
>и возобновления его работы?
Как я понял оно автоматически синхронизируется, при выполнении первой операции с ФС после возврата в строй отключенного узла.
| |
|
1.8, Sw00p aka Jerom (?), 10:04, 16/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
мне не нравиться то что репликация происходит только тогда когда идёт запрос на файл или на листинг директории
получается ситуация если на одной ноде положили файл и на другой ноде не производили никаких действий то в случаее падения первой ноды добавленные файлы на второй ноде не появятся
| |
|
2.17, Nas_tradamus (ok), 21:27, 16/01/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>мне не нравиться то что репликация происходит только тогда когда идёт запрос
>на файл или на листинг директории
>
>получается ситуация если на одной ноде положили файл и на другой ноде
>не производили никаких действий то в случаее падения первой ноды добавленные
>файлы на второй ноде не появятся
Ценное замечание.
Кто-нибудь из спецов не посоветует решение полноценной репликации ФС "мастер-слэйв"?
Мне понравилось как можно легко это сделать с SVN: просто вешаешь хук на коммит, который через ssh на слэйв-сервере запускает процесс синхронизации с мастером.
| |
|
3.18, Sw00p aka Jerom (?), 22:04, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>Мне понравилось как можно легко это сделать с SVN: просто вешаешь хук на коммит, который через ssh на слэйв-сервере запускает процесс синхронизации с мастером.
вы бенчмарк проводили ?
как ведёт себя такая система при интенсивной записи на мастере ???
в вашем случае (мастер-слейв) лучше использовать систему болчного копировнаия типа дрбд
| |
|
4.20, Nas_tradamus (ok), 22:41, 16/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>>Мне понравилось как можно легко это сделать с SVN: просто вешаешь хук на коммит, который через ssh на слэйв-сервере запускает процесс синхронизации с мастером.
>
>вы бенчмарк проводили ?
>
Нет. Подумал что такая система не должна влиять на производительность самого хранилища, беря во внимание особенности самой SVN. К тому же, поверил опыту знакомого - у него на ПК Pentium2 300 MHz, 256 RAM живет хранилище с 3 тысячами файлов, с которыми работают постоянно с десяток программистов.
>как ведёт себя такая система при интенсивной записи на мастере ???
>
У себя же, "на глаз" снижения производительности не заметил.
К слову, у меня в проекте более 13 тысяч файлов, но с ними работает лишь несколько человек (редко когда более двух крупных коммита происходит одновременно).
Первая синхронизация слэйва с мастером происходила примерно 20 минут (хранилище 500 Мегабайт, 13 тысяч файлов).
В общем, пока меня более чем устраивает такая схема зеркалирования репозитория.
>в вашем случае (мастер-слейв) лучше использовать систему болчного копировнаия типа дрбд
А под FreeBSD как быть? (
| |
|
5.21, named (?), 11:20, 17/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
под FreeBSD только костыль через GEOM, geom_gate и gmirror, в продакшен я бы не ставил, слишком далека от полной автоматизации.
| |
|
|
|
|
1.24, empty (?), 20:51, 17/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А есть какие-нибудь бенчмарки для glusterfs? типа bonnie+ - какая там будет скорость записи?
| |
|
|
3.29, empty (?), 09:52, 18/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>тока не бони а обычный дд
>
>http://www.gluster.com/community/documentation/index.php/GlusterFS_2.0_I/O_Be
>
>ужос не производительность
>
Вроде бы ничего так себе производительность. Если бы они тома в страйп сконфигурировали, может и вообще-бы запредельные значения получились бы. Но хотелось бы на bonnie+ посмотреть.
А этот glusterfs - это же fuse файловая система? Тогда как они монтировали эту систему на клиенте - с флагом direct_io или без? Оно может и улучшит значения чтения/записи, но это автоматически влечет запрет на выполнение в этой файловой системе.
http://article.gmane.org/gmane.comp.file-systems.fuse.devel/5292
>[оверквотинг удален]
>
>
> 17,7 35,7
>mit GlusterFS 1 Thread pro Server
> 33,1
>27,85
>mit GlusterFS 15 Lese- und 5 Schreibthreads pro Server 57,56 11,88
>
>lesen - чтение
>shreiden - дословно писать
| |
|
|
3.30, empty (?), 10:01, 18/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>а еще смешно выглядит это
>
>гластер пытались доказать что он круче )) люстры
>
>http://www.gluster.com/community/documentation/index.php/GlusterFS_1.3.pre2-V
>
>если люстру маштабировать горизонтально то производительность также будет увеличиваться (хотя есть предел
>если не ошибаюсь до 64 нод (не помню))
>
>а гластер ваше чем больше нод тем хуже будет работать
Я так понял, что они сконфигурировали с одинаковым количеством data-server-ов, что Люстру, что Гластер. Получилось, что на 10 нодах они ведут себя примерно одинаково.
| |
|
|
5.32, empty (?), 11:07, 18/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>http://manual.lustre.org/manual/LustreManual16_HTML/Benchmarking.html
>
>вот бенч боннии и айозона (версия люстры староватая но всёже)
Ну, это ж для Люстры ... С ней и так всё более-менее понятно (как и с Саном). А я от автора статьи (как, по всей видимости, единственному человеку на всем опеннете, у которого есть работающая гластерфс), чтоб он показал свои бенчмарки и объяснил как там обстоят дела с direct_io и исполняемыми файлами.
| |
|
|
|
|
1.36, Нихт Арбайтен (?), 11:31, 20/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Ребята, прежде чем каменты тереть - прочтите их внимательно.
"Приводим файл конфигурации клиента /etc/glusterfs/glusterfsd.vol в следующий вид:"
Здесь /etc/glusterfs/glusterfsd.vol нужно заменить на /etc/glusterfs/glusterfs.vol, поскольку этот файл потом используется в:
"Монтируем файловую систему GlusterFS в каталог /mnt/glusterfs:
glusterfs -f /etc/glusterfs/glusterfs.vol /mnt/glusterfs
или
mount -t glusterfs /etc/glusterfs/glusterfs.vol /mnt/glusterfs"
А glusterfsd.vol - это файл конфигурации сервера.
О чём вам аноним в потёртом каменте и напейсал.
| |
1.37, luzers (?), 21:42, 26/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
граждане а есть мастер-мастер ФС? время репликации неважно. работающяя нормально. желательно маштабируемая во все стороны. географически распределённая.
| |
|
2.38, empty (?), 15:57, 27/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>граждане а есть мастер-мастер ФС? время репликации неважно. работающяя нормально. желательно маштабируемая
>во все стороны. географически распределённая.
Работающая нормально - самый сложный пункт.
Есть XtreemFS сделанная с прицелом на Cloud-вычисления, можно попробовать, может это, то что тебе нужно (если только низкая производительность не смущает) ...
| |
|
|