Как настроить работу двух разных серверов 1С с одной СУБД MS SQL и решить ошибки подключения

Системный администратор 1С v8.3 (Управляемые формы) 1С:Розница IT и автоматизация бизнеса
← На главную

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

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

Архитектурная схема решения: два сервера 1С и один MS SQL

Для начала разберем общую схему взаимодействия компонентов. СУБД MS SQL Server является полностью самостоятельным программным обеспечением. Она способна хранить неограниченное количество баз данных и обслуживать запросы от множества независимых клиентов. С точки зрения SQL-сервера, каждый сервер 1С — это обычный клиент, который шлет SQL-запросы.

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

  1. Сервер №1 (Физический ПК/ВМ): Здесь функционирует основной сервер 1С (версии 8.3.5) и СУБД MS SQL Server. На этом сервере крутятся старые рабочие базы. Сервер 1С общается с MS SQL по сверхбыстрому протоколу Shared Memory (общая память), поскольку они установлены локально на одной машине.
  2. Сервер №2 (Физический ПК/ВМ): Сюда мы устанавливаем только службу сервера 1С:Предприятие новой версии (8.3.7). На этой машине СУБД не устанавливается. Сервер 1С №2 будет обращаться к базам данных, расположенным на Сервере №1, используя сетевой протокол TCP/IP через локальную сеть.

При такой схеме базы данных физически лежат на одном SQL-сервере, но управляются разными кластерами 1С. Это абсолютно рабочий и надежный вариант.

Шаг 1. Решение проблемы несовместимости версий клиента и сервера

Первая ошибка, с которой сталкиваются администраторы при развертывании такой схемы: «Различаются версии клиента и сервера». Выясним причину этой ошибки.

Платформа 1С:Предприятие требует строгого соответствия версии клиентского приложения (тонкого или толстого клиента), запускаемого на рабочем месте администратора/пользователя, и версии службы сервера 1С, к которой происходит подключение. Если вы пытаетесь создать базу на сервере 8.3.7, используя утилиту запуска или консоль администрирования от версии 8.3.5, вы гарантированно получите ошибку несоответствия.

Для исправления этой ситуации выполним следующие действия:

  1. На компьютере, с которого выполняется администрирование и создание баз данных, установим клиентскую часть платформы версии 8.3.7.
  2. При добавлении информационной базы в список баз 1С обязательно проверим дополнительные параметры запуска. Убедимся, что запуск базы инициируется именно нужным релизом платформы. Для этого в свойствах подключения к базе в окне запуска 1С можно явно прописать параметр Версия платформы (например, 8.3.7.1850).
  3. При использовании консоли администрирования (которая представляет собой оснастку MMC) убедимся, что мы зарегистрировали и запускаем версию утилиты Radmin.exe именно из каталога новой платформы (C:\Program Files\1cv8\8.3.7.XXXX\bin\).

Шаг 2. Настройка сетевого доступа к СУБД MS SQL Server

Когда мы пытаемся создать базу на Сервере №2 через сервер 1С версии 8.3.7, указывая СУБД на Сервере №1, может возникнуть ошибка: «Ошибка при выполнении операций с информационной базой...». Это связано с тем, что Сервер №2 не может достучаться до удаленного SQL-сервера по сети.

Проанализируем сетевые настройки и выполним пошаговую конфигурацию СУБД на Сервере №1:

  1. Включение протокола TCP/IP: Откроем утилиту SQL Server Configuration Manager на Сервере №1. Перейдем в раздел SQL Server Network Configuration -> Protocols for MSSQLSERVER (или имя вашего экземпляра). Убедимся, что протокол TCP/IP находится в статусе Enabled. По умолчанию в некоторых редакциях (особенно SQL Server Express) он отключен.
  2. Настройка портов в Брандмауэре (Firewall): На Сервере №1 необходимо открыть входящие порты для подключения из локальной сети. Стандартный порт MS SQL — TCP 1433. Если СУБД установлена как именованный экземпляр, дополнительно требуется запустить службу SQL Server Browser и открыть порт UDP 1434. Пропишем правила для входящих подключений в Брандмауэре Windows на Сервере №1 для этих портов.
  3. Установка драйверов на Сервере №2: Чтобы сервер 1С (8.3.7) мог общаться с MS SQL, на Сервере №2 должен быть установлен соответствующий клиентский драйвер. Скачаем и установим официальный пакет Microsoft SQL Server Native Client (для старых версий платформ) или актуальный Microsoft OLE DB Driver for SQL Server на Сервер №2. Без этого компонента сервер 1С просто не поймет, как транслировать запросы к СУБД.

Шаг 3. Разрешение имен (DNS) и имя сервера СУБД

Важнейший момент, из-за которого чаще всего происходит сбой при создании базы — некорректное указание имени сервера баз данных в параметрах создания ИБ. Рассмотрим типичную ошибку.

Если в поле «Сервер баз данных» указано просто локальное имя компьютера, например, retail, то служба 1С на Сервере №2 попытается найти этот компьютер в сети. Если в локальной сети нет выделенного и корректно настроенного DNS-сервера, имя компьютера может не разрешиться в IP-адрес.

Решить эту проблему можно двумя путями:

Шаг 4. Настройка авторизации на SQL Server

При межсерверном взаимодействии крайне важно использовать правильный тип авторизации. Если сервер 1С работает под локальной учетной записью (например, стандартной usr1cv8), созданной на Сервере №2, то при попытке использовать Windows-авторизацию для подключения к SQL-серверу на Сервере №1 мы получим отказ в доступе. Windows-авторизация без проблем работает только в рамках единого домена Active Directory.

Поэтому при создании информационной базы в 1С всегда выбираем SQL-авторизацию:

Альтернативный вариант: Запуск двух версий сервера 1С на одном физическом сервере

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

Разберем по шагам, как запустить службы 1С версий 8.3.5 и 8.3.7 параллельно на Сервере №1:

  1. Установим обе платформы на Сервер №1.
  2. Версия 8.3.5 остается работать на стандартных портах:
    • Порт агента: 1540
    • Порт главного менеджера кластера: 1541
    • Диапазон рабочих процессов: 1560:1591
  3. Для версии 8.3.7 мы создадим новую отдельную службу Windows с альтернативными портами. Откроем командную строку от имени администратора и выполним команду регистрации новой службы (замените номера релизов на ваши актуальные):
    
    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"
    
  4. Обратите внимание на параметр -d — мы обязательно должны указать отдельный пустой каталог для хранения реестра кластера новой версии платформы, иначе настройки кластеров перепутаются.
  5. Запустим созданную службу. Теперь на одной машине работают два независимых кластера 1С. При подключении клиентов к базам новой версии 8.3.7 в адресе сервера мы просто будем указывать альтернативный порт, например: имя_сервера:2540.

Важное предупреждение по распределенным базам (РИБ)

В ходе обсуждения автор темы обоснованно беспокоился о судьбе 150 узлов РИБ. Настоятельно рекомендуем прислушаться к этим опасениям. Механизм распределенных баз данных 1С крайне чувствителен к версиям платформ. Если обновить центральный узел до новой версии (например, до 8.3.7) и осуществлять выгрузку данных, периферийные узлы, оставшиеся на старых версиях (8.3.5), скорее всего, не смогут прочитать XML-пакеты обмена из-за изменений в механизмах сериализации данных. Обмен заблокируется.

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

← На главную