Jump to content

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


Recommended Posts

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

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

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

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

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

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

Link to post
Share on other sites

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

 

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

Link to post
Share on other sites

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

 

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

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

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

Edited by ucTuHa
Link to post
Share on other sites

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

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

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

 

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

 

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

Link to post
Share on other sites

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

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

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

 

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

 

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

 

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

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

 

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

Edited by ucTuHa
Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

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

Link to post
Share on other sites

 

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

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

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

 

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

 

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

 

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

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

 

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

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

Link to post
Share on other sites

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

 

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

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

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

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

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

Link to post
Share on other sites

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

 

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

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

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

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

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

 

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

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

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

Заземление.

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

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

Link to post
Share on other sites

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

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

Заземление.

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

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

 

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

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

 

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...