Как установить второй сервер 1С:Предприятие (лицензия МИНИ) на одном физическом компьютере для тестового контура

При развитии ИТ-инфраструктуры часто возникает задача развертывания тестового контура для обкатки обновлений, разработки или миграции на другие системы управления базами данных (СУБД). Типичная ситуация: на физическом сервере уже работает промышленная база под управлением 1С:Предприятие 8.3 (Мини-сервер) и PostgreSQL. Появляется необходимость поднять второй экземпляр сервера для работы с MS SQL Server Developer Edition. В этой статье мы подробно разберем, как реализовать такую схему, учитывая жесткие ограничения лицензии «МИНИ».

Особенности лицензирования «Сервера МИНИ»

Прежде чем приступать к техническим работам, проанализируем лицензионные ограничения. Лицензия «1С:Сервер МИНИ на 5 подключений» существенно отличается от версий PROF и CORP. Основные моменты, которые нам необходимо учитывать:

1. Ограничение кластера: В рамках одного кластера может быть только один рабочий сервер. Вы не сможете объединить две лицензии «МИНИ» для масштабирования производительности одного кластера.
2. Количество сеансов: Лицензия жестко ограничивает количество сеансов (не более 5) плюс один сеанс в режиме конфигуратора.
3. Программная активация: Поскольку это программная лицензия, она привязывается к параметрам железа (Hardware ID). При попытке активировать вторую аналогичную лицензию на той же операционной системе часто возникают конфликты, так как система защиты может «перепутать» ключи.

Шаг 1: Подготовка окружения и выбор стратегии

Рассмотрим два варианта реализации тестового контура. Первый — установка второй службы 1С на ту же операционную систему. Второй (рекомендуемый) — использование виртуализации.

Если мы выбираем установку на одну ОС, нам потребуется разнести службы по разным сетевым портам. По умолчанию сервер 1С использует порты 1540 (агент), 1541 (менеджер кластера) и диапазон 1560-1591 (рабочие процессы). Для тестового контура мы будем использовать, например, 1640, 1641 и 1660-1691 соответственно.

Шаг 2: Установка и настройка второй службы сервера 1С

Для создания второго экземпляра службы сервера 1С нам не нужно повторно запускать инсталлятор. Мы воспользуемся командной строкой и утилитой sc. Разберем по шагам создание новой службы:

1. Откроем командную строку от имени администратора.
2. Выполним команду для регистрации новой службы агента сервера. Обратите внимание на кавычки и пробелы после знаков равенства — это критически важно для корректной работы команды sc create.

sc create "1C:Enterprise 8.3 Server Test" binPath= "\"C:\Program Files\1cv8\8.3.XX.XXXX\bin\ragent.exe\" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d \"C:\Program Data\1C\1cv8_test\"" displayname= "1C:Enterprise 8.3 Server Test" depend= LanmanServer/Tcpip start= auto

В этой команде параметр -d указывает на отдельный каталог данных 1cv8_test. Это необходимо, чтобы настройки тестового кластера не пересекались с боевым. Создайте эту папку заранее и убедитесь, что у пользователя, от имени которого будет запускаться служба, есть права на запись в этот каталог.

Шаг 3: Настройка СУБД MS SQL Developer Edition

Поскольку наш тестовый контур будет работать на MS SQL Server Developer Edition, а основной — на PostgreSQL, важно минимизировать их конкуренцию за ресурсы сервера. Проанализируем ситуацию: обе СУБД крайне требовательны к оперативной памяти и дисковой подсистеме.

Выясним причину возможных тормозов: MS SQL по умолчанию настроен на захват максимально возможного объема ОЗУ. Если мы оставим настройки «как есть», SQL Server со временем вытеснит PostgreSQL из памяти, что приведет к деградации производительности боевой базы. Настроим лимиты:

1. Зайдем в SQL Server Management Studio (SSMS).
2. В свойствах сервера перейдем в раздел Memory.
3. Установим Maximum server memory в разумных пределах (например, если на сервере 32 ГБ, выделим под тестовый SQL не более 8-12 ГБ).

Аналогично стоит поступить с PostgreSQL, ограничив его параметры shared_buffers и effective_cache_size в файле конфигурации postgresql.conf.

Шаг 4: Активация второй лицензии Мини-сервера

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

Наиболее стабильный вариант — развернуть тестовый контур в виртуальной машине (используя Hyper-V, VMware или Proxmox). Это полностью изолирует Hardware ID. Если же виртуализация невозможна, при активации через Конфигуратор тестового сервера (запущенного на порту 1640) обязательно указывайте путь к новому файлу лицензии, чтобы он не перезаписал существующий.

Посмотрим на пример параметров запуска Конфигуратора для подключения к тестовому серверу:

1cv8.exe DESIGNER /S "ИмяСервера:1641\ИмяТестовойБазы"

Шаг 5: Перенос баз с PostgreSQL на MS SQL

Так как форматы хранения данных у PostgreSQL и MS SQL различаются, прямой перенос файлов невозможен. Мы будем использовать штатный механизм выгрузки и загрузки данных через файлы .dt.

1. В боевом контуре (на PostgreSQL) зайдем в Конфигуратор и выполним Администрирование -> Выгрузить информационную базу...
2. На тестовом сервере (на MS SQL) создадим пустую базу через консоль администрирования (не забываем указывать порт 1640).
3. Зайдем в Конфигуратор пустой тестовой базы и выполним Администрирование -> Загрузить информационную базу...

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

Резюме и рекомендации

Подводя итог, отметим, что совместное использование двух Мини-серверов на одном «железе» — задача выполнимая, но требующая аккуратности. Рассмотрим основные выводы:

• Изоляция: Если ресурсы позволяют, всегда выбирайте виртуализацию. Это снимет 90% проблем с лицензированием и конфликтами портов.
• Ресурсы: Жестко ограничивайте аппетиты СУБД по памяти. Дисковая подсистема станет «бутылочным горлышком», поэтому для тестового контура желательно использовать отдельные физические диски или SSD.
• Порты: Не забывайте открывать новые порты (1640, 1641 и т.д.) в брандмауэре Windows, иначе клиенты не смогут подключиться к тестовому серверу.

Таким образом, мы настроили полноценный тестовый контур, сохранив стабильность работы основной системы на PostgreSQL и обеспечив возможность тестирования на MS SQL.