Развертывание серверной инфраструктуры 1С часто предполагает разделение ролей: сервер приложений 1С находится на одном физическом или виртуальном сервере, а система управления базами данных (СУБД), такая как MS SQL Server, — на другом. При такой схеме новички часто сталкиваются с проблемой "невидимости" сервера баз данных. Рассмотрим подробно, как преодолеть эти трудности, настроить сетевые экраны и обеспечить корректную авторизацию между компонентами системы.
Первое, с чего мы начнем — это проверка физической и логической доступности виртуальной машины. Распространенное заблуждение гласит, что виртуализация создает непреодолимый барьер для кластера 1С. На самом деле для rphost (рабочего процесса 1С) не имеет значения, является ли целевой сервер "железным" или виртуальным. Главное условие — наличие стабильного сетевого канала и открытых портов.
Разберем по шагам проверку портов:
ping, так как он проверяет только доступность узла по протоколу ICMP, но не конкретный сервис. Используем команду в консоли сервера 1С:
telnet IP_АДРЕС_SQL_СЕРВЕРА 1433
Если экран очистился — порт открыт. Если возникла ошибка подключения — порт заблокирован или служба SQL не слушает этот интерфейс.SERVER\SQLEXPRESS), вам обязательно нужно открыть порт UDP 1434, чтобы служба 1С могла узнать динамический порт этого экземпляра.Проанализируем ситуацию, когда порт вроде бы открыт, но соединения нет. Часто причина кроется в том, что в самом SQL Server Configuration Manager отключен протокол TCP/IP. Рассмотрим, как это исправить:
TCP/IP находится в статусе Enabled.TCP/IP на вкладке IP Addresses пролистайте вниз до раздела IPAll и проверьте, что поле TCP Port содержит 1433.Важный момент: любые изменения сетевых протоколов SQL требуют обязательного перезапуска службы SQL Server (MSSQLSERVER). Без перезагрузки новые правила не вступят в силу, что часто становится причиной долгих и безрезультатных поисков ошибки.
Одной из самых сложных проблем является настройка прав доступа. Рассмотрим типичную ошибку: попытка использовать Windows Authentication при создании базы в консоли 1С, когда серверы находятся на разных машинах.
Выясним причину, почему это не работает "из коробки":
Служба Агент сервера 1С:Предприятия по умолчанию запускается под локальной системной учетной записью (LocalSystem) или локальным пользователем (USR1CV8). Когда сервер 1С пытается постучаться на другой сервер SQL под "виндовой" авторизацией, он делает это от имени своей учетной записи. Но LocalSystem одного сервера ничего не знает о правах на другом сервере. Это называется проблемой "двойного прыжка".
Проанализируем правильные варианты решения:
SQL Server and Windows Authentication mode.db_owner_1c), задайте ему сложный пароль и назначьте роли dbcreator и processadmin на уровне сервера.Если же политика безопасности требует использовать исключительно доменную авторизацию, вам придется запустить службу 1C:Enterprise 8.3 Server Agent от имени специально созданного доменного пользователя, который также должен быть добавлен в список Logins на SQL-сервере с соответствующими правами.
Иногда возникают ситуации, когда разрешение имен (DNS) в виртуальной сети работает некорректно. Например, сервер 1С не может разрешить имя SRVR-SQL-01 в IP-адрес. Посмотрим, как решить это с помощью системной утилиты cliconfg.exe.
Рассмотрим алгоритм создания псевдонима:
C:\Windows\System32\cliconfg.exe.SQL_VM).Теперь в консоли администрирования 1С в поле "Сервер баз данных" вы можете просто писать SQL_VM, и система мгновенно найдет нужный сервер по жестко прописанному адресу, минуя сетевые задержки и ошибки DNS.
Для успешного подключения базы 1С к SQL Server на виртуальной машине мы должны обеспечить выполнение трех условий:
1433, включен протокол TCP/IP в настройках SQL, служба SQL перезапущена.Mixed Mode в SQL Server, создан технический пользователь SQL с правами на создание баз.Соблюдение этих шагов позволяет избежать 99% проблем, связанных с первичным подключением и миграцией баз в виртуальную среду.