DR-сайт в арендованной стойке: rsync, log shipping и четыре часа RTO вместо «неизвестно»

Разговор про DR у большинства клиентов начинается и заканчивается примерно одинаково. «У нас есть резервное копирование» - и дальше либо тема закрывается, либо кто-то осторожно спрашивает: «А если сгорит серверная?» После секундной паузы обычно следует ответ в духе «ну, будем восстанавливаться». Сколько времени займёт это «восстанавливаться» - никто не считал.

Один из клиентов этой осенью дозрел до честного разговора. Торгово-производственная компания, несколько десятков пользователей, критичная зависимость от ERP на SQL Server и набор файловых шар с рабочими документами. Бэкапы на ленту есть, регулярные - тоже есть. Но лента хранится в той же серверной. Сценарий «затопило», «сгорело», «вынесли сервера» - это полная потеря всего, включая бэкапы.

Мы предложили сделать нормально.

Что решили строить

Никаких дата-центров уровня Tier III - задача не та и бюджет не тот. Взяли в аренду одну стойку у небольшого хостинга с нормальным питанием и интернетом. Туда поставили один бюджетный сервер с RAID-массивом и достаточным объёмом дисков. Это и есть DR-сайт. Не красиво, но честно.

Задача была не обеспечить мгновенное переключение, а ответить на вопрос: если основная площадка недоступна, за какое время мы можем поднять работу на резервной? До проекта ответ был «неизвестно». После - конкретное число.

Три компонента схемы

Файлы - rsync по VPN. Между основной площадкой и арендованной стойкой подняли IPSec-туннель через два интернет-канала - по одному с каждой стороны. На файловые шары - rsync по расписанию ночью, когда нагрузка минимальна и можно не жалеть пропускную способность. Скрипт на bash, лог в файл, алерт на почту если что-то пошло не так. Ничего умного, зато надёжно и прозрачно. Дельта за сутки у клиента умещалась в разумный объём - первая полная синхронизация заняла несколько ночей, инкрементальные - час-полтора.

Базы данных - SQL Server log shipping. Log shipping - это не новинка и не экзотика, он в SQL Server с давних пор. Транзакционные логи с основного сервера пакуются и по расписанию доставляются на резервный, там разворачиваются. Резервная база постоянно находится в режиме restoring - к ней нельзя подключиться в штатном режиме, но при failover она переводится в рабочее состояние за несколько минут.

Интервал доставки логов поставили 30 минут - баланс между свежестью данных и нагрузкой на канал. Потенциальные потери при аварии - максимум полчаса транзакций. Для этого клиента приемлемо.

VPN-туннель как основа всего. Без туннеля ни rsync, ни log shipping не имеют смысла - данные шли бы по открытому интернету. OpenVPN в режиме site-to-site, сертификаты, журналирование соединений. Туннель мониторится через Zabbix: если упал - алерт. Площадки небольшие, трафика немного, туннель держится стабильно.

Тестовый failover

Это важная часть, про которую часто забывают: написать план переключения - одно, а реально проверить его - другое. Мы договорились с клиентом на тестовый failover в выходной день, чтобы понять реальное время восстановления.

Сценарий: считаем, что основная площадка недоступна полностью. Что нужно сделать на резервной:

• Перевести SQL Server из log shipping в рабочий режим (RESTORE DATABASE WITH RECOVERY) - это несколько минут.
• Обновить DNS-записи, чтобы клиенты ходили на резервный адрес - ещё несколько минут, но TTL у нас был выставлен на час, так что часть времени просто ждали.
• Проверить, что приложение поднимается и подключается к базе на резервном сервере - конфиги приложения ссылались на имя сервера, а не IP, поэтому после обновления DNS всё заработало.
• Убедиться, что пользователи видят актуальные файлы.

Итого от начала до момента «пользователи работают»: четыре часа. Большую часть времени съел TTL DNS и несколько неожиданных мелочей - одно приложение хранило строку подключения к БД в реестре, а не в конфиге, нашли и поправили по ходу.

Четыре часа RTO - это не мало. Но это конкретная цифра вместо «неизвестно», и клиент может принимать осознанное решение: устраивает это или нужно вкладываться в более быстрое переключение.

Что стоит иметь в виду

Log shipping хранит данные с задержкой в интервал доставки логов. Если авария происходит прямо перед очередной доставкой - потеряются данные за последние 30 минут. Это не баг схемы, это её характеристика, о которой нужно честно говорить.

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

VPN-туннель - единственная точка связи между площадками. Если оба интернет-канала одновременно упадут, репликация остановится. Мониторинг туннеля обязателен.

Где это место в общей картине

VMware HA, которую мы ставили на кластере из двух хостов раньше этой осенью, решает задачу отказа физического сервера - VM перезапускается за полторы минуты. DR-сайт решает другую задачу: что делать, если вся площадка недоступна. Это разные уровни защиты, и одно не заменяет другое.

Клиент теперь ведётся в рамках сопровождения инфраструктуры, в котором мониторинг репликации и ежеквартальный тестовый failover - обязательные пункты. Потому что DR-сайт, который не проверялся полгода, - это DR-сайт с неизвестными характеристиками. А «неизвестно» - это то, с чего мы начали.