При настройке высокодоступной связки MSSQL 2016 AlwaysOn с кластером 1С 8.3 многие системные администраторы сталкиваются с трудностями при подключении сервера 1С к базе данных через прослушиватель SQL. Часто возникают ошибки аутентификации, как при использовании доменных учетных записей, так и при попытках подключения с учетной записью sa. Рассмотрим подробнее, как корректно настроить это подключение и устранить типовые проблемы.
Когда мы настраиваем группу доступности AlwaysOn в MSSQL Server, мы стремимся обеспечить отказоустойчивость и высокую доступность нашей базы данных. Кластер 1С должен подключаться не к конкретному экземпляру SQL Server, а к прослушивателю группы доступности (Availability Group Listener). Этот прослушиватель представляет собой виртуальное сетевое имя, которое всегда указывает на активную реплику. Такой подход обеспечивает автоматическое переключение на резервный сервер в случае сбоя основной реплики, минимизируя простой.
Для корректной работы 1С с AlwaysOn критически важны следующие аспекты:
Далее разберем по шагам процесс настройки и устранения ошибок.
Прежде чем углубляться в тонкости аутентификации, мы должны убедиться в базовой сетевой доступности прослушивателя и открытых портах. Часто проблемы возникают из-за некорректной настройки сетевого окружения или брандмауэра.
ping.
Сервер 1С для взаимодействия с MSSQL Server использует клиентские библиотеки. Проблемы с подключением часто могут быть вызваны отсутствием, повреждением или несовместимостью установленного SQL клиента.
sa), попробуем переустановить клиент. В некоторых случаях, как показывает опыт, это решает часть проблем. Рекомендуется использовать Microsoft OLE DB Driver 19 for SQL Server как более современную альтернативу Native Client.
Когда мы получаем общие ошибки подключения, очень важно обратиться к журналам ошибок SQL Server. Они могут дать более точную информацию о причинах отказа в подключении.
Проверим журнал событий MSSQL Server на предмет ошибок входа или других проблем с аутентификацией. Например, сообщение "попытка использования имени учетной записи NT при проверке подлинности SQL Server" может указывать на то, что SQL Server пытается использовать Windows-аутентификацию, хотя мы могли ожидать SQL-аутентификацию, или наоборот.
Наиболее надежный и рекомендованный способ подключения сервера 1С к MSSQL AlwaysOn – это использование доменной учетной записи для запуска службы сервера 1С. Этот подход позволяет избежать множества проблем, связанных с аутентификацией, особенно при отработке отказа.
Рассмотрим, почему подключение через локальную SQL-учетную запись (например, sa или специально созданную 1c_db) может быть ненадежным в связке с AlwaysOn. При стандартной настройке группы доступности, SQL-логины, созданные на одном экземпляре SQL Server, являются локальными для этого экземпляра. При отработке отказа (failover) и переключении активной реплики на другой сервер SQL Server, локальная SQL-учетная запись на этом новом активном сервере может не иметь соответствующих прав на базу данных, даже если мы создадим ее с таким же именем и паролем. Это происходит потому, что идентификаторы безопасности (SID) для локальных SQL-логинов различаются на разных экземплярах SQL Server по умолчанию. В результате после переключения сервер 1С потеряет доступ к базе данных.
Именно поэтому мы приходим к выводу, что наиболее устойчивым решением является подключение сервера 1С с MS SQL через доменную учетную запись.
Для корректной работы сервера 1С с MSSQL AlwaysOn через доменную учетную запись, выполним следующие действия:
DOMAIN\1CSQL. Этот пользователь будет использоваться исключительно для запуска службы сервера 1С.
DOMAIN\1CSQL все необходимые права на SQL Server. Мы должны добавить этого доменного пользователя как логин на всех экземплярах SQL Server, участвующих в группе доступности, и предоставить ему права db_owner на базы данных 1С.
Важно, чтобы службы Microsoft SQL Server на всех нодах кластера также запускались от имени доменной учетной записи. Эта учетная запись должна быть включена в локальную группу безопасности "Администраторы" на всех узлах.
1C:Enterprise 8.3 Server) так, чтобы она запускалась от имени созданного доменного пользователя DOMAIN\1CSQL. Это можно сделать через консоль "Службы" Windows:
services.msc).1C:Enterprise 8.3 Server.DOMAIN\1CSQL и соответствующий пароль.В этом случае сервер 1С будет подключаться к SQL Server под учетной записью, от имени которой запущена его служба, то есть под DOMAIN\1CSQL. Такой подход гарантирует, что при отработке отказа AlwaysOn, сервер 1С всегда будет успешно авторизоваться на новой активной реплике.
Мы видим, что платформа 1С по умолчанию не позволяет указывать доменного пользователя в явном виде в настройках подключения к базе данных через консоль кластера. Если мы попытаемся ввести учетную запись вида DOMAIN\User или user@domain.local, то 1С будет пытаться использовать SQL-авторизацию, что приведет к ошибке "Ошибка входа пользователя "DOMAIN\User"." (HRESULT=80040E4D, SQLSrvr: SQLSTATE=28000, native=18456).
Таким образом, оставляя поля аутентификации в настройках базы 1С пустыми и запуская службу 1С под доменным пользователем, мы реализуем надежную Windows-аутентификацию для AlwaysOn.
Как уже упоминалось, в настройках информационной базы 1С в поле "Сервер баз данных" всегда указываем DNS-имя прослушивателя группы доступности, а не его IP-адрес. Это критически важно для корректной работы AlwaysOn, так как IP-адрес прослушивателя может меняться в зависимости от активной ноды, особенно в случае многоподсетевой конфигурации. Использование DNS-имени гарантирует, что 1С всегда будет обращаться к актуальной активной реплике.
Помимо основной настройки, существуют и другие важные аспекты, которые следует учитывать при работе с AlwaysOn и 1С, а также альтернативные решения.
Для обеспечения стабильности и надежной отработки отказа кластера Windows (WSFC), который лежит в основе AlwaysOn, мы настоятельно рекомендуем добавить свидетеля кворума (Witness Server). Особенно это актуально для сценариев с двумя узлами.
Свидетель кворума помогает предотвратить ситуации "разделения мозга" (split-brain), когда обе ноды кластера считают себя активными после потери связи. Достаточно использовать файловую шару (File Share Witness), которая находится на отдельном сервере или в надежном сетевом хранилище, доступном обеим нодам.
Мы должны понимать, что без свидетеля кворума, отказоустойчивость группы доступности может быть нестабильной, и восстановление после падения активной ноды может быть затруднено или некорректно.
Если по каким-либо причинам мы все же хотим использовать SQL-аутентификацию для подключения к базе данных через AlwaysOn, то нам необходимо решить проблему с различием SID для локальных SQL-логинов на разных экземплярах SQL Server.
Рассмотрим следующий подход для синхронизации SQL логинов (пользователей СУБД):
1c_db.
SELECT name, SID FROM sys.server_principals WHERE name = '1c_db'
Мы скопируем полученное значение SID.
USE [master]
GO
CREATE LOGIN [1c_db] WITH PASSWORD=N'пароль', SID=0xBC7920C2C8063143806A19894B7F9DCA, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
Мы заменим N'пароль' на фактический пароль и 0xBC7920C2C8063143806A19894B7F9DCA на скопированный SID. Параметры CHECK_EXPIRATION=OFF и CHECK_POLICY=OFF отключают требования к сроку действия и сложности пароля соответственно, что часто удобно для служебных учетных записей.
db_owner для базы 1С.
Этот подход гарантирует, что SQL-логин 1c_db будет иметь одинаковые SID на всех экземплярах SQL Server, и при отработке отказа он не потеряет свои права на базу данных.
Вместо устаревшего MS SQL Native Client мы можем использовать Microsoft OLE DB Driver 19 for SQL Server на сервере 1С. Этот драйвер является более современным и поддерживаемым решением для подключения к SQL Server, что может улучшить совместимость и производительность.
В контексте AlwaysOn мы можем настроить Read-Only Routing, чтобы направлять запросы на чтение к вторичным репликам, тем самым разгружая первичную реплику и распределяя нагрузку. Для этого необходимо выполнить ряд настроек:
ApplicationIntent=ReadOnly в своих строках подключения, чтобы запросы были маршрутизированы к вторичным репликам.
Однако, мы должны учитывать, что платформа 1С:Предприятие напрямую не поддерживает новый синтаксис строки подключения к MSSQL, включающий параметр ApplicationIntent=ReadOnly, в своей консоли кластера. Это означает, что для реализации read-only маршрутизации для клиентов 1С могут потребоваться дополнительные настройки или обходные пути, которые выходят за рамки стандартных возможностей конфигурации 1С.
Мы должны быть готовы к тому, что для достижения полного эффекта Read-Only Routing с 1С могут потребоваться более сложные интеграционные решения или специализированные настройки на уровне драйверов или промежуточных прокси.
Настройка связки MSSQL 2016 AlwaysOn с кластером 1С 8.3 требует внимательности к деталям, особенно в части аутентификации и сетевых настроек. Наиболее надежным решением проблемы подключения сервера 1С к базе через прослушиватель является использование доменной учетной записи для запуска службы сервера 1С и оставление полей логина/пароля СУБД в настройках базы 1С пустыми. Мы также рассмотрели важные аспекты стабильности кластера, альтернативные подходы к SQL-аутентификации и возможности Read-Only Routing.
Следуя этим рекомендациям, мы сможем построить отказоустойчивую и производительную систему, обеспечивающую надежную работу наших информационных баз 1С.