Обеспечение непрерывной работы системы 1С на предприятии с несколькими территориально удаленными подразделениями — это комплексная задача, требующая внимания как к аппаратному обеспечению, так и к архитектуре самой базы данных. Рассмотрим ситуацию, когда второе подразделение полностью зависит от серверов и наличия электроэнергии в первом подразделении. Разберем пошагово, как минимизировать риски простоя и создать систему, которая продолжит функционировать даже при серьезных сбоях.
Прежде всего, проанализируем текущую ситуацию. Мы имеем классическую централизованную схему, где все данные хранятся в одном месте. Основные риски здесь:
Для решения этих проблем мы должны рассмотреть три уровня защиты: инфраструктурный (питание), сетевой (связь) и прикладной (архитектура 1С).
Начнем с самого фундаментального — обеспечения автономности центрального узла. Если основной сервер 1С находится в подразделении №1, оно должно быть защищено от перепадов и отключений электроэнергии. Рассмотрим варианты:
Использование ИБП и дизель-генераторов. Для серверного оборудования недостаточно обычного бытового бесперебойника. Проанализируем схему с использованием промышленного ИБП онлайн-типа и генератора с системой АВР (автоматический ввод резерва). Мощный ИБП должен держать нагрузку минимум 15–20 минут, что достаточно для автоматического запуска дизель-генератора и выхода его на рабочую мощность.
Практический совет: если бюджет ограничен, можно рассмотреть сборку кастомного решения на базе инвертора и большой сборки аккумуляторов (например, типа AGM), как это делают многие небольшие предприятия. Однако важно помнить, что такая система требует регулярного обслуживания (проверки плотности электролита или емкости банок раз в месяц).
Выясним причину, по которой радиомост или основной канал связи могут подводить. Часто это связано с погодными условиями или техническими особенностями провайдера. Разберем способы стабилизации связи:
1С:Предприятия мгновенно перенаправляется на альтернативный путь без разрыва сессии пользователя.Перейдем к программной части. Если мы не можем гарантировать 100% аптайм связи, нам необходимо сделать второе подразделение автономным. Рассмотрим основные подходы:
Это классический механизм платформы 1С. Развернем в подразделении №2 локальный сервер с копией базы. Настроим автоматический обмен данными между ними. Плюсы этого решения очевидны: при обрыве связи второе подразделение продолжает работать в своей локальной базе, а после восстановления канала данные синхронизируются.
Однако здесь могут возникнуть коллизии (одновременное изменение одного объекта в двух базах). Рекомендуется четко разделить области ответственности: например, подразделение №2 работает только со своими документами и справочниками.
Посмотрим на возможности платформы 8.3. Мы можем настроить кластер серверов, где рабочие процессы будут распределены между двумя физическими машинами. При падении одного сервера, сеансы пользователей перейдут на другой. Важно учитывать, что для эффективной работы такого кластера между серверами необходим высокоскоростной канал связи с минимальными задержками (не более 5-10 мс).
Вместо использования РИБ, который работает на логическом уровне 1С, можно настроить репликацию на уровне базы данных. Например, технология Microsoft SQL Server AlwaysOn Availability Groups позволяет держать актуальную копию данных на втором сервере. Переключение происходит практически мгновенно и прозрачно для системы.
-- Пример проверки состояния синхронизации в SQL Server
SELECT
ar.replica_server_name,
adc.database_name,
ag.name AS group_name,
drs.synchronization_state_desc,
drs.last_hardened_lsn
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON drs.replica_id = ar.replica_id
JOIN sys.availability_groups AS ag ON ar.group_id = ag.group_id
JOIN sys.availability_databases_cluster AS adc ON drs.group_database_id = adc.group_database_id;
Проанализируем ситуацию, когда 1С управляет производственными станками (сообщение 46). В этом случае критически важно, чтобы команды на оборудование не прерывались. Рассмотрим использование брокеров сообщений, таких как RabbitMQ. Станки отправляют данные в локальную очередь в подразделении №2, которая затем передает их в центральную 1С по мере доступности канала. Это гарантирует, что данные производства не будут потеряны даже при полной изоляции площадки.
Рассмотрим альтернативный путь — вынос серверов в профессиональный Дата-Центр (ЦОД). В облаке вопросы питания, охлаждения и физической безопасности серверов уже решены специалистами. Для бизнеса это часто оказывается дешевле, чем строить собственный защищенный серверный узел. В этом случае обе площадки подключаются к облаку как равноправные клиенты. Главное условие здесь — наличие двух независимых интернет-провайдеров на каждой точке (например, оптика + 4G-антенна).
Построение отказоустойчивой системы — это всегда баланс между стоимостью решения и стоимостью простоя. Проанализируем наши шаги:
SQL AlwaysOn — необходимость. Если простой на пару часов не критичен, достаточно качественных ИБП и резервного канала связи.Выбрав правильное сочетание аппаратных средств защиты и архитектуры 1С (РИБ или кластер), мы создадим надежный фундамент для стабильной работы производства в любых условиях.