Налаштування резервного дата-центру для 1С-Бітрікс

Налаштування резервного дата-центру для 1С-Бітрікс

Якщо основний сервер недоступний — резервний ДЦ повинен прийняти трафік без ручного втручання і без втрати даних. На практиці більшість «резервних ДЦ» — це сервер із застарілим бекапом, на який перемикаються вручну через годину після аварії. Нормально працюючий резервний ДЦ для Бітрікс — це реплікована БД, дзеркало файлів і автоматичне перемикання DNS.

Компоненти резервного ДЦ

1. Реплікація бази даних

Репліка MySQL/MariaDB у резервному ДЦ — обов'язкова. Налаштовується через стандартну бінлог-реплікацію або GTID:

# На резервній репліці
[mysqld]
server-id = 10
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON
log_slave_updates = ON  # потрібно, якщо репліка стане мастером

Моніторинг лагу реплікації — ключова метрика для оцінки RPO:

SHOW SLAVE STATUS\G
-- Seconds_Behind_Master: 2  -- прийнятно
-- Seconds_Behind_Master: 300 -- проблема, потрібне розслідування

2. Синхронізація файлів

Каталог upload/ синхронізується через rsync за розкладом або безперервно через inotifywait:

# Безперервна синхронізація через inotify
inotifywait -m -r -e create,modify,delete /var/www/bitrix/upload/ |
while read path action file; do
    rsync -az /var/www/bitrix/upload/ \
        backup-dc:/var/www/bitrix/upload/ &
done

Файли конфігурації (/bitrix/.settings.php, dbconn.php) — через Git або окремий rsync-скрипт при кожній зміні.

3. Готовий веб-стек на резервному майданчику

Резервний сервер повинен мати встановлений і налаштований стек (nginx, php-fpm, redis) з коректним конфігом. Файли Бітрікс (/bitrix/, /local/) — синхронізуються раз на добу або з останнього деплою.

Перемикання: ручне vs автоматичне

Ручне перемикання — оператор змінює A-запис DNS після підтвердження аварії. Мінімальний TTL для швидкого перемикання — 60–300 секунд.

Автоматичне (failover) — healthcheck на основному ДЦ, при недоступності — скрипт оновлює DNS через API:

#!/bin/bash
# healthcheck.sh — запускається щохвилини через cron
MAIN_IP="185.10.1.100"
BACKUP_IP="195.20.2.100"
DOMAIN="your-site.ru"

if ! curl -sf --max-time 10 "https://$DOMAIN/health" > /dev/null; then
    # Перемикаємо DNS через Cloudflare API
    curl -X PATCH \
        "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$CF_RECORD_ID" \
        -H "Authorization: Bearer $CF_TOKEN" \
        -H "Content-Type: application/json" \
        --data '{"content":"'"$BACKUP_IP"'","ttl":60}'

    # Повідомлення команди
    curl -s "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
        -d "chat_id=$TG_CHAT&text=FAILOVER+ACTIVATED:+switched+to+backup+DC"
fi

Активація резервного ДЦ: чеклист

Коли failover спрацьовує, на резервному майданчику потрібно:

1. Підвищити репліку до мастера: STOP SLAVE; RESET SLAVE ALL;
2. Оновити /bitrix/.settings.php — замінити IP мастера БД на локальний
3. Переконатися, що Redis запущено і сесії доступні
4. Перевірити cron-завдання 1С-Бітрікс (агенти): /bitrix/admin/agent_list.php
5. Запустити тестову транзакцію в магазині
6. Повідомити службу підтримки про зміну точки обробки замовлень

Кроки 1–3 автоматизуються через Ansible playbook:

# failover.yml
- name: Promote MySQL replica to master
  mysql_replication:
    mode: stopreplica

- name: Update Bitrix DB config
  template:
    src: settings.php.j2
    dest: /var/www/bitrix/bitrix/.settings.php
  vars:
    db_host: "127.0.0.1"  # локальний мастер на резервному майданчику

- name: Restart php-fpm
  service:
    name: php8.1-fpm
    state: restarted

Терміни налаштування

Налаштування резервного ДЦ з реплікацією БД, синхронізацією файлів і автоматичним failover DNS — включно з тестуванням перемикання — займає 5–8 робочих днів.