В практике администрирования крупных информационных систем на базе «1С:Предприятие» иногда возникает соблазн распределить нагрузку весьма нестандартным путем. Например, настроить два независимых кластера серверов 1С и подключить их к одной и той же физической базе данных на сервере MS SQL. На первый взгляд, это кажется рабочим решением для изоляции пользователей или балансировки. Однако такая схема архитектурно порочна и неизбежно ведет к катастрофическим последствиям для данных.
В этой статье мы подробно проанализируем, почему подобное подключение категорически недопустимо, рассмотрим официальную позицию фирмы «1С» и разберем глубокие технические последствия, которые гарантированно разрушат логическую целостность вашей базы данных.
Начнем с того, как этот вопрос позиционируется разработчиками платформы. Технически «1С:Предприятие» при создании новой информационной базы в консоли администрирования не запрещает указать имя базы СУБД, к которой уже подключен другой кластер. Программный запрет на уровне кода платформы отсутствует, так как разработчики справедливо считают выбор архитектуры зоной ответственности системного администратора.
Тем не менее, в официальных методических материалах ИТС четко зафиксировано предупреждение: «Одновременное использование нескольких экземпляров служебных данных с одной базой данных нарушает их логическую целостность». Фирма «1С» официально не поддерживает такие конфигурации, и любые сбои в подобных схемах не признаются гарантийными случаями.
Давайте выясним глубокие технические причины этого запрета и разберем по шагам, что именно происходит «под капотом» системы при одновременной работе двух изолированных кластеров с одной СУБД.
Современные конфигурации 1С по умолчанию работают в режиме управляемых блокировок. Важно понимать, что этот механизм реализуется не на уровне СУБД (например, MS SQL Server или PostgreSQL), а непосредственно в оперативной памяти сервера приложений (кластера 1С).
Проанализируем стандартную ситуацию:
В результате мы получаем классическую логическую ошибку: остатки в регистре уходят в глубокий минус, себестоимость рассчитывается некорректно, а финансовый результат искажается. Данные внутри базы становятся недостоверными.
Каждая зарегистрированная информационная база в рамках своего кластера считает себя «единственным и полноправным хозяином» расписания фоновых и регламентных заданий. Механизм РегламентныеЗадания координируется менеджером конкретного кластера.
Когда к одной базе СУБД подключены два кластера, регламентные задания (например, закрытие месяца, расчет себестоимости, отправка уведомлений клиентам или синхронизация данных с внешними системами) запускаются параллельно на обоих серверах.
Это приводит к следующим последствиям:
deadlocks) на уровне СУБД, так как два тяжелых процесса пытаются одновременно обрабатывать одни и те же таблицы.Пессимистическая блокировка защищает данные от интерактивного изменения, когда один пользователь открыл форму объекта (например, документа или элемента справочника) для редактирования, а второй пытается сделать то же самое.
Рассмотрим эту ситуацию по шагам:
В итоге работа пользователей превращается в хаос, а данные постоянно теряются.
Для обеспечения высокой скорости работы сервер 1С активно использует кэширование в оперативной памяти рабочих процессов. В кэше хранятся структуры метаданных, значения констант, параметры сеанса, а также часто запрашиваемые справочники.
Если на Кластере А пользователь изменит значение важной константы (например, ставку НДС или учетную политику), СУБД обновит запись в таблице. Однако Кластер Б об этом изменении не узнает, так как он обращается к своему локальному кэшу в оперативной памяти. Пользователи на втором кластере продолжат работать со старыми значениями до тех пор, пока кэш сервера не будет принудительно сброшен или не истечет время его жизни. Это гарантирует появление ошибок в расчетах и документах.
Попытка обновить конфигурацию в такой архитектуре — это прямой путь к полной потере базы данных. Когда администратор запускает «Конфигуратор» на Кластере А и выполняет обновление (особенно динамическое или требующее реструктуризации таблиц СУБД), этот кластер блокирует работу своих пользователей.
Однако пользователи на Кластере Б продолжают активно работать с базой, проводить документы и записывать данные. В момент изменения структуры таблиц (когда изменяются служебные таблицы Config и ConfigSave) активная запись со стороны пользователей другого кластера приведет к фатальному разрушению структуры таблиц метаданных. После этого база просто перестанет открываться, и ее придется восстанавливать из резервной копии.
Получением оперативного времени проведения документов управляет менеджер конкретного кластера. При наличии двух изолированных систем велика вероятность того, что два разных документа получат абсолютно одинаковое оперативное время или неуникальные номера. Это нарушит строгую последовательность проведения документов, из-за чего последующее восстановление партионного учета или взаиморасчетов станет невозможным.
Журнал регистрации в современных версиях 1С пишется в файлы на уровне сервера приложений (в каталог srvinfo конкретного кластера). Подключив два кластера к одной базе, вы получите две разрозненные истории действий пользователей. Собрать единый аудит безопасности, расследовать инциденты или понять, кто именно изменил документ, станет практически невыполнимой задачей.
Если перед вами стоит задача распределить нагрузку, повысить отказоустойчивость или выделить отдельные мощности под фоновые задания, делать это нужно строго в рамках одного общего кластера 1С. Рассмотрим, как правильно спроектировать такую систему:
MS SQL Server для распределения нагрузки на чтение), но серверная часть 1С должна оставаться единым логическим кластером.Таким образом, мы распределяем физическую нагрузку по разным серверам приложений, но полностью сохраняем логическую целостность данных в СУБД за счет единого координатора в лице одного кластера 1С.