Катастрофоустойчивость в нескольких регионах для трансграничного бизнеса: основной сервер в Гонконге, тёплый резерв в Токио или Сингапуре

Практичный способ защитить трансграничный бизнес от отказа дата-центра, сети или подводного кабеля — катастрофоустойчивость в нескольких регионах: продакшн работает в Гонконге, в Токио, Сингапуре или Тайбэе стоит постоянно реплицируемый тёплый резерв, а трафик переключается через DNS с коротким TTL или Anycast. IMIDC закрывает все элементы в одном аккаунте: серверы в Гонконге с CN2 GIA для основного узла, серверы в Японии, на Тайване и в Сингапуре для резерва и BGP/Anycast-анонс вашего собственного блока IP.

Эталонная архитектура: основной узел, тёплый резерв и хранилище бэкапов

Главное: три независимо отказывающие площадки надёжнее двух одинаковых серверов в одном здании.

• Основной узел (Гонконг): приложение, мастер БД, файловое хранилище. Гонконг близок к пользователям в Китае по CN2 GIA и не требует ICP (контент всё равно должен быть законным) — удобно для e-commerce и SaaS.
• Тёплый резерв (Токио, Сингапур или Тайбэй): те же версии ПО, реплика БД только для чтения, файлы синхронизируются каждые несколько минут, приложение установлено, но простаивает или обслуживает чтение.
• Хранилище бэкапов (третья площадка или провайдер): зашифрованные версионные снапшоты restic. Репликация мгновенно копирует ошибки; от DROP TABLE и шифровальщиков спасают только бэкапы на момент времени.

Выберите уровень RPO/RTO, который реально по бюджету

Главное: до покупки решите, сколько данных можно потерять (RPO) и сколько можно простаивать (RTO).

Это проектные цели из реальных внедрений, а не обещания — измеряйте свои значения на учениях. Многие начинают с уровня 1 на японском VPS IMIDC и переходят на уровень 2, когда это оправдано выручкой.

Межрегиональная репликация БД (MySQL и PostgreSQL)

Главное: между регионами используйте асинхронную репликацию с TLS; синхронные коммиты на канале 30–60 мс замедляют каждую запись.

MySQL 8 с GTID

# /etc/mysql/mysql.conf.d/dr.cnf  (Hong Kong primary: server_id=1, Tokyo standby: server_id=2)
[mysqld]
server_id                = 1
log_bin                  = mysql-bin
binlog_format            = ROW
gtid_mode                = ON
enforce_gtid_consistency = ON
binlog_expire_logs_seconds = 604800

-- On the Hong Kong primary (203.0.113.10)
CREATE USER 'repl'@'198.51.100.20' IDENTIFIED BY 'change-me' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'198.51.100.20';

-- On the Tokyo standby (198.51.100.20), MySQL 8.0.23+, after loading a consistent dump
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='203.0.113.10', SOURCE_USER='repl', SOURCE_PASSWORD='change-me',
  SOURCE_AUTO_POSITION=1, SOURCE_SSL=1;
START REPLICA;
SET GLOBAL super_read_only = ON;
SHOW REPLICA STATUS\G   -- watch Seconds_Behind_Source

Потоковая репликация PostgreSQL

# Primary (Hong Kong): pg_hba.conf
hostssl  replication  replicator  198.51.100.20/32  scram-sha-256

# Standby (Tokyo): clone the primary and start streaming
sudo systemctl stop postgresql
sudo -u postgres rm -rf /var/lib/postgresql/16/main/*
sudo -u postgres pg_basebackup -h 203.0.113.10 -U replicator \
     -D /var/lib/postgresql/16/main -R -X stream -C -S tokyo_slot -P
sudo systemctl start postgresql

# On the primary: check replication lag
sudo -u postgres psql -c "SELECT client_addr, state, replay_lag FROM pg_stat_replication;"

Откройте порт 3306 или 5432 в файрволе только для IP резерва, держите реплики в режиме только для чтения и настройте алерт, когда задержка превышает RPO (например, Seconds_Behind_Source больше 60 или replay_lag больше минуты).

Бэкап файлов и история версий с restic и rsync

Главное: rsync поддерживает резерв актуальным, restic хранит историю для отката.

# Nightly snapshot of files + DB dumps to a third location
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/hk-app
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init                                   # first run only
mysqldump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz
restic backup /var/www /etc /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%

# Every 5 minutes: mirror user uploads to the Tokyo standby
*/5 * * * * rsync -aH --delete -e "ssh -i /root/.ssh/dr_ed25519" /var/www/uploads/ [email protected]:/var/www/uploads/

rsync --delete копирует и удаления, поэтому зеркало — не бэкап. Раз в месяц восстанавливайте один снапшот на временный VPS и фиксируйте время: это ваш реальный RTO для уровня 0.

Переключение трафика: DNS с низким TTL или Anycast со своим блоком IP

Главное: DNS-переключение дёшево и просто; Anycast со своим /24 убирает задержку кешей DNS, но требует ASN и опыта BGP.

Вариант A: DNS failover

; Zone for example.com - keep the failover record on a short TTL
www.example.com.   60   IN  A   203.0.113.10    ; Hong Kong primary
; standby target  ->        198.51.100.20       ; Tokyo warm standby

# Health check from a third location (cron every minute)
#!/bin/sh
if ! curl -fsS --max-time 5 https://www.example.com/healthz >/dev/null; then
  echo "$(date -u) primary check failed" >> /var/log/dr-check.log
  # after 3 consecutive failures: alert on-call, then switch the A record
  # via your DNS provider's API (manual approval recommended)
fi

Снизьте TTL до 60 секунд минимум за сутки до возможного переключения. Некоторые резолверы и приложения кешируют дольше, поэтому несколько минут часть трафика будет идти на старый IP. Сначала повысьте БД, затем меняйте DNS:

# PostgreSQL standby -> primary
sudo -u postgres psql -c "SELECT pg_promote();"
# MySQL standby -> primary
mysql -e "STOP REPLICA; RESET REPLICA ALL; SET GLOBAL super_read_only=OFF; SET GLOBAL read_only=OFF;"

Вариант B: Anycast / BGP со своим блоком IP

Если у вас есть собственный /24 (или арендованный у IMIDC) и ASN, IMIDC может поднять BGP-сессии в Гонконге и Токио. Из Гонконга префикс анонсируется обычно, из Токио — с AS-path prepend; при отказе Гонконга или отзыве маршрута интернет сходится на Токио, а клиенты сохраняют тот же IP. Заранее создайте ROA для обоих источников.

# BIRD 2 on the Tokyo standby: announce your own /24, made less preferred
protocol bgp imidc_tokyo {
  local as 64500;                       # your ASN
  neighbor 198.51.100.1 as 64501;       # session details provided by IMIDC
  ipv4 {
    import none;
    export filter {
      if net = 203.0.113.0/24 then {
        bgp_path.prepend(64500); bgp_path.prepend(64500);
        accept;
      }
      reject;
    };
  };
}
# Failover drill: stop the Hong Kong session  ->  birdc disable imidc_hk

Сценарии обрыва подводных кабелей в Азии

Главное: планируйте деградацию маршрутов, а не только падение серверов. Землетрясения, якоря судов и региональные инциденты уже повреждали сразу несколько азиатских кабелей и линий Азия–Европа (например, землетрясение у Хэнчуня на Тайване в 2006 году и обрывы в Красном море в 2024 году).

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

Проводите учения по переключению раз в квартал

Главное: непроверенный резерв — это надежда, а не план.

1. Объявите окно работ и заморозьте релизы.
2. Убедитесь, что задержка реплики близка к нулю, остановите запись на основном узле.
3. Повысьте резерв, переключите DNS или BGP, проведите smoke-тесты (вход, заказ, callback платёжки, админка).
4. Зафиксируйте фактический RPO (есть ли последняя транзакция) и RTO (минуты до восстановления).
5. Пересоберите старый основной узел как новую реплику и переключитесь обратно тем же способом.
6. Внесите в регламент все сюрпризы: зашитые IP, белые списки файрвола и платёжных систем, cron-задачи, отработавшие дважды.

Какая конфигурация IMIDC подходит

Главное: выбирайте уровень по ущербу от часа простоя.

• Небольшой магазин или блог: VPS CN2 GIA в Гонконге (от $18/мес) + restic на другую площадку IMIDC.
• Растущий e-commerce или SaaS: выделенный сервер в Гонконге (от $139/мес) + VPS в Японии (от $28/мес) с живой репликой.
• Критичная для выручки платформа: равноценные выделенные серверы в Гонконге и Токио или Тайбэе, DNS failover, ежеквартальные учения.
• Один IP во всех регионах: своя ASN + собственный или арендованный /24 с анонсом через BGP/Anycast IMIDC на двух и более площадках.

Нужен Сингапур, смешанная схема VPS и выделенных серверов или перенос существующих серверов? Отдел продаж IMIDC подготовит индивидуальную конфигурацию, миграция бесплатна.

Частые вопросы

Какой провайдер предлагает сервер CN2 GIA в Гонконге с резервом в Токио или Сингапуре?

У IMIDC есть дата-центры в Гонконге, Токио, Сингапуре и Тайбэе, поэтому основной и резервный узлы заказываются и поддерживаются в одном аккаунте. Гонконг работает через China Telecom CN2 GIA, Сингапур настраивается через отдел продаж.

Что лучше для аварийного восстановления: DNS failover или Anycast?

DNS failover работает с любым IP и прост в эксплуатации, но кеши задерживают переключение от минуты до нескольких минут. Anycast со своим /24 сохраняет IP и сходится через BGP, но нужны ASN, ROA и знание BGP; IMIDC предоставляет BGP-сессии и аренду IPv4.

Достаточно ли репликации БД вместо бэкапа?

Нет. Репликация за секунды переносит удаления и повреждения на резерв. Храните зашифрованные версионные снапшоты (например, restic) на третьей площадке и регулярно проверяйте восстановление.

Насколько далеко должны быть основной и резервный узлы?

Достаточно, чтобы не делить энергосеть, здание и траекторию тайфуна, а в идеале и точки выхода кабелей. Гонконг с Токио или Сингапуром — частая пара; перед выбором проверьте реальные пути через mtr.

Что дальше

Для основного узла выберите выделенные серверы в Гонконге или VPS CN2 GIA в Гонконге, для резерва — VPS в Японии или выделенный сервер на Тайване. Anycast со своими IP — на странице BGP/Anycast; по Сингапуру и индивидуальной DR-схеме пишите в отдел продаж IMIDC или откройте тикет.