Расскажу про систему построения отказоустойчивого сервиса из подручных средств по цене аренды железа

Расскажу про систему построения отказоустойчивого сервиса из подручных средств по цене аренды железа. Я её когда-то придумал, протестировал и использовал некоторое время для одного сайта. Не могу сказать, что мне понравилось, как всё это работало, но там были частности в виде репликации СУБД, у которой может быть разное решение, которое на саму схему не влияет.

Допустим, у вас условно есть 2 виртуалки в разных датацентрах. Это могут быть и полноценные сервера, и группы серверов. В данном случае это не принципиально. И вы хотите разместить на них сайт, чтобы в случае недоступности одной виртуальной машины, все клиенты автоматом обращались ко второй с минимальным простонем и без какого-либо участия человека, то есть полностью автоматически.

Реализовать это можно следующим образом. На каждой виртуалке настраиваем DNS сервер, например, bind (named). Поднимаем там зону своего сайта, указывая в A записи IP адрес своей виртуалки. То есть каждый DNS сервер резолвит имя сайта в свой IP адрес. TTL записи ставим как можно меньше, в зависимости от того, как быстро вы хотите переключить клиентов. Думаю, имеет смысл поставить 1-2 минуты.

У регистратора сайта в качестве NS серверов указываем 2 своих DNS сервера. Когда клиент будет резолвить адрес сайта, регистратор выдаст ему один из NS серверов, который отрезолвит свой IP адрес и клиент попадёт на сайт. Если один из NS серверов станет недоступен, то клиент снова обратится к регистратору и тот автоматически будет отдавать другой NS сервер, который, если доступен, будет резолвить свой IP адрес. В итоге все запросы будут автоматически попадать на активный NS сервер, и, соответственно, на работающий веб сервер.

Если на одной из виртуалок погасить bind, то весь трафик с него в течении нескольких минут уедет на второй сервер. И можно проводить профилактику.

У такой схемы есть масса нюансов. Первое и самое главное. Если используется СУБД, то вам нужна Master-Master репликация, так как в обычном режиме, когда работают оба сервера, запросы на чтение и запись идут на оба параллельно. Я использовал MySQL и там куча нюансов с репликацией, так что нельзя сказать, что всё работало автоматически. С репликацией приходилось разбираться вручную после аварий, так что полной автоматики не получалось.

Но это, как я уже сказал, частности конкретной реализации. Можно использовать прокси для MySQL на обоих машинах и запись вести с обоих серверов в одну СУБД, которая будет синхронизироваться со второй, а в случае аварии эти прокси переключаются на запись в другую живую СУБД.

С файлами всё проще. Их синхронизация - дело техники. Для статики можно использовать внешнее S3 хранилище или синхронизироваться тем же rsync или csync2 (https://t.me/srv_admin/2413). Если хостов больше двух, то вариантов ещё больше. Можно и ceph (https://t.me/srv_admin/2482) развернуть. Отдельный вопрос с сессиями пользователей. Это уже нужно решать на уровне приложения.

Схема со своими DNS серверами простая и вполне рабочая. Каких-то особых подводных камней нет. Есть нюансы с итоговой нагрузкой, так как разные регистраторы по разному отдают NS адреса из списка. Кто-то вразнобой, кто-то по алфавиту, кто-то вообще хз как.

Конечно, всё намного проще, когда есть какой-то внешний арбитр, который управляет трафиком. Это может быть какой-то готовый сервис. Но он и будет основной точкой отказа. Ляжет он, ляжет всё остальное. А тут независимая схема, которая, если всё аккуратно настроить, будет работать сама по себе без внешнего арбитра.

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

Источник: t.me

Комментарии: