Как объединить кластеры 1С

Объединение кластеров 1С — задача, которая возникает при консолидации инфраструктуры после слияния компаний, при миграции на новое оборудование или при сокращении числа серверов приложений. Под объединением обычно понимают два сценария: перенос информационных баз из одного кластера сервера 1С:Предприятие в другой и слияние двух физических серверов в единый кластер с общим агентом.

Важно сразу разграничить понятия: кластер серверов 1С — это логическая структура процессов ragent, rmngr и rphost, а не объединение баз данных. Сами базы данных хранятся в СУБД (MS SQL Server, PostgreSQL), и при «объединении кластеров» чаще всего достаточно перенести регистрацию баз между кластерами, не трогая данные. Полноценное слияние данных двух разных информационных баз — отдельная и гораздо более сложная задача, решаемая средствами конвертации данных.

Ниже разобраны оба сценария: перенос баз между кластерами на уровне сервера 1С и объединение данных из двух баз в одну. Выбор зависит от того, что именно требуется: свести администрирование в одну точку или получить единую учётную систему.

Определите, какой сценарий объединения вам нужен

Прежде чем что-либо менять, ответьте на вопрос: данные в базах одинаковые или разные? Если на двух серверах крутятся разные учётные базы (например, бухгалтерия на одном кластере и зарплата на другом), то задача сводится к переносу регистрации баз в один кластер — данные в СУБД остаются на месте.

Если же две организации вели учёт в двух похожих базах (например, две «Бухгалтерии предприятия» после слияния юрлиц) и требуется одна общая база, объединение кластеров — лишь малая часть работы. Основной объём займёт перенос справочников, документов и остатков с контролем дублей.

Маршрут решения

Как выбрать действие

Базы разные, нужно просто администрировать их в одном кластереПеренесите регистрацию баз через консоль кластеров — данные в СУБД не трогайте

Две базы с одинаковой конфигурацией нужно слить в одну учётную системуИспользуйте типовую синхронизацию данных или конвертацию данных 2.1/3.0

Нужно объединить два физических сервера в отказоустойчивый кластерДобавьте второй сервер как рабочий в существующий кластер через консоль администрирования

Подготовка: что проверить перед объединением

Любые операции с кластером начинайте с резервных копий. Сделайте бэкап всех баз средствами СУБД и дополнительно выгрузите критичные базы в dt-файлы. Перенос регистрации сам по себе данные не затрагивает, но при ошибках в настройках или несовпадении версий платформы последствия могут быть серьёзными.

Проверьте версии платформы 1С:Предприятие на обоих серверах. Рабочий сервер, добавляемый в кластер, должен иметь ту же версию платформы, что и центральный сервер кластера. Также убедитесь, что агенты серверов (ragent) доступны по сети: по умолчанию используются порты 1540 (агент), 1541 (менеджер кластера) и диапазон 1560–1591 (рабочие процессы).

Составьте список информационных баз в исходном кластере: имена баз, серверы СУБД, типы СУБД, блокировки регламентных заданий. Этот список понадобится для переноса и последующей сверки.

Перенос информационных баз из одного кластера в другой

Откройте консоль администрирования серверов 1С и подключитесь к обоим кластерам. В исходном кластере найдите нужную информационную базу, откройте её свойства и зафиксируйте параметры: имя базы на сервере СУБД, сервер баз данных, тип СУБД, имя пользователя СУБД.

В целевом кластере создайте новую информационную базу, но вместо создания новой базы данных укажите параметры существующей — ту же СУБД, тот же сервер и то же имя базы данных. Платформа зарегистрирует существующую базу в новом кластере без изменения данных. После регистрации проверьте подключение через конфигуратор или тонкий клиент.

Когда база работает в новом кластере, удалите её регистрацию из старого. В диалоге удаления обязательно выберите вариант без удаления базы данных в СУБД. После переноса всех баз и проверки работы пользователей старый кластер можно остановить и вывести сервер из эксплуатации.

1. 1
   Сделайте резервную копию базы средствами СУБД
2. 2
   Запишите параметры базы из свойств в исходном кластере
3. 3
   Заблокируйте сеансы и регламентные задания в исходной базе
4. 4
   Создайте регистрацию базы в целевом кластере с указанием существующей базы данных
5. 5
   Проверьте вход в базу через тонкий клиент и конфигуратор
6. 6
   Удалите регистрацию из исходного кластера без удаления данных в СУБД
7. 7
   Проверьте работу регламентных заданий и фоновых процессов в новом кластере

Объединение двух серверов в один кластер

Если цель — отказоустойчивость или распределение нагрузки, второй сервер добавляется в существующий кластер как рабочий. На втором сервере установите ту же версию платформы 1С:Предприятие и запустите службу агента сервера.

В консоли администрирования откройте целевой кластер, в ветке «Рабочие серверы» добавьте новый сервер по имени или IP-адресу. После добавления настройте требования назначения функциональности: укажите, какие сервисы и рабочие процессы могут выполняться на каждом сервере. Без явных требований кластер распределяет нагрузку автоматически, что не всегда оптимально.

Обратите внимание на реестр кластера: файл 1CV8Clst.lst и каталог srvinfo хранятся на центральном сервере. При добавлении второго сервера центральным остаётся первый; для повышения отказоустойчивости настройте резервирование кластеров — регистрацию одного кластера на нескольких серверах.

Объединение данных двух информационных баз

Если требуется слить данные двух баз с одинаковой конфигурацией, штатный путь — синхронизация данных через план обмена. В типовых конфигурациях («Бухгалтерия предприятия», «Зарплата и управление персоналом», «Управление торговлей») есть встроенные механизмы обмена, которые настраиваются в разделе администрирования.

Для нестандартных случаев используется «Конвертация данных 2.1» или «Конвертация данных 3.0»: разрабатываются правила обмена, по которым справочники и документы переносятся из базы-источника в базу-приёмник. Это проектная задача: потребуется сопоставление справочников, контроль дублей по ключевым полям и перенос остатков на дату свёртки.

Практический порядок такой: сначала переносят нормативно-справочную информацию и сверяют её, затем вводят начальные остатки на дату перехода, и только после этого переносят документы текущего периода. Попытка перенести всё разом почти всегда приводит к расхождениям в остатках и дублям контрагентов и номенклатуры.

Проверка результата после объединения

После переноса баз проверьте список баз в целевом кластере и сравните его с исходным списком, составленным на этапе подготовки. Войдите в каждую базу тонким клиентом, убедитесь, что открываются журналы документов и отчёты, выполните тестовый запуск регламентного задания.

Для объединённого кластера из двух серверов проверьте распределение рабочих процессов rphost по серверам и корректность применения лицензий — программные лицензии привязаны к серверу, и при переносе рабочих процессов может потребоваться повторная активация.

При объединении данных контрольными точками служат: оборотно-сальдовая ведомость на дату свёртки (должна совпадать с суммой данных двух исходных баз), отчёт по остаткам склада, отсутствие дублей в справочниках контрагентов и номенклатуры.

Контрольные точки

Как проверить результат

Список баз в целевом кластере

Норма

Все базы из исходного списка зарегистрированы и доступны

Тревожный признак

База отсутствует или выдаёт ошибку подключения к СУБД

Рабочие процессы rphost

Норма

Процессы распределены по серверам согласно требованиям

Тревожный признак

Все процессы висят на одном сервере или не стартуют

Остатки после объединения данных

Норма

ОСВ на дату свёртки сходится с суммой исходных баз

Тревожный признак

Расхождения по счетам, задвоенные остатки

Регламентные задания

Норма

Задания выполняются в новом кластере по расписанию

Тревожный признак

Задания заблокированы или дублируются

Ограничения и когда лучше привлечь специалиста

Самостоятельный перенос регистрации баз между кластерами — безопасная операция при наличии резервных копий и внимательности с флажками удаления. Но есть ситуации, где риски заметно выше: кластеры с большим числом активных пользователей, интеграции через веб-сервисы, привязка программных лицензий к конкретному оборудованию, использование СУБД с репликацией.

Объединение данных двух рабочих баз почти всегда требует участия специалиста по 1С: нужно разрабатывать или адаптировать правила обмена, решать конфликты дублей и организовывать параллельную работу на период перехода. Ошибки здесь ведут к искажению учётных данных, восстановление которых обойдётся дороже самого проекта.

Частые вопросы

Можно ли объединить кластеры с разными версиями платформы 1С?

Нет, в один кластер должны входить серверы с одной и той же версией платформы. Если версии различаются, сначала обновите платформу на отстающем сервере, проверьте совместимость конфигураций и только потом добавляйте сервер в кластер.

Что происходит с лицензиями при объединении серверов в кластер?

Программные лицензии привязываются к аппаратным параметрам конкретного сервера. При добавлении нового сервера в кластер для него может потребоваться отдельный комплект лицензий или перенос существующих с повторной активацией. Аппаратные ключи HASP работают в пределах сервера, где установлены.

Можно ли объединить две базы с разными конфигурациями?

Напрямую — нет. Нужно либо привести конфигурации к одной (например, перейти обе организации на одну типовую), либо использовать конвертацию данных с правилами сопоставления объектов разных конфигураций. Второй путь трудоёмок и требует разработки правил обмена.

Нужно ли останавливать работу пользователей при переносе базы в другой кластер?

Да, на время переноса сеансы следует завершить и заблокировать новые подключения. Сама операция регистрации занимает минуты, но без блокировки пользователи могут продолжить работу в старом кластере и потерять изменения после переключения.

Как не потерять данные при удалении базы из старого кластера?

В диалоге удаления информационной базы платформа предлагает три варианта: удалить базу данных в СУБД, очистить или оставить без изменений. Выбирайте вариант без удаления данных в СУБД. Перед удалением убедитесь, что база уже зарегистрирована и работает в новом кластере, а резервная копия существует и проверена восстановлением.