В практике администрирования систем на платформе 1С:Предприятие часто возникает классическая задача: необходимо запустить новую конфигурацию (например, современную редакцию 1С:Розница), требующую актуальную версию платформы (например, 8.3.7 и выше), но при этом на предприятии уже успешно функционирует старая база на более ранней платформе (например, 8.3.5). Обновлять основную платформу крайне нежелательно, так как к ней подключены сотни пользователей и развернута сложная сеть распределенных информационных баз (РИБ) из 150 узлов, обновление которых потребует колоссальных временных и трудовых затрат.
В данной статье мы подробно рассмотрим, как развернуть второй сервер 1С другой версии, подключить его к уже имеющейся СУБД MS SQL, расположенной на первом сервере, и успешно решить все сопутствующие проблемы с версиями клиентов, авторизацией и сетевыми именами.
Для начала разберем общую схему взаимодействия компонентов. СУБД MS SQL Server является полностью самостоятельным программным обеспечением. Она способна хранить неограниченное количество баз данных и обслуживать запросы от множества независимых клиентов. С точки зрения SQL-сервера, каждый сервер 1С — это обычный клиент, который шлет SQL-запросы.
Таким образом, мы можем развернуть следующую топологию:
Shared Memory (общая память), поскольку они установлены локально на одной машине.TCP/IP через локальную сеть.При такой схеме базы данных физически лежат на одном SQL-сервере, но управляются разными кластерами 1С. Это абсолютно рабочий и надежный вариант.
Первая ошибка, с которой сталкиваются администраторы при развертывании такой схемы: «Различаются версии клиента и сервера». Выясним причину этой ошибки.
Платформа 1С:Предприятие требует строгого соответствия версии клиентского приложения (тонкого или толстого клиента), запускаемого на рабочем месте администратора/пользователя, и версии службы сервера 1С, к которой происходит подключение. Если вы пытаетесь создать базу на сервере 8.3.7, используя утилиту запуска или консоль администрирования от версии 8.3.5, вы гарантированно получите ошибку несоответствия.
Для исправления этой ситуации выполним следующие действия:
Версия платформы (например, 8.3.7.1850).Radmin.exe именно из каталога новой платформы (C:\Program Files\1cv8\8.3.7.XXXX\bin\).Когда мы пытаемся создать базу на Сервере №2 через сервер 1С версии 8.3.7, указывая СУБД на Сервере №1, может возникнуть ошибка: «Ошибка при выполнении операций с информационной базой...». Это связано с тем, что Сервер №2 не может достучаться до удаленного SQL-сервера по сети.
Проанализируем сетевые настройки и выполним пошаговую конфигурацию СУБД на Сервере №1:
SQL Server Configuration Manager на Сервере №1. Перейдем в раздел SQL Server Network Configuration -> Protocols for MSSQLSERVER (или имя вашего экземпляра). Убедимся, что протокол TCP/IP находится в статусе Enabled. По умолчанию в некоторых редакциях (особенно SQL Server Express) он отключен.1433. Если СУБД установлена как именованный экземпляр, дополнительно требуется запустить службу SQL Server Browser и открыть порт UDP 1434. Пропишем правила для входящих подключений в Брандмауэре Windows на Сервере №1 для этих портов.Microsoft SQL Server Native Client (для старых версий платформ) или актуальный Microsoft OLE DB Driver for SQL Server на Сервер №2. Без этого компонента сервер 1С просто не поймет, как транслировать запросы к СУБД.Важнейший момент, из-за которого чаще всего происходит сбой при создании базы — некорректное указание имени сервера баз данных в параметрах создания ИБ. Рассмотрим типичную ошибку.
Если в поле «Сервер баз данных» указано просто локальное имя компьютера, например, retail, то служба 1С на Сервере №2 попытается найти этот компьютер в сети. Если в локальной сети нет выделенного и корректно настроенного DNS-сервера, имя компьютера может не разрешиться в IP-адрес.
Решить эту проблему можно двумя путями:
retail укажем в настройках базы прямой IP-адрес Сервера №1 (например, 192.168.1.100). Если используется именованный экземпляр SQL, строка подключения будет выглядеть так: 192.168.1.100\ИмяЭкземпляра.C:\Windows\System32\drivers\etc\hosts с правами администратора и добавим строчку соответствия IP-адреса и сетевого имени:
192.168.1.100 retail
После этого сервер 1С мгновенно найдет нужную машину по имени.При межсерверном взаимодействии крайне важно использовать правильный тип авторизации. Если сервер 1С работает под локальной учетной записью (например, стандартной usr1cv8), созданной на Сервере №2, то при попытке использовать Windows-авторизацию для подключения к SQL-серверу на Сервере №1 мы получим отказ в доступе. Windows-авторизация без проблем работает только в рамках единого домена Active Directory.
Поэтому при создании информационной базы в 1С всегда выбираем SQL-авторизацию:
sa) или специально созданного пользователя SQL с правами роли sysadmin или, как минимум, ролей dbcreator и processadmin.Рассмотрим очень выгодный альтернативный вариант, который позволяет не тратить ресурсы на покупку второго сервера и, что важнее всего, **сэкономить на лицензиях**. По правилам лицензирования фирмы 1С, лицензия на сервер 1С:Предприятия привязывается к аппаратному обеспечению (физическому серверу или виртуальной машине). Если разносить сервера 1С на две разные машины, вам придется покупать две дорогие серверные лицензии. Если же запустить их параллельно на одной машине, понадобится всего **одна** лицензия!
Разберем по шагам, как запустить службы 1С версий 8.3.5 и 8.3.7 параллельно на Сервере №1:
154015411560:1591
sc create "1C:Enterprise 8.3.7.1850 Server" binPath= "\"C:\Program Files\1cv8\8.3.7.1850\bin\ragent.exe\" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \"C:\Program Files\1cv8\srvinfo_8_3_7\"" start= auto obj= "NT AUTHORITY\SYSTEM"
-d — мы обязательно должны указать отдельный пустой каталог для хранения реестра кластера новой версии платформы, иначе настройки кластеров перепутаются.имя_сервера:2540.В ходе обсуждения автор темы обоснованно беспокоился о судьбе 150 узлов РИБ. Настоятельно рекомендуем прислушаться к этим опасениям. Механизм распределенных баз данных 1С крайне чувствителен к версиям платформ. Если обновить центральный узел до новой версии (например, до 8.3.7) и осуществлять выгрузку данных, периферийные узлы, оставшиеся на старых версиях (8.3.5), скорее всего, не смогут прочитать XML-пакеты обмена из-за изменений в механизмах сериализации данных. Обмен заблокируется.
Поэтому решение разделить базы на разные серверы 1С разных версий для работы со старой конфигурацией на 8.3.5 и новой конфигурацией Розницы на 8.3.7 является стратегически верным. Это позволит обновлять периферийные точки постепенно и контролируемо, избегая коллапса всей торговой сети.