Есть сервер с 100+ клиентами. Клиенты сидят на общей кодовой базе, при этом у каждого клиента своя база данных (MySQL). Временами случаются форс-мажоры у хостера, DNS-службы и т.д., при этом происходит перебой в предоставлении сервиса, что негативно сказывается на нашей репутации (
Хотелось бы каким-либо образом построить отказоустойчивый сервис с дублированием, чтобы при падении чего-то одного мы могли легко переключаться на продублированные сервисы (в идеале, чтобы это происходило автоматически). Если при этом можно будет сделать балансировку нагрузки, то было бы еще лучше.
Рассматривались варианты с репликацией БД master-master, но наслышаны про то, что и это не
панацея и может быть рассинхронизация и прочие проблемы.
Подскажите, можно ли что-нибудь придумать подобное на облачных сервисах? Например,
Amazon или может быть кто-нибудь еще?
Как там будет происходить дублирование сервисов? Как должна быть выстроена архитектура?
Насколько это надежно, какие существуют подводные камни?
Ну MySQL-то более или менее нормально умеет multi-commit-master (в виде Galera). Только медленнее будет и нужно как минимум 3 ноды в разных местах, иначе оно при split-brain в себя уйдет.
Про остальное zxc80@ прав - комплексно тема сложная, спецы, которые её умеют, получают приличное кол-во денег и давно трудоустроены на 20 лет вперед.
Консультации тоже могу в жаббере-почте дать бесплатно, чтобы у вас была другая точка зрения.
@zxc80 ну там нужно закладываться на кворум. У меня в галерах кворум=2, любая нода из трех в одиночестве перестаёт принимать запросы на запись (можно и на чтение переставать).
Другой вопрос, что если при одной упавшей ноде порвется линк между двумя другими - то вся эта конструкция сама себя тушит и потом приходится восстанавливать руками.
А вообще оно ничо так, работает. Раз в 10-15 медленнее нативного mysql на запись, зато отказоустойчиво )
Так что да, вы правы, в общем-то, после split-brain всё разваливается и нужно чинить руками. И монгу, и гластер, и галеру. Что-то легче, что-то сложнее.
"Другой вопрос, что если при одной упавшей ноде порвется линк между двумя другими - то вся эта конструкция сама себя тушит" вот в этом и беда :-( никто решения не нашел, кроме вмешательства человека, но эту беду не решить ru.wikipedia.org/wiki/%D2%E5%EE%F0%E5%EC%E0_CAP :-( Зато админы не вымрут :-)
@zxc80 ну архитекторы в общем-то фигачат такое, что split-brain не страшен. Другой вопрос, что там решения специфичные и подходят только в одном конкретном случае. И не опенсорс, само собой.
А так да - страдаем, страдаем) Кормим кластера железом и задираем кворумы до nДЦ-2
А кто просит то для одного, просто если между базами нет связи, а вам в принципе все равно есть она или нет, к тому же она в интернете, а там вы вообще не контролируете её, и у вас работает одна копия сайта с одной копией бд, как связь будет все отсинкается на вторую бд. И в это время система будет нормально работать.
ВОобще не понимаю зачем использовать решения со сплитбрейнами на уровне интернета, где вы ну никак не контролируете сеть, я бы сказал эта сеть зависит от сотен и тысяч факторов и эта сеть одна из самых не надежных вещей в мире.
@opium ну failover/failback в данном случае вещь страшная и чинить придется ручками после каждого отключения. split-brain на трех нодах куда менее вероятен. Да и ноды можно посадить рядом.
зачем чинить ручками после каждого отключения?
оно само засинкает изменения , понятно что есть определенные риски десинхронизации и прочего, но мне кажется они в сто раз лучше чем сплит брейн в никем не гарантированной сети
@opium "ВОобще не понимаю зачем использовать решения со сплитбрейнами на уровне интернета, где вы ну никак не контролируете сеть, " Вы их просто не готовили ;-)
@opium окей, давайте перечислять проблемы вашей идеи
1) не факт, что на момент падения мастера (или что там у вас) реплика будет актуальной.
2) не факт, что ваш скрипт переключения отработает корректно. Например, при том же split-brain и публичной доступности мастера.
3) не факт, что за время использования failover-ноды, в базу не запишутся изменения, несовместимые с недоступной базой (посинкать обратно не получится).
4) из-за пункта 3 не факт, что ваша автоматическая синхронизация отработает.
5) если выбрать вариант "убивать базу, заливать заново" - можно потерять данные на момент падения.
И вероятность всего этого сильно выше, чем возможность потери взаимной связанности между тремя нодами в интернете.
1) Не факт, но данные дольются потом, когда все восстановится.
2)Он не может отработать не корректно, просто потому что он затестен годами, там простейшие тупые команды.
3)Какие именно могут данные записаться не совместимые, в целом с такой ситуацией не встречался чисто из за сетевых проблем, основная проблема мастер мастера все таки крах файлухи или окончание места на диске.
4)Отработает если конечно не случились проблемы описаные мной выше.
5)Не понятно зачем убивать и заливать заново.
Вероятности точно такие же как если выбрать ваше решение, только у вас ещё сплит брейн из за отсутствия коннекта в большой сети интернет в которой по пути между вашими серверами сотни коммутаторов прочей гадости.
никак не поведет, но я указал что сплитбрейн будет не из за проблем сети которую вы не контролируете, а из за краха файловой системы или переполнения диска, при настроенном мониторинге данные проблемы можно свести к минимуму, проблемы с интернетом вы к минимуму не можете свести.
кластер на мускуле хорошее решение если он в одной стойке стоит, при работе даже в разных дц уже сложнее с ним все, если конечно это не ваши дц и вы в них контролите все.
тот же амазон это просто впски, а вот там реплики и прочее вы делаете сами ручками, он ничего вам не дублирует и не масштабирует тем более сам.
есть конечно там кое какие плюшки для упрощения, но решает хороший администратор .
Подскажите, я правильно понимаю, что мы на амазоне берем просто vps? Я предполагал, что амазон дает инфраструктуру и сам заботится о доступности vps в случае падения сервера на котором расположен vps.
Мне кажется все кто продает впс заботятся об этом, развернуть файловер дело не сложное и он есть у всех, иначе просто заколебешься чинить все в экстренном режиме.
Сейчас подавляющее большинство провайдеров это кластеры с файловером. Суть то облака не в том чтобы файловер был, а в том чтобы ресурсы были по запросу и сколько хочешь.
Ну и есть вероятность скажем умирания данных в амазоне, у них там прописано много девяток, но клиенты иногда получают письма счастья, что данные на ваших дисках потеряны.
В общем то даже я продавая качественный приватный хостинг интернет магазинам имею файловер, что уж говорить про любого крупного продавца впс.
Тогда два вопроса - был ли у вас опыт построения отказоустойчивых систем на амазоне и таких же решений, но с использованием своих серверов? Какие плюсы и минусы вариантов?
Сколько будут стоить подобные услуги?
Да много разного опыта было,
Можно почитать немного моих статей на хабре habrahabr.ru/users/opium/topics
У амазона все по запросу , то есть надо тебе 1000 серверов получай. у амазона есть достаточно много плюшек, как к примеру автоскалинг(сразу скажу тут надо приложение менять чтобы оно могло масштабироваться), лоадбалансер(по сути обычный nginx, но оно там довольно хитро умеет не умирать при проблемах в части датацентра, если весь дц упал то тоже упадет ), есть route 53 это такой отличный днс сервер, который умеет к примеру следить живой ли ваш сервер и если не живой то не направлять на него юзеров, ну и умеет геолокацию, направляет юзеров на ближайший к ним сервер.
Обычно работаю через одеск , цена часа от $30 до $60
О кстати вхожу в 5% лучших фрилансеров на одеске. pumainthailand.com/congrats-roman-you-are-in-our-top-5
Используйте обычную репликацию Master-Slave для резервирования БД (работать с приложениями будет только Мастер). В случае выхода из строя слейва - он пересобирается на фоне. В случае выхода Мастера, Вы переключаетесь на Слейв. Лучше использовать 1 Мастер + 2 Слейва.
Сложный
