Инструкция по создании зеркалируемого (реплицированного) между двумя машинами хранилища файлов на базе GlusterFS (http://www.gluster.com/) и Ubuntu 9.10. Добавляемый в созданное хранилище файл на первом сервере буде сразу доступен на втором и наоборот, при этом данные на каждой машине будут использоваться из локального раздела, что обеспечивает значительно более высокую производительность, по сравнению с NFS. С особенности кластерной файловой системы GlusterFS можно познакомиться на [[http://www.opennet.me/opennews/art.shtml?num=21760 данной странице]].В рассматриваемой конфигурации задействованы три машины: два сервера (server1.example.com/192.168.0.100, server2.example.com/192.168.0.101) и один клиент (client1.example.com: IP адрес 192.168.0.102). Серверы выступают в роли машин для экспорта дисковых разделов, доступ к отказоустойчивому хранилищу осуществляется на стороне клиента.
В представленном примере серверы и клиент размещены на разных машинах, но в реальных условиях клиентские и серверные составляющие обычно совмещены на одной машине. Соответствующую конфигурацию можно сгенерировать при помощи утилиты glusterfs-volgen.
++ Установка серверной части GlusterFS на server1.example.com и server2.example.com:
Так как GlusterFS доступен в стандартном репозитории Ubuntu 9.10, достаточно выполнить (сейчас и далее все действия выполняются под пользователем root):
apt-get install glusterfs-server
Для организации хранилища на сервере будем использовать каталог /data/export.
Приводим файл конфигурации /etc/glusterfs/glusterfsd.vol на серверах в следующий вид:
volume posix
type storage/posix
option directory /data/export
end-volumevolume locks
type features/locks
subvolumes posix
end-volumevolume brick
type performance/io-threads
option thread-count 8
subvolumes locks
end-volumevolume server
type protocol/server
option transport-type tcp
# далее через запятую нужно перечислить IP или имена хостов клиентов
# можно использовать маски вида 192.168.*,
option auth.addr.brick.allow 192.168.0.102
subvolumes brick
end-volumeЗапускаем сервер GlusterFS:
/etc/init.d/glusterfs-server start
++ Настройка клиента GlusterFSДля установки клиентской части GlusterFS выполняем:
aptitude install glusterfs-client glusterfs-server
Хранилище будем монтировать в каталог /mnt/glusterfs.
Приводим файл конфигурации клиента /etc/glusterfs/glusterfsd.vol в следующий вид:
volume remote1
type protocol/client
option transport-type tcp
option remote-host 192.168.0.100 # server1.example.com
option remote-subvolume brick
end-volumevolume remote2
type protocol/client
option transport-type tcp
option remote-host 192.168.0.101 # server2.example.com
option remote-subvolume brick
end-volumevolume replicate
type cluster/replicate
subvolumes remote1 remote2
end-volumevolume writebehind
type performance/write-behind
option window-size 1MB
subvolumes replicate
end-volumevolume cache
type performance/io-cache
option cache-size 512MB
subvolumes writebehind
end-volume
Монтируем файловую систему GlusterFS в каталог /mnt/glusterfs:glusterfs -f /etc/glusterfs/glusterfs.vol /mnt/glusterfs
или
mount -t glusterfs /etc/glusterfs/glusterfs.vol /mnt/glusterfsДля автоматизации монтирования во время загрузки в /etc/fstab сдедует добавить:
/etc/glusterfs/glusterfs.vol /mnt/glusterfs glusterfs defaults 0 0
++ Тестирование
Создаем в GlusterFS разделе на стороне клиента несколько файлов:
touch /mnt/glusterfs/test1
touch /mnt/glusterfs/test2Эти файла сразу должны появиться на серверах в каталоге /data/export
Выключим первый сервер и добавить на стороне клиента еще несколько файлов:
touch /mnt/glusterfs/test3
touch /mnt/glusterfs/test4
rm -f /mnt/glusterfs/test2Изменения должны появиться на втором сервере.
Включим первый сервер и увидим, что данные на нем неактуальны. Изменения будут синхронизированы автоматически, для инициирования синхронизации на стороне клиента достаточно выполнить любую операцию с разделом, например, посмотреть содержимое через "ls -l /mnt/glusterfs/".
++ GlusterFS в роли замены NFS с поддержкой кэширования.Чтобы примонтировать раздел в NFS-подобном виде, без репликации, [[http://www.howtoforge.net/creating-an-nfs-like-standalone-st... достаточно]] добавить в конфигурации сервера в блоке "volume locks" опцию "option mandatory-locks on". На стороне клиента нужно закомментировать в конфигурации блок "volume replicate" и убрать блок, описывающий вторую реплицируемую директорию "volume remote2". В секции "volume writebehind" на стороне клиента при этом заменяем опцию "subvolumes replicate" на "subvolumes remote", а также можем уменьшить размер окна до 1 Мб ("option window-size 1MB").
++ Создание распределенного на 4 узла хранилища
При реализации хранилища, распределенного на 4 узла, настройка [[http://www.howtoforge.net/distributed-storage-across-four-st... производится]] аналогично, по аналогии с remote2 добавляются разделы remote3 и remote4. Вместо "volume replicate" добавляется раздел "volume distribute":
...
volume remote3
type protocol/client
option transport-type tcp
option remote-host server3.example.com
option remote-subvolume brick
end-volumevolume remote4
type protocol/client
option transport-type tcp
option remote-host server4.example.com
option remote-subvolume brick
end-volumevolume distribute
type cluster/distribute
subvolumes remote1 remote2 remote3 remote4
end-volume
...В блоке "volume writebehind" приписывается "subvolumes distribute".
Конфигурацию можно сгенерировать автоматически, например, запустив на одном из серверов:
glusterfs-volgen --name repstore1 --raid 1 hostname1:/export/sdb1 \
hostname2:/export/sdb1 hostname3:/export/sdb1 hostname4:/export/sdb1При надлежащей настройке параметров доступа к серверам все параметры конфигурации серверных и клиентских составляющих на всех машинах распределенного хранилища будут обновлены автоматически. Для систем не поддерживающих GlusterFS доступ к хранилищу можно организовать через NFS, SMB или WebDAV.
URL: http://www.howtoforge.net/high-availability-storage-with-glu...
Обсуждается: http://www.opennet.me/tips/info/2264.shtml
Отличная статья! Спасибо.
А как можно автоматизировать процесс синхронизации в случае выключения одного из серверов и возобновления его работы?
И что будет если разместить там базу MySQL/PostreeSQL ?
>И что будет если разместить там базу MySQL/PostreeSQL ?при запуске второй БД файл окажется залочен.
вот вот и ваще мускул рекомендует не ставить базу на НФС лайк Фса сам гластер это полное ГЭ для продакшена не годится
Аргументы?(не, в самом деле интересно про грабли, ибо серьезно думаю над.)
>Аргументы?
>
>(не, в самом деле интересно про грабли, ибо серьезно думаю над.)читаем коммент номер 8 (внизу)
я ещё не говорю про производительностьпс: если хотите использовать гластер как НФС то лучше сразу использовать саму НФс ФС
а так я пробовал вариант когда все ноды реплицируются (все мастера - любое изменения на любой ноде реплицируются на остальные ноды) и это всё жутко тормозило и тормозило горизонтально
если две мастер-мастер ноды то это ещё ничего а когда подключил 4 бля это был ужас листинг директории чутьли не 5 секунд выполнялся
>вот вот и ваще мускул рекомендует не ставить базу на НФС лайк
>Фс
>
>а сам гластер это полное ГЭ для продакшена не годитсяА в какую сторону посмотреть для продакшен ?
>>вот вот и ваще мускул рекомендует не ставить базу на НФС лайк
>>Фс
>>
>>а сам гластер это полное ГЭ для продакшена не годится
>
>А в какую сторону посмотреть для продакшен ?в цель какая - отказоустойчивость?
>>>вот вот и ваще мускул рекомендует не ставить базу на НФС лайк
>>>Фс
>>>
>>>а сам гластер это полное ГЭ для продакшена не годится
>>
>>А в какую сторону посмотреть для продакшен ?
>
>в цель какая - отказоустойчивость?отказоустойчивость и полная сохранность данных при выходе из строя любого из хранилищ
скоростные характеристики тут второстепенноежелезные райды уже стоят
>[оверквотинг удален]
>>>
>>>А в какую сторону посмотреть для продакшен ?
>>
>>в цель какая - отказоустойчивость?
>
>отказоустойчивость и полная сохранность данных при выходе из строя любого из хранилищ
>
>скоростные характеристики тут второстепенное
>
>железные райды уже стоятвот как раз мне понравился механизм фейловера люстры
правда чтобы достигнуть фейловера надо использовать внешние хранилища ибо без них (на голых серверах) фейловер не построить
>[оверквотинг удален]
>>>
>>>А в какую сторону посмотреть для продакшен ?
>>
>>в цель какая - отказоустойчивость?
>
>отказоустойчивость и полная сохранность данных при выходе из строя любого из хранилищ
>
>скоростные характеристики тут второстепенное
>
>железные райды уже стояттогда вас интересует репликация на уровне приложения - master-slave в самом mysql или репликация на уровне блочного устройства - смотрите в сторону drbd (+ для автоуправления доступностью heartbeat)
для продакшена советую либо GPFS либо LustreFS если нужна распределённая шаред ФС
правда люстра хоть и используется на многих супер кластерах я её считаю сырой
А что скажете насчет drbd+oсf2 ?
для последующего экспорта в nfs и чтоб все жило при отказе одной из нод
>А что скажете насчет drbd+oсf2 ?
>для последующего экспорта в nfs и чтоб все жило при отказе одной
>из нод))) про oсf2 как раз хотел и сказать
отмечу что oсf2 это шаред файловая система которая позволяет работать двум серверам совместно с одним внешним хранилищем (так же как и GFS2)
(использовать oсf2 для директ дисков не получится)и использовать drbd+oсf2 не имеет смысла
это понятие пошло из того что, чтобы использовать drbd в режиме мастер-мастер нужна кластерная (точнее шаред) файловая система с распределённой системой блокировок и приводят как раз ту самую oсf2как мы знаем любые внешние хранилища имеют собственные рейды то использование drbd здесь вовсе не нужно
просто подключаем к хранилищу несколько серверов и всё при отказе одного из серверов система будет жива, при отказе диска есть рейд
drbd лучше использовать только в схеме мастер-слейв для бекапа
а что делать при отказе хранилища? (в моем случае это обычныые сервера + iscsi)
>а что делать при отказе хранилища? (в моем случае это обычныые сервера
>+ iscsi)вероятность полного слета хранилища мала
у вас может слететь один диск в рейде но не всё сразу )))и ваще что вы сделаете если у вас всё слетит и резервных хранилищ ваще нету ? - потеряете данные
>А как можно автоматизировать процесс синхронизации в случае выключения одного из серверов
>и возобновления его работы?Как я понял оно автоматически синхронизируется, при выполнении первой операции с ФС после возврата в строй отключенного узла.
А поддержку ACL в ней сделали ?
мне не нравиться то что репликация происходит только тогда когда идёт запрос на файл или на листинг директорииполучается ситуация если на одной ноде положили файл и на другой ноде не производили никаких действий то в случаее падения первой ноды добавленные файлы на второй ноде не появятся
>мне не нравиться то что репликация происходит только тогда когда идёт запрос
>на файл или на листинг директории
>
>получается ситуация если на одной ноде положили файл и на другой ноде
>не производили никаких действий то в случаее падения первой ноды добавленные
>файлы на второй ноде не появятсяЦенное замечание.
Кто-нибудь из спецов не посоветует решение полноценной репликации ФС "мастер-слэйв"?
Мне понравилось как можно легко это сделать с SVN: просто вешаешь хук на коммит, который через ssh на слэйв-сервере запускает процесс синхронизации с мастером.
>>Мне понравилось как можно легко это сделать с SVN: просто вешаешь хук на коммит, который через ssh на слэйв-сервере запускает процесс синхронизации с мастером.вы бенчмарк проводили ?
как ведёт себя такая система при интенсивной записи на мастере ???
в вашем случае (мастер-слейв) лучше использовать систему болчного копировнаия типа дрбд
>>>Мне понравилось как можно легко это сделать с SVN: просто вешаешь хук на коммит, который через ssh на слэйв-сервере запускает процесс синхронизации с мастером.
>
>вы бенчмарк проводили ?
>Нет. Подумал что такая система не должна влиять на производительность самого хранилища, беря во внимание особенности самой SVN. К тому же, поверил опыту знакомого - у него на ПК Pentium2 300 MHz, 256 RAM живет хранилище с 3 тысячами файлов, с которыми работают постоянно с десяток программистов.
>как ведёт себя такая система при интенсивной записи на мастере ???
>У себя же, "на глаз" снижения производительности не заметил.
К слову, у меня в проекте более 13 тысяч файлов, но с ними работает лишь несколько человек (редко когда более двух крупных коммита происходит одновременно).
Первая синхронизация слэйва с мастером происходила примерно 20 минут (хранилище 500 Мегабайт, 13 тысяч файлов).
В общем, пока меня более чем устраивает такая схема зеркалирования репозитория.>в вашем случае (мастер-слейв) лучше использовать систему болчного копировнаия типа дрбд
А под FreeBSD как быть? (
под FreeBSD только костыль через GEOM, geom_gate и gmirror, в продакшен я бы не ставил, слишком далека от полной автоматизации.
20 минут чтобы скопировать 500 метров с мастера на слейв О_о ????пс: переходите на гит ))))
А есть какие-нибудь бенчмарки для glusterfs? типа bonnie+ - какая там будет скорость записи?
тока не бони а обычный ддhttp://www.gluster.com/community/documentation/index.php/Glu...
ужос не производительность
вот здесь по-немецки
http://cloudcontrol.de/glusterfs-benchmark/
Lesen Schreiben
ohne GlusterFS 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,88lesen - чтение
shreiden - дословно писать
>тока не бони а обычный дд
>
>http://www.gluster.com/community/documentation/index.php/Glu...
>
>ужос не производительность
>Вроде бы ничего так себе производительность. Если бы они тома в страйп сконфигурировали, может и вообще-бы запредельные значения получились бы. Но хотелось бы на bonnie+ посмотреть.
А этот glusterfs - это же fuse файловая система? Тогда как они монтировали эту систему на клиенте - с флагом direct_io или без? Оно может и улучшит значения чтения/записи, но это автоматически влечет запрет на выполнение в этой файловой системе.
http://article.gmane.org/gmane.comp.file-systems.fuse.devel/...
>[оверквотинг удален]
>
>
> 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 - дословно писать
>А есть какие-нибудь бенчмарки для glusterfs? типа bonnie+ - какая там будет
>скорость записи?а еще смешно выглядит это
гластер пытались доказать что он круче )) люстры
http://www.gluster.com/community/documentation/index.php/Glu...
если люстру маштабировать горизонтально то производительность также будет увеличиваться (хотя есть предел если не ошибаюсь до 64 нод (не помню))
а гластер ваше чем больше нод тем хуже будет работать
>[оверквотинг удален]
>а еще смешно выглядит это
>
>гластер пытались доказать что он круче )) люстры
>
>http://www.gluster.com/community/documentation/index.php/Glu...
>
>если люстру маштабировать горизонтально то производительность также будет увеличиваться (хотя есть предел
>если не ошибаюсь до 64 нод (не помню))
>
>а гластер ваше чем больше нод тем хуже будет работатьЯ так понял, что они сконфигурировали с одинаковым количеством data-server-ов, что Люстру, что Гластер. Получилось, что на 10 нодах они ведут себя примерно одинаково.
http://manual.lustre.org/manual/LustreManual16_HTML/Benchmar...вот бенч боннии и айозона (версия люстры староватая но всёже)
>http://manual.lustre.org/manual/LustreManual16_HTML/Benchmar...
>
>вот бенч боннии и айозона (версия люстры староватая но всёже)Ну, это ж для Люстры ... С ней и так всё более-менее понятно (как и с Саном). А я от автора статьи (как, по всей видимости, единственному человеку на всем опеннете, у которого есть работающая гластерфс), чтоб он показал свои бенчмарки и объяснил как там обстоят дела с direct_io и исполняемыми файлами.
время будет проведу бенч на поверных серверах
можно будет посмотреть здеся http://paranoidchaos.livejournal.com/
У меня вот что получилось с одним сервером и одним клиентом на локалхосте:Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
xxxx.xxxx.xx 15512M 9012 32 15543 3 10167 3 9361 52 31980 5 75.5 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 384 2 2124 5 425 1 382 2 2434 4 417 1
mount:glusterfs#/usr/local/etc/stripe-client.vol on /mnt/zip type fuse (rw,allow_other,default_permissions,max_read=131072)
Конфиг сервера:
volume posix1
type storage/posix
option directory /var/lib/glusterfs
end-volumevolume locks1
type features/locks
subvolumes posix1
end-volumevolume brick1
type performance/io-threads
option thread-count 8
subvolumes locks1
end-volumeolume server
type protocol/server
option transport-type tcp
option transport.socket.listen-port 6996
subvolumes brick1
option auth.addr.brick1.allow *
end-volumeКонфиг клиента:
volume client1
type protocol/client
option transport-type tcp
option remote-host 127.0.0.1
option transport.socket.remote-port 6996
option remote-subvolume brick1
end-volumevolume replicate
type cluster/replicate
subvolumes client1
end-volumeНа примонтированной директории программы запускаются.
time dd if=/dev/zero of=/mnt/zip/zero bs=64k count=20000
20000+0 records in
20000+0 records out
1310720000 bytes (1.3 GB) copied, 11.2308 s, 117 MB/sreal 0m13.094s
user 0m0.024s
sys 0m0.340s
Ребята, прежде чем каменты тереть - прочтите их внимательно."Приводим файл конфигурации клиента /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 - это файл конфигурации сервера.
О чём вам аноним в потёртом каменте и напейсал.
граждане а есть мастер-мастер ФС? время репликации неважно. работающяя нормально. желательно маштабируемая во все стороны. географически распределённая.
>граждане а есть мастер-мастер ФС? время репликации неважно. работающяя нормально. желательно маштабируемая
>во все стороны. географически распределённая.Работающая нормально - самый сложный пункт.
Есть XtreemFS сделанная с прицелом на Cloud-вычисления, можно попробовать, может это, то что тебе нужно (если только низкая производительность не смущает) ...
Могу посоветовать почитать эту статью по тестированию распределения контента в GlusteFS - http://sysadm.pp.ua/linux/glusterfs-setup.html. Очень толково написано, может кому-то понадобиться.