← На главную

Разберем классическую задачу оптимизации инфраструктуры: перенос службы кластера 1С:Предприятие на тот же физический или виртуальный сервер, где развернута СУБД (например, Microsoft SQL Server). В исходной схеме сервер 1С часто оказывается вынесен на терминальный сервер вместе с пользователями или на отдельную слабую машину, что порождает паразитный сетевой трафик между 1С и SQL. Рассмотрим по шагам, как грамотно выполнить миграцию, избежать типичных ошибок с регламентными заданиями и лицензиями, а также минимизировать вмешательство в работу пользователей.

Шаг 0. Подготовка и обязательное резервное копирование

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

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

Шаг 1. Развертывание платформы и решение вопроса лицензирования

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

1. Программные лицензии: они жестко привязаны к характеристикам «железа» (процессор, материнская плата, сетевые карты, BIOS, операционная система). Просто скопировать файлы лицензий с расширением .lic со старого сервера на новый нельзя — они станут недействительными. Подготовим резервный пинкод и выполним повторную активацию на новом сервере, строго контролируя точное совпадение регистрационных данных организации.
2. Аппаратные USB-ключи (HASP): переставим USB-ключ в новый сервер, установим драйвер Sentinel HASP и при необходимости раздачи клиентских лицензий запустим службу HASP License Manager (nhsrv.exe).

Шаг 2. Перенос баз и правильная обработка регламентных заданий

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

Разберем правильный порядок действий:

1. На старом сервере 1С открываем консоль администрирования кластера (или используем утилиту rac).
2. В свойствах каждой информационной базы взводим флаг Блокировка начала сеансов включена, а также обязательный флаг Блокировка регламентных заданий включена.
3. В поле сообщения об ошибке блокировки сеансов вводим понятный для пользователей текст, например: «База перенесена на новый сервер. Обратитесь к администратору для обновления путей подключения». Это избавит пользователей от системных ошибок и сразу объяснит ситуацию, если кто-то попытается зайти по старой ссылке.
4. Подключаем базы данных к новому кластеру 1С через консоль администрирования. При регистрации базы на новом сервере сразу выставляем флаг блокировки регламентных заданий, чтобы они не стартовали до полной проверки работоспособности системы администратором.
5. После тестового входа администратора и успешной проверки снимаем блокировку сеансов и регламентных заданий на новом сервере. Старую службу ragent можно полностью остановить.

Обратим внимание на каталог данных кластера srvinfo: не следует просто копировать его целиком со старого сервера на новый. Файлы реестра кластера (1CV8Clst.lst, 1cv8wsrv.lst) содержат жесткую привязку к старым сетевым именам и портам хоста, что часто приводит к падению службы при запуске на новом месте. Надежнее зарегистрировать информационные базы в новом кластере заново.

Шаг 3. Оптимизация совместной работы 1С и СУБД на одном сервере

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

1. Ограничение оперативной памяти СУБД: Microsoft SQL Server по умолчанию забирает под свой кэш всю доступную оперативную память. Если не ограничить параметр Max Server Memory в свойствах экземпляра SQL Server, рабочим процессам 1С (rphost) не хватит памяти, что вызовет их падение и выброс пользователей. Рассчитаем предел так, чтобы гарантированно оставить нужный объем памяти для ОС и процессов 1С.
2. Использование протокола Shared Memory: при локальном размещении 1С и SQL обмен между ними может осуществляться через общую память, минуя стек сетевых протоколов TCP/IP. Для этого в SQL Server Configuration Manager проверяем активность протокола Shared Memory, а в консоли 1С при создании базы в поле «Сервер баз данных» указываем localhost, (local) или сетевое имя текущего сервера. Это дает прирост скорости взаимодействия СУБД и сервера приложений.

Шаг 4. Перенаправление пользователей на новый сервер

Разберем способы обновления путей подключения к информационной базе у пользователей:

1. Использование DNS-псевдонима (CNAME): идеальный вариант, при котором пользователям вообще не требуется менять ярлыки. Если старый сервер выводится из эксплуатации, создаем в корпоративном DNS запись CNAME со старым именем сервера, указывающую на имя нового сервера. При совпадении сетевых портов кластера клиенты продолжат подключаться по прежним ссылкам без модификации файлов баз.
2. Скриптовое обновление файла со списком баз: если перенаправление через DNS невозможно, автоматизируем замену старого имени сервера на новое в файле ibses.v8i через групповые политики (GPO) или скрипты автозагрузки.
3. Плавная миграция через добавление рабочего сервера: если требуется исключить даже кратковременный простой, новый сервер предварительно добавляется в существующий кластер как дополнительный рабочий сервер. Затем центральные сервисы и рабочие процессы плавно переводятся на новый хост, а старый сервер выводится из состава кластера.

Соблюдение этой последовательности действий гарантирует безопасный перенос баз данных, сохранение целостности регламентных процедур и стабильную работу системы на новом оборудовании.