2 биллинга одновременно работающих. нужна помощь в организации

[KJack 35]

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

юзаем фринибс на убунту сервер х64

 

буду благодарен за любую помощь и конструктивную критику

[Serjio 19]

CARP на серверах А и Б + master-master репликация.

[Kucher2 122]

Если +- 10 минут по статистике не критичны для такой системы, то можно и СТГ на скриптах скрутить таким макаром.

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

Я просто хочу вас успокоить, что не всё так сложно как может казаться, ибо этот момент уже рассматривался. Может стоить пригласить в тему тех, у кого в базе крутится несколько тысяч абонов (madf например)?

[NiTr0 583]

pacemaker, кластеризация, ну и мускул с репликацией ессно. После вдумчивого раскуривания - настраивается за 15 минут. В первыйй раз ессно несколько дней может занять изучение и эксперименты.

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

[Prime 51]

А после восстановления работы синхронизировал бы изменения согласно серверу Б, и наоборот.

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

например VMWare vCloud или же проекта OpenStack:

в случае падения контроллера, просто не будет доступа к данным.

 

скриптами тут не обойтись.

 

 

 

размазывание данных вещь не сильно хитрая в отличии от общего проекта failover схемы.

в первую очередь следует вынести из сервера функции маршрутизации трафика.

[NiTr0 583]

в случае падения контроллера, просто не будет доступа к данным.

Что в лоб, что по лбу...

Это сильно отличается от падения сервера с данными?

[Prime 51]

конечно сильно.

данные же не потеряются.

 

контроллеры на порядок проще резервировать.

 

UPD:

вариант с Master - Slave очень даже ничего.

при условии, что со Slave не будет на Master ничего синхронизироваться.

 

Тупая репликация БД спасет

[NiTr0 583]

конечно сильно.

данные же не потеряются.

При падении сервера с данными данные, как это ни странно, тоже не теряются. Лежат себе спокойно, ждут пока их поднимут. А при настроенной репликации - вообще песня, данные синхронизируются везде...

 

контроллеры на порядок проще резервировать.

Накой городить огород из кучи машин (N серверов биллинга + M контроллеров облака), если достаточно простого кластера на 2 ноды, с pacemaker'ом в качестве CRM, мускулом в режиме мастер-мастер, и биллингом в виде мигрирующего ресурса? Разве что письками мериться, мол, "у меня биллинг в облаке личном живет"?

[Prime 51]

конечно сильно.

данные же не потеряются.

При падении сервера с данными данные, как это ни странно, тоже не теряются. Лежат себе спокойно, ждут пока их поднимут. А при настроенной репликации - вообще песня, данные синхронизируются везде...

 

контроллеры на порядок проще резервировать.

Накой городить огород из кучи машин (N серверов биллинга + M контроллеров облака), если достаточно простого кластера на 2 ноды, с pacemaker'ом в качестве CRM, мускулом в режиме мастер-мастер, и биллингом в виде мигрирующего ресурса? Разве что письками мериться, мол, "у меня биллинг в облаке личном живет"?

да, это уже почти стандарт дефакто СХД.

 

pacemaker хорош, бесспорно

просто со схемой Master-Master можно долго просидеть

тут же задача:

"сервер А после восстановления работы синхронизировал бы изменения согласно серверу Б, и наоборот."

[NiTr0 583]

просто со схемой Master-Master можно долго просидеть

тут же задача:

"сервер А после восстановления работы синхронизировал бы изменения согласно серверу Б, и наоборот."

А чего просидеть-то? Вроде как в мускуле с экспортом-импортом бинарных логов все гладко и шелковисто, проблем особо нет.

И да, если вы предлагаете таким образом шарить SAN - это еще помимо облачной вундервафли нужно будет завести отдельные сервера биллинга (основной и резерв), так? Итого минимум 2 SAN + минимум 2 контроллера облака + минимум 2 сервера биллинга, итого...

И это к слову не обеспечит целостность данных при падении машины с мускулом к примеру - если в этот момент производилась запись в БД, на всех SAN получится битая база, требующая проверки/восстановления. Не совсем то, что нужно, не так ли?

[KJack 35]

а вариант, взять такую штучку QNAP TS-669 Pro, ну или попроще QNAP TS-419P II и прикрутить к ним два одинаковых тазика ч/з свитч? кто-то практиковал такое?

[NiTr0 583]

Падает сохо нас, скукоживается вся сеть + битая БД бонусом (кеш записи)...

[pavlabor 1 914]

 

А после восстановления работы синхронизировал бы изменения согласно серверу Б, и наоборот.

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

например VMWare vCloud или же проекта OpenStack:

в случае падения контроллера, просто не будет доступа к данным.

 

скриптами тут не обойтись.

 

размазывание данных вещь не сильно хитрая в отличии от общего проекта failover схемы.

в первую очередь следует вынести из сервера функции маршрутизации трафика.

 

Есть опыт реализации?

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

Понятно, точил с портов.

Відредаговано 2013-09-07 05:46:50 pavlabor

[pavlabor 1 914]

Падает сохо нас, скукоживается вся сеть + битая БД бонусом (кеш записи)...

Вот через пару таких залетов,

отказались от карпа, сейчас работает два зеркальных билинга, с посуточным бекапом и онлайн синхронизацией запросов INSERT, UPDATE, DELETE.

[KJack 35]

Падает сохо нас, скукоживается вся сеть + битая БД бонусом (кеш записи)...

насы на отдельных тазиках ч/з свитч с осфп2 маршрутизацией

[KJack 35]

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

[KJack 35]

NiTr0

дублировать хранилище - тоже вроде как не вариант

[NiTr0 583]

Вот через пару таких залетов,

отказались от карпа, сейчас работает два зеркальных билинга, с посуточным бекапом и онлайн синхронизацией запросов INSERT, UPDATE, DELETE.

Пиленный на коленке мульти-мастер кластер СУБД? А как у него с транзакциями-то? Синхронной-то репликации у вас нет, а асинхронная мастер-мастер - грусть и печаль по части рассинхронизации данных нод. О периодических заданиях - помолчу (на каком из биллингов выполнять их, и как резервировать?).

 

насы на отдельных тазиках ч/з свитч с осфп2 маршрутизацией

NAS - network attached storage имелось ввиду. Да и странный выбор - дешевая сохо железка... Понимаю, какую-то дисковую полку-SAN скзевую по дешевке взять рекомендвали бы, а так...

 

дублировать хранилище - тоже вроде как не вариант

Репликацию СУБД настроить религия не позволяет?

[KJack 35]

насы на отдельных тазиках ч/з свитч с осфп2 маршрутизацией

NAS - network attached storage имелось ввиду. Да и странный выбор - дешевая сохо железка... Понимаю, какую-то дисковую полку-SAN скзевую по дешевке взять рекомендвали бы, а так...

 

дублировать хранилище - тоже вроде как не вариант

Репликацию СУБД настроить религия не позволяет?

 

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

зачем репликация субд? если есть райд, ну и скажем раз в мес беэкап?

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

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

[NiTr0 583]

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

Вот та вот китайская коробочка и есть самый что ни на есть NAS. То вы с SAN попутали.

 

зачем репликация субд? если есть райд, ну и скажем раз в мес беэкап?

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

 

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

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

Угу, а сдохнет хранилище (или вы считаете, что там БП качественнее, чем в сервере?) - ляжет все...

Не занимайтесь техноонанизмом, включите мозг и почитайте о отказоустойчивых кластерах и репликации. У мускула с этим все вообще прекрасно (percona replication manager для heartbeat к примеру годная вещь), у постгри - похуже, но в принципе жить можно.

[KJack 35]

ну, у нас на MySQL крутится...

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

если я в общих чертах всё правильно понял, то на 2-х железках организовывается кластерная система с репликацией, и я сплю и гуляю спокойно?

[ttttt 195]

то на 2-х железках организовывается кластерная система с репликацией, и я сплю и гуляю спокойно?

Нет. Спокойно не получится. У mysql вообще нет синхронной репликации, только асинхронная. Т.е. потеря данных и нарушение консистентности при выпадании главного тазика практически неизбежна. Это первая проблема. Вторая проблема - после замены сервера все равно нужно будет выключать активный.

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

[KJack 35]

печалька

[NiTr0 583]

если я в общих чертах всё правильно понял, то на 2-х железках организовывается кластерная система с репликацией, и я сплю и гуляю спокойно?

В общем - да, но гораздо спокойнее если железки 3. Причем третья - какая угодно, чисто для кворума. 

 

У mysql вообще нет синхронной репликации, только асинхронная. Т.е. потеря данных и нарушение консистентности при выпадании главного тазика практически неизбежна. Это первая проблема.

Вообще-то есть полусинхронная. semi-synchronous. В рамках кластера из 2 мускул нод - разницы по сравнению с синхронной не будет. В рамках кластера из N нод - да, придется по отвалу мастера делать выборы слэйва. Зато быстро, мастер не тупит в сторонке пока самый неторопливый слэйв подтянет транзакцию...

 

Вторая проблема - после замены сервера все равно нужно будет выключать активный.

С какой радости?

Посмотрите перкону, вроде как все автоматически делает. И старый мастер, вернувшийся в строй, синхронизирует со слэйвом, и т.д...

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

 

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

Софтовый рэйд к кластеризации никакого отношения не имеет. Да и бекапы - тоже конечно полезно, но не заменят кластер. Как и кластер не заменит бэкапы.

[ttttt 195]

 

У mysql вообще нет синхронной репликации, только асинхронная. Т.е. потеря данных и нарушение консистентности при выпадании главного тазика практически неизбежна. Это первая проблема.

Вообще-то есть полусинхронная. semi-synchronous. В рамках кластера из 2 мускул нод - разницы по сравнению с синхронной не будет. В рамках кластера из N нод - да, придется по отвалу мастера делать выборы слэйва. Зато быстро, мастер не тупит в сторонке пока самый неторопливый слэйв подтянет транзакцию...

 

Давно уже не слежу, значит гугловский патч таки внедрили.

 

С какой радости?

Тормозить будет, юзеры по таймаутам отваливаться будут. Это только без нагрузки все нормально, а я думаю без нагрузки никто HA не заморачивается. Хотя это на HDD, на SSD наверное не так страшно уже.

 

Софтовый рэйд к кластеризации никакого отношения не имеет.

Кластеризация вообще ни к чему здесь в теме отношения не имеет. А о рейде речь шла в том смысле, чтобы и не усложнять и все еще получать не очень большой простой. Відредаговано 2013-09-13 00:07:37 ttttt