Публикация одной информационной базы 1С:Предприятие на нескольких веб-серверах — это стандартная задача при построении отказоустойчивых систем, распределении сетевой нагрузки или разделении физического доступа для внутренних сотрудников и внешних контрагентов. Однако при такой настройке администраторы часто сталкиваются с неприятной проблемой: в то время как тонкий клиент отлично работает по веб-ссылке, веб-клиент (подключение через обычный браузер) намертво зависает на стартовой заставке с логотипом «1С:Предприятие» еще до появления окна авторизации.
В этой статье мы подробно разберем, как правильно реализовать архитектуру с двумя веб-серверами IIS для одной клиент-серверной базы 1С, проанализируем причины зависания веб-клиента в браузере и пошагово настроим всю систему для стабильной работы.
Прежде чем переходить к тонким настройкам IIS, давайте разберем фундаментальный вопрос: можно ли публиковать файловую базу на двух веб-серверах? Теоретически это возможно, если оба веб-сервера будут обращаться к общему файлу 1Cv8.1CD через сетевой ресурс (например, по протоколу SMB).
Однако на практике такая схема крайне нестабильна. При одновременной работе пользователей через разные веб-серверы блокировки СУБД перекладываются на сетевые протоколы операционной системы. Это приводит к критическому падению производительности, постоянным блокировкам таблиц и высокому риску необратимого повреждения базы данных. Для надежной работы нескольких веб-серверов подходит исключительно клиент-серверный вариант работы 1С.
В клиент-серверном варианте веб-серверы выступают лишь в роли трансляторов HTTP/HTTPS-запросов к кластеру серверов 1С. База данных развернута под управлением MS SQL, PostgreSQL или другой поддерживаемой СУБД. В такой конфигурации вы можете подключить хоть 10 веб-серверов — сам кластер 1С будет корректно управлять сеансами, блокировками и распределением нагрузки.
Это самая частая причина, по которой тонкий клиент успешно запускается, а браузер зависает на заставке. Давайте разберем разницу в механизмах их работы:
Если в настройках информационной базы на сервере 1С запрещена раздача лицензий сервером, тонкий клиент запустится (так как найдет локальный ключ), а браузер будет бесконечно ожидать лицензию, зависнув на заставке.
Решение:
По умолчанию веб-сервер IIS для повышения производительности может использовать технологию «Web Garden» (веб-сад), запуская несколько рабочих процессов w3wp.exe для обслуживания одного пула приложений. Для обычных сайтов это отлично, но для веб-клиента 1С это критично.
Сеанс веб-клиента жестко инициализируется внутри конкретного рабочего процесса IIS, где загружается библиотека wsisapi.dll. Браузер в процессе работы отправляет множество асинхронных HTTP-запросов. Если в пуле запущено несколько процессов w3wp.exe, то первый запрос уйдет на один процесс, а второй запрос (например, на получение интерфейса авторизации) может быть перенаправлен IIS на другой рабочий процесс. Второй процесс ничего не знает об этой сессии, из-за чего веб-клиент зависает намертво.
Решение:
DefaultAppPool или созданный нами выделенный пул).Современная платформа 1С использует протокол WebSockets для обеспечения интерактивного взаимодействия между сервером и веб-клиентом (например, для работы системы взаимодействия, всплывающих оповещений и динамического обновления форм). Если этот компонент не установлен в операционной системе веб-сервера, IIS пытается использовать обходные технологии длинных опросов (long-polling), что при строгих настройках брандмауэра приводит к зависанию на стартовом экране.
Решение:
iisreset в командной строке от имени администратора).Модуль расширения веб-сервера 1С работает в контексте безопасности учетной записи, от имени которой запущен пул приложений IIS (обычно это системная встроенная учетная запись ApplicationPoolIdentity). Для успешной инициализации сеанса модулю wsisapi.dll требуется доступ к временным папкам профиля пользователя для создания кэша сессий.
Если профиль не загружен в операционную систему, запись во временные директории может быть заблокирована, что вызовет ошибку инициализации и зависание.
Решение:
IIS_IUSRS есть полные права на чтение и запись в папку публикации 1С (где лежит файл default.vrd).Если мы публикуем одну базу на двух физически разных веб-серверах IIS, пользователи должны обращаться к ним. Обычно для этого перед веб-серверами ставят балансировщик нагрузки (например, Nginx, HAProxy или модуль IIS Application Request Routing — ARR).
Здесь кроется важнейший архитектурный нюанс: на балансировщике в обязательном порядке должна быть настроена технология Sticky Sessions (Session Affinity / Привязка сеансов).
Поскольку веб-клиент инициализирует сессию на конкретном веб-сервере, все последующие запросы от этого пользователя должны отправляться строго на этот же веб-сервер. Если балансировщик будет распределять запросы по обычному алгоритму Round Robin (поочередно), то пользователь, зайдя в систему, при первом же клике по меню получит ошибку отсутствия сеанса или интерфейс снова зависнет.
Рассмотрим пример настройки «липких сессий» в конфигурационном файле Nginx с использованием директивы ip_hash, которая привязывает клиента к серверу по его IP-адресу:
upstream 1c_web_servers {
ip_hash;
server iis-server1.local:80;
server iis-server2.local:80;
}
server {
listen 443 ssl;
server_name 1c.company.com;
location / {
proxy_pass http://1c_web_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Если же вы используете аппаратные балансировщики или IIS ARR, настройте привязку на основе Cookie-файлов (Client Affinity Cookie). Это более надежно, так как несколько пользователей за NAT (с одинаковым внешним IP) смогут равномерно распределяться по серверам.
При использовании двух веб-серверов критически важно следить за идентичностью настроек. Файлы описания виртуального ресурса default.vrd на обоих серверах IIS должны быть абсолютно одинаковыми.
Посмотрим на пример структуры файла default.vrd для клиент-серверной базы:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/Trade"
ib="Srvr="1C-AppServer";Ref="TradeProduction";">
<ws enable="true" pointEnable="true"/>
<httpServices publishByDefault="true"/>
<standardOdata enable="false"/>
</point>
При обновлении платформы 1С:Предприятие на сервере приложений помните, что вам необходимо одновременно обновить платформу на обоих веб-серверах IIS. Пути к библиотеке расширения веб-сервера в конфигурационных файлах IIS должны указывать на одну и ту же версию платформы 1С:
C:\Program Files\1cv8\8.3.XX.XXXX\bin\wsisapi.dll
Если версии будут различаться, пользователи, попав на необновленный веб-сервер, будут получать сообщение о несоответствии версий клиента и сервера.
Придерживаясь этих рекомендаций и последовательно проверив настройки пулов приложений IIS, WebSocket и параметры раздачи лицензий в кластере 1С, вы сможете успешно развернуть отказоустойчивую и быструю систему публикации баз данных на нескольких веб-серверах без зависаний и сбоев у конечных пользователей.