[alishkka]

Доброе утро, имеются 2 сервера RACKABLE SERVER 2U 2X INTEL XEON QUAD CORE 2.33GHz QC, на 1-м сервере ОС FreeBSD 8, на нем поднят pptp сервер(mpd5) и биллинг(LanBilling), 2-й сервер новый и пока пуст.

Подскажите пожалуйста как можно полностью зарезервировать их? Т.е. чтоб при сбое одного, другой сразу включался в работу

[pppoetest]

vrrp?

Изменено 11 июня, 2013 пользователем pppoetest

[alishkka]

Нужно разервирование всего сервера, т.е. своего рода RAID из 2-х серверов, зеркалирование двух серверов

[Сильвер]

Подскажите пожалуйста как можно полностью зарезервировать их?

carp же.

[alishkka]

Ну это вы говорите о том, как эти серверам один и тот же адрес дать одновременно, а для начала мне нужно сделать чтоб даннные писались сразу на 2 сервера

[tartila]

Ну это вы говорите о том, как эти серверам один и тот же адрес дать одновременно, а для начала мне нужно сделать чтоб даннные писались сразу на 2 сервера

 

сетевая файловая система аля smb на backup интерфейсе? и carp на основном интерфейсе.

[mrlexus]

У Ланбиллинга есть статья на эту тему. Там пример для Linux, но для FreeBSD тоже можно сделать.

Чтобы абоненты не ждали таймаута сброса сессий mpd можно в скриптах обработки carp чистить таблицу sessionradius.

[NiTr0]

сетевая файловая система аля smb на backup интерфейсе?

Мсье знает толк в извращениях... Вообще-то для этих целей есть drbd, но оверхид большой, а надежность - малая.

 

То, что топикстартер хочет - зовется кластеризацией. Реализуется на том же pacemaker'е к примеру. Делается active-passive mysql (или что там бэкэндом служит) с репликацией (ну или если репликация отсуствует - то тогда уже в крайнем случае поверх drbd лепить), поднимаются копии радиуса, хттп сервера и mpd на обеих серверах.

Линк между нодами кластера должен резервироваться (к примеру бондинг из одного физического интерфейса и одного влана через интерфейсы, смотрящие в общую сеть) ибо обрыв линка - событие весьма печальное, вызывающее split-brain и требующее вмешательства админа.

[Сильвер]

для начала мне нужно сделать чтоб даннные писались сразу на 2 сервера

HAST + CARP. Я бы при этом мигрировал с 8_Stable.

[QWE]

Мсье знает толк в извращениях... Вообще-то для этих целей есть drbd, но оверхид большой, а надежность - малая.

 

То, что топикстартер хочет - зовется кластеризацией. Реализуется на том же pacemaker'е к примеру. Делается active-passive mysql (или что там бэкэндом служит) с репликацией (ну или если репликация отсуствует - то тогда уже в крайнем случае поверх drbd лепить), поднимаются копии радиуса, хттп сервера и mpd на обеих серверах.

Линк между нодами кластера должен резервироваться (к примеру бондинг из одного физического интерфейса и одного влана через интерфейсы, смотрящие в общую сеть) ибо обрыв линка - событие весьма печальное, вызывающее split-brain и требующее вмешательства админа.

 

"ну или если репликация отсутствует - то тогда уже в крайнем случае поверх drbd лепить" - этот крайний случай нисколько не надежный. MySQL innodb поверх drbd. Крах сервера приведет к тому, что MySQL на резервном сервере не загрузиться на тех данных которые на нем есть благодаря drbd. И тогда БД дропать и восстанавливать из бекапа. MySQL Мастер-Мастер или Мастер-Слейв куда более пригодно. а статику можно и rsync ом почаще. Не тратьте время на drbd под MySQL innodb движок. LanBilling1.9 работает с innodb таблицами. drbd быть может под статику. Режим работы drbd опять же лучше primary - secondary. В конце настроек - тесты с выкл. основного сервера.

[vlad11]

1) Миграция на 9.1-STABLE.

2) CARP на внутренних интерфейсах. Или общие вланы на внутреннем интерфейсах, отличаются только по IP, например 10.0.1.1 и 10.0.1.2. И средствами биллинга отдавать нужный шлюз для балансировки.

3) Mysql репликация Master-Master.

4) Если данные на дисках где-то меняется - тогда rsync. Ну, взаимный бэкап конфигов обязательно.

[NiTr0]

"ну или если репликация отсутствует - то тогда уже в крайнем случае поверх drbd лепить" - этот крайний случай нисколько не надежный. MySQL innodb поверх drbd.

Дык зачем лепить drbd там, гре репликация присутствует? :)

Да, шанс что нифига не поднимется есть, особенно при асинхронном drbd, но - если СУБД не поддерживает репликацию, drbd становится единственным решением.

 

3) Mysql репликация Master-Master.

master-slave ИМХО надежнее, с переключением мастера - благое дело реализуется просто. percona replication manager к pacemaker'у ИМХО весьма годен.

 

И да, по поводу rsync'а - распределенная ФС вместо него тоже вполне имеет право на жизнь ;)

[Alex/AT]

Мы хитрее сделали. N брасов, два радиуса, завязанных на MySQL NDB Cluster с двумя репликами. Но там надо сильно больше двух нод + с NDB весьма сложная и многозвенная система получается + жрёт до фига памяти, поэтому решение не для всех.

 

Тупо и быстро зарезервировать "малой кровью" - рекомендую Galera Cluster для MySQL + VRRP для всего остального, делал на Galera маленькое внедрение - работает. Но третью SQL-ноду всё равно где-то еще поднимать придётся, иначе при падении одной из нод кворума не будет. Ну и сырое оно достаточно, несмотря на возраст.

 

Если надо зарезервировать сайтик-настройки-кабинет-скрипты и некоторые файловозависимые подсистемы - GlusterFS решает почти все проблемы. Нюансов у него хватает, но для задач, работающих именно с файлами по отдельности (а не с одним и тем же файлом в роли БД или еще чего) - вполне применим.