Администрирование · 11 мин
Что такое узел в 1С и для чего он нужен
Что такое узел в 1С: узел плана обмена в распределённой базе и узел кластера серверов. Разбираем назначение, настройку, типичные ошибки и проверку обмена.
Термин «узел» в 1С встречается в двух разных контекстах, и их часто путают. Первый — узел плана обмена: логический участник обмена данными в распределённой информационной базе (РИБ) или в синхронизации с другой системой. Второй — узел (рабочий сервер) кластера серверов 1С:Предприятия, то есть физическая или виртуальная машина, на которой работают процессы кластера. Оба значения связаны с распределённой работой, но относятся к разным уровням: первый — к данным и прикладной логике, второй — к инфраструктуре.
Чаще всего вопрос «что такое узел 1С» возникает у бухгалтеров и администраторов при настройке обмена между базами: например, между центральной базой головного офиса и базами филиалов, между «Управлением торговлей» и «Бухгалтерией» или при синхронизации с интернет-магазином. В этом случае речь идёт именно об узле плана обмена — объекте конфигурации, который идентифицирует конкретную базу-участницу обмена.
Понимание того, как устроены узлы, критично для безопасной работы: ошибочное удаление узла, сброс номеров сообщений или изменение состава обмена могут привести к потере данных, дублированию документов и остановке синхронизации. Ниже разберём оба значения термина, практику настройки и контрольные точки для проверки.
Узел плана обмена: что это и как работает
План обмена — объект метаданных конфигурации, который описывает, какие данные (справочники, документы, регистры) передаются между базами и куда именно. Каждая база-участница обмена представлена в плане обмена отдельным узлом. Узел хранит код (уникальный идентификатор базы), наименование, а также служебные счётчики — номера отправленных и принятых сообщений, по которым система отслеживает, какие изменения уже переданы, а какие ещё нет.
Механизм работает так: при изменении объекта, входящего в состав плана обмена, 1С регистрирует изменение для всех узлов-получателей (регистрация изменений). При выгрузке формируется сообщение обмена — файл с данными в формате XML, которому присваивается очередной номер. Принимающая сторона записывает номер последнего принятого сообщения и при следующей выгрузке получает подтверждение, что данные дошли. Если подтверждения нет — изменения отправляются повторно.
В каждом плане обмена есть предопределённый узел — «этот узел», то есть сама текущая база. Его код задаётся при начальной настройке и менять его после запуска обмена нельзя: иначе вся цепочка номеров сообщений потеряет смысл, и обмен придётся настраивать заново.
Центральный и подчинённый узлы в РИБ
Распределённая информационная база (РИБ) — классический сценарий использования узлов. Структура РИБ строго иерархична: есть один центральный (главный) узел и один или несколько подчинённых. Подчинённый узел может обмениваться только со своим главным, «горизонтального» обмена между филиалами напрямую не существует.
Ключевая особенность РИБ — миграция изменений конфигурации. Обновить конфигурацию можно только в центральном узле; изменения автоматически передаются подчинённым вместе с сообщением обмена, и база-приёмник обновляется при загрузке. Это удобно для сети филиалов, но накладывает ограничение: в подчинённом узле нельзя дорабатывать конфигурацию самостоятельно.
Создание подчинённого узла выполняется через механизм создания начального образа: в центральной базе добавляют новый узел, затем формируют образ — копию базы, уже настроенную как подчинённую. Эту копию разворачивают в филиале, и обмен начинает работать без ручной привязки кодов.
- 1В центральной базе откройте план обмена и добавьте новый узел с уникальным кодом (например, код филиала)
- 2Запустите создание начального образа подчинённого узла и укажите каталог или готовую базу
- 3Разверните образ на рабочем месте филиала и проверьте, что база открывается в режиме подчинённого узла
- 4Выполните первую выгрузку из центрального узла и загрузку в подчинённом
- 5Проверьте, что счётчики сообщений синхронизированы и документы переносятся в обе стороны
Узлы в синхронизации между разными конфигурациями
Помимо РИБ, узлы используются в универсальном механизме синхронизации данных между разными конфигурациями — например, «Управление торговлей» ↔ «Бухгалтерия предприятия» или обмен с сайтом. Здесь нет жёсткой иерархии «главный-подчинённый»: обе базы равноправны, а соответствие объектов определяется правилами конвертации.
Настройка обычно выполняется через помощник синхронизации: указывается вторая база (через файл, прямое подключение, веб-сервис или каталог), создаётся узел обмена, задаются правила выгрузки и отборы. В отличие от РИБ, конфигурации здесь обновляются независимо, но при обновлении нужно следить за совместимостью правил обмена — после обновления одной из баз старые правила могут перестать подходить.
РИБ или синхронизация данных
Подходит для одинаковых конфигураций в филиалах. Конфигурация обновляется централизованно. Ограничение: строгая иерархия, нельзя дорабатывать конфигурацию в филиале
Подходит для разных конфигураций (УТ + БП, обмен с сайтом). Гибкие правила и отборы. Ограничение: правила нужно поддерживать при обновлениях, возможны конфликты при изменении одного объекта в обеих базах
Узел кластера серверов 1С
Второе значение термина относится к клиент-серверной архитектуре. Кластер серверов 1С:Предприятия может включать несколько рабочих серверов — их и называют узлами кластера. Каждый узел — это компьютер, на котором запущены процессы кластера (ragent, rmngr, rphost), обслуживающие подключения пользователей и фоновые задания.
Несколько узлов добавляют для отказоустойчивости и распределения нагрузки: если один сервер выходит из строя, сеансы переносятся на оставшиеся. Узлы кластера настраиваются в консоли администрирования серверов 1С, там же задаются требования назначения функциональности — какие сервисы (фоновые задания, сервисы сеансовых данных) на каком узле работают.
Важно не путать: узел кластера никак не связан с обменом данными. База в кластере из трёх серверов — это всё равно одна информационная база, и в плане обмена она будет представлена одним узлом.
Частые ошибки при работе с узлами обмена
Самая разрушительная ошибка — удаление узла плана обмена, по которому ещё идёт обмен. Вместе с узлом удаляются зарегистрированные изменения и счётчики сообщений: восстановить обмен «с того же места» невозможно, придётся создавать узел заново и выполнять первичную выгрузку всех данных. Перед удалением узла убедитесь, что база-участница выведена из эксплуатации окончательно.
Вторая типичная проблема — восстановление базы из старой копии. Если подчинённый узел восстановили из архива недельной давности, его счётчики сообщений отстанут от центрального узла. Центральная база будет считать часть сообщений уже доставленными, и изменения за этот период не придут. Лечится сбросом номеров сообщений и повторной выгрузкой либо пересозданием образа.
Как проверить, что обмен через узел работает корректно
Основной инструмент контроля — сопоставление счётчиков: номер последнего отправленного сообщения в базе-источнике должен совпадать с номером принятого в базе-приёмнике. Расхождение означает, что сообщения теряются или не загружаются. В типовых конфигурациях есть обработки мониторинга обмена, показывающие незагруженные пакеты и ошибки.
Дополнительно проверяют очередь зарегистрированных изменений: если она постоянно растёт и не очищается после выгрузки, значит, приёмник не подтверждает получение. Также стоит контролировать журнал регистрации на предмет ошибок загрузки — например, конфликтов ссылок или нарушений формата.
Как проверить результат
Номер отправленного в источнике равен номеру принятого в приёмнике
Номера расходятся — сообщения теряются или не загружаются
После успешной выгрузки очередь очищается
Очередь растёт — подтверждения не приходят, изменения копятся
Созданный в одной базе документ появляется в другой после обмена
Документ не переносится или дублируется при повторных обменах
Нет ошибок загрузки после сеанса обмена
Ошибки формата, конфликты ссылок, незагруженные объекты
Как выбрать действие
Часто задаваемые вопросы
Чем узел плана обмена отличается от узла кластера?
Узел плана обмена — прикладной объект, идентифицирующий базу-участницу обмена данными; он хранит код и счётчики сообщений. Узел кластера — физический или виртуальный сервер в составе кластера 1С, обслуживающий сеансы пользователей. Это разные уровни: данные и инфраструктура.
Можно ли изменить код узла после настройки обмена?
Технически код можно отредактировать, но делать этого не следует: нумерация сообщений привязана к паре узлов, и смена кода разрывает цепочку. Обе базы перестанут понимать, какие изменения переданы. Если код нужно сменить, корректный путь — удалить узел и настроить обмен заново с первичной выгрузкой.
Что делать, если в подчинённом узле РИБ просит обновить конфигурацию?
Это нормальная ситуация: в центральном узле обновили конфигурацию, и изменения пришли с сообщением обмена. Выполните загрузку сообщения, затем обновите конфигурацию базы данных штатно через конфигуратор. Самостоятельно обновлять подчинённый узел из файла поставки нельзя — только через обмен с главным узлом.
Почему после обмена появляются дубли справочников?
Чаще всего причина в том, что один и тот же элемент (контрагент, номенклатура) создан независимо в обеих базах до настройки соответствий. При синхронизации система не находит пару и создаёт новый объект. Лечится сопоставлением объектов в настройках синхронизации и ручным устранением дублей, в РИБ — правильным развёртыванием начального образа вместо создания базы «с нуля».
Сколько узлов может быть в плане обмена?
Жёсткого практического лимита на количество узлов в типовых механизмах нет — распределённые базы с десятками филиалов встречаются на практике. Реальные ограничения — производительность при большом объёме регистраций и сложность администрирования: чем больше узлов, тем труднее контролировать очереди и ошибки обмена.
Что важно запомнить
Узел в 1С — чаще всего участник обмена данными в плане обмена (РИБ или синхронизация), реже — сервер в кластере. Узел хранит код базы и счётчики сообщений, поэтому его нельзя бездумно удалять или переименовывать. Контролируйте обмен по счётчикам, очереди регистрации и тестовым документам, а перед любыми изменениями узлов делайте резервные копии обеих баз.