Резервный сервер для интернет-магазина: переключение за минуту и почему мы отказались от балансировщика

21 октября утром сервер интернет-магазина, который мы ведём, перестал отвечать целиком: не открывались ни сайт, ни SSH. Это не тот случай, когда упал nginx или кончился диск и можно зайти и разобраться. Машины просто не было в сети, и когда она вернётся, никто сказать не мог.

Мы подняли копию магазина на другом своём сервере. Около 11:20 по Москве сайт работал там. Около 11:45 основной сервер ожил, и мы вернули домен на него. Новых заказов за это время на копии не появилось, сводить ничего не пришлось. Но восстановление показало, где у нас тонко, и после него мы сделали магазину резервный сервер. Ниже о том, как он устроен, где мы ошиблись и что из этого стоит проверить у себя.

Что мешало восстановиться быстрее

В бэкапе не было файла с настройками. Сайт выкладывается релизами: каждая версия кода лежит в своей папке, а общий .env с паролями и ключами подключается в неё символической ссылкой. Бэкап сохранял ссылку, а не сам файл. Код, база и картинки восстановились, а .env пришлось собирать заново, и на копии почта, капча и ключи внешних сервисов остались без своих секретов. Бэкапы делает наш собственный плагин, так что ошибка наша; на следующий день мы её исправили.

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

Восстановление упиралось в объём. Снимок весил около 38 ГБ, больше половины из них занимали нарезанные картинки. Причём список файлов снимка скачивался медленнее, чем сами данные. Код и дамп базы стоит восстанавливать отдельно и первыми: с ними магазин уже открывается, а картинки можно догружать потом.

У записи домена был TTL 3600. TTL показывает, сколько секунд DNS-серверы провайдеров держат ответ у себя. При часовом TTL новый адрес домена доходит до части посетителей только через час, даже если копия сайта готова за десять минут. Про то, что TTL снижают заранее, мы писали в чек-листе переезда. В аварии вспоминать об этом уже поздно.

Сколько простоя допустимо

С этого вопроса начинается любой резерв, и отвечает на него заказчик, а не админ. Нулевой простой стоит дорого: несколько серверов, балансировка, база, которая принимает запись в двух местах. Для этого магазина договорились, что допустимы 5-10 минут в любое время суток.

Из этой цифры выросло всё остальное. За 5-10 минут ночью человек не успеет проснуться, понять, что случилось, и переключить сайт. Значит, переключение должно уметь происходить само. А раз само, ему нужна защита от ложных тревог, иначе резерв начнёт отбирать сайт у живого сервера.

Как устроен резерв

Резервный сервер стоит в другом дата-центре: основной в Москве, резервный в Петербурге. Авария одной площадки не должна задевать обе.

База на резервном сервере работает как реплика: каждое изменение на основном через закрытый туннель между серверами повторяется на резервном. Отставание измеряется секундами. Резервная база открыта только на чтение, писать в неё может лишь основной сервер.

Картинки и файлы магазина, около 39 ГБ, раз в минуту уходят в облачное хранилище, и резервный сервер отдаёт их оттуда. Копировать все гигабайты на второй диск не пришлось.

Код выкладывается на оба сервера одной командой. Фоновые задачи (очереди, рассылки, выгрузки) работают только на основном: если запустить их на обоих, покупатель получит два одинаковых письма. Сертификат тоже продлевает только основной сервер и кладёт его в хранилище, а резервный забирает оттуда.

Переключение делается одной командой на резервном сервере. Он перестаёт быть репликой, база становится доступной для записи, запускаются фоновые задачи, и сам же сервер меняет адрес домена в DNS. TTL теперь 60 секунд, поэтому большинство посетителей окажутся на резервном сервере через минуту-две. Часть DNS-серверов держит ответы дольше, чем просит TTL, так что минута получится для большинства, но не для всех.

Ошибка с балансировщиком

Сначала мы сделали по-другому. 22 октября вечером перевели домен на балансировщик облачного провайдера: посетители идут на его адрес, а он сам решает, какому серверу отдать запрос. Переключение получалось почти мгновенным: на учениях сайт был недоступен 13 секунд при переезде на резерв и 9 секунд при возврате. Мы проверили балансировщик с нескольких своих серверов и из дома, всё отвечало.

Утром 23 октября у заказчика сайт не открылся: браузер показывал ошибку сброса соединения. Мы проверили доступность через ping-admin.com из разных городов. До балансировщика не достучались Москва, Томск, Рига, Копенгаген и Нидерланды, ответили Уфа, Хабаровск, Нюрнберг и Гонконг. Со всех наших точек он по-прежнему работал. Около 10:50 мы вернули домен прямо на основной сервер и в тот же день переделали переключение на DNS, как описано выше.

Это был уже второй экземпляр балансировщика: первый терял 10-20 % соединений, и его пересоздали. Поддержка провайдера за четыре дня причину не нашла, и 27 октября мы от услуги отказались.

Проверять доступность нужно из чужих сетей, а не со своих серверов. Наши серверы стоят в дата-центрах с хорошей связностью, и то, что они видят сайт, ничего не говорит о покупателе с домашним интернетом в Москве. Перед переводом домена на новый адрес проверяйте его через ping-admin.com или check-host.net из десятка городов.

И одна деталь при удалении. Балансировщик передавал серверу настоящий адрес посетителя, и nginx был настроен доверять этим сведениям, если они пришли с адреса балансировщика. После отказа от услуги адрес возвращается провайдеру и может достаться кому угодно. Если доверие не убрать, новый владелец адреса сможет подставлять серверу любой «адрес посетителя»: обходить ограничения по IP и путать логи. Мы убрали эти настройки на обоих серверах в тот же день.

Почему автомат пока только наблюдает

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

Поэтому решение принимает не один сервер. Арбитр на каждом узле раз в 15 секунд проверяет соседа и спрашивает двух свидетелей в других дата-центрах, видят ли они сайт. Резерв становится основным, только если основной сервер не видит никто, а основной сервер, который потерял связь со всеми, сам перестаёт принимать запись.

С 22 октября арбитр работает в теневом режиме: записывает, что переключил бы, но ничего не делает. За первые четыре дня он ни разу не ошибся. Зато подготовка нашла случай, который в бою дал бы ложное переключение: во время выкладки сайт примерно на 25 секунд уходит в режим обслуживания и отвечает 503, а арбитр принял бы это за падение. Пока это не исправлено, переключение делает человек одной командой. Так и задумано: автомат включают после того, как он отработал вхолостую и разобраны все его сомнения.

Что проверить у себя

Если у вас магазин или другой сайт, простой которого стоит денег:

• договоритесь, сколько минут простоя допустимо: от этого зависит, нужен ли резерв и каким ему быть;
• откройте последний бэкап и убедитесь, что в нём есть .env или другой файл с настройками, а не ссылка на него;
• снизьте TTL записей домена до 300 или меньше заранее, а не в день аварии;
• новый адрес сайта проверяйте из многих сетей, а не только со своих серверов;
• убирая прокси или балансировщик, убирайте и доверие к его адресу в настройках веб-сервера.

Что делать в первые минуты, если сервер всё-таки упал, разобрано в статье «Сервер упал в три ночи».