Объединение кластеров 1С: подробное руководство с примерами и предупреждениями

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

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

Если вы планируете объединить кластеры в продуктивной среде — прочитайте статью до конца. Здесь нет общих советов: только конкретные команды, скриншоты логики процесса и предупреждения о "подводных камнях", которые не очевидны на первый взгляд.

1. Когда действительно нужно объединять кластеры 1С?

Прежде чем приступать к технической части, убедитесь, что объединение кластеров — это действительно необходимое решение, а не временное "лечение симптомов". Вот обоснованные причины для проведения процедуры:

• 🔄 Миграция на новое "железо". Старые серверы физически или морально устарели, а перенос баз по одной занимает слишком много времени.
• 📉 Оптимизация затрат. Сокращение количества серверов для уменьшения расходов на лицензии, электроэнергию или обслуживание.
• 🔗 Консолидация инфраструктуры. Объединение разрозненных кластеров после поглощения компании или реорганизации бизнес-процессов.
• 🛡️ Повышение отказоустойчивости. Переход на кластер с резервированием (например, с 1C:Enterprise 8.3 Server на Linux с PostgreSQL и репликацией).

А теперь — когда объединение кластеров НЕ нужно:

• ❌ Если проблема только в производительности отдельных баз — достаточно оптимизировать запросы или добавить ресурсы конкретному серверу.
• ❌ При временных сбоях в работе кластера (например, из-за сетевых проблем) — сначала устраните корневую причину.
• ❌ Если цель — просто "привести всё к единому виду" без объективных технических или бизнес-причин.

⚠️ Внимание: Объединение кластеров в 1С:Предприятии 8.3.18 и ниже имеет ограничения по работе с PostgreSQL в распределённой конфигурации. Если используете эту СУБД — проверьте совместимость версий сервера и клиента до начала процедуры.

2. Подготовка к объединению: чек-лист обязательных действий

На этом этапе 80% успеха зависит от тщательности подготовки. Пропуск даже одного пункта может привести к неработоспособности баз после объединения. Используйте наш чек-лист:

Создать резервные копии всех информационных баз (включая конфигурации и данные)|Проверить совместимость версий платформы 1С на исходных и целевом кластерах|Остановить все фоновые задания и регламентные операции|Уведомить пользователей о времени простоя системы|Проверить свободное место на дисках целевого сервера (минимум 150% от объёма переносимых данных)|Подготовить тестовое окружение для предварительного объединения (если возможно)|Сохранить текущие настройки кластера (особенно параметры ragent и rmngr)

-->

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

1. Обновите целевой кластер до версии, которая не ниже, чем на исходном.
2. Если версия целевого кластера выше — проверьте совместимость конфигураций баз данных с новой платформой (некоторые обработки могут перестать работать).
3. Для PostgreSQL убедитесь, что версия СУБД на целевом сервере поддерживается используемой версией 1С (актуальные требования смотрите в readme.txt дистрибутива платформы).

Также обязательно проверьте:

• 🔌 Сетевые настройки: целевой сервер должен быть доступен для всех клиентов, которые ранее работали с исходными кластерами.
• 🔐 Права доступа: учётная запись, под которой выполняется объединение, должна иметь права администратора на всех серверах 1С и СУБД.
• ⏱️ Время выполнения: для крупных баз (100+ ГБ) процесс может занять несколько часов — планируйте работу на период минимальной нагрузки.

3. Методы объединения кластеров: какой выбрать?

Существует три основных способа объединения кластеров 1С, каждый из которых подходит для разных сценариев. Выбор метода зависит от размера баз, версий платформы и требований к времени простоя.

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

⚠️ Внимание: Если вы объединяете кластеры с разными СУБД (например, с MS SQL на PostgreSQL), то ручной перенос через dt-файлы становится единственным рабочим методом. В этом случае обязательно протестируйте процесс на копии базы!

4. Пошаговая инструкция: объединение через резервные копии

Этот метод подразумевает полное копирование баз данных с исходных кластеров на целевой с последующим подключением пользователей. Следуйте инструкции строго по шагам:

Шаг 1. Создание резервных копий

На каждом исходном кластере выполните резервное копирование всех информационных баз. Для этого:

1. Откройте консоль администратора сервера 1С (1C:Enterprise Server Administration Console).
2. Выберите кластер и перейдите в раздел Информационные базы.
3. Для каждой базы выполните команду:

   ras cluster --cluster=TARGET_CLUSTER backup --infobase=IB_NAME --file=PATH_TO_BACKUP --user=ADMIN_USER --pwd=ADMIN_PASSWORD

   где:

   • TARGET_CLUSTER — имя целевого кластера;
   • IB_NAME — имя информационной базы;
   • PATH_TO_BACKUP — путь к файлу резервной копии (например, C:\Backups\base1.dt).

Для PostgreSQL вместо ras используйте утилиту pg_dump:

pg_dump -U postgres -F c -f backup.dump DB_NAME

Шаг 2. Перенос резервных копий на целевой сервер

Скопируйте все файлы резервных копий на целевой сервер. Для крупных баз (>20 ГБ) рекомендуется:

• 📦 Использовать сетевые диски или FTP для передачи.
• 🔒 Проверять контрольные суммы файлов (md5sum в Linux или CertUtil в Windows).
• ⏳ Если передача занимает >1 часа — разбивайте архивы на части.

Шаг 3. Восстановление баз на целевом кластере

Для восстановления используйте команду:

rac infobase --cluster=TARGET_CLUSTER restore --infobase=NEW_IB_NAME --file=PATH_TO_BACKUP --user=ADMIN_USER --pwd=ADMIN_PASSWORD

Где NEW_IB_NAME — новое имя базы на целевом кластере (может совпадать со старым).

Для PostgreSQL:

pg_restore -U postgres -d NEW_DB_NAME -C backup.dump

Шаг 4. Настройка подключений

После восстановления баз необходимо:

1. Обновить список опубликованных баз на целевом кластере:

   rac infobase --cluster=TARGET_CLUSTER publish --infobase=NEW_IB_NAME --name="Отображаемое имя" --dbms=SQL --db-server=DB_SERVER --db-name=DB_NAME --user=DB_USER --pwd=DB_PASSWORD

2. Проверить права доступа пользователей 1С к новым базам.
3. Обновить файлы 1CEStart.cfg на клиентских машинах (или использовать DNS-алиасы для плавного перехода).

💡

При восстановлении баз на целевом кластере не изменяйте идентификаторы информационных баз (IBID), если хотите сохранить историю изменений и ссылки в интеграциях с другими системами.

5. Типичные ошибки и как их избежать

Даже опытные администраторы допускают ошибки при объединении кластеров. Вот самые распространённые из них и способы их предотвращения:

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

  ⚠️ Внимание: Платформа 1С:Предприятие 8.3.19+ не поддерживает восстановление баз, созданных в 8.3.20+, на более ранние версии. Проверяйте совместимость до начала переноса!

• 🔴 Нехватка места на диске. При восстановлении базы временно требуется в 2-3 раза больше места, чем занимает резервная копия.
• 🔴 Потеря связей между базами. Если в конфигурации используются ВнешниеИсточникиДанных или ПланыОбмена, их настройки могут сбиться.
• 🔴 Проблемы с кодировкой. При переносе между Windows и Linux-серверами возможны искажения символов в данных.

Чтобы избежать большинства проблем, следуйте этим правилам:

• 🔹 Тестируйте процесс на копии базы перед работой с продуктивной средой.
• 🔹 Используйте журналирование всех действий (например, ведите лог команд в текстовом файле).
• 🔹 Проверяйте целостность данных после переноса с помощью тестовых отчётов.
• 🔹 Если используете PostgreSQL, убедитесь, что параметр shared_buffers на целевом сервере не меньше, чем на исходном.

Что делать, если база не восстановилась?

Если при восстановлении базы возникает ошибка типа "Недопустимый формат файла", проверьте:

1. Совместимость версий платформы (команда rac about).

2. Целостность резервной копии (сравните контрольные суммы исходного и скопированного файла).

3. Наличие свободного места на диске (минимально требуется 150% от размера базы).

4. Права доступа на папку с резервной копией (учётная запись 1С должна иметь права на чтение).

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

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

После завершения переноса не торопитесь открывать доступ пользователям. Сначала выполните полную диагностику:

1. Проверка подключения:

   - Откройте каждую базу в Конфигураторе и убедитесь, что она загружается без ошибок.

   - Выполните тестовое подключение из клиентского приложения 1С.

2. Тестирование данных:

   - Сравните количество документов в ключевых регистрах (например, Документ.РеализацияТоваровУслуг) до и после переноса.

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

3. Проверка интеграций:

   - Убедитесь, что работают ПланыОбмена с другими системами.

   - Протестируйте HTTP-сервисы и REST API, если они используются.

4. Мониторинг производительности:

   - Запустите Перфоманс Монитор (для Windows) или top (для Linux) и проверьте нагрузку на CPU и RAM.

   - Убедитесь, что время выполнения типовых операций (например, проведение документа) не увеличилось более чем на 20%.

Если всё в порядке — можно постепенно открывать доступ пользователям, начиная с тестовой группы. Рекомендуем первые 2-3 дня работать в режиме повышенного мониторинга, отслеживая журналы сервера 1С (C:\Program Files\1cv8\srvinfo\reg_1541\*.log).

💡

Для автоматической проверки целостности данных после переноса используйте обработку "ТестИБ.epf" из стандартной поставки 1С. Она сравнивает контрольные суммы метаданных и данных, выявляя скрытые ошибки.

7. Оптимизация кластера после объединения

Объединение кластеров — хороший повод оптимизировать производительность новой инфраструктуры. Вот что можно сделать:

• 🔧 Настройка пула соединений:

  - Для MS SQL: увеличьте параметр max worker threads до 512 (если на сервере >16 ядер).

  - Для PostgreSQL: оптимизируйте work_mem и maintenance_work_mem в postgresql.conf.

• 📊 Распределение нагрузки:

  - Разнесите базы по разным рабочим процессам (в настройках кластера 1С).

  - Для крупных баз (>50 ГБ) выделите отдельные rmngr-процессы.

• 🔄 Обновление конфигураций:

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

  - Обновите внешние обработки и отчёты, если они привязаны к старой инфраструктуре.

• 🛡️ Настройка резервного копирования:

  - Переконфигурируйте задачи резервного копирования с учётом нового расположения баз.

  - Настройте лог вращения для журналов сервера 1С (параметр LogFileSizeLimit в srvinfo.cfg).

Если после объединения наблюдается падение производительности, проверьте:

• 🔹 Сетевые задержки между клиентами и новым сервером (команда ping и tracert).
• 🔹 Фрагментацию индексов в СУБД (для MS SQL используйте ALTER INDEX REORGANIZE).
• 🔹 Настройки кэширования в 1С (параметр CacheSize в srvinfo.cfg).

8. Альтернативные сценарии: когда стандартные методы не работают

Иногда объединение кластеров стандартными способами невозможно. Рассмотрим нетипичные ситуации и их решения:

Сценарий 1: Перенос баз между разными СУБД

Если нужно перенести базу с MS SQL на PostgreSQL (или наоборот), используйте промежуточный формат DT:

1. Выгрузите базу в DT-файл на исходном кластере:

   Designer /DumpIB "C:\backup\base.dt" /N"Admin" /P"password" /Out"log.txt"

2. Создайте новую базу на целевом кластере с нужной СУБД.
3. Загрузите данные из DT-файла:

   Designer /RestoreIB "C:\backup\base.dt" /N"Admin" /P"password" /Out"log.txt"

Сценарий 2: Объединение кластеров с разными конфигурациями

Если базы на исходных кластерах имеют разные версии конфигурации, перед переносом:

1. Обновите конфигурации до единой версии на исходных кластерах.
2. Сравните объекты метаданных с помощью Конфигуратор → Сравнить конфигурации.
3. При необходимости выполните объединение конфигураций вручную.

Сценарий 3: Перенос только части данных

Если нужно перенести не всю базу, а только отдельные документы или справочники, используйте:

• 🔹 Выгрузку/загрузку данных через XML (обработка "ВыгрузкаЗагрузкаДанныхXML.epf").
• 🔹 Планы обмена (если базы остаются разделёнными, но нужно синхронизировать данные).
• 🔹 Внешние обработки для избирательного переноса (например, только документы за последний год).

⚠️ Внимание: При избирательном переносе данных всегда проверяйте ссылки между объектами. Например, если вы переносите документы РеализацияТоваровУслуг, но не переносите связанные элементы справочника Номенклатура, возникнут ошибки при открытии документов.

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

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

Технически да, но это требует сложной схемы с репликацией данных и временным "раздвоением" баз. Для большинства компаний проще запланировать окно технических работ на выходные или ночное время. Если простой критичен — рассмотрите вариант с постепенным переносом баз по одной, с перенаправлением пользователей через DNS или балансировщик нагрузки.

Что делать, если после объединения базы открываются очень медленно?

Причины могут быть разные:

• 🔹 Недостаточные ресурсы сервера (проверьте CPU и RAM через Диспетчер задач или htop).
• 🔹 Неоптимальные настройки СУБД (например, маленький shared_buffers в PostgreSQL).
• 🔹 Фрагментация данных (выполните REINDEX DATABASE для PostgreSQL или DBCC INDEXDEFRAG для MS SQL).
• 🔹 Сетевые задержки (проверьте ping между клиентами и сервером).

Начните с мониторинга производительности (утилиты PerfMon для Windows или vmstat для Linux).

Как перенести настройки кластера (пользователей, роли, права)?

Настройки кластера 1С (пользователи, роли, права доступа) не переносятся автоматически вместе с базами. Их нужно настраивать вручную на целевом кластере:

1. Экспортируйте список пользователей из исходного кластера:

   rac user --cluster=SOURCE_CLUSTER list --output=users.txt

2. Создайте пользователей на целевом кластере:

   rac user --cluster=TARGET_CLUSTER create --name=USER_NAME --pwd=PASSWORD

3. Назначьте права доступа к базам через Конфигуратор → Администрирование → Пользователи.

Для PostgreSQL не забудьте перенести роли базы данных:

pg_dumpall --roles-only -f roles.sql

Можно ли откатиться назад, если что-то пойдёт не так?

Да, если вы правильно подготовились:

• 🔹 Сохранили резервные копии исходных баз.
• 🔹 Зафиксировали настройки кластера (файлы srvinfo.cfg, conf.cfg).
• 🔹 Использовали тестовое окружение для проверки процедуры.

Для отката:

1. Остановите целевой кластер.
2. Восстановите базы из резервных копий на исходные серверы.
3. Верните старые настройки DNS или 1CEStart.cfg на клиентских машинах.

Если откат невозможен (например, исходные серверы уже выведены из эксплуатации), восстанавливайте данные из резервных копий на новом кластере.

Как объединить кластеры 1С, если они находятся в разных доменах Active Directory?

В этом случае необходимо:

1. Настроить доверительные отношения между доменами (если это возможно).
2. Использовать локальные учётные записи для подключения к кластеру 1С (вместо доменных).
3. Перенастроить аутентификацию пользователей в базах 1С на стандартную аутентификацию (вместо аутентификации Windows).
4. После переноса баз создать пользователей на целевом домене и назначить им права вручную.

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