Представим ситуацию: обычное рабочее утро, сервер 1С работает в штатном режиме, большинство пользователей успешно зашли в систему. Однако для двух-трех конкретных информационных баз при попытке входа программа выдает лаконичное, но крайне неприятное сообщение: «Ошибка установки соединения». При этом остальные базы на том же самом сервере и в том же кластере продолжают работать как ни в чем не бывало. Перезагрузка всего сервера — мера радикальная и нежелательная, когда в других базах уже работают сотни людей. Разберем детально, почему это происходит и как решить проблему «малой кровью».
Для начала проанализируем ситуацию. Если часть баз работает, значит, сетевая связность с сервером есть, служба ragent запущена, и лицензии в целом доступны. Проблема носит локальный характер для конкретных баз. Чтобы понять, что происходит в момент «отвала» соединения, обратимся к технологическому журналу (ТЖ) на стороне клиента.
Рассмотрим фрагмент лога, который фиксирует момент ошибки:
15:46.340000-15991,SCALL,2,process=1cv8c,OSThread=160136,ClientID=1,Interface=73b7d3a3-fe0b-4fdf-ba70-b74b3589ffc3,IName=ISelectSrvrProcess,Method=0,CallID=1058,MName=selectProcess,DstClientID=69769
15:47.340001-1,SCALL,2,process=1cv8c,OSThread=160136,ClientID=1,Interface=73b7d3a3-fe0b-4fdf-ba70-b74b3589ffc3,IName=ISelectSrvrProcess,Method=0,CallID=1059,MName=selectProcess,DstClientID=69769
15:50.355008-0,EXCP,1,process=1cv8c,OSThread=160136,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr='src\VResourceSessionImpl.cpp(529):
580392e6-ba49-4280-ac67-fcd6f2180121: Ошибка установки соединения'
Проанализируем эти записи. Ключевым здесь является вызов интерфейса ISelectSrvrProcess и метода selectProcess. Этот метод отвечает за выбор рабочего процесса (rphost), который будет обслуживать сеанс конкретной информационной базы. Когда менеджер кластера (rmngr) не может назначить клиенту рабочий процесс или процесс не отвечает на запрос, возникает исключение в модуле VResourceSessionImpl.cpp.
Выясним причину такого поведения. Это может быть связано с тем, что рабочий процесс, «закрепленный» за базой, завис, либо в реестре кластера произошел сбой, из-за которого менеджер пытается отправить клиента на несуществующий или недоступный порт.
Как показывает практика, это самый быстрый и эффективный способ вернуть базу в строй без остановки всего сервера. Суть метода заключается в том, чтобы заставить менеджер кластера пересоздать внутренние структуры данных для проблемной базы.
Выполним следующие шаги:
После этой процедуры менеджер кластера заново инициализирует связи, и ошибка selectProcess, как правило, исчезает. Это происходит потому, что старые «битые» привязки к процессам сбрасываются.
Если перерегистрация не помогла, нам необходимо рассмотреть более глубокие системные причины. Одной из них является повреждение файлов в каталоге snaccfg, где сервер хранит настройки соответствия баз и процессов.
Разберем алгоритм очистки:
1C:Enterprise 8.3 Server Agent. Помните, что это прервет работу всех пользователей во всех базах.C:\Program Files\1cv8\srvinfo или C:\ProgramData\1C\1cv8).reg_1541 (или вашего номера порта) найдем папки с идентификаторами баз. Однако нас больше интересует очистка временных файлов.snaccfg и temp.Также проанализируем ситуацию с динамическими портами. Если в настройках кластера задан слишком узкий диапазон портов (например, стандартные 1560–1591), и на сервере много баз или рабочих процессов, портов может просто не хватить. Убедитесь, что антивирус не блокирует соединения по этим портам и что сторонние приложения не занимают этот диапазон.
Иногда ошибка возникает из-за того, что один рабочий процесс (rphost) перегружен или впал в «ступор» из-за тяжелого запроса в одной базе, что мешает ему принимать соединения для других баз, которые он обслуживает.
Рассмотрим возможность изоляции баз. В свойствах кластера можно отрегулировать параметры «Количество информационных баз на процесс» и «Количество соединений на процесс». Если установить значение Количество баз на процесс = 1, то для каждой базы будет запускаться свой экземпляр rphost. Это требует больше оперативной памяти, но значительно повышает отказоустойчивость: падение или зависание процесса одной базы никак не затронет остальные.
Выясним причину редких, но стабильных ошибок при проверке сетевых адресов. В логах ТЖ иногда встречается запись addrBelongsToThisComputer2, result=false. Это часто указывает на конфликты с протоколом IPv6. Если ваш сервер не требует работы через IPv6, рекомендуется отключить его в настройках сетевого адаптера или приоритезировать IPv4 через реестр Windows. Это исключит задержки и ошибки при разрешении имен серверов (DNS).
Также стоит отметить, что данная проблема была характерна для старых релизов платформы (ветки 8.3.6 – 8.3.12). В современных версиях механизмы распределения нагрузки были переработаны. Если вы часто сталкиваетесь с ошибкой «Ошибка установки соединения» на ровном месте, рассмотрите возможность обновления платформы до актуального стабильного релиза.
Подведем итог: если базы внезапно перестали отвечать, первым делом попробуйте их перерегистрировать в консоли кластера. Это самый быстрый способ восстановления работоспособности, который не требует перезагрузки всей системы и не мешает остальным пользователям.