Обеспечение непрерывной работы корпоративных систем на платформе 1С:Предприятие — одна из приоритетных задач системного администратора. При проектировании инфраструктуры СУБД часто возникает дилемма: какую технологию отказоустойчивости выбрать, чтобы минимизировать время простоя (RTO) и потенциальную потерю данных (RPO). При этом в сообществе циркулирует множество мифов и полуправды о совместимости различных решений с платформой 1С. В этой статье мы подробно проанализируем доступные варианты, развеем популярные заблуждения и дадим пошаговые рекомендации по настройке высокодоступной среды.
В кругах ИТ-специалистов часто обсуждается слух, что полноценная синхронизация баз данных 1С на уровне SQL невозможна из-за специфической структуры таблиц СУБД, а именно — отсутствия первичных ключей (Primary Keys) на некоторых служебных таблицах или таблицах итогов регистров. Выясним, откуда взялось это утверждение и почему оно не должно останавливать нас при внедрении современных систем высокой доступности.
Ограничение по обязательности наличия первичных ключей действительно существует в MS SQL Server. Однако оно относится исключительно к технологии транзакционной репликации (Transactional Replication). Данный метод синхронизации работает на уровне логического отслеживания изменений в таблицах и действительно требует наличия строго определенных первичных ключей для однозначной идентификации строк. В старых версиях платформы 1С (и в некоторых структурах метаданных современных версий) действительно встречаются таблицы без явных суррогатных или естественных PK, что делает транзакционную репликацию неприменимой для баз данных 1С.
Но для решения задач высокой доступности (HA) транзакционная репликация практически никогда не используется. Современные технологии отказоустойчивости работают совершенно по другим принципам:
Таким образом, технологии AlwaysOn и зеркалирование полностью и без каких-либо ограничений совместимы с любыми конфигурациями 1С:Предприятия.
Выбирая между классическим кластером Microsoft (Failover Cluster Instance) и группами доступности AlwaysOn, необходимо четко понимать их архитектурные различия и возможные точки отказа.
Failover Cluster Instance (FCI) — это классическое решение высокой доступности на уровне экземпляра SQL Server. В этой схеме два или более вычислительных узла (сервера) подключены к одному общему дисковому хранилищу (SAN, NAS, SAS-хранилище). Активным в каждый момент времени является только один сервер. Если он выходит из строя, кластерная служба Windows (WSFC) инициирует запуск службы SQL Server на втором узле, который монтирует те же самые диски с базой данных.
Главный недостаток FCI заключается в наличии единой точки отказа (SPOF — Single Point of Failure), которой выступает дисковая полка или каналы связи с ней. Если экскаватор перебьет оптический кабель до системы хранения данных или произойдет аппаратный сбой самого контроллера СХД, весь кластер мгновенно перестанет функционировать, а данные могут оказаться повреждены.
AlwaysOn Availability Groups — это более современная технология (появившаяся в SQL Server 2012), которая работает на уровне баз данных. Каждый SQL-сервер имеет свои собственные, независимые дисковые массивы (например, локальные быстрые NVMe/SSD диски). Синхронизация данных между основным (Primary) и резервным (Secondary) узлами происходит по локальной сети в режиме реального времени (синхронно или асинхронно). Схема AlwaysOn полностью исключает единую точку отказа на уровне СХД. Если один сервер вместе со своими дисками физически сгорает, у вас остается полностью работоспособная копия базы на втором сервере.
Одним из ключевых преимуществ технологии AlwaysOn является возможность перевода резервной копии базы данных (Secondary Replica) в режим «только для чтения» (Readable Secondary). Проанализируем, как это можно использовать для оптимизации работы инфраструктуры 1С.
Сама платформа 1С:Предприятие по умолчанию не умеет разделять транзакции записи и чтения «из коробки». Клиентское приложение и сервер приложений 1С всегда работают в режиме полного монопольного доступа «чтение-запись», отправляя все запросы на первичную ноду. Вы не сможете запустить сеансы пользователей так, чтобы часть из них проводила документы на основном сервере, а другая часть формировала отчеты на резервном.
Тем не менее, Readable Secondary может принести колоссальную пользу для смежных задач:
Если мы приняли решение разворачивать AlwaysOn Availability Groups для СУБД SQL Server 2012 (версии Enterprise) или более новых версий, необходимо учесть ряд важнейших технических нюансов, без которых система не сможет корректно работать при аварийном переключении.
1. Синхронизация SID учетных записей пользователей СУБД.
Сервер приложений 1С авторизуется на MS SQL Server под конкретной учетной записью (например, sa или специально созданным пользователем usr1cv8). Если мы создадим этого пользователя на основном и резервном серверах вручную через графический интерфейс SSMS, они будут иметь разные уникальные идентификаторы безопасности (SID) в системной базе данных master.
При аварийном переключении базы данных на резервный сервер пользователи 1С столкнутся с ошибкой авторизации, так как база данных будет ожидать пользователя с SID первичного сервера, а на вторичном сервере у пользователя с тем же именем будет другой SID. Чтобы избежать этой проблемы, перенесем логин с первичного сервера на вторичный с сохранением его точного SID и хэша пароля с помощью следующего скрипта:
-- Выполняем на ПЕРВИЧНОМ сервере для получения hex-значений SID и пароля
SELECT name, sid, password_hash
FROM sys.sql_logins
WHERE name = 'usr1cv8';
-- Полученные значения подставляем в скрипт создания на ВТОРИЧНОМ сервере
CREATE LOGIN [usr1cv8]
WITH PASSWORD = 0x01004FDF... HASHED,
SID = 0x8A12B34C...,
DEFAULT_DATABASE = [master];
2. Использование параметра MultiSubnetFailover.
Если ваши серверы СУБД разнесены по разным дата-центрам или находятся в разных сетевых подсетях, то при переключении группы доступности AlwaysOn на другой IP-адрес клиенты могут долго ожидать очистки кэша DNS. Для мгновенного переключения пользователей в строке подключения сервера приложений 1С к СУБД (или в настройках параметров связи с базой данных) обязательно укажем параметр:
MultiSubnetFailover=True
Этот параметр заставляет сетевой драйвер опрашивать все IP-адреса, привязанные к прослушивателю (Listener) группы доступности, параллельно, снижая время переключения до сотых долей секунды.
3. Идентичность конфигурации базы TempDB.
Системная база данных tempdb активно используется платформой 1С для работы с временными таблицами при сложных расчетах. Она создается заново при каждом перезапуске службы SQL Server и не реплицируется средствами AlwaysOn. Мы должны вручную убедиться, что настройки tempdb на резервном сервере абсолютно идентичны основному (база разбита на равные файлы по количеству ядер процессора, файлы расположены на самых производительных локальных SSD/NVMe дисках). В противном случае, после переключения на резервный узел производительность всей системы 1С резко снизится.
4. Идентичность параметров сортировки (Collation).
Системные параметры сортировки на обоих серверах MS SQL обязаны быть строго одинаковыми (для корректной работы 1С традиционно используется Cyrillic_General_CI_AS). Различие в Collation на уровне инстансов сделает невозможным объединение серверов в группу доступности или приведет к критическим ошибкам сопоставления метаданных при попытке запустить базу после сбоя.
Рассмотрим альтернативный вариант для компаний, которые не могут или не планируют приобретать дорогостоящие лицензии MS SQL Server Enterprise, необходимые для полноценного функционирования AlwaysOn. В современных реалиях отличным стандартом отказоустойчивости для 1С стала связка СУБД PostgreSQL с оркестратором Patroni.
Patroni — это специализированное решение с открытым исходным кодом для шаблонизации и управления высокодоступными кластерами PostgreSQL. Совместно с распределенным хранилищем конфигураций (DCS), таким как etcd или Consul, Patroni обеспечивает:
Эта связка отлично зарекоменбировала себя в крупных инсталляциях 1С и обеспечивает уровень надежности, сопоставимый с MS SQL AlwaysOn, при нулевых затратах на лицензирование СУБД.
Иногда внедрение автоматического переключения (failover) несет в себе больше рисков, чем ручное управление процессом. Как справедливо заметили опытные администраторы, при ложных срабатываниях систем автоматического переключения объем работ по восстановлению целостности данных может в сотни раз превышать трудозатраты на минутное ручное переключение.
Если бюджет и штатные ресурсы ограничены, рассмотрим простой и крайне надежный сценарий «теплого резерва» (Warm Standby):
NORECOVERY или STANDBY.RECOVERY (что переводит базу в рабочий режим), меняет адрес сервера СУБД в настройках кластера 1С и запускает пользователей. Время простоя при этом составляет не более 10–15 минут, а потеря данных ограничивается лишь последним часом работы, что для многих видов бизнеса является вполне допустимым.Выбор конкретной технологии зависит от требований бизнеса к непрерывности процессов. Для критически важных систем со временем простоя, близким к нулю, оптимальным выбором станет внедрение MS SQL AlwaysOn или PostgreSQL + Patroni с обязательным учетом всех технических тонкостей настройки сетевого взаимодействия и прав доступа.