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

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

Зачем нужен сервер 1С и когда без него не обойтись

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

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

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

Важно понимать, что «сервер 1С» — это не одна программа, а связка: сам сервер предприятия (агент и рабочие процессы), СУБД (MS SQL Server, PostgreSQL, Oracle или IBM Db2) и лицензии на сервер и клиентские подключения. Ошибка в любом из этих звеньев сводит на нет преимущества всей схемы.

Чем клиент-серверный режим отличается от файлового

В файловом режиме база — это один файл 1Cv8.1CD на сетевом диске. Каждый клиент сам читает и пишет этот файл, а платформа координирует доступ через файловые блокировки. Пока работают 3–5 человек, схема приемлема. При росте нагрузки начинаются очереди на запись, ошибки «конфликт блокировки при выполнении транзакции» и резкое падение скорости при проведении крупных документов.

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

Дополнительное отличие — где выполняется код. В файловом режиме вся логика крутится на компьютере пользователя, и слабый офисный ПК становится узким местом. В серверном режиме серверные вызовы выполняются на мощной машине, а клиент получает только результат, что заметно ускоряет отчёты и обработки.

Сравнение вариантов

Файловый режим

Подходит до 5–10 пользователей и небольших баз. Прост в развёртывании, не требует отдельных лицензий на сервер, но плохо переносит конкурентную запись и рост объёма.

Клиент-серверный режим

Нужен при десятках пользователей, больших объёмах и требованиях к отказоустойчивости. Дороже по лицензиям и требует администрирования СУБД.

1С:Фреш (облако)

Альтернатива собственному серверу: инфраструктуру обслуживает оператор. Подходит, если нет своего администратора, но есть ограничения по доработкам и доступу к данным.

Какие задачи решает сервер 1С

Первая задача — параллельная работа. Сервер распределяет подключения между рабочими процессами (rphost), и каждый процесс обслуживает часть сеансов. Если один процесс «завис» на тяжёлом запросе, остальные пользователи продолжают работать. В файловом режиме такой изоляции нет в принципе.

Вторая задача — выполнение фоновых и регламентных заданий. Обмены с сайтом, загрузка курсов валют, рассылка отчётов, пересчёт итогов — всё это сервер выполняет по расписанию без участия пользователей. В файловой базе регламентные задания привязаны к сеансу конкретного пользователя и перестают работать, когда он закрывает программу.

Третья задача — безопасность. Пользователи не имеют прямого доступа к файлам данных: они подключаются к серверу, а тот — к СУБД. Пароль от базы знает только администратор, что исключает копирование базы «флешкой» через сетевую папку.

Четвёртая задача — централизованное управление: через консоль кластера администратор видит сеансы, может завершить зависший сеанс, установить блокировку соединений на время обновления и настроить требования назначения функциональности между рабочими серверами.

Пользователей больше 10–15Конкуренция за файл базы

Частые ошибки блокировок и очереди при проведении документов

База вырослаДесятки гигабайт в одном файле

Долгое тестирование, медленные отчёты, риск повреждения файла

Нужны обмены и интеграцииСайт, ЭДО, веб-сервисы

Фоновые задания должны работать круглосуточно, без привязки к сеансу

Требуется разграничение доступаЗащита от копирования базы

Прямой доступ к файлу данных должен быть закрыт

Когда сервер действительно необходим

Однозначные сценарии: одновременная работа более 10–15 пользователей, база заметного объёма с интенсивной записью (торговля с частыми продажами, складской учёт), необходимость круглосуточных обменов с внешними системами, работа через веб-клиент или тонкий клиент по интернету, требования к отказоустойчивости и резервированию.

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

Обратная ситуация: небольшая фирма с тремя бухгалтерами и одной базой. Здесь сервер не даст ощутимого выигрыша, но добавит расходы на лицензии, железо и администрирование. Разумнее остаться на файловом режиме с автоматическим резервным копированием.

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

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

До 5–10 пользователей, база небольшая, нет интеграцийОставайтесь на файловом режиме, настройте регулярные копии и мониторинг свободного места
10–30 пользователей, растут жалобы на скорость и блокировкиПланируйте переход на клиент-серверный режим с PostgreSQL или MS SQL
Более 30–50 пользователей или критичная непрерывность работыПроектируйте отказоустойчивый кластер: несколько рабочих серверов, резервирование СУБД
Нет своего администратора и инфраструктурыРассмотрите облачный вариант вместо покупки собственного сервера

Из чего состоит серверная инфраструктура

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

Выбор СУБД влияет на стоимость и трудоёмкость. PostgreSQL — бесплатный вариант, но требует грамотной настройки. MS SQL Server проще в администрировании для типовых задач, но лицензируется отдельно. Oracle и Db2 встречаются в крупных внедрениях со своими требованиями.

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

Как внедрить серверный режим без простоя

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

Обязательно проведите тестовый прогон на копии: загрузите базу, проверьте проведение ключевых документов, обмены и отчёты. Некоторые доработки, написанные под файловый режим (например, прямой доступ к файлам на диске клиента из серверного кода), в клиент-серверном режиме работают иначе или не работают вовсе.

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

Порядок перехода на серверный режим
  1. 1
    Разверните СУБД и сервер 1С, проверьте связность и права учётных записей
  2. 2
    Создайте пустую информационную базу в консоли кластера
  3. 3
    Сделайте тестовую выгрузку .dt из файловой базы и загрузите в серверную
  4. 4
    Проверьте проведение документов, отчёты, обмены и права пользователей
  5. 5
    В нерабочее время выполните финальную выгрузку и загрузку, переключите пользователей
  6. 6
    Настройте резервное копирование средствами СУБД и мониторинг рабочих процессов

Типичные ошибки и риски

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

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

Третья группа рисков — обновления. Обновление платформы на сервере без обновления клиентов (или наоборот) приводит к невозможности подключения. Обновляйте в строгом порядке: сначала сервер, затем клиентские места, с блокировкой сеансов на время работ.

Типичные ошибки
01
Ставить сервер 1С и СУБД на тот же диск, что и система, без выделенных SSD — рост базы быстро упирается в производительность дисков
02
Не настраивать СУБД после установки — параметры по умолчанию дают низкую скорость и раздувание журнала транзакций
03
Копировать файлы базы вручную вместо штатного бэкапа — копия оказывается несогласованной и не восстанавливается
04
Забывать про клиентские лицензии при расширении штата — новые пользователи не могут подключиться
05
Оставлять один рабочий процесс на всех — его падение обрывает сеансы всех пользователей

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

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

Полезно зафиксировать эталонные замеры сразу после перехода: сколько занимает проведение реализации, формирование оборотно-сальдовой ведомости, закрытие месяца. При жалобах «всё стало медленнее» сравнение с эталоном сразу покажет, деградировала ли система или проблема в конкретной операции.

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

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

Распределение сеансов в консоли кластера
Норма

Сеансы распределены между несколькими рабочими процессами

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

Все сеансы висят на одном rphost, он растёт по памяти

Резервные копии СУБД
Норма

Бэкапы выполняются по расписанию, тестовое восстановление проходит

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

Копий нет, либо восстановление ни разу не проверялось

Скорость типовых операций
Норма

Время соответствует замерам после перехода

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

Рост времени в разы без роста объёма данных

Журнал транзакций
Норма

Размер контролируется моделью восстановления и бэкапами

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

Журнал разрастается и занимает всё место на диске

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

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

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

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

Ускорит ли сервер работу одного пользователя?

Для одиночной работы выигрыш минимален, а иногда файловый режим на локальном диске даже быстрее за счёт отсутствия сетевых обращений. Сервер окупается при параллельной работе, фоновых заданиях и больших объёмах данных, а не в сценарии «один пользователь — одна база».

Какую СУБД выбрать для сервера 1С?

PostgreSQL — бесплатный и распространённый вариант, но требует внимательной настройки. MS SQL Server проще в сопровождении для типовых задач, но требует отдельных лицензий. Выбор зависит от бюджета, квалификации администратора и требований к нагрузке; заранее универсального ответа нет.

Что будет, если сервер 1С выключится во время работы?

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

Нужен ли отдельный администратор для сервера 1С?

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

Можно ли вернуться с серверного режима обратно в файловый?

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

Итог

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

Сервер 1С нужен для параллельной работы пользователей, фоновых заданий, безопасности и масштабирования. До 5–10 пользователей обычно достаточно файлового режима. Переход делайте через тестовый прогон на копии, с настройкой СУБД, штатным резервным копированием и контрольными замерами производительности.