Организация отказоустойчивой системы (High Availability), когда серверы разнесены географически, — это сложная инженерная задача. Она требует учета не только программных механизмов синхронизации данных, но и особенностей сетевых протоколов, задержек связи и правил лицензирования. В данной статье мы подробно разберем, как построить надежную инфраструктуру для 1С:Предприятие и SQL Server, используя различные технологические стеки.
Прежде всего, проанализируем ситуацию: серверы находятся в разных концах города. Основными рисками являются обрыв канала связи (интернет) и отключение электропитания на одной из площадок. Нам необходимо обеспечить автоматический или максимально быстрый ручной перевод клиентов на резервный сервер. Разберем основные архитектурные варианты решения этой задачи.
Рассмотрим наиболее современный и надежный метод обеспечения доступности на уровне СУБД — технологию Always On. В отличие от устаревшего «зеркалирования» (Mirroring), Always On позволяет объединять несколько баз данных в группу доступности.
Для реализации этой схемы нам потребуется:
SQL Server версии Enterprise (для полноценных групп) или Standard (для Basic Availability Groups).Выясним причину, почему это важно для 1С: при падении основного сервера SQL Слушатель автоматически переключает соединение на второй узел. 1С-сервер при этом не требует перезагрузки или изменения строк подключения.
Важный нюанс по режимам синхронизации:
Обеспечение доступности базы SQL — это только половина дела. Нам также необходимо зарезервировать сам сервер приложений 1С. Рассмотрим, как это работает в штатном режиме кластера 1С.
Для автоматического перевода сеансов без участия администратора потребуются лицензии уровня КОРП. В этом режиме можно настроить «уровень отказоустойчивости», который определяет, сколько рабочих серверов могут выйти из строя без прерывания работы пользователей. Данные о сеансах (кто залогинен, какие формы открыты) дублируются между серверами кластера.
Если используется версия ПРОФ, автоматического «бесшовного» переключения не произойдет. При падении сервера 1С пользователям придется заново запускать программу и авторизовываться на втором сервере (если настроен список серверов в лаунчере).
Проанализируем ситуацию, когда связь между серверами обрывается, но оба сервера продолжают работать. Это называется split-brain. Оба сервера могут решить, что они «главные», и начнут принимать данные, что приведет к фатальному расхождению баз данных.
Для решения этой проблемы в кластере должен быть Кворум. Поскольку у нас всего два сервера, нам жизненно необходим третий узел. Однако это не обязательно должен быть полноценный мощный компьютер. Мы можем использовать File Share Witness (свидетель на общей папке):
Если бюджет не позволяет купить лицензии SQL Enterprise или канал связи слишком нестабилен для Always On, рассмотрим технологию Log Shipping. Разберем по шагам принцип её работы:
Standby или Restoring.Плюсы: минимальная нагрузка на сеть. Минусы: переключение на резерв происходит вручную (нужно «оживить» базу на втором сервере), и данные за последние минуты перед аварией будут потеряны.
Посмотрим на ситуацию со стороны встроенных механизмов 1С. Использование РИБ позволяет иметь две независимые базы данных, которые обмениваются изменениями. Это самое живучее решение для плохих каналов связи, так как каждая точка может работать автономно неограниченное время.
Однако, как отмечалось на форуме, РИБ требует тщательного контроля. Основные риски здесь — конфликты нумерации и ошибки синхронизации. Если вы выбираете этот путь, обязательно настройте префиксы информационных баз:
// Пример настройки префикса в коде для исключения конфликтов
Объект.Номер = "МСК" + ТекущийНомер; // Для сервера в Москве
Объект.Номер = "СПБ" + ТекущийНомер; // Для сервера в Питере
Выясним важный момент с лицензиями. При создании зеркала или кластера вам потребуется:
Подводя итог, выделим три сценария в зависимости от требований бизнеса:
Используем SQL Server Always On в синхронном режиме + кластер 1С КОРП. Требуется выделенный скоростной канал связи (оптика) между серверами. Это обеспечит работу без потери данных и без разрыва сессий пользователей при аварии.
Используем SQL Server Always On в асинхронном режиме + кластер 1С ПРОФ. При падении основного сервера пользователям придется перезайти в 1С. Возможна минимальная потеря данных (за последние секунды).
Используем Log Shipping или РИБ. Настройка переключения DNS или файла hosts на клиентах через скрипты:
# Пример простого скрипта для переключения IP сервера в файле hosts
192.168.1.10 1c-server-main
# При аварии меняем на:
# 192.168.2.10 1c-server-main
Рассмотренные методы позволяют создать устойчивую систему, способную пережить серьезные инфраструктурные сбои. Выбор конкретного метода должен основываться на допустимом времени простоя (RTO) и допустимом объеме потери данных (RPO).