Переключение между разными серверами в разных городах

Активист

Активист
Команда форума
Собственно, есть сайт. Разработает прекрасно, сервера в стойках в питере у инфобокса, проблем нет. Но, где питер и где Сибирь ;)

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

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

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

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

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

Нагрузка на сайт небольшая, 1000-2000 хостов, хитов на хост в стреднем 8. Но это пока.

Сейчас, я настроил master-slave репликацию в офис и на ВДС, плюс каждый час снимаю со слейвев бейкап базы. На слейвах стоит копия сайта , но нджинкс отключен.

В случае аварии мне нужно максимально быстро переключать трафик на дополнительный ВДС в случае если падает сервер/канал в основном ЦОДе или на канал в офис (в случае падения канала до МСК/СПБ). В принципе, с репликацией все ясно. Слейвы у меня еще пишут бин-логи и имеют роль мастеров, но с них никто ничего в нормальном режиме не реплицирует, настроить репликацию на основном сервере с временного мастера после поднятия сервера в основном ЦОДе не сложно, а вот как быть с DNS? Можно допустить простой в работе - 5-10 минут у клиентов, но если больше - все - считай кабздец. Даже если я переключаю работу на офисный сервер (а внутри региона трафик не идет через МСК) - канал будет, но на клиентах будет задержка обновления DNS.

Первое что приходит - настроить TTL DNS на 5 минут, но вопрос - будут ли DNS сервера на клиентах это учитывать, и бразуеры? В общем, как настроить DNS что бы тот не кешил данные и быстро начал отдавать новые IP? Есть технологии маршрутизации, но не в моем случае ;)
 
Последнее редактирование:

AnrDaemon

Продвинутый новичок
Я бы решал проблему с другого конца.
Поднял рабочие сайты на ВСЕХ региональных хостах, и гонял между ними только реплики. Так у тебя есть полностью рабочая система на всех точках в каждый момент времени.
 

Активист

Активист
Команда форума
Я бы решал проблему с другого конца.
Поднял рабочие сайты на ВСЕХ региональных хостах, и гонял между ними только реплики. Так у тебя есть полностью рабочая система на всех точках в каждый момент времени.
Обдумываю. Есть возможность нарваться на зедержки в репликах? Или сейчас мускуль норм реплицируется на разных каналах? Еще вопрос - как заставить работать оба сервера одновременно - ясно - две (три) A записи в DNS, но вот как вырубить один сервер или браузеры при наличии двух A записей будут по очереди коннектиться, если к одному не приконектились?
Понятно, что если упал один сервер в одном цоде - просто меняем ему IP, или там один балансер на NGINX - тоже не проблема, балансер сам решает кому коннектиться и не в офлайне ли бекэнды. У меня есть сервера, что работают в одном цоде в кластере, но небыло опыта построения отказаоустойчевой системы с нашим гавенным инетом в регионах.
 

AnrDaemon

Продвинутый новичок
А это уже совсем другой вопрос. И другая организация взаимодействия серверов.
Я бы сделал синхронизацию на уровне собственного API, и поставил сервера в регионах мастерами по региональным перевозкам. Так что при падении линка между серверами, они всё таки могли бы что-то сделать, а при падении собственно сервера, внешние сервера могли как-то поддержать ситуацию, передать бронь в продажу и т.п.
Дополнительная синхронизация на уровне БД полезна для общего консистентного бэкапа. Но не критична.
Но это всё лирика, конечно. Надо исходить из реальных возможностей твоей платформы, которые мне неизвестны.
 

AnrDaemon

Продвинутый новичок
По поводу множества IP для одного сайта, я тут плаваю. :( Предположительно, клиент должен пробовать адреса, пока один не ответит.
 

Активист

Активист
Команда форума
А это уже совсем другой вопрос. И другая организация взаимодействия серверов.
Я бы сделал синхронизацию на уровне собственного API, и поставил сервера в регионах мастерами по региональным перевозкам. Так что при падении линка между серверами, они всё таки могли бы что-то сделать, а при падении собственно сервера, внешние сервера могли как-то поддержать ситуацию, передать бронь в продажу и т.п.
Дополнительная синхронизация на уровне БД полезна для общего консистентного бэкапа. Но не критична.
Но это всё лирика, конечно. Надо исходить из реальных возможностей твоей платформы, которые мне неизвестны.
Да прикол в том, что покупки идут со всей страны. Понятно, что разруливать например ситуацию когда на одном места два пассажира проще, чем когда упадет все. Ладно, если остановиться на том, что у меня есть два мастера в разных цодах нашей страны. Хорошие каналы, репликация мастер-мастер. Падает один сервер, осталось решить, как его быстро выводить из запросов клиентов.
 

MiksIr

miksir@home:~$
На один рейс билеты могут продаваться перед отправлением (не по предпродаже) из разных регионов? Или все же из одной - точки отправления.
 

Активист

Активист
Команда форума
На один рейс билеты могут продаваться перед отправлением (не по предпродаже) из разных регионов? Или все же из одной - точки отправления.
Продажи открыты на все рейсы, включая промежуточные остановки, есть как внутри региональные рейсы, так и меж региональные рейсы. Продажи на рейсы открываются за 14 дней до отправления со станции отправления. Онлайн продажи открыты для всех, хоть откуда хоть куда, по любым направлениям. Но партнер активно вводит продажи через сайт с ведением бух. учета в кассах. Есть автобусные маршруты - пересекают три региона и кассы трех регионов их продают.
 

AnrDaemon

Продвинутый новичок
Так, кое-что нагуглилось.
По поводу один сайт - много IP, общественный мосск говорит, "должно просто работать".

Продажи открыты на все рейсы, включая промежуточные остановки, есть как внутри региональные рейсы, так и меж региональные рейсы. Продажи на рейсы открываются за 14 дней до отправления со станции отправления. Онлайн продажи открыты для всех, хоть откуда хоть куда, по любым направлениям. Но партнер активно вводит продажи через сайт с ведением бух. учета в кассах. Есть автобусные маршруты - пересекают три региона и кассы трех регионов их продают.
Это нормально. :)
Как я бы это сделал (чистая теория!):
Общее имя "билеты.му IN A IP1 IP2 … IPN", там весь фронт. Фронт идентичен на всех серверах и работает так же на всех серверах аналогично.
Персональные имена региональных серверов "регион1.билеты.му IN A IP1" - на этом сайте крутится API backend, проводящий транзакции по отправлениям из его региона.
Все транзакции по возможности синхронизируются со всеми остальными региональными серверами.
Т.е. у тебя лог транзакций региона, и остальные регионы знают, на какой записи они последний раз синхронизировались. В нормальной ситуации синхронизация проходит в момент выписывания билета. Даже несколько синхронизаций. Т.е. человек пытается зарезервировать билет - фронт через API пингует региональный сервер и просит отложить билетик. Если региональный сервер недсотупен, фронт (реально - один из серверов другого региона) обращается к серверам в других регионах (Эй! Вы там с этим пропащим когда последний раз синхронизировались? Что? На 380? Ну, да, блин, у меня та же фигня! Пропал, бедняга!) и принимает решение, либо выписывать билет самому, либо сказать "извините, билеты вот прямо сейчас кончились".
Если же у кого-то есть более новая синхронизация, то возможны варианты. Можно попросить у того сервера попинать пропавший, в надежде что там есть живой линк. Можно просто догнать синхронизацию, и выписать билеты локально.
Короче, задачка интересная. :)
 

MiksIr

miksir@home:~$
Центральный сервер, по паре каналов разных операторов из точек, as, bgp и не морочить голову ;)
 

MiksIr

miksir@home:~$
Центральный сервер уже зарезервировать не проблема - все в одном ЦОД-е. ЦОД-ы падают не часто, особо, опять же, если взять два канала от разных поставщиков.
 

AnrDaemon

Продвинутый новичок
А я предлагаю по-настоящему отказоустойчивую систему. А не "надёжную, если ничего не упадёт".
Как показала практика, и ЦОДы падают, и сервера изымают…
 

MiksIr

miksir@home:~$
Поверь, там проблем будет немало, хотя бы банальный split brain. И выльется в итоге в проблемах типа продано больше, чем мест и т.п.
 

AnrDaemon

Продвинутый новичок
Поверь, там проблем будет немало, хотя бы банальный split brain. И выльется в итоге в проблемах типа продано больше, чем мест и т.п.
Ответ был в условии задачи. Продаются не 100% билетов, сколько-то остаётся на кассу. У тебя всегда есть небольшой люфт. Опять же, никто не заставляет продавать билеты из упавшего региона. И вообще есть больше одного варианта разрулить ситуацию.
split brain - только если ты целенаправленно будешь упираться в работоспособность системы в ущерб консистентности.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
По DNS помню, как на конференции ребята из 2gis, или кто-то другой, рассказывали, что несколько лет мучались с проблемой распределения трафика по стране, в результате сделали влоб: регионам отдается IP их регионального сервера. База сеток по регионам где-нибудь находится, кастомный DNS-сервер - тоже.

В целом задача решается микросервисами. Простой мастер-слейв тут не подходит, latency в репликации - наше все, значение задержки надо проверять на половине запросов.
Обработка денежных транзакций с резервированием товаров при разрыве соединения на уровне базы невозможна.
Я когда-то проработал решение для сети партнерских магазинов на случайных хостингах. API с очередями и офлайновой синхронизацией - нормально, потому что с этой архитектурой поведение при лагах определяется бизнес-логикой, но писать надо много.
 
Последнее редактирование:
Сверху