Переход с файлового режима на клиент-серверный в 1С: ключевые шаги и риски

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

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

Аудит инфраструктуры и предварительная оценка

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

Отдельного внимания заслуживает конфигурация прикладного решения. Зачастую код, написанный под файловый режим, использует прямые обращения к файловой системе, монопольные блокировки или специфические возможности встроенного языка, которые ведут себя иначе на сервере 1С. Чем раньше удастся выявить такие места, тем спокойнее пройдёт опытная эксплуатация.

Выбор СУБД и аппаратной платформы

Платформа 1С:Предприятие поддерживает несколько СУБД: PostgreSQL, Microsoft SQL Server, IBM Db2, а также Oracle Database. Наиболее распространённый выбор для российских компаний — PostgreSQL благодаря отсутствию лицензионных отчислений и активной поддержке версии для 1С. Microsoft SQL Server популярен там, где уже есть соглашения с вендором и развитая экспертиза DBA.

При подборе сервера учитывают три параметра: объём оперативной памяти, быстродействие дисковой подсистемы и количество ядер процессора. На практике под сервер 1С обычно выделяют машину с 32–128 ГБ ОЗУ, SSD или NVMe массивом, а СУБД размещают на отдельном хосте, чтобы снизить конкуренцию за ресурсы.

Установка сервера 1С и настройка кластера

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

Отдельно стоит проверить сетевые порты и протоколы. По умолчанию сервер 1С использует диапазон 1541–1545, а менеджер кластера — 1540. Если в инфраструктуре действует строгий межсетевой экран, эти порты открывают заблаговременно, иначе клиенты не смогут подключиться к базе.

Перенос информационных баз

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

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

Лицензирование и разграничение доступа

Клиент-серверный режим меняет подход к лицензиям. Вместо аппаратного ключа или программной лицензии на каждый компьютер используется серверная лицензия и лицензии на рабочие места, которые раздаёт сервер 1С. Это удобнее для крупных компаний, но требует корректной активации и регулярной проверки через утилиту ring.

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

Тонкая настройка после миграции

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

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

Типичные ошибки и как их избежать

На этапе миграции чаще всего встречаются следующие ситуации:

• Запуск сервера 1С под учётной записью с недостаточными правами к каталогам и СУБД.
• Открытие портов только на одном сетевом интерфейсе, из-за чего клиенты из других подсетей не подключаются.
• Пропущенная настройка регламентных операций обслуживания СУБД: вакуумизация в PostgreSQL, реиндексация в MS SQL.
• Хранение журнала регистрации в файловом каталоге вместо отдельной таблицы СУБД, что быстро приводит к разрастанию базы.
• Отсутствие резервного копирования на новой площадке, из-за чего первая же авария становится критичной.

Дополнительные ориентиры по оптимизации прикладного кода:

• Использовать прямые запросы к СУБД только там, где это действительно оправдано.
• Выносить тяжёлые вычисления в фоновые задания с контролем утечек памяти.
• Минимизировать обращения к точке Получить() в циклах по большим коллекциям.
• Контролировать размер таблиц значений и при необходимости потоково выгружать их во временные таблицы.
• Регулярно анализировать план запроса средствами технологического журнала.

Если вы планируете перевод базы на клиент-серверный режим или уже столкнулись с трудностями на одном из этапов, загляните на форум сообщества 1С: обсуждения, готовые обработки и рекомендации практиков помогут ускорить миграцию и избежать повторных ошибок.