Разнесение сервера приложений 1С и системы управления базами данных (СУБД) на разные физические или виртуальные машины — это стандартная практика для высоконагруженных систем или специфических задач интеграции. Часто это продиктовано необходимостью использовать преимущества разных операционных систем: например, Windows Server для работы COM-соединений и специфических драйверов, и Linux для обеспечения высокой производительности PostgreSQL. В этой статье мы подробно разберем, как правильно настроить такую связку и устранить типичные ошибки подключения.
Рассмотрим сценарий: сервер приложений 1С переносится на машину под управлением Windows (Сервер X), а база данных PostgreSQL остается на Linux (Сервер Y). При попытке подключения администратор получает ошибку: Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение (10061). Проанализируем причину. Данная ошибка на порту 1541 чаще всего означает, что служба rphost или ragent на целевом сервере недоступна. Либо служба не запущена, либо брандмауэр блокирует пакеты, либо в настройках кластера указан неверный адрес.
Для корректной работы 1С в распределенной среде недостаточно открыть только стандартный порт СУБД. Разберем по шагам, какие порты должны быть открыты на каждой из сторон.
На сервере приложений (Windows):
1540 — Агент сервера (ragent).1541 — Менеджер кластера (rmngr).1560–1591 — Диапазон рабочих процессов (rphost).На сервере базы данных (Linux):
5432 — Стандартный порт PostgreSQL.Выясним, как проверить доступность порта с Windows-сервера на Linux-сервер. Для этого удобно использовать PowerShell:
Test-NetConnection -ComputerName 192.168.1.100 -Port 5432
Если результат TcpTestSucceeded : False, значит, запрос блокируется либо настройками самой СУБД, либо сетевым экраном (iptables/ufw).
По умолчанию PostgreSQL часто настроен на работу только с локальным хостом (localhost). Чтобы разрешить подключения с сервера 1С, необходимо внести изменения в конфигурационные файлы.
Проанализируем файл postgresql.conf. Найдем параметр listen_addresses. Если там указано 'localhost', СУБД будет игнорировать любые внешние запросы. Изменим значение:
# Разрешаем прослушивание на всех сетевых интерфейсах
listen_addresses = '*'
Далее настроим права доступа в файле pg_hba.conf. Нам нужно разрешить подключение пользователю базы данных с IP-адреса нашего Windows-сервера. Добавим строку в конец файла:
# host database user address auth-method
host all all 192.168.1.50/32 md5
Здесь 192.168.1.50 — IP-адрес сервера приложений 1С. Использование метода md5 (или password) обязательно для успешной аутентификации со стороны платформы 1С.
Важно понимать, что 1С крайне чувствительна к задержкам (Latency) между сервером приложений и БД. Если сервер приложений находится в одном дата-центре, а БД — в другом (через публичный интернет), производительность упадет в десятки раз. Рекомендуется соединять серверы через гигабитную локальную сеть или выделенный VPN-канал. Оптимальный пинг должен составлять менее 1 мс.
Также следует отключить обратный поиск DNS в postgresql.conf, так как некорректная работа DNS-сервера может вызвать паузы при каждом новом соединении:
log_hostname = off
Поскольку одной из причин выноса 1С на Windows является работа COM-соединения, рассмотрим настройки прав. Служба 1С на Windows по умолчанию запускается от имени пользователя USR1CV8. Посмотрим, что нужно сделать для стабильной работы обменов:
Разберем неочевидную причину ошибок — рассинхронизацию времени. Если время на сервере Windows и Linux отличается более чем на 5 минут, механизмы блокировок и аутентификации могут работать некорректно. Настроим синхронизацию через NTP на обоих серверах. Кроме того, на Linux-сервере должна быть установлена русская локаль, иначе 1С не сможет корректно создавать базы данных:
# Проверка локали в Linux
locale -a
# Должна присутствовать ru_RU.utf8
После того как мы изменили listen_addresses, настроили pg_hba.conf, открыли порты в Firewall и убедились в доступности 1541 порта, ошибка 10061 должна исчезнуть. Теперь сервер приложений на Windows сможет прозрачно транслировать запросы пользователей к базе данных на Linux, сохраняя при этом возможность использовать COM-соединение для интеграции с другими конфигурациями.