Отказоустойчивый сервер, как?

Question

[MDXL]

Последнее время Hetzner начинает частенько «шалить». Задумались над резервным сервером в другом дата центре.

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

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

Answer 1

[Влад Животнев]

Если вы держите сервер в hetzner — то можете проходить мимо с такими вопросами. Если у вас есть бюджет порядка 20-30к в месяц на всё это — тогда продолжайте думать.

Answer 2

[shadowalone]

А можно узнать, что значит «шалить»? А то, вот, у меня там 7 серверов, и я, что-то, шалостей не замечаю.

По делу: синхронизация чего именно в реальном времени? файлов? DB? и того и другого? чего-то еще?
как планируете переключаться с одного сервера на другой, какой механизм?
Или Вы сами пока не знаете?

Comments

[MDXL]

Бывают проблемы с доступностью ресурсов. Пару недель назад, вообще 6 часов лежали.
Бэкап желательно всего, чтобы в случае чего не пришлось по частям все перетаскивать. Как переключатся между серверами, пока не знаем. Собственно и написал сюда чтобы помогли с решением.

[shadowalone]

Вообще-то у них, всегда наперед написано, если что-то будет лежать — hetzner-status.de/

Механизмов переключения может быть много. Самый простой, короткий TTL на A-запись в DNS, и переключать на нем.
Вы опять пишите абстрактно… что значит бекап ВСЕГО? всего чего?

[shadowalone]

Если DB, то настроить репликацию, если файло, то rsync.

[Алексей Сундуков]

>Бывают проблемы с доступностью ресурсов. Пару недель назад, вообще 6 часов лежали.
Так может сервер просто не справляется с нагрузкой? Hetzner вам не обязан вести настройку и поддерживать работоспособность серверов, анти DDoS они тоже не предоставляют. Их сфера — железо и инфраструктура ДЦ.

И это не говоря уже о такой возможной проблеме как магистрали в нашей стране. С ситуациями, когда на работающий нормально сервер не могли попасть пользователи лично я сталкивался не раз. Проблемы оказывались либо в маршрутах от пользователя, либо в проблемах провайдера последней мили (к примеру, «залипшие» записи на DNS-ах провайдера).

Answer 3

[DmitryGushin]

Готового решения нет. То, что Вы хотите — достаточно дорого и геморно. Если, конечно, хотите «как только падает сервер, резервный сервер все принимает на себя», а не «падает сервер, теоретически через 20 минут, а по факту через час начинает кое-как работать с резерва».
Что Вам нужно:
1) хороший канал между ДЦ. Иначе не получится в иметь актуальную БД (заблокировали на основном сервере, записали на резервном и получили подтверждение, разблокировали на основном), или будет работать очень медленно.
2) единое адресное пространство (значит, BGP) — без этого не получится поднять 1 IP на разных серверах. С единым адресным пространством уже появляются варианты, как рулить переключением — на роутере (если умеет) или через что-то вроде keepalived (опять требования к каналу между ДЦ, хоть и более мягкие чем в пункте 1).

Все другие варианты (ДНС, например) однозначно подводят Вас к тому или иному времени простоя. Причем у части пользователей это время может быть очень большим и независящим от Ваших усилий(не перевелись еще криворукие настраивальщики локальных ДНСов среди провайдеров).

Comments

[DmitryGushin]

Так что да, или облако (как советовали выше), или строить свою инфраструктуру. Конкретное решение зависит от масштабов Вашего бизнеса и деталей решаемых задач.

[Алексей Сундуков]

В Hetzner получить falover ip вполне возможно, как и API для переключения на резервный сервер (с задержкой порядка 20 сек, полминуты). Но происходит все понятное дело в рамках одного ДЦ.

Answer 4

[bakset]

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

Comments

[MDXL]

Пример не могли бы скинуть ?? Кого именно порекомендуете ??

[egorinsk]

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

[Пума Тайланд]

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

Answer 5

[yakubovsky]

Настраиваем днс. В домене указать два днса. Первый нс на основной сервере, второй на резерве. Самый малый ттл для записей.
На резерве отдаем по днс основную А запись. Стоит мониторинг доступности сервера основного. Раз в минуту пингуем адрес, конектимся к порту 80 или получаем страничку проекта и ищем на ней чекпоинт.
Не сработало что-то из проверок — на резерве скрипт мониторинга заменяет файл зоны с А записью на резерв и релодим днс.
Тут кроется опасность. ТТЛ по хорошему истечет и переспросить должны адрес, но как говорили выше не перевелись криворукие «кешаторы» днс ответов.
Синхронизация файлов по incron через рсинк.
Синхронизация базы? Репликация мастер-мастер или если возможно урезать функционал, то на резерве только на чтении база.

Comments

[AstonMartin]

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

[MDXL]

Интересное замечание. Об этом не подумали.

[yakubovsky]

схемка-то на коленке и подешевле. если есть лишняя копеечка, то платный нормальный dns failover с мониторингом доступности праймари из многих точек.