При администрировании инфраструктуры 1С:Предприятие часто возникает соблазн объединить имеющиеся серверные мощности в единую структуру для упрощения управления или обеспечения отказоустойчивости. Однако, когда речь заходит о серверах, работающих на разных релизах платформы (например, один на 8.3.12, а другой на актуальном 8.3.25), мы сталкиваемся с жесткими архитектурными ограничениями системы. Давайте разберем подробно, почему такая конфигурация невозможна и как правильно организовать работу нескольких версий платформы на одном или разных серверах.
Сразу ответим на главный вопрос: объединить серверы разных релизов в один кластер технически невозможно. Для функционирования кластера 1С требуется не просто совпадение мажорной версии (8.3), но и полное идентичное соответствие номера сборки (build). Если вы попытаетесь добавить сервер с версией 8.3.22.1709 в кластер, где центральный сервер работает на версии 8.3.22.1750, система выдаст ошибку несоответствия версий, и рабочие процессы не будут запущены.
Проанализируем основные причины, по которым разработчики платформы установили такие жесткие рамки:
srvinfo. Формат сериализации этих данных часто меняется между релизами. Если бы серверы разных версий одновременно обратились к этим файлам, это привело бы к моментальной порче структуры данных и полной неработоспособности кластера.Рассмотрим ситуацию, когда администратор хочет объединить серверы 8.3.12 и 8.3.25 ради отказоустойчивости. В понимании 1С отказоустойчивость подразумевает, что если один сервер "падает", пользователи продолжают работу на другом. Но пользователи 1С подключаются к базе с помощью клиентского приложения определенной версии.
Выясним причину конфликта на стороне клиента: если база запущена на кластере с версией 8.3.25, то и клиент (толстый или тонкий) обязан быть версии 8.3.25. Если этот кластер внезапно "переключится" на сервер 8.3.12, клиентское приложение не сможет установить соединение из-за критического несоответствия версий. Таким образом, сама идея отказоустойчивости при разных релизах теряет смысл.
Если перед нами стоит задача использовать возможности старого релиза для одних баз и нового — для других, мы должны использовать метод параллельной установки. Рассмотрим, как это реализовать по шагам.
Для того чтобы два разных релиза 1С работали на одном физическом или виртуальном сервере, нам необходимо разнести их по разным портам и каталогам данных. По умолчанию 1С занимает следующие порты:
154015411560-1591Разберем алгоритм настройки второго кластера (например, для новой версии) на портах 1640, 1641 и т.д.:
C:\Program Files\1cv8\srvinfo_new.
sc create "1C:Enterprise 8.3.25 Server" binPath= "\"C:\Program Files\1cv8\8.3.25.1234\bin\ragent.exe\" /srvc /agent /regport 1641 /port 1640 /range 1660:1691 /d \"C:\Program Files\1cv8\srvinfo_new\"" start= auto obj= ".\USR1CV8" password= "YourPassword" displayname= "1C:Enterprise 8.3.25 Server"
В данном примере мы четко разграничили ресурсы:
/port определяет порт агента./regport определяет основной порт кластера./range задает диапазон портов для рабочих процессов rphost./d указывает на изолированный каталог данных.После того как мы развернули два независимых кластера, нам нужно правильно настроить подключение пользователей. Посмотрим на пример строки подключения для старого и нового кластеров:
Для старой базы (стандартные порты): ServerName:1541
Для новой базы (измененные порты): ServerName:1641
Важно помнить, что при использовании «полной» установки платформы на рабочих станциях, программа запуска 1cestart.exe сама определит версию сервера, к которому идет обращение, и запустит соответствующую версию тонкого клиента. Это позволяет пользователям прозрачно работать с базами разных релизов, не задумываясь о технических сложностях на стороне сервера.
Мы выяснили, что попытка заставить "кота дышать водой", объединяя разные релизы в один кластер, приведет лишь к фатальным ошибкам. Для построения надежной системы следует придерживаться следующих правил:
Failover, обновите все серверы в связке до одной актуальной версии.С точки зрения лицензирования, запуск нескольких экземпляров сервера 1С на одном аппаратном устройстве обычно не требует покупки дополнительных серверных лицензий 1С, что делает вариант с параллельной установкой не только технически правильным, но и экономически выгодным.