Дублирование серверов FreeBSD

[NETOS 129]

Приветствую! Посоветуйте как сделать полное дублирование (зеркалирование) серверов на ОС FreeBSD?

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

Как организовать сей проект?

[andryas 1 058]

Самый простой вариани - pppoe. Ставите сколько хотите серверов, при выходе из строя какого-то из них, его клиенты переподключатся к работающим.

Если ipoe или же pptp и другие, основаные на IP тунели - переключать управляемым комутатором, перепрописывать маршрут к новому серверу, для pptp также можно использовать DNS.

[Maxxx 444]

Значит вы предлагаете поменять тип авторизации на N к народу, тем более на какое то  pppoe, от которого все тикают как могут.

[TretUliy2 1]

Для IPoE pfsync+carp http://www.opennet.ru/base/sec/openbsd_carp_pf.txt.html , сам не пробовал но слышал что работает.

Відредаговано 2013-02-12 09:22:39 TretUliy2

[andryas 1 058]

ТС не указал способ авторизации

[greyshadow 22]

Мало данных...

Как вариант - 2 сервака, ваш шлюз/биллинг и т.д. в виртуалку, виртуалку синхронить на второй сервак.

Резервирование практически на "хардварном" уровне.

Ну или излагайте поподробнее.

[...sirius 3]

carp, vrrpd

[NETOS 129]

да что тут подробнее. Обычный мощный тазик, на нем две сетевые, одна в провайдера вторая в мою сеть. На серваке крутится, MySQL, NoDeny, Zabbix и остальная серверная лабуда. Авторизация IP+MAC но перехожу на RADIUS, сеть Wi-FI. 

 

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

[logic 513]

дешевле заземлить и поставить хороший БП. чем рядом будет гудеть в холостую еще один комп

[ucTuHa 199]

да что тут подробнее. Обычный мощный тазик, на нем две сетевые, одна в провайдера вторая в мою сеть. На серваке крутится, MySQL, NoDeny, Zabbix и остальная серверная лабуда. Авторизация IP+MAC но перехожу на RADIUS, сеть Wi-FI. 

 

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

Ну так если сеть у вас будет уходить на бс с помощью какого то свича, то толку от двух серверов тогда, есть у вас сгорит порт в свиче? Или как вы хотите два исхода в бс вставить?

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

Відредаговано 2013-02-12 14:36:59 ucTuHa

[greyshadow 22]

Т.к. самый класный вопрос - резервирование именно "остальной всей лабуды" вкуче с базой данных, то:

1. Вынос базы данных на нормальный сервак с заземлением/питанием.

2. машинка, которая собственно занимается разруливанием трафика и наиболее подвержена воздействию гроз резервируется на уровне vrrp.

 

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

 

при ручном переключении достаточно хранить конфиги+ зеркало базы, и работоспособность шлюза будет восстановлена минут за 5, если сдохнет именно комп.

[ucTuHa 199]

Т.к. самый класный вопрос - резервирование именно "остальной всей лабуды" вкуче с базой данных, то:

1. Вынос базы данных на нормальный сервак с заземлением/питанием.

2. машинка, которая собственно занимается разруливанием трафика и наиболее подвержена воздействию гроз резервируется на уровне vrrp.

 

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

 

при ручном переключении достаточно хранить конфиги+ зеркало базы, и работоспособность шлюза будет восстановлена минут за 5, если сдохнет именно комп.

 

2. Разность базу и доступ на разные машины? Был пс, стало два, отличная получается отказоустойчивость.

А если у ТС сервер с базой за 50 км. от него, и некому больше переключить?

 

Если нет возможности спрятать кабель от наводок, то лучший вариант это оптика к базе, ну а для сервера выпрямитель какой нибудь.

Відредаговано 2013-02-12 14:45:19 ucTuHa

[rootvm 1]

hast+carp+pf не убиваемая связка.

[Lambert 5]

dd и регулярный бэкап на другой винт

в случае чего - винт в аналогичный тазик и поехали

но полностью автоматически не получится, конечно. А от гроз и прочего лучше защищаться, не так уж это и дорого, имхо

[NiTr0 583]

Поднимаете отказоустойчивый кластер.... Или настраиваете репликацию БД на другую машину, с последующим подъемом всего хозяйства ручками...

[greyshadow 22]

 

Т.к. самый класный вопрос - резервирование именно "остальной всей лабуды" вкуче с базой данных, то:

1. Вынос базы данных на нормальный сервак с заземлением/питанием.

2. машинка, которая собственно занимается разруливанием трафика и наиболее подвержена воздействию гроз резервируется на уровне vrrp.

 

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

 

при ручном переключении достаточно хранить конфиги+ зеркало базы, и работоспособность шлюза будет восстановлена минут за 5, если сдохнет именно комп.

 

2. Разность базу и доступ на разные машины? Был пс, стало два, отличная получается отказоустойчивость.

А если у ТС сервер с базой за 50 км. от него, и некому больше переключить?

 

Если нет возможности спрятать кабель от наводок, то лучший вариант это оптика к базе, ну а для сервера выпрямитель какой нибудь.

Все оперативные данные, требующие синхронизации, именно БД; все остальное решается конфигами, хранить и синхронизировать которые гораздо проще.

[UStas_rinet 43]

Отвяжите гальванически сервер и не парьтесь. 

 

А если уже хотите шпиливили то:

- vrrp для резервирования IP шлюза.

- на обоих серваках днс и оба отдавать клиентам

- master-master репликация базы, один сервер автоинкремент вносит четный. другой не четный

- все доменные имена прописывать А записью на оба сервака, браузер сам разберется если какой то отвалится

[NiTr0 583]

Отвяжите гальванически сервер и не парьтесь. 

 

А если уже хотите шпиливили то:

- vrrp для резервирования IP шлюза.

- на обоих серваках днс и оба отдавать клиентам

- master-master репликация базы, один сервер автоинкремент вносит четный. другой не четный

- все доменные имена прописывать А записью на оба сервака, браузер сам разберется если какой то отвалится

 

Мастер-мастер, при отсутствии синхронной репликации (а у мускула вроде как ее нет) - это будет адская попоболь владельцу...

Не даром ведь умные люди CRM всякие понапридумывали. Либо - самому CRM пилить на скриптах...

[NETOS 129]

Ну да, то что вы написали для решения моей задачи, это реально тяжело осуществить! Тогда нужно максимально обезопасить сервер. Что посоветуете от гроз и перепадов напряжения?

[greyshadow 22]

Так все давно известно,

Нормальный UPS инверторного типа с аккумуляторами в буфере.

Заземление.

езер - через оптические медики.

В идеале - сервак на нормальной железке с двумя БП и хардварным RAID-ом.

[UStas_rinet 43]

Так все давно известно,

Нормальный UPS инверторного типа с аккумуляторами в буфере.

Заземление.

езер - через оптические медики.

В идеале - сервак на нормальной железке с двумя БП и хардварным RAID-ом.

 

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

[maxx 196]

а облако никто не поднимал?

[greyshadow 22]

Нормальное серверное (не десктоп) железо RAID 1 содержит практически всегда на борту, а большего там ненадо.

[greyshadow 22]

а облако никто не поднимал?

Облака бывают разные.

PaaS, SaaS, IaaS (это если забыть о перистых и кучевых) - вы о каком конкретно? и под какие цели/задачи?

[UStas_rinet 43]

Нормальное серверное (не десктоп) железо RAID 1 содержит практически всегда на борту, а большего там ненадо.

 

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