Эксперты в подборе IT-оборудования
Публикация базы на веб-сервере делается одинаково для файлового и клиент-серверного варианта: ставите модуль расширения, выдаёте права, публикуете из конфигуратора. Сама процедура с настройками IIS и Apache разобрана отдельно - веб-сервер для 1С.
Здесь про другое: что меняется, когда за адресом стоит файловая база. Права нужны шире, чем кажется; блокировки начинают мешать раньше, чем ожидаешь; конфигуратор перестаёт открывать базу монопольно; бэкап, который работал раньше, начинает отдавать битые копии.
Ни одна из этих вещей не чинится настройкой веб-сервера. Это свойства файлового варианта, и знать их лучше до публикации.
Самая частая ошибка при публикации файловой базы - выдать учётной записи веб-сервера права только на чтение. Логика понятная: пользователи же просто смотрят данные. На деле платформа пишет в каталог базы постоянно, даже когда никто ничего не меняет: файлы блокировок, служебный журнал, временные файлы сеансов.
Поэтому правило простое: учётной записи веб-сервера нужны и чтение, и запись в каталог с базой.
| Веб-сервер | Кому выдавать | Что выдавать |
|---|---|---|
| IIS | Пользователь IUSR и группа IIS_IUSRS | «Чтение и выполнение» плюс «Изменение» на каталог базы |
| Apache на Windows | Учётная запись службы Apache (по умолчанию системная) | То же самое |
| Apache на Linux | www-data (Debian, Ubuntu) или apache (CentOS, RHEL) | Чтение каталога платформы, чтение и запись каталога базы |
Здесь ломается чаще всего, и симптом сбивает с толку: локально всё открывается, а через браузер база не видна.
Причина в том, что служба веб-сервера по умолчанию работает от системной учётной записи, а системная учётка машины в сеть под своим именем не ходит. До папки на соседнем файловом сервере она не дотянется, какие бы права на шаре вы ни выставили.
Лечится это одним из двух способов. Либо перевести службу веб-сервера на доменную учётную запись, у которой есть права на сетевую папку, - тогда она будет ходить на шару под своим именем. Либо, что надёжнее и быстрее, положить файловую базу на ту же машину, где стоит веб-сервер, и не гонять файл базы по сети вообще.
Второй вариант выигрывает и по скорости. Файловая база по сети работает заметно медленнее локальной: платформа читает и пишет мелкими порциями, и каждая такая операция превращается в сетевой запрос. Веб-доступ этого не исправляет.
Ожидание, которое чаще всего не оправдывается: опубликовали базу на веб-сервере - и теперь в неё можно пустить полкомпании. Веб-доступ меняет способ подключения, механика работы с файлом остаётся прежней.
Файловый вариант рассчитан на небольшие рабочие группы. Комфортно работают примерно три-пять человек одновременно; на десятке система идёт заметно тяжелее. Жёсткого предела платформа не ставит - ограничение практическое, и упирается оно в блокировки.
В файловом варианте область данных блокируется на время изменения, а параллельное проведение документов невозможно в принципе. Пока один пользователь проводит документ, остальные ждут. В толстом клиенте это заметно как подтормаживание, через браузер выглядит хуже: форма просто висит без объяснений, и человек жмёт кнопку ещё раз.
Отсюда практический вывод. Если после публикации жалуются на «тормоза веб-клиента», причину чаще всего ищут в веб-сервере и канале, а лежит она в другом месте: сколько человек одновременно работают с базой и что именно они делают. Пять бухгалтеров, проводящих документы в конце месяца, нагружают файловую базу сильнее, чем двадцать человек, читающих отчёты.
Конфигуратор перестаёт открывать базу монопольно. После публикации базу начинают держать веб-сеансы - даже если браузер у всех закрыт, сеанс живёт до истечения таймаута. Конфигуратор при попытке обновить конфигурацию сообщает, что база заблокирована.
Сообщение «База данных заблокирована» на файловой базе почти всегда означает именно это, а не повреждение файла. Порядок действий: завершить активные сеансы, дождаться, пока отвалятся зависшие, и только потом открывать конфигуратор. На время серьёзных работ - обновления конфигурации, тестирования и исправления - проще временно снять публикацию, а после вернуть.
Зависший сеанс некому убить. Вот это отличие от клиент-серверного варианта чувствуется больнее всего. В клиент-серверной базе есть консоль администрирования кластера, где сеанс виден списком и снимается одной кнопкой. В файловом варианте такой консоли нет: управлять сеансами приходится изнутри самой базы - пользователь с правами администратора открывает «Администрирование → Блокировка работы пользователей», ставит блокировку установки соединений и завершает работу остальных.
Проблема в том, что до веб-доступа «завершить сеанс» означало подойти к коллеге и попросить закрыть 1С. Теперь на том конце браузер, который могли закрыть кнопкой крестика или вовсе усыпить вместе с ноутбуком. Такой сеанс продолжает держать базу, пока не истечёт таймаут, и ускорить это снаружи нечем. Отсюда практика: обновления конфигурации планируют на окно, а не делают «по-быстрому между делом», как это работало на двух коллегах в соседней комнате.
Схема, которая работала до публикации, после неё может начать отдавать битые копии.
Копировать файл 1Cv8.1CD на ходу нельзя. Пока с базой кто-то работает, файл меняется в процессе копирования, и на выходе получается архив, из которого база не поднимется. Хуже всего то, что заметно это станет в тот единственный день, когда копия понадобится.
Рабочих вариантов два:
Копия файловой базы, снятая штатным средством резервного копирования «на живую», без теневых копий тома или остановки службы - это не резервная копия, а надежда на неё. Общие схемы бэкапа разобраны в материале про резервное копирование 1С.
Отдельно стоит упомянуть, потому что сообщение сбивает с толку и его часто списывают на файловый вариант.
«Невозможна публикация на веб-сервере из-за разной разрядности платформы» к файловой базе отношения не имеет. Это несовпадение разрядности веб-сервера и платформы 1С. Для IIS параметр «Разрешены 32-разрядные приложения» в дополнительных параметрах пула должен стоять False для 64-разрядной платформы и True для 32-разрядной. Для Apache сборка веб-сервера должна быть той же разрядности, что и платформа.
Какой файл модуля к какому серверу относится и что делать, когда он не грузится, разобрано в статье про модуль расширения веб-сервера 1С.
Заодно про Apache: ставить нужно версию 2.4 нужной разрядности. Ветка 2.2 закончилась релизом 2.2.34 в июле 2017 года, обновления безопасности для неё давно не выходят, и модуль 1С для неё тоже отдельный. Старые инструкции, которые до сих пор попадаются в поиске, советуют именно 2.2 - не следуйте им.
Признаки, по которым пора считать переезд на клиент-серверный вариант:
Переезд на клиент-серверный вариант снимает блокировки файлового уровня и даёт нормальное резервное копирование средствами СУБД. Публикацию переделывать не придётся: адрес остаётся тем же, меняется только строка соединения в настройках публикации. Подключаться можно всё так же через браузер или тонким клиентом по HTTP.
Считать переезд стоит вместе с железом. Файловая база упирается прежде всего в скорость накопителя и частоту процессора - многопоточность в этом варианте почти не используется, и многоядерный сервер ей не поможет. Клиент-серверная нагрузка распределяется иначе, и конфигурация под неё получается другая. Как это считать под конкретное число пользователей, разобрано в материале про сборку сервера для 1С.
И последнее, вне зависимости от варианта базы. Публикация не добавляет ни шифрования, ни аутентификации сверх той, что настроена внутри 1С. Если база будет доступна из интернета, HTTPS обязателен, а список пользователей и их права надо привести в порядок до публикации. Пускать файловую базу наружу по голому HTTP не стоит ни при каком объёме.
Собираете сервер под 1С?
Под файловую базу и под клиент-серверную конфигурации получаются непохожие, и «взять помощнее» тут не работает - переплатите за ядра, которые простаивают. Инженеры ITTELO подберут сервер под ваше число пользователей и объём базы, соберут и протестируют под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
