Если интернет-магазин крутится на одном VPS, любой сбой у провайдера — и покупатели видят ошибку вместо каталога. DNS-фейловер решает эту проблему: один сервер берёт на себя нагрузку, когда другой недоступен, и сайт продолжает работать. Разберём, как собрать такую связку из двух VPS в Беларуси, какие DNS-записи менять, за какое время реально переключиться и где чаще всего спотыкаются на практике.
Из чего вообще состоит фейловер и зачем он магазину
В основе схемы — два независимых VPS у разных провайдеров или в разных дата-центрах, чтобы авария на одной площадке не задевала вторую. На каждом сервере поднимают свой экземпляр сайта и базы данных, а DNS-записи направляют трафик на активный узел. Когда основной сервер перестаёт отвечать, роль активного берёт второй. Технически фейловер отличается от обычного резервного копирования: бэкап — это страховка данных, а фейловер — это страховка доступности.
Для белорусского интернет-магазина критичны именно секунды простоя. Покупатель не станет ждать, пока у сервера восстановится диск, и уйдёт к конкуренту. Задержка переключения зависит от того, как настроен мониторинг и какой TTL стоит на DNS-записях: при коротком TTL браузер и resolver быстро заберут новый IP, при длинном — посетители ещё минуту-две будут стучаться на умерший адрес.
Что подготовить на двух VPS, прежде чем трогать DNS
Сначала — две одинаковые площадки. Один VPS станет master, второй — replica или standby. На обоих должна быть одна и та же операционная система, одинаковый стек (например, Nginx + PHP-FPM + MySQL), идентичные SSL-сертификаты и одинаковая структура каталогов. Иначе при переключении вы получите не зеркало, а второй сайт, который выглядит иначе.
Дальше синхронизируйте данные. Файлы проще всего раздавать через rsync по SSH или rsnapshot, базу — через репликацию MySQL или периодический дамп с восстановлением на втором сервере. Важно, чтобы время между снимками базы было меньше того интервала, который вы готовы потерять при аварии: если магазин делает 50 заказов в час, дамп каждые 15 минут означает, что в худшем случае пропадут 12–13 заказов.
Какие сервисы поставить на standby
На резервном VPS должен работать тот же набор, что и на основном: веб-сервер, обработчик PHP, база данных и кэш. Иначе при переключении вы увидите 502 Bad Gateway. Есть два подхода:
- Standby-сервер постоянно работает и принимает реплику базы — переключение почти мгновенное, но платить приходится за два полноценных сервера.
- Standby-сервер «просыпается» только при сбое через snapshot или скрипт — дешевле, но запуск занимает минуты, а не секунды.
Для магазина с потоком от 100 уникальных посетителей в сутки первый вариант оправдан, потому что оживление холодного сервера занимает слишком много времени и покупатели успеют закрыть вкладку.
Как настроить DNS так, чтобы переключение прошло автоматически
Управлять записями удобнее через внешний DNS-сервис с API — например, через регистратора домена или отдельный сервис вроде Cloudflare. Это позволяет менять A-записи скриптом, не заходя в панель руками. На домене создают две A-записи с одинаковым именем: одна указывает на IP мастера, вторая — на IP резервного. У обеих ставят низкий TTL, обычно 60–300 секунд. Длинный TTL в сутки при фейловере не работает: запись обновится только через 24 часа, и клиенты всё это время будут попадать на мёртвый сервер.
Автоматику делает health-check. На отдельном узле (или на резервном VPS) запускают скрипт, который каждые 30–60 секунд проверяет мастер: шлёт HTTP-запрос на заранее заданный URL, например /health, и смотрит код ответа. Если 200 не пришёл два-три раза подряд, скрипт идёт в API DNS-провайдера и меняет запись так, чтобы трафик пошёл на резервный. Сам мониторинг размещают вне мастера — иначе при его падении мониторить будет некому.
Какие параметры выставить в DNS и мониторинге
| Параметр | Рекомендуемое значение | Зачем |
|---|---|---|
| TTL A-записи | 60–300 секунд | Чем короче, тем быстрее посетители получат новый IP |
| Интервал проверки | 30–60 секунд | Баланс между скоростью реакции и нагрузкой на монитор |
| Число неудачных попыток до переключения | 2–3 | Защита от ложных срабатываний на коротких сбоях |
| Время восстановления | 5–10 минут | Возврат на мастер только после того, как он стабильно отвечает |
Почему белорусским магазинам важно выбирать разные дата-центры
Два VPS у одного провайдера в одной стойке — это не фейловер, а видимость. У провайдера бывают аварии на уровне маршрутизатора, питания или канала, и тогда ложатся оба сервера одновременно. Беларусь — небольшой рынок, и многие провайдеры делят инфраструктуру между собой, поэтому проверяйте физическое размещение, а не только юридическое название компании. Белорусские и соседние площадки в Латвии или Калининграде дают дополнительную географическую развязку, потому что аварии в магистральных каналах редко задевают оба региона сразу.
При выборе VPS под реплику обращайте внимание на три вещи: поддержку частных сетей между дата-центрами (чтобы репликация базы не шла через публичный интернет), возможность заказать snapshot всего сервера (для быстрого развёртывания standby) и наличие IPv6 — Яндекс и Google всё чаще обращаются к сайтам по этому протоколу. Подбор сервера под конкретные требования CMS хорошо описан в материале про выбор VPS для интернет-магазина на 1С-Битрикс.
Сколько времени реально занимает переключение
На практике сценарий выглядит так: мастер упал, через 60 секунд мониторинг заметил, через 90 — отправил запрос в DNS, через 120–180 секунд запись разошлась по resolver-ам провайдеров, через 240–300 секунд основная масса посетителей уже на резервном. Итого 4–5 минут — это нормальный ориентир. Полностью избавиться от этого окна нельзя, потому что DNS — это распределённая система с кэшированием, и какой-то процент пользователей всегда будет получать старую запись из кэша своего провайдера.
Если магазин работает через CDN или «припаркован» на сервисе, который сам управляет DNS, окно можно ужать до 1–2 минут, потому что CDN-узлы обновляются быстрее. Но это уже отдельная история и отдельная статья расходов.
Типичные ошибки при настройке фейловера
- Слишком длинный TTL на A-записи — при суточном TTL посетители часами попадают на мёртвый сервер после сбоя.
- Мониторинг и DNS-управление живут на том же VPS, который мониторят — при падении мастера скрипту переключения тоже негде работать.
- Реплика базы настроена, но файлы (загруженные картинки, документы) забыли — после переключения часть контента пропадает или становится битой.
- SSL-сертификаты выпущены только на основной домен и не обновляются на резервном — браузер покажет предупреждение о небезопасном соединении.
- Не проверили возврат: после восстановления мастера никто не возвращает трафик обратно, и standby продолжает работать в одиночку, пока не упрётся в мощности.
Как это вписывается в работу обычного магазина
Сам фейловер — это полдела. Дальше его нужно обслуживать: раз в квартал тестировать переключение руками, раз в месяц проверять, что реплика базы не отстаёт, и держать под рукой актуальные SSL. Без этого через полгода при реальной аварии выяснится, что standby отстаёт от мастера на сутки, а сертификат истёк. Имеет смысл заранее закрыть и другие слабые места — например, защиту от DDoS, потому что фейловер сам по себе не отбивает атаку, а только переключает её на резервный узел. Подробнее про это — в материале о защите VPS от DDoS без лишних затрат.
Фейловер не заменяет бэкапы и не защищает от ошибок в коде: если администратор случайно удалил таблицу с заказами, реплика её тоже «удалит». Поэтому связку DNS-фейловер + регулярные снимки базы + план восстановления из бэкапа раз в неделю проверяют как единое целое. Только тогда интернет-магазин перестаёт зависеть от одного дата-центра и одного инженера, который в отпуске.
3 шага, которые можно сделать на этой неделе:
- Выписать текущий TTL для A-записи домена и при необходимости снизить до 300 секунд.
- Поднять второй VPS у другого провайдера, настроить rsync файлов и репликацию MySQL.
- Запустить внешний health-check с интервалом 60 секунд и один раз руками сымитировать падение мастера, чтобы замерить реальное время переключения.
