Несколько версий сервера 1С на одном сервере: службы, порты и порядок настройки

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

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

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

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

Когда действительно нужны две версии сервера 1С

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

Отдельный экземпляр сервера может понадобиться в следующих ситуациях:

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

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

Как устроены два кластера на одном сервере

Каждый экземпляр серверного кластера запускается собственным процессом агента ragent. Агент создает и обслуживает менеджер кластера, рабочие процессы и служебные данные своего экземпляра.

Если на одном компьютере работают две версии, их необходимо развести по сетевым портам и каталогам.

                 Пользователи и администраторы
                            │
              ┌─────────────┴─────────────┐
              ▼                           ▼
       Кластер старой версии       Кластер новой версии
          8.3.xx.xxxx                8.3.yy.yyyy
              │                           │
        ragent: 1540                 ragent: 1640
        rmngr: 1541                  rmngr: 1641
      rphost: 1560–1591            rphost: 1660–1691
              │                           │
              ▼                           ▼
      Каталог данных A              Каталог данных B
              │                           │
              └─────────────┬─────────────┘
                            ▼
                       SQL Server
                    или PostgreSQL

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

Что проверить до установки второй версии

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

Версия действующей службы

В оснастке Windows «Службы» нужно открыть свойства службы сервера 1С и проверить строку запуска исполняемого файла.

Также службы можно найти в PowerShell:

Get-CimInstance Win32_Service |
    Where-Object {
        $_.PathName -match "ragent.exe"
    } |
    Select-Object Name, DisplayName, State, StartName, PathName

Команда показывает:

• системное имя службы;
• отображаемое имя;
• состояние;
• учетную запись запуска;
• полную командную строку;
• путь к версии ragent.exe;
• параметры портов и каталога данных.

Полученный вывод нужно сохранить до начала работ.

Зарегистрированные информационные базы

В консоли администрирования следует зафиксировать:

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

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

Свободные сетевые порты

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

Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress, LocalPort, OwningProcess

Для проверки конкретного диапазона:

Get-NetTCPConnection -State Listen |
    Where-Object {
        $_.LocalPort -ge 1600 -and $_.LocalPort -le 1700
    } |
    Sort-Object LocalPort

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

Резервные копии

До установки необходимо подготовить:

• проверенные резервные копии информационных баз;
• backup или снимок VPS перед изменением;
• копию параметров существующей службы;
• копию каталога служебных данных кластера;
• список установленных версий платформы;
• план отката;
• доступ к консоли сервера вне RDP, если она предусмотрена провайдером.

Как установить вторую версию платформы

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

Выбор компонентов

Для нового экземпляра обычно нужны:

• сервер «1С:Предприятия»;
• модули администрирования сервера;
• RAS и RAC, если используется командное администрирование;
• клиентские компоненты — при необходимости локального тестирования;
• драйвер защиты — только в соответствии с используемой схемой лицензирования.

После установки нужно убедиться, что новая версия появилась в отдельном каталоге, например:

C:\Program Files\1cv8\8.3.yy.yyyy\bin\

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

Почему нельзя использовать одинаковое имя службы

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

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

1C_Server_8_3_xx
1C_Server_8_3_yy

Отображаемое имя также желательно дополнить точной версией и портом агента. Это уменьшает риск остановки не той службы во время обновления.

Разделение каталогов служебных данных

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

Пример структуры:

D:\1C\ClusterData\
├── 8.3.xx\
└── 8.3.yy\

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

Регистрация службы

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

Перед выполнением команды нужно определить:

• полный путь к ragent.exe новой версии;
• системное имя службы;
• отображаемое имя;
• учетную запись и пароль службы;
• порт агента;
• основной порт кластера;
• диапазон рабочих процессов;
• каталог служебных данных;
• режим автоматического запуска.

Не следует копировать команду регистрации из случайной инструкции без сопоставления с документацией установленной версии. Набор параметров и расположение компонентов могут отличаться.

Как развести сетевые порты

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

Порт агента

Порт агента используется для первичного обращения к центральному серверу. Для стандартного экземпляра обычно применяется 1540.

Для второго экземпляра можно выбрать другой свободный порт, например 1640.

Основной порт кластера

Менеджер кластера также должен иметь отдельный порт. Если первый экземпляр использует 1541, для второго можно назначить 1641.

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

Диапазон рабочих процессов

Рабочие процессы rphost используют диапазон портов. Для двух экземпляров диапазоны не должны пересекаться.

Пример:

• старый кластер — 1560–1591;
• новый кластер — 1660–1691.

Размер диапазона следует выбирать с учетом предполагаемого количества рабочих процессов.

Порт RAS

RAS используется для удаленного администрирования через утилиту rac. Если одновременно запускаются два экземпляра RAS, каждому нужен собственный порт.

Например:

• RAS старой версии — 1545;
• RAS новой версии — 1645.

Кроме того, RAS должен подключаться к правильному агенту соответствующего кластера.

       rac старой версии
              │
              ▼
        RAS 1545
              │
              ▼
       ragent 1540

       rac новой версии
              │
              ▼
        RAS 1645
              │
              ▼
       ragent 1640

Правила Windows Firewall

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

Перед изменением полезно проверить существующие правила:

Get-NetFirewallRule |
    Where-Object {
        $_.DisplayName -match "1C|1С"
    } |
    Select-Object DisplayName, Enabled, Direction, Action

Внутри доверенной сети могут потребоваться:

• порт агента нового кластера;
• основной порт кластера;
• диапазон рабочих процессов;
• порт RAS только для административных узлов;
• соединение с сервером СУБД.

Административные порты и порты рабочих процессов не следует публиковать непосредственно в интернет.

Как проверить запуск второго экземпляра

После регистрации новой службы не нужно сразу переносить рабочие базы. Сначала проверяется сам экземпляр сервера.

Состояние служб

В PowerShell:

Get-CimInstance Win32_Service |
    Where-Object {
        $_.PathName -match "ragent.exe"
    } |
    Select-Object Name, State, StartName, PathName

Нужно убедиться, что:

• обе службы находятся в состоянии Running;
• каждая запускается из нужной версии;
• параметры портов различаются;
• каталоги данных не совпадают;
• используются ожидаемые учетные записи.

Прослушиваемые порты

Проверка выбранных портов:

Get-NetTCPConnection -State Listen |
    Where-Object {
        $_.LocalPort -in 1540,1541,1640,1641,1545,1645
    } |
    Sort-Object LocalPort

Рабочие процессы появляются после запуска кластера и возникновения соответствующей нагрузки. Поэтому отсутствие всего диапазона в состоянии Listen не всегда означает ошибку.

Процессы и версии файлов

Запущенные процессы можно сопоставить с исполняемыми файлами:

Get-CimInstance Win32_Process |
    Where-Object {
        $_.Name -match "ragent|rmngr|rphost|ras"
    } |
    Select-Object ProcessId, Name, ExecutablePath, CommandLine

Это позволяет увидеть, из какого каталога запущен каждый компонент и с какими параметрами.

Подключение консоли администрирования

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

SERVER01:1540 — рабочий кластер 8.3.xx
SERVER01:1640 — новый кластер 8.3.yy

После подключения проверяется, что консоль показывает два независимых экземпляра, а их списки информационных баз не смешиваются.

Как перенести информационную базу на новую версию

Перенос лучше выполнять по одной базе. Это позволяет проверить совместимость конфигурации и быстро локализовать проблему.

Подготовка тестовой копии

До переноса рабочей базы следует:

• создать актуальную резервную копию;
• развернуть тестовую копию в СУБД;
• зарегистрировать ее в новом кластере;
• запустить под новой платформой;
• проверить обновление структуры;
• протестировать основные операции;
• проверить фоновые задания;
• проверить внешние компоненты и драйверы;
• проверить лицензирование;
• проверить интеграции.

Регистрация базы в новом кластере

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

Переключение рабочей базы

Порядок переключения может выглядеть так:

1. Согласовать технологическое окно.
2. Завершить пользовательские сеансы.
3. Остановить регламентные и фоновые задания.
4. Создать финальную резервную копию.
5. Заблокировать вход через старый кластер.
6. Зарегистрировать или активировать базу в новом кластере.
7. Обновить строку подключения пользователей.
8. Выполнить первый запуск под новой версией.
9. Проверить фоновые задания и интеграции.
10. Разрешить вход ограниченной группе.
11. После проверки вернуть обычный режим работы.

В строке клиентского подключения указывается адрес нового кластера с его основным портом, если используется нестандартное значение.

Что проверить после переноса

Основные риски параллельной эксплуатации

База зарегистрирована в двух кластерах

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

Для предотвращения ошибки нужно:

• закрыть доступ к старой регистрации;
• обновить списки баз на рабочих местах;
• проверить ярлыки и RDP-профили;
• проверить публикации веб-клиента;
• проверить задания автоматического запуска;
• зафиксировать фактический порт нового кластера.

Фоновые задания запускаются дважды

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

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

Используется неправильная консоль или RAS

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

Для административных скриптов рекомендуется указывать полный путь к исполняемому файлу, а не полагаться на переменную PATH.

Общие каталоги и права службы

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

• к каталогу данных кластера;
• к временным каталогам;
• к сетевым ресурсам;
• к файлам внешних компонент;
• к сертификатам;
• к каталогу технологического журнала;
• к серверу СУБД.

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

Нехватка ресурсов

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

Во время параллельной эксплуатации нужно контролировать:

• потребление памяти процессами rphost;
• загрузку процессора;
• дисковую очередь;
• число рабочих процессов;
• фоновые задания;
• подключения к СУБД;
• свободное место;
• время выполнения основных операций.

Как удалить старую версию после миграции

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

Контрольный список перед удалением

• Все рабочие базы перенесены на новый кластер.
• В старом кластере нет активных сеансов.
• Фоновые задания выполняются только в новом экземпляре.
• Обновлены клиентские строки подключения.
• Обновлены веб-публикации.
• Обновлены административные скрипты.
• RAS и RAC используют правильную версию.
• Проверены внешние компоненты и интеграции.
• Создана финальная резервная копия.
• Сохранены параметры старой службы.
• Прошел согласованный период наблюдения.

Остановка старой службы

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

Проверка служб:

Get-CimInstance Win32_Service |
    Where-Object {
        $_.PathName -match "ragent.exe"
    } |
    Select-Object Name, State, StartMode, PathName

Старый экземпляр лучше оставить остановленным на короткий контрольный период, а не удалять немедленно. Это упрощает возврат при обнаружении пропущенной зависимости.

Удаление службы и платформы

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

1. Отменяется регистрация старой службы.
2. Удаляются или архивируются старые правила firewall.
3. Удаляется ненужный экземпляр RAS.
4. Платформа удаляется штатным установщиком Windows.
5. Проверяется, не затронуты ли общие компоненты.
6. Каталог данных кластера архивируется на согласованный срок.
7. Обновляется техническая документация.

Практический чек-лист администратора

• Зафиксирована версия действующего сервера 1С.
• Сохранена командная строка существующей службы.
• Созданы резервные копии информационных баз.
• Сохранены параметры и служебные данные старого кластера.
• Выбраны уникальные имена служб.
• Назначены непересекающиеся сетевые порты.
• Созданы отдельные каталоги данных кластера.
• Проверены права учетных записей служб.
• Обновлены правила Windows Firewall.
• Проверено, из какой версии запускаются процессы.
• Оба кластера отдельно добавлены в консоль администрирования.
• Тестовая копия базы проверена на новой платформе.
• Рабочие базы переносятся по одной.
• Исключена одновременная работа одной базы в двух кластерах.
• Проверены фоновые задания и интеграции.
• Старая служба удаляется только после контрольного периода.

Заключение

Несколько версий сервера 1С могут временно работать на одном Windows Server, если каждый экземпляр кластера настроен независимо. Для этого используются отдельные службы, непересекающиеся порты, собственные каталоги данных и подходящие версии инструментов администрирования.

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

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

Что почитать дальше

Для подготовки обновления и проверки серверной инфраструктуры 1С будут полезны следующие материалы:

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

Когда стоит обратиться к специалистам

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

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

Кратко

• На одном компьютере можно установить несколько версий платформы 1С.
• Для одновременной работы серверных версий нужны отдельные экземпляры кластера.
• Каждый экземпляр должен иметь уникальное имя службы.
• Порты агента, менеджера, RAS и рабочих процессов не должны пересекаться.
• Каталоги служебных данных кластеров необходимо разделить.
• Одну базу нельзя одновременно использовать через два кластера.
• Перенос следует начинать с тестовой копии и выполнять по одной базе.
• Старая версия удаляется только после проверки всех зависимостей.