Кто пользовался? есть ли плюсы, минусы. Может еще чего интересного есть. Хочется сделать отказоустойчивое хранение базы данных помимо бекапов.
Ни когда не юзал эту технологию. Прошу помощи. В наличии два сервера. Вот на них и хочется сделать репликацию. Мне подсказали, что для этого подойдет DRBD, а сверху накатить samba например.
главное не использовать его в active/active режиме, для фейловера в принципе сойдет, если база не слишком нагружена. Если нагружена, то лучше запустить репликацию средствами самой базы.
Если нагружена, то лучше запустить репликацию средствами самой базы.
Тут не скажу. Попросили помочь. Скорее всего там 1С база средних размеров. Средствами самой базы не понятно совсем (из-за не знания какая база используется)
Хотя хочется сделать, так сказать, отказоустойчивый кластер, на безе двух серверов.
да, заранее предупреждаю - drbd штука популярная, особенно в рунете, и народ любит устраивать холивары с криками "у меня все работает". Так вот, мое мнение насчет а/а не высосано из пальца а взято из очень близкого общения с Linbit, когда я управлял интеграцией drbd с ovirt. они сами не рекомендуют а/а для серьезных нагрузок и продакшена вообще, только а/p.
Если база 1С файловая думаю не стоит так делать. Ты же все равно будешь подключать базу по доменному имени. Сервак упадет как быть тогда? какое имя использовать? Просто нужно надежное СХД.
Кто пользовался? есть ли плюсы, минусы. Может еще чего интересного есть. Хочется сделать отказоустойчивое хранение базы данных помимо бекапов.
Ни когда не юзал эту технологию. Прошу помощи. В наличии два сервера. Вот на них и хочется сделать репликацию. Мне подсказали, что для этого подойдет DRBD, а сверху накатить samba например.
Правильно подсказали. Только одно предупреждение - не ведись на primary-primary режим. От лукаваго это. Только Primary-Secondary. А оптимально сделать так:
1. выделить два компьютера и на них организовать реплицируемый по DRBD СХД.
2. Управлять этой связкой через heartbeat. То есть поднять кластер высокой доступности.
3. Под этот же heartbeat подложить ресурсом iSCSI-Target. И пусть он раздает по iSCSI drbd-том высокой доступности.
4. На третьем компьютере поднять виртуальную машину, в ней - iSCSI-initiator, и далее - раздавать съинициированное по самбе.
5. Поднять 4-й компьютер и реализовать тем же heartbeat'ом или pacemaker'ом живую миграцию виртуальной машины с третьего хоста.
И вот тогда ты получишь действительно реальный файловый сервер организованный в кластере высокой доступности.
Предупреждение - не пытайся поднимать iSCSI-Target и initiator на одном хосте. При живой миграции, случись что, оно становится колообразно.
И еще одна особенность DRBD - надо регулярно следить за его логами. Чтобы не пропустить соcтояние split-brian. Года 3 назад оно у меня возникало регулярно. Сейчас - три раза тьфу.... Это раз.
Второе: если компилируешь drbd из исходников, то там надо под каждое новое ядро компилировать и инсталлировать модуль drbd-km. Иначе после обновления ядра drbd-тома не заведутся.
Третье: время на синхронизацию дисков требуется весьма определенное. Не стоит делать терабайтный том, если у тебя данных на пару деcятков гигабайт всего.
И последнее - между хостами с drbd (и самбой) надо иметь, минимум, гигабитный канал.
Если база 1С файловая думаю не стоит так делать. Ты же все равно будешь подключать базу по доменному имени. Сервак упадет как быть тогда? какое имя использовать? Просто нужно надежное СХД.
Все решаемо. И без каких либо специализированных СХД. По крайней мере у меня с высокой доступностью проблем нет.
Сделано следующее:
1. 2 одинаковых сервера с шустрыми дисками связаны отдельным выделенным гигабитным каналом.
2. На них - drbd-том гигабайт так на 240.
3. Для создания кластера высокой доступности и управления им - heartbeat. drbd переключается с упавшего хоста за пару-другую секунд.
4. С primary-томом в кластере связан специальный IP-адрес, который всегда живет на том хосту (виртуальный интерфейс), где primary-node drbd. Ну, там же и сама самба поднимается (хочу её в отдельную виртуалку утащить).
5. В том же кластере (чтобы хосты не слишком простаивали) живут bind+dhcp, openVPN, squid, ldap и что то еще из мелочи, не помню.
Миграция сервисов с упавшего хоста на выживший занимает несколько секунд, щелк, и они на новом месте. Только сквид не спешит... Здесь есть тонкость одна - процедура штатного выключения. Есть два режима штатного выключения:
1. По команде админа. Здесь - все поддерживаемые сервисы должны переехать на живой хост.
2. По команде с ИБП. Здесь ехать никуда не нужно, выключаемся всем кагалом.
И дополнение:
На этих двух серверах помимо drbd развернут также и glusterfs. Очень удобно на нём настройки держать, скрипты из /usl/local/bin и отдельные "базы" из /var'а, тот же /var/named, например. Ну и архивы кидать в гластер приятно.
Однако не стоит думать, что glusterfs-тома можно беспроблемно раздавать по самбе. Раздавать можно, но вот беспроблемно - никак. Там засады с блокировками и M$Office, да и 1С спотыкается конкретно. Для 1С - только drbd.
Все понял. Пойду повышать уровень матчасти. А вообще интересно. Если все на тестах гуд будет, то может и приживется. Может кто это организовывал на CentOS?
Все понял. Пойду повышать уровень матчасти. А вообще интересно. Если все на тестах гуд будет, то может и приживется. Может кто это организовывал на CentOS?
Ну я организовывал. Проблем нет. То, что написал выше - мой реальный опыт. Из реального продакшена. Кувыркался одно время с применением pacemaker'а для управления кластером. Вроде и удобно получается, и всё видно... Но не прижилось как-то. Какие-то внутренние конфликты, тормоза, задержки с переключениями... Не айс. Может, я не умею его готовить. Но на крайне тупом heartbeat'е всё работает как часы. С него и начинай.
Вот тебе ссылка на один из первоисточников: http://wiki.centos.org/HowTos/Ha-Drbd
Ну и на русском тоже всё неплохо разжевано: http://www.opennet.ru/docs/RUS/ha_cluster/
Вкуривай до полного просветления. И, поверь, оно - реально работает.
без проблем, только есть пару "НО"
Если использовать пакеты из репозитория, то проблем не будет, хотя версия там не очень то и свежая.
Если самому собирать, то могут возникнуть проблемы при обновлении ядра: надо будет пересобирать модуль.
+ ко всему еще и pacemaker/openais понадобиться.
И еще одна особенность DRBD - надо регулярно следить за его логами. Чтобы не пропустить соcтояние split-brian
text
The DRBD distribution contains a split brain handler script that installs as /usr/lib/drbd/notify-split-brain.sh. It simply sends a notification e-mail message to a specified address.
The DRBD distribution contains a split brain handler script that installs as /usr/lib/drbd/notify-split-brain.sh. It simply sends a notification e-mail message to a specified address.
Тиха украинская ночь... Но сало лучше перепрятать.
Главное надо знать, что такое состояние возможно и, в пределе, лечится принудительной переливкой (средствами drbd-же) данных с одной ноды (волюнтаристки выбранной за более актуальную) на другую. Мне в начале карьеры приходилось этим заниматься несколько раз. Сейчас этого развлечения нет. То ли скрипты выручают, то ли качество кода выросло... Не знаю.
Если самому собирать, то могут возникнуть проблемы при обновлении ядра: надо будет пересобирать модуль.
+ ко всему еще и pacemaker/openais понадобиться.
Я эту проблему решил очень просто в свое время. При загрузке, в /etc/rc.local, сравнивал текущую версию ядра с запомненной ранее. И если версии расходились, то .configure; make; make install. Ну и только потом service drbd start. И никаких проблем при обновлении ядра.
pacemaker/openais по моему излишен и тяжеловесен для drbd. Для него вполне достаточно heartbeat.
