Организация удаленной работы с базами 1С — задача, с которой сталкиваются многие системные администраторы. Особую сложность вызывает сценарий, когда необходимо обеспечить веб-доступ к базовым версиям 1С в файловом варианте. Часто это делается из соображений экономии: покупается один мощный компьютер, на нем разворачивается веб-сервер (Apache или IIS), и пользователи подключаются к своим базам через браузер.
Однако на практике такая схема часто дает сбой: соединения "подвисают", пользователи не могут войти в базу, получая ошибки о блокировке или превышении лимита сеансов. Давайте подробно разберем, почему это происходит, проанализируем архитектурные ограничения и рассмотрим конкретные технические решения для стабилизации работы.
Прежде чем приступать к правке конфигурационных файлов, нам необходимо четко понимать причину проблемы. В обсуждаемой ситуации мы имеем дело с 1С:Базовая версия.
Главное ограничение базовой версии — возможность работы только одного пользователя (один активный сеанс) одновременно. Когда мы публикуем базу на веб-сервере, происходит следующее:
Кроме того, в файловом варианте работы веб-сервер Apache (процесс httpd.exe) напрямую захватывает файлы базы данных. Если процесс зависает, файлы блокировок (*.cdn, *.cLck) не удаляются, и база становится недоступной до перезагрузки службы Apache.
Это, пожалуй, самый важный шаг для файловых баз, опубликованных на веб-сервере, особенно если их много (в теме упоминается 30 баз). Рассмотрим почему это важно.
В файловом варианте "сервером" выступает само клиентское приложение. Когда пользователь входит в базу, платформа пытается запустить фоновые процессы (обновление полнотекстового поиска, загрузка курсов валют и т.д.). Для базовой версии запуск фонового задания — это попытка создания второго сеанса. Первый сеанс занят пользователем, второй пытается занять фоновое задание -> возникает конфликт блокировок.
Мы должны принудительно отключить запуск регламентных заданий через веб-сервер. Сделаем это через файл публикации default.vrd. Для анализа и ручного управления списком задач удобно использовать консоль регламентных и фоновых заданий.
Откроем файл default.vrd для конкретной базы в текстовом редакторе и найдем (или добавим) секцию управления заданиями. Нам нужно установить атрибут enable в значение false.
<point name="JobService"
alias="ws1.1cws"
enable="false"
reuseSessions="dontuse"
sessionMaxAge="20"
poolSize="10"
poolTimeout="5"/>
Обратите внимание на параметр reuseSessions="dontuse". Для базовых версий рекомендуется запретить переиспользование сеансов (или использовать с осторожностью), так как "залипший" сеанс гарантированно блокирует работу.
Стандартные настройки Apache не оптимизированы для работы с 1С Предприятием. Если мы используем Apache, нам необходимо отредактировать файл конфигурации httpd.conf. Если же вы планируете расширять возможности интеграции, изучите особенности публикации HTTP сервисов через Apache с использованием SSL сертификата.
Давайте внесем изменения, которые помогут стабильнее управлять соединениями:
Пример настроек в httpd.conf:
KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 100
Также для Windows-систем часто помогает добавление директивы, исправляющей работу с сетевыми сокетами:
<IfModule mpm_winnt_module>
Win32DisableAcceptEx
</IfModule>
Работа через браузер (Web-клиент) потребляет больше ресурсов и менее стабильно управляет закрытием сеансов по сравнению с Тонким клиентом.
Вместо того чтобы давать пользователям ссылку для браузера, установим им на компьютеры платформу 1С (Тонкий клиент) и настроим подключение к веб-серверу. Для упрощения этого процесса, особенно в распределенных сетях, можно применить лаунчер для 1C с проверкой доменной авторизации, который автоматизирует запуск тонкого клиента.
Преимущества такого подхода:
Адрес подключения в Тонком клиенте будет таким же, как и в браузере: http://ip-адрес-сервера/имя_базы.
Если Apache продолжает вести себя нестабильно, имеет смысл рассмотреть переход на IIS, который встроен в Windows. Для сценария с большим количеством баз (как в обсуждении — 30 штук) IIS имеет существенное преимущество — Пулы приложений (Application Pools).
В Apache перезагрузка службы перезапускает веб-сервер целиком, обрывая сеансы всех пользователей во всех базах. В IIS мы можем настроить отдельный пул приложений для каждой базы (или группы баз).
Как это помогает:
Начиная с версии 8.3.22, 1С представила Автономный сервер. Это возможность запускать файловую базу как сервис, доступный по протоколу HTTP, без необходимости установки Apache или IIS.
Однако в контексте обсуждаемой темы (30 баз на 16 ГБ ОЗУ) этот вариант нужно применять с осторожностью. Каждый экземпляр автономного сервера — это отдельный процесс ОС, который потребляет оперативную память (от 150-200 МБ в простое). Запуск 30 таких процессов может полностью исчерпать ресурсы сервера.
Необходимо понимать, что описанные выше методы — это "костыли" для попытки заставить работать архитектуру, которая для этого не предназначена. Базовая версия создана для локальной работы одного человека. Работа 30 пользователей в 30 разных базах на одном хосте создает огромную нагрузку на дисковую подсистему и процессор из-за особенностей файлового режима.
Правильный путь развития системы:
Клиент-серверная архитектура (даже в варианте Мини) полностью решает проблему "повисших" файловых блокировок, так как работой с базой данных управляет процесс rphost, а не веб-сервер напрямую.
Если апгрейд невозможен по бюджету, выполним следующие действия в строгом порядке:
default.vrd.KeepAlive в Apache и увеличим таймауты.