К статье
Практический материал

Администрирование · 15 мин

1С на сервере: как устроена и работает клиент-серверная архитектура

Как работает 1С на сервере: архитектура клиент-серверного режима, роль СУБД и агента сервера 1С, требования к ресурсам, настройка и типичные ошибки администрирования.

Когда в компании с 1С работает больше нескольких пользователей одновременно, файловый режим начинает тормозить: база блокируется целиком при записи, сеть перегружается передачей файла данных, а риск повреждения информационной базы растёт. Решение — перевод 1С в клиент-серверный режим, где данные хранит не файл на общем диске, а полноценная СУБД, а бизнес-логику выполняет отдельный сервер приложений.

Клиент-серверная архитектура 1С — трёхзвенная: клиентское приложение (толстый, тонкий или веб-клиент), сервер 1С:Предприятия и сервер баз данных. Каждое звено отвечает за свою задачу и может располагаться на отдельной физической машине. Понимание того, как эти звенья взаимодействуют, помогает правильно спланировать инфраструктуру, диагностировать проблемы производительности и не допустить потери данных.

Ниже разобрано устройство каждого компонента, порядок развёртывания, требования к ресурсам, типичные ошибки администраторов и способы проверить, что система работает корректно.

Из чего состоит клиент-серверная архитектура 1С

Первое звено — клиентское приложение. Тонкий клиент и веб-клиент выполняют минимум кода: отображают интерфейс и передают вызовы на сервер. Толстый клиент способен исполнять часть логики локально, но в серверном режиме основная нагрузка всё равно ложится на сервер. Чем «тоньше» клиент, тем меньше требования к рабочим местам пользователей и тем проще обновление.

Второе звено — сервер 1С:Предприятия. Это набор служб и процессов, которые исполняют код конфигурации, управляют сеансами пользователей, обрабатывают фоновые и регламентные задания, кешируют данные и формируют запросы к СУБД. Именно здесь выполняются проведение документов, расчёты итогов, проверки прав доступа.

Третье звено — сервер баз данных. 1С не хранит данные сама, а поручает это внешней СУБД: Microsoft SQL Server, PostgreSQL (в том числе сборка Postgres Pro), Oracle Database или IBM DB2. СУБД отвечает за транзакции, индексы, блокировки на уровне строк и целостность данных. Файл базы 1Cv8.1CD в серверном режиме не используется — таблицы размещаются в базе данных СУБД.

Как клиент, сервер 1С и СУБД взаимодействуют между собой

Когда пользователь запускает клиент и выбирает базу, происходит следующая цепочка. Клиент подключается к агенту сервера 1С по порту 1540 и запрашивает адрес рабочего процесса для нужной базы. Агент через менеджер кластера (ragent обращается к rmnsrv на порту 1541) определяет подходящий рабочий процесс rphost и возвращает клиенту его адрес и порт. Дальше клиент работает напрямую с этим rphost.

Рабочий процесс rphost исполняет код конфигурации: обработчики форм, проведение документов, запросы. Когда коду нужны данные, rphost формирует SQL-запрос и отправляет его в СУБД через клиентскую библиотеку соответствующей базы данных. Результат возвращается в rphost, обрабатывается логикой конфигурации и передаётся клиенту в виде готовых данных для отображения.

Важно понимать, что клиент никогда не обращается к СУБД напрямую. Это даёт два следствия: пользователям не нужны учётные записи в базе данных (достаточно одной сервисной учётной записи), а закрыть доступ к данным мимо 1С можно настройками самой СУБД. Весь трафик между клиентом и сервером 1С идёт по собственному протоколу платформы, который можно шифровать.

Клиент долго открывает базуПроблема на этапе подключения к агенту или выбора rphost

Доступность портов 1540–1591, DNS-разрешение имени сервера, загрузку CPU на сервере 1С

Формы открываются, но документы проводятся медленноУзкое место — СУБД или дисковая подсистема

Счётчики ожиданий СУБД, длительность запросов в технологическом журнале, очередь диска

Все пользователи отваливаются одновременноСбой рабочего процесса или агента сервера

Журнал событий ОС, логи кластера, перезапуски службы агента

Что делает кластер серверов и зачем нужны процессы rphost

Кластер серверов 1С — это группа рабочих серверов под управлением одного агента. В простейшем случае кластер состоит из одного сервера, но при росте нагрузки можно добавить второй и третий: агент будет распределять сеансы между ними. Реестр кластера (каталог srvinfo с файлом 1CV8Clst.lst) хранит список информационных баз, рабочих серверов и настроек. Повреждение или потеря этого каталога означает, что базы придётся регистрировать в кластере заново — сами данные при этом не пострадают, они в СУБД.

Рабочие процессы rphost — основные «исполнители». Каждый rphost может обслуживать несколько сеансов и потребляет оперативную память пропорционально выполняемой работе. Если процесс аварийно завершается (например, из-за нехватки памяти), пользователи, чьи сеансы обслуживал этот процесс, получают ошибку соединения. Поэтому в консоли кластера настраивают ограничения: максимальный объём памяти на процесс, допустимое число соединений, автоматический перезапуск.

Дополнительно в кластере работают вспомогательные процессы: rmngr (менеджер кластера, координирует задания) и rphost-процессы для фоновых заданий. Регламентные операции — пересчёт итогов, обмены, обновление агрегатов — выполняются именно на сервере, поэтому их расписание стоит планировать на часы минимальной нагрузки.

Требования к серверу и выбор СУБД

Точные требования зависят от числа пользователей, объёма базы и интенсивности работы, поэтому универсальных цифр нет. Общие ориентиры таковы. Для сервера 1С критичны быстрый процессор с высокой тактовой частотой (бизнес-логика 1С во многом однопоточна в рамках сеанса) и достаточный объём оперативной памяти. Для сервера СУБД важнее всего дисковая подсистема: базы данных чувствительны к задержкам записи, поэтому журнал транзакций и файлы данных размещают на быстрых дисках, желательно SSD.

Размещать сервер 1С и СУБД на одной машине допустимо для небольших внедрений — это убирает сетевые задержки между звеньями. При росте нагрузки их разносят на разные серверы, связывая быстрой сетью: обмен между rphost и СУБД интенсивный, и медленная сеть станет узким местом.

Сравнение вариантов СУБД для 1С

Microsoft SQL Server

Наиболее распространённый вариант под Windows, удобные средства администрирования. Ограничение — стоимость лицензий при большом числе ядер; редакция Express не подходит из-за ограничений на объём базы и память.

PostgreSQL / Postgres Pro

Бесплатная альтернатива, официально поддерживаемая платформой 1С. Требует более внимательной настройки (shared_buffers, work_mem, автовакуум), иначе производительность заметно проседает.

Oracle Database / IBM DB2

Применяются в крупных организациях, где эти СУБД уже используются. Высокая стоимость владения и потребность в квалифицированных администраторах.

Как развернуть 1С на сервере: порядок действий

Развёртывание выполняется последовательно, и нарушение порядка — частая причина ошибок. Сначала ставится и настраивается СУБД, затем сервер 1С той же разрядности, что и ОС, после чего база регистрируется в кластере и загружается из файловой копии или создаётся пустой.

Порядок развёртывания серверной 1С
  1. 1
    Установите СУБД, создайте сервисную учётную запись с правами на создание баз данных
  2. 2
    Установите компоненты «Сервер 1С:Предприятия» и «Администрирование сервера» на сервер приложений
  3. 3
    Откройте в брандмауэре порты 1540, 1541 и диапазон 1560–1591 между клиентами и сервером 1С
  4. 4
    Откройте консоль администрирования кластеров, создайте новую информационную базу: укажите тип СУБД, имя сервера БД, имя базы и учётные данные
  5. 5
    Загрузите данные из выгрузки .dt файловой базы через конфигуратор или создайте пустую базу из шаблона
  6. 6
    Проверьте вход тонким клиентом с рабочей станции и выполните тестовое проведение документа

После развёртывания обязательно настройте резервное копирование средствами СУБД. Выгрузка в .dt — это не замена бэкапа: она долгая на больших базах и не позволяет восстановиться на произвольный момент времени. Регулярное копирование базы и журнала транзакций средствами СУБД — обязательный минимум.

Как проверить, что серверный режим работает правильно

После запуска полезно пройтись по контрольным точкам, чтобы отличить нормальную работу от скрытых проблем, которые проявятся под нагрузкой.

Контрольные точки

Как проверить результат

Служба агента сервера 1С в оснастке services.msc или systemctl
Норма

Служба запущена, в консоли кластера видны база и активные сеансы

Тревожный признак

Служба периодически перезапускается, в журнале событий ошибки ragent или rphost

Соединение клиента с базой
Норма

Тонкий клиент подключается за секунды, сеанс виден в консоли кластера

Тревожный признак

Ошибка «сервер недоступен», таймауты, долгий выбор рабочего процесса

Нагрузка на СУБД при типовых операциях
Норма

Проведение документов и отчёты выполняются за приемлемое время без роста очереди диска

Тревожный признак

Длительные ожидания блокировок, дисковая очередь растёт, отчёты «висят» минутами

Резервное копирование
Норма

Задание бэкапа завершается успешно, тестовое восстановление на копии проходит

Тревожный признак

Копии не создаются или восстановление никогда не проверялось

Для глубокой диагностики платформа предоставляет технологический журнал — текстовые логи событий сервера: длительные запросы, блокировки, ошибки СУБД, аварийные завершения процессов. Включается он через конфигурационный файл logcfg.xml в каталоге конфигурации сервера. Постоянно держать его включённым с полной детализацией не стоит — логи быстро разрастаются и сами влияют на производительность; включайте нужные события на время расследования.

xml
<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1clogs" history="24"><event><eq property="name" value="DBMSSQL"/></event><event><eq property="name" value="EXCP"/></event><property name="all"/></log></config>

Типичные ошибки администрирования серверной 1С

Большинство проблем серверной 1С связано не с платформой, а с окружением: неверно настроенной СУБД, нехваткой ресурсов или отсутствием регламентного обслуживания. Ниже — ошибки, которые встречаются чаще всего.

Типичные ошибки
01
Установка 32-разрядного сервера 1С на 64-разрядную ОС — процесс ограничен объёмом памяти, под нагрузкой rphost аварийно завершается
02
Отключённый автовакуум или отсутствие обновления статистики в PostgreSQL — планы запросов деградируют, база «пухнет», запросы тормозят
03
Антивирус сканирует каталоги СУБД и srvinfo — растут задержки диска, возможны блокировки и повреждение файлов реестра кластера
04
Хранение базы и журнала транзакций на одном медленном диске — запись упирается в дисковую подсистему при интенсивной работе
05
Отсутствие регламентных заданий СУБД: перестроение индексов и очистка процедурного кэша не выполняются, производительность падает постепенно и незаметно
06
Полагаться только на выгрузку .dt вместо бэкапа СУБД — при сбое восстановление возможно лишь на момент последней выгрузки

Отдельно стоит сказать про сеть. Сервер 1С и сервер СУБД должны быть связаны быстрым и стабильным каналом; Wi-Fi и VPN между ними недопустимы. Клиенты же могут работать и по медленным каналам — для этого существуют тонкий и веб-клиент, которые передают только интерфейсные данные, а не запросы к базе.

Маршрут решения

Как выбрать действие

Пользователей меньше 5 и база небольшаяОставайтесь на файловом режиме, но обеспечьте регулярные копии — переход на сервер пока не окупится
Пользователей 10–50, база растёт, появляются блокировки файлового режимаРазворачивайте сервер 1С и СУБД на одной машине с SSD и достаточным объёмом RAM
Десятки-сотни пользователей, критична непрерывность работыРазносите сервер 1С и СУБД на разные машины, добавляйте второй рабочий сервер в кластер, настраивайте мониторинг и резервирование
Пользователи работают из филиалов по медленным каналамИспользуйте веб-клиент или публикацию базы на веб-сервере — трафик между клиентом и сервером минимален

Ограничения и альтернативы серверному режиму

Клиент-серверный режим требует лицензий: помимо клиентских лицензий 1С нужна лицензия на сервер 1С:Предприятия, а для MS SQL или Oracle — лицензии на саму СУБД. Это существенная статья расходов, поэтому для небольших компаний часто выбирают PostgreSQL как бесплатную СУБД. Также серверный режим требует квалифицированного администрирования: СУБД без обслуживания со временем деградирует.

Альтернативы существуют. Для небольших команд — файловый режим с размещением базы на быстром сервере (не на NAS с медленным диском). Для распределённых команд — публикация файловой или серверной базы на веб-сервере с доступом через браузер. Для компаний без своей инфраструктуры — облачные сервисы аренды 1С, где серверную часть обслуживает провайдер. Каждый вариант имеет свои ограничения по нагрузке, безопасности и стоимости.

Итог

Что важно запомнить

Серверная 1С — это три звена: клиент, сервер 1С:Предприятия с процессами ragent и rphost, и внешняя СУБД, которая хранит данные. Правильная работа зависит от настройки всех трёх звеньев: лимитов памяти кластера, обслуживания СУБД, быстрых дисков и сети. Обязательный минимум безопасности — резервное копирование средствами СУБД и блокировка сеансов перед регламентными работами.

Частые вопросы

Можно ли перенести файловую базу на сервер без потери данных?

Да. Делается выгрузка файловой базы в файл .dt через конфигуратор («Администрирование → Выгрузить информационную базу»), затем в консоли кластера создаётся пустая серверная база и в неё загружается этот файл. Пользователи, права и настройки сохраняются. Перед выгрузкой завершите все сеансы и убедитесь, что база не повреждена.

Что лучше для 1С: MS SQL или PostgreSQL?

Обе СУБД официально поддерживаются. MS SQL проще в администрировании и предсказуемее «из коробки», но требует платных лицензий. PostgreSQL бесплатен, но требует ручной настройки памяти и автовакуума, иначе производительность заметно ниже. Выбор обычно определяется бюджетом и наличием администратора с опытом конкретной СУБД.

Почему пользователей выбрасывает из базы с ошибкой соединения?

Чаще всего аварийно завершается рабочий процесс rphost — из-за нехватки памяти или внутренней ошибки. Проверьте журнал событий ОС и логи кластера, настройте ограничение памяти на процесс и перезапуск кластера. Если ошибки массовые и одновременные — проверяйте сеть между клиентами и сервером и стабильность самой службы агента.

Нужно ли открывать доступ пользователей напрямую к базе данных в СУБД?

Нет, и делать этого не следует. Клиенты 1С работают с данными только через сервер 1С, который подключается к СУБД под одной сервисной учётной записью. Прямой доступ пользователей к таблицам обходит механизмы прав 1С и создаёт риск повреждения данных — закрывайте его настройками СУБД.

Можно ли запустить сервер 1С и СУБД на одном компьютере?

Можно, и для небольших внедрений это нормальная практика: убираются сетевые задержки между звеньями. Ограничение — суммарное потребление ресурсов: серверу 1С нужны процессор и память, СУБД — память и быстрые диски. При росте числа пользователей звенья разносят на разные серверы.

Чем выгрузка .dt отличается от резервной копии СУБД?

Выгрузка .dt — логическая копия базы в формате 1С, удобная для переноса между СУБД и режимами, но медленная на больших базах и не позволяющая восстановиться на произвольный момент. Бэкап средствами СУБД выполняется быстрее, поддерживает разностные копии и восстановление на точку во времени. В серверном режиме основным средством защиты должна быть копия СУБД.