При построении отказоустойчивой инфраструктуры под системы 1С:Предприятие неизбежно возникает вопрос резервирования системы управления базами данных (СУБД). Высокие требования бизнеса к времени минимального простоя (RTO) и допустимым потерям данных (RPO) заставляют отказываться от концепции одиночного сервера. Проанализируем доступные технологии создания отказоустойчивых кластеров MS SQL Server и других СУБД, а также разберем особенности их взаимодействия с платформой 1С.
Рассмотрим четыре основных архитектурных подхода к резервированию MS SQL Server, их преимущества и ограничение в контексте работы с 1С:
Группы доступности AlwaysOn (AlwaysOn Availability Groups)
Современное и наиболее универсальное решение для MS SQL Server. Позволяет объединять одну или несколько баз данных в группу доступности, которая реплицируется на резервные узлы в синхронном или асинхронном режиме. При выходе из строя основного узла происходит автоматический отработка отказа (failover) на дублирующий узел.
Для полноценной работы AlwaysOn требуется редакция MS SQL Server Enterprise. В редакции Standard доступна только базовая группа (Basic Availability Groups) с ограничением в 1 базу данных на группу и максимальным количеством узлов — 2.
Отказоустойчивые кластерные экземпляры (Failover Cluster Instances — FCI)
Классический кластер на уровне экземпляра MS SQL Server, использующий технологию Windows Server Failover Clustering (WSFC) и общее дисковое хранилище (SAN или виртуальные общие диски). В случае сбоя текущего узла весь экземпляр СУБД со всеми системными базами данных (master, msdb) перезапускается на резервном узле.
Время автоматического переключения при FCI обычно составляет от 1 до 3 минут, так как службе требуется время для запуска и накатывания незавершенных транзакций на новом узле.
Зеркалирование баз данных (Database Mirroring)
Устаревшая технология передачи транзакций между двумя экземплярами SQL Server. Позволяет автоматически переключать активную базу данных при использовании сервера-свидетеля (Witness). Однако компания Microsoft официально объявила Database Mirroring устаревшей функцией, и на смену ей пришла технология AlwaysOn Availability Groups.
Доставка журнала транзакций (Log Shipping)
Механизм регулярного создания бэкапов журнала транзакций на основном сервере, их передачи по сети и восстановления на резервном сервере. Данный метод обеспечивает резервирование со сдвигом по времени и требует ручного переключения при аварии. Подходит для сценариев катастрофоустойчивости, но не обеспечивает автоматического переключения за считанные секунды.
Разберем, как именно платформа 1С подключается к отказоустойчивой СУБД и какие нюансы нужно учитывать системному администратору при настройке:
Использование прослушивателя (Availability Group Listener)
Чтобы 1С корректно обращалась к активной реплике AlwaysOn, в настройках соединения с базой данных в кластере 1С указывается имя виртуального сетевого имени — прослушивателя группы доступности (Listener). Прослушиватель регистрируется в DNS и автоматически перенаправляет сетевые запросы на узел, который в данный момент является первичным (Primary).
Параметры DNS и работы в разных подсетях
Если узлы отказоустойчивого кластера расположены в разных подсетях (Multi-Subnet Cluster), при сбое может возникать задержка подключения. В MS SQL для решения этой проблемы используется параметр строки подключения MultiSubnetFailover=True. Однако платформа 1С не передает этот параметр напрямую. Для устранения задержек подключают следующие настройки ресурса DNS в кластере Windows:
Уменьшают время жизни DNS-записи до минимума:
Set-ClusterResource -Name "IP Address Name" -Parameters @{HostRecordTTL = 60}
Отключают регистрацию всех IP-адресов прослушивателя, оставляя только адрес активного узла:
Set-ClusterResource -Name "IP Address Name" -Parameters @{RegisterAllProvidersIP = 0}
Поведение сеансов 1С при аварийном переключении
При отработке отказа AlwaysOn или FCI происходят разрыв текущих TCP-соединений и откат активных транзакций. База данных TempDB на новом узле всегда создается заново, поэтому временные таблицы текущих сеансов теряются. В момент переключения пользователи 1С могут получить сообщение об ошибке связи с сервером. После завершения failover и переподключения к СУБД пользователи смогут продолжить работу, но незавершенную транзакцию (например, проведение документа) потребуется запустить повторно.
Модель восстановления и обслуживание журналов транзакций
При использовании групп доступности AlwaysOn базы данных обязаны находиться в полной модели восстановления (FULL). Это требует обязательной настройки регулярного резервного копирования журнала транзакций (Log Backup). Если транзакции не бэкапятся, файл журнала LDF быстро переполнит дисковое пространство, что приведет к остановке работы СУБД.
Если в качестве СУБД для 1С используется PostgreSQL или Postgres Pro, разберем популярные инструменты построения кластера высокой доступности:
Patroni + etcd / Consul
Стандартное и зарекомендовавшее себя бесплатное решение для создания отказоустойчивого кластера PostgreSQL. Patroni управляет состоянием узлов, автоматизирует процесс выбора нового мастера (Leader) при сбое и обновляет конфигурацию прокси-сервера (например, HAProxy) или виртуального IP (Keepalived), выступающего единой точкой входа для кластера 1С.
Postgres Pro BiHA (Built-in High Availability)
Встроенный механизм высокой доступности, поставляемый в коммерческих редакциях Postgres Pro Enterprise. Он интегрирован непосредственно в ядро СУБД и не требует развертывания сторонних распределенных хранилищ конфигураций, таких как etcd.
Выясним важную деталь: создание отказоустойчивой СУБД не гарантирует непрерывность бизнеса, если сам сервер приложений 1С остается единственной точкой отказа. Для построения полностью отказоустойчивого контура необходимо параллельно настраивать резервирование кластера 1С: