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