Как перенести базы и серверы в один кластер 1С:Предприятия 8.3

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

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

Когда объединение кластеров 1С оправдано, а когда нет

Объединять имеет смысл, если выгода понятна в цифрах. Типичные поводы:

• 🖥️ Сокращение серверов. Второй сервер загружен на 10–20 %, а лицензия и обслуживание стоят как за полноценный.
• 🔑 Лицензии. Клиентские лицензии на сервере выданы кластеру, где сидит половина пользователей, а второй кластер их не видит.
• 🛠️ Единое администрирование. Одни настройки рабочих процессов, один технологический журнал, одно место для блокировок и сеансов.
• 📈 Масштабирование. Нужно не убрать сервер, а объединить два сервера в один кластер, чтобы распределять нагрузку между ними.

Когда объединять не стоит:

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

Подготовка к объединению кластеров серверов

Подготовка занимает больше времени, чем сам перенос. Большинство сбоев после объединения — это пропущенный пункт отсюда.

Сверьте версии платформы

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

Если на сервере A стоит 8.3.24.1548, а на сервере B — 8.3.22.2208, то базы с B после переноса будут открываться клиентом 8.3.24. Проверьте заранее, что конфигурации этих баз поддерживают такую версию: минимальную версию платформы указывают в описании релиза конфигурации.

Составьте реестр баз

На каждом кластере выпишите:

1. Имя информационной базы в кластере.
2. Сервер СУБД, тип СУБД и имя базы данных в СУБД (это разные вещи: в кластере база может называться buh, а в SQL — buh_2019).
3. Пользователя СУБД, под которым кластер подключается к базе.
4. Флаги: блокировка регламентных заданий, блокировка начала сеансов, безопасный режим, профиль безопасности.
5. Кто и как подключается: список баз у пользователей, веб-публикации, обмены, внешние соединения.

Список баз с параметрами быстро выгружается через сервер администрирования:

rem запустить сервер администрирования, если он не работает как служба
ras cluster --daemon

rem получить идентификатор кластера
rac cluster list

rem краткий список баз кластера
rac infobase summary list --cluster=<uuid-кластера>

Если какие-то параметры баз не видны в кратком списке, откройте свойства каждой базы в консоли администрирования серверов 1С и перепишите их вручную.

Проверьте конфликты имён и лицензии

• 🔤 Имя базы уникально внутри кластера. Если в обоих кластерах есть buh, одну придётся зарегистрировать под другим именем, например buh_filial. Имя базы данных в СУБД при этом не меняется.
• 🔑 Программные лицензии привязаны к оборудованию компьютера, на котором активированы. Если сервер B выводится из эксплуатации, лицензии с него не переедут сами: их нужно активировать заново на сервере A. Для этого понадобятся пин-коды и данные регистрации из комплекта лицензии.
• 📄 Часть механизмов многосерверного кластера (уровень отказоустойчивости, требования назначения функциональности) рассчитана на серверную лицензию КОРП. Если планируете распределять нагрузку между серверами, сверьте тип серверной лицензии заранее.

Способы объединить кластеры 1С: какой выбрать

Выбор метода зависит от того, переезжают ли сами данные.

Пошаговое объединение кластеров через перерегистрацию и резервные копии

Основной сценарий: кластер на сервере B упраздняется, все его базы переходят в кластер на сервере A. Переносите базы по одной, начиная с наименее критичной.

Шаг 1. Остановите работу в базе на старом кластере

1. Предупредите пользователей о времени работ. Лучше вечер или выходной.
2. В консоли кластера B откройте свойства базы, включите «Блокировка начала сеансов включена» и «Блокировка регламентных заданий включена». Задайте сообщение для пользователей.
3. Дождитесь, пока пользователи выйдут. Оставшиеся сеансы завершите в разделе «Сеансы» базы.

Шаг 2. Сделайте резервную копию

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

Для MS SQL Server:

BACKUP DATABASE [buh_2019]
TO DISK = N'D:\Backup\buh_2019_before_merge.bak'
WITH COPY_ONLY, COMPRESSION, CHECKSUM;

COPY_ONLY не ломает цепочку ваших штатных резервных копий. Для PostgreSQL:

pg_dump -U postgres -Fc -f /backup/buh_2019_before_merge.dump buh_2019

Шаг 3. Если меняется сервер СУБД — восстановите базу

Восстановите копию на новом сервере СУБД под тем же или новым именем. Для MS SQL Server используйте RESTORE DATABASE ... WITH MOVE, чтобы разложить файлы данных и журнала по дискам нового сервера. Для PostgreSQL создайте пустую базу и выполните pg_restore -d <имя_базы> <файл>.

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

Шаг 4. Зарегистрируйте базу в кластере A

1. В консоли администрирования откройте кластер A → «Информационные базы» → контекстное меню → «Создать» → «Информационная база».
2. Укажите имя базы в кластере, сервер СУБД, тип СУБД, имя базы данных и пользователя СУБД.
3. Не устанавливайте флажок «Создать базу данных в случае её отсутствия» — база уже существует.
4. Задайте ту же блокировку регламентных заданий, что стоит сейчас, и снимите её только после проверки.

Если база переезжает из файлового варианта или с другого типа СУБД, создайте пустую базу так же, но с созданием базы данных, затем откройте её в Конфигураторе и загрузите .dt через меню Администрирование → Загрузить информационную базу.

Шаг 5. Переключите пользователей

• Поправьте строку подключения в списке баз: Srvr="A";Ref="buh"; вместо Srvr="B";Ref="buh";.
• Если списки баз раздаются централизованно через общий файл списка (.v8i, подключённый в 1CEStart.cfg параметром CommonInfoBases), достаточно поправить его один раз.
• Перенастройте веб-публикации: в файле default.vrd строка подключения указана в атрибуте ib.
• Не забудьте обмены, внешние соединения COM и скрипты резервного копирования, где указан старый сервер.

Шаг 6. Уберите регистрацию на старом кластере

Когда база проверена в кластере A, удалите её регистрацию в кластере B. В окне удаления консоль спрашивает, что сделать с базой данных: выберите вариант без удаления базы данных.

Ошибки при объединении кластеров 1С, которые портят данные

Эти ошибки не видны сразу, поэтому опасны.

• 🔁 Работа через два кластера одновременно. Управляемые блокировки 1С ведёт менеджер кластера. Если часть пользователей зашла в базу через кластер A, а часть через B, кластеры не знают о блокировках друг друга. Итог — нарушение целостности остатков и последовательностей. Держите блокировку начала сеансов на старом кластере до удаления регистрации.
• ⏰ Двойные регламентные задания. База зарегистрирована в двух кластерах без блокировки регламентных заданий — каждый кластер запускает обмены, загрузку курсов и закрытие операций. Отсюда задвоенные документы обмена и ошибки «объект уже изменён».
• 🔐 Разные учётные записи службы. Служба агента на A работает от другого пользователя, чем на B. Если базы используют сетевые каталоги, внешние компоненты или файлы обмена, у нового пользователя службы не окажется прав.
• 🗂️ Каталоги обмена с путём к старому серверу. Узлы обмена с путями вида \\B\exchange продолжают работать, пока сервер B включён, и молча ломаются после его выключения.

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

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

1. Подключение. Откройте базу в режиме 1С:Предприятие с рабочего места пользователя, не с сервера.
2. Сеанс в консоли. В кластере A в разделе «Сеансы» базы должен появиться ваш сеанс. Если сеанса нет, а база открылась — вы попали в старый кластер.
3. Лицензия. В свойствах сеанса проверьте, откуда получена лицензия. Для серверной выдачи лицензий это работает так: rac session list --cluster=<uuid> --licenses.
4. Проверка данных. Сформируйте пару отчётов, которые бухгалтер знает «в лицо»: оборотно-сальдовую ведомость за прошлый месяц, остатки по складу на дату. Цифры должны совпасть с тем, что было до переноса.
5. Регламентные задания. Снимите блокировку и посмотрите в журнале регистрации, что задания стартуют один раз и без ошибок.
6. Обмены и веб-сервисы. Запустите обмен вручную, откройте веб-публикацию в браузере.

Настройка кластера после объединения серверов

После переноса на кластер ложится больше баз и пользователей. Параметры, которые стоит пересмотреть:

Если второй сервер остаётся в работе, добавьте его в кластер A: в консоли откройте кластер → «Рабочие серверы» → «Создать» → «Рабочий сервер», укажите имя компьютера, порт агента (по умолчанию 1540) и диапазон портов рабочих процессов. Сборка платформы на обоих серверах должна совпадать. Затем задайте требования назначения функциональности, если хотите закрепить конкретные базы или фоновые задания за конкретным сервером.

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

Если стандартный перенос не подходит

Бывают случаи, когда схема «перерегистрировал — проверил» не работает .

Разные сборки платформы, и одну базу нельзя обновить. Не переводите базу на сборку, которую конфигурация не поддерживает. На одном сервере можно запустить агент второй сборки на других портах (например, 2540–2541 и свой диапазон рабочих процессов). Это уже не объединение, а соседство, но оно позволяет убрать лишнюю машину.

База не восстанавливается из бэкапа СУБД. Частые причины — разная сортировка (collation) серверов MS SQL или разные сборки PostgreSQL для 1С. Тогда переносите через .dt: Конфигуратор сам приведёт данные к целевой СУБД.

Выгрузка .dt падает на большой базе. Проверьте свободное место во временном каталоге пользователя, под которым запущен Конфигуратор, и в каталоге выгрузки. Выгрузку запускайте на самом сервере, а не по сети.

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

Пользователи всё ещё попадают на старый сервер. У них остался локальный список баз со старой строкой подключения. Удалите старую запись или раздайте общий список заново. Если сомневаетесь, что клиент подхватил изменения, запустите его с ключом /ClearCache.

Частые вопросы об объединении кластеров 1С