Как лучше организовать отказоустойчивость между дата-центрами?
Добрый день.
Имеется некий проект, для которого самым ценным и наиболее часто меняющимся является БД - mysql.
Код, к примеру, редко меняется, и его легко восстановить.
Задача такова: нужно организовать катастрофоустойчивость таким образом, чтобы при любых обстоятельствах сохранить БД в рабочем состоянии и по транзакциям - по возможности самой последней версии, ну или N-m (где N - основное, достаточно большое количество уже имеющихся записей в БД, и m -потеря нескольких последних транзакций, когда виртуалка с основной системой упала, и несколько последних запросов могли не обработаться)
Есть мысль сделать БД на каком-то очень устойчивом к отказам хостинге вроде Amazon, где mysql будет всегда (ну или почти всегда ) работать. А из виртуалки с кодом, из любых дата-центров, где бы я его не разместил, будет прописан коннект к Амазон-хранилищу.
И быстрыми NS-ами буду переключать точку входа в проект, менять А-запись для домена, в последствии автоматизирую это переключение.
Как мне видится, способ не особо затратный и вполне рабочий.
Но может есть и получше?
В любых ОС реализовано кэширование DNS. Если возможности его отключить нет, то идея с DNS скорее всего провальна. Да и смотря сколько кэш держит.
Здесь упор на пользователей. Если основной сервер упал, надо менять А-запись, иначе проект будет недоступен. Кэшированием пренебрегаем. И оно, насколько мне известно, происходит на промежуток времени, не более , чем TTL у домена. А если TTL достаточно маленький в настройках NS-серверов, переключение будет быстрым. Так ведь работают все сколько-нибудь большие публичные сервисы. Постоянно меняют А-записи.
Хотел бы ещё прояснить, как поведёт себя проект, если А-записей будет несколько? И точек входа, фронт-енд, тоже. Тут действительно , не обойтись без mysql master-master...
>Хотел бы ещё прояснить, как поведёт себя проект, если А-записей будет несколько? И точек входа, фронт-енд, тоже.
Будут выбраны случайные записи, и таким образом нагрузка будет рандомно распределяться. При этом, фронтенды должны быть строго одинаковыми, чтоб не ввергать в шок посетителей.
Однако не стоит терять из виду то, что репликация - процесс быстрый, но не молниеносный, и таким образом желательно, чтобы (в зависимости от характера нагрузки) пользователи подключались к одной базе, пусть даже разными фронтендами.
Андрей: Да, и поэтому, собственно, больше склоняюсь к тому, чтобы держать БД где-то на Амазоне, а фронт-энд где-либо ещё... Так и не могу определиться с выбором архитектуры отказоустойчивости.
Ок, если А-записей 3шт, тогда каждый 3-й запрос идёт на 1 конкретный сервер проекта. И если он уходит в даун, то остальные счастливчики, кто будет направлен по распределению DNS на этот же сервер, будут видеть удручающую картину? Или всё же браузер/ОС попробует выбрать одну из 2х других записей для домена?
pashaxp: Выбирает не браузер, а ОС, и то выбирает случайно.. Системе без разницы, работает IP или нет. В слой приложения приходит как правило 1 адрес (выбранный системой), и приложение с ним уже работает. Если он недоступен, то всё на этом..
Поэтому для отказоустойчивости тогда можно временно удалять нужную А-запись, и оставлять другие.. Но опять же, это будет не прям сильно быстро..
Для распределенной системы только репликация никакой кластер не будет нормально работать в разнесенных дц.
Сделайте мастер слейв реплику и переключайтесь на второй сервер в случае проблем.
pashaxp: При использовании PXC в разных ДЦ, с большим пингом между ними - производительность записи/изменения данных будет очень низкой.
Синхронная репликация неплохо себя чувствует в рамках одного ДЦ.
Между разными ДЦ лучше поднимать обычный асинхронный Master-Slave у MySQL и переключаться на второй сервер - в случае проблем на первом.
И быстрыми NS-ами буду переключать точку входа в проект, менять А-запись для домена, в последствии автоматизирую это переключение.
В любых ОС реализовано кэширование DNS. Если возможности его отключить нет, то идея с DNS скорее всего провальна. Да и смотря сколько кэш держит.
Как мне кажется, можно сделать репликацию master-master между двумя хранилищами, и в коде фронтенда (если же он будет находиться в третьем месте) при сбоях (возможно даже автоматом) переключать БД с одного хранилища на другое. При восстановлении связи отставшая база наверстает упущенное, и можно будет переключать обратно, если она является самой оптимальной по производительности.
По отказоустойчивости точки входа трафика - можно например арендовать на том же Амазоне виртуалку, и на ней поднять nginx с проксирвоанием трафика на ваши виртуалки, за аренду такой тачки будут сущие копейки, а доступность у ней будет в разы больше. Не придётся городить огород с DNS и всегда можно будет поднять заглушку на случай падения обоих бакендов.
Средний
Средний
