Развёртывание MS SQL Always On Availability Groups

• Минимум два синхронных узла в основном ЦОД — для автоматического переключения при сбое основного узла без потери данных. Репликация транзакций происходит в реальном времени с подтверждением записи на втором узле.
• Третий асинхронный узел в географически удалённой резервной площадке — для аварийного восстановления. Он позволяет сохранить работоспособность даже при полной недоступности основного ЦОД.
• Выделенная сеть репликации (отдельный VLAN, 10 Гбит/с) — чтобы трафик синхронизации не конкурировал с пользовательскими запросами и не влиял на производительность приложений.
• Базы данных в режиме полного восстановления (Full Recovery Model) — с регулярным снятием лог-бэкапов каждые 5–15 минут. Это обеспечивает гибкость восстановления до любой точки во времени (PITR) и минимизирует потерю данных (RPO ≈ 0 при синхронной репликации).

Особое внимание уделяется безопасности и аудиту:

• Все соединения между узлами шифруются через сертификаты из локального УЦ (включая ГОСТ-совместимые провайдеры при работе в российской среде).
• Доступ к SQL-инстансам разрешён только через корпоративную сеть или защищённые шлюзы (например, RDP Gateway с MFA).
• Все события (логины, DDL-операции, изменения реплик) логируются и передаются в систему мониторинга (Zabbix, «Пульт»).

Но даже самая продуманная архитектура не гарантирует отказоустойчивость без регулярного тестирования. Поэтому мы проводим:

• Ежеквартальный фейловер-тест: принудительный переход основной реплики на резервный узел в изолированной среде.
• Валидацию целостности данных: проверка консистентности, отсутствия «битых» страниц, корректности ссылочной и логической целостности.
• Проверку времени восстановления (RTO): от момента сбоя до полной доступности сервиса — не более 30–60 секунд в типовой конфигурации.
• Тестирование восстановления из резервной площадки: запуск приложений на удалённой реплике с проверкой производительности и корректности бизнес-логики.

Все процедуры документируются: пошаговая инструкция, ответственные лица, временные окна, критерии успеха. Конфигурации хранятся в системе контроля версий (Git), а администраторы проходят обучение по восстановлению и диагностике.

Мы не просто «ставим кластер SQL». Мы развёртываем доказуемо отказоустойчивую СУБД, которая остаётся доступной даже в условиях аппаратного сбоя, сетевой аварии или человеческой ошибки — без остановки бизнеса.