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

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

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

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

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

Основные компоненты клиент-серверной архитектуры:

Сервер баз данных — хранит данные и выполняет SQL-запросы. Для 1С используют Microsoft SQL Server или PostgreSQL.
Сервер приложений 1С — обрабатывает бизнес-логику конфигурации, проводит документы, выполняет серверные процедуры.
Клиентское приложение — отображает интерфейс, передаёт команды пользователя на сервер и показывает результаты.

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

Как работает клиент-серверный вариант 1С

Разберём типичный сценарий: пользователь открывает справочник номенклатуры с 50 000 позиций.

Файловый режим: что происходит на клиенте и на сервере

В файловом варианте:

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

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

Клиент-серверный режим: на клиенте и на сервере что значит

В клиент-серверном варианте:

Клиентское приложение отправляет серверу 1С запрос: «Показать номенклатуру с фильтром по группе Х».
Сервер приложений 1С формирует SQL-запрос к базе данных.
SQL Server обрабатывает запрос, применяет индексы, фильтрует данные на уровне СУБД.
Результат (только нужные строки — десятки килобайт вместо мегабайт) передаётся клиенту.
Клиент отображает данные в интерфейсе.

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

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

Файловая и клиент-серверная 1С: отличия в деталях

Сравним две архитектуры по ключевым параметрам.

Параметр	Файловая база	Клиент-серверная база
Где хранятся данные	Файл *.1CD на сетевой папке	SQL Server или PostgreSQL
Где обрабатываются запросы	На клиентском компьютере	На сервере приложений и СУБД
Нагрузка на сеть	Высокая (передаются большие объёмы данных)	Низкая (только запросы и результаты)
Требования к клиентским ПК	Высокие (нужна мощность для обработки)	Минимальные (только интерфейс)
Количество пользователей	До 5-10 без торможений	От 10 до нескольких сотен
Скорость работы с большими базами	Падает при росте данных	Остаётся стабильной при правильной настройке
Механизм блокировок	Файловые блокировки (медленно, конфликты)	Транзакционные блокировки СУБД (быстро, надёжно)
Резервное копирование	Копирование файла (требуется остановка работы)	Средства СУБД (без остановки системы)
Стоимость лицензий	Только 1С (MSQL может быть бесплатным Express)	1С + SQL Server (или бесплатный PostgreSQL)
Требования к серверу	Простой файловый сервер или NAS	Производительный сервер с быстрыми дисками и оперативной памятью

Производительность: конкретные цифры

Пример из практики: база 1С:Управление торговлей, 3 года работы, 80 ГБ данных, 15 пользователей.

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

Открытие отчёта «Анализ продаж» — 4-5 минут.
Проведение документа «Реализация товаров» с 200 позициями — 30-40 секунд.
Формирование регламентированного отчёта — до 10 минут.
При одновременной работе 10 пользователей система «встаёт».

Клиент-серверный режим (тот же объём данных):

Открытие отчёта «Анализ продаж» — 15-20 секунд.
Проведение документа с 200 позициями — 2-3 секунды.
Регламентированный отчёт — до 1 минуты.
Система стабильно работает с 20-30 пользователями одновременно.

Ускорение — в 10-20 раз при тяжёлых операциях.

Когда нужен переход на клиент-серверный вариант

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

Явные признаки, что пора переходить

Больше 5-7 одновременных пользователей. Файловая база начинает тормозить уже при 5 активных подключениях. Если в вашей компании 10+ сотрудников работают с 1С одновременно — файловый режим точно не подходит.
Размер базы превысил 10-15 ГБ. С ростом данных файловый режим экспоненциально замедляется. База на 50 ГБ в файловом варианте — это катастрофа.
Долгое выполнение операций. Если проведение документов занимает больше 10 секунд, а отчёты формируются минутами — архитектура не справляется.
Частые ошибки блокировок. Сообщения «Объект заблокирован другим пользователем» появляются регулярно — файловые блокировки работают плохо.
Регламентные операции мешают работе. Закрытие месяца или выгрузка в ЕИС блокирует базу на часы — пользователи не могут работать.
Планируется рост бизнеса. Если сейчас 5 пользователей, но через год будет 15 — лучше сразу внедрять серверную архитектуру, чем мигрировать потом.

Дополнительные факторы

Клиент-серверный вариант даёт преимущества, даже если файловая база пока справляется:

Географическая распределённость. Если есть филиалы в других городах, серверная база с удалённым доступом работает быстрее, чем VPN к файловой.
Высокие требования к безопасности. СУБД даёт гранулированные права доступа на уровне таблиц и полей, шифрование, аудит изменений.
Интеграция с другими системами. Клиент-серверная база легче интегрируется с внешними приложениями через SQL-запросы.
Отказоустойчивость. SQL Server поддерживает кластеризацию, репликацию, зеркалирование — файловая база этого не умеет.

Выбор оборудования для клиент-серверной 1С

Производительность серверной базы 1С критически зависит от железа. Экономия на сервере приведёт к тому, что клиент-серверный вариант будет работать не быстрее файлового.

Процессор: частота важнее ядер

1С и SQL Server активно используют несколько ядер, но не масштабируются линейно. Для базы с 10-20 пользователями достаточно 4-8 физических ядер с высокой тактовой частотой. Лучше процессор Intel Xeon с частотой 3.0+ ГГц, чем модель с 16 ядрами на 2.0 ГГц.

Для баз с 20-50 пользователями выбирайте серверы с процессорами уровня Intel Xeon Gold или Platinum. Актуальные модели — Intel Xeon Gold 5300/6300 серий или более новые поколения.

Оперативная память: не экономьте

SQL Server кэширует данные в оперативной памяти. Чем больше памяти — тем больше «горячих» данных хранится в ОЗУ, тем реже обращение к дискам.

Минимальные требования:

До 10 пользователей: 16 ГБ RAM.
10-30 пользователей: 32-64 ГБ RAM.
30-100 пользователей: 64-128 ГБ RAM.
Более 100 пользователей: от 128 ГБ и выше.

Учитывайте объём базы: хорошо, если в оперативную память помещается вся база целиком. Для базы на 50 ГБ желательно иметь 64+ ГБ RAM (с учётом операционной системы и других процессов).

Если планируете апгрейд, выбирайте серверы с большим количеством слотов под память. Например, серверная оперативная память стандартов DDR4/DDR5 легко добавляется в процессе эксплуатации.

Дисковая подсистема: самое узкое место

Скорость дисков — критичный параметр для 1С. База данных постоянно читает и пишет на диск. HDD 7200 RPM категорически не подходит для серверной 1С.

Рекомендации:

SSD NVMe — идеальный вариант. Скорость чтения/записи в 10-50 раз выше HDD. Задержки (latency) минимальны.
SAS SSD — альтернатива для корпоративных серверов, где важна надёжность и горячая замена дисков.
RAID 10 — оптимальная конфигурация: скорость + надёжность. Требуется минимум 4 диска.
RAID-контроллер с кэшем — обязательно. Контроллеры PERC (для Dell) с кэшем 2-4 ГБ заметно ускоряют запись.

Не экономьте на дисках. Разница в цене между HDD и SSD окупается производительностью за первые месяцы работы.

Сетевая инфраструктура

Хотя клиент-серверный вариант снижает нагрузку на сеть, всё равно важна пропускная способность. Минимум — Gigabit Ethernet (1 Гбит/с). Для крупных баз с интенсивным обменом данными рекомендуется 10 GbE.

Если серверов несколько (кластер 1С, отдельные серверы для СУБД и приложений), они должны быть в одной высокоскоростной сети.

Примеры конфигураций серверов для 1С

Малый бизнес (до 15 пользователей):

Процессор: Intel Xeon E-2300 (4 ядра, 3.5 ГГц).
Память: 32 ГБ DDR4.
Диски: 2× SSD SATA 960 ГБ в RAID 1.
Форм-фактор: Tower-сервер (если нет серверной стойки).

Средний бизнес (15-50 пользователей):

Процессор: 2× Intel Xeon Gold 5320 (26 ядер, 2.2 ГГц).
Память: 128 ГБ DDR4.
Диски: 4× SSD NVMe 1.92 ТБ в RAID 10.
Форм-фактор: Rack-сервер 2U (для монтажа в стойку).

Крупный бизнес (более 50 пользователей):

Процессор: 2× Intel Xeon Platinum 8300 (32+ ядер).
Память: 256-512 ГБ DDR4/DDR5.
Диски: 6-8× SSD NVMe в RAID 10 + выделенные диски для логов.
Отказоустойчивость: кластер из 2+ серверов, репликация SQL Server Always On.

Для компаний, работающих с 1С на постоянной основе, рекомендуем выбирать конфигурации из линейки серверов для 1С — они оптимизированы под специфику нагрузки платформы.

Миграция с файловой базы на клиент-серверную

Переход на клиент-серверный вариант — это не просто копирование данных. Процесс требует планирования и тестирования.

Основные этапы миграции

Подготовка сервера. Установка операционной системы (Windows Server), СУБД (SQL Server или PostgreSQL), платформы 1С:Предприятие в серверном режиме.
Создание пустой базы на SQL Server. Через конфигуратор 1С создаётся новая информационная база с типом «Клиент-сервер», указывается подключение к SQL Server.
Выгрузка данных из файловой базы. Стандартная выгрузка в формат *.dt через конфигуратор.
Загрузка данных в серверную базу. Восстановление из *.dt файла в клиент-серверную базу.
Проверка работоспособности. Тестовые сценарии: проведение документов, формирование отчётов, обмен данными с внешними системами.
Настройка производительности. Индексы, планы обслуживания SQL Server, параметры кластера 1С.
Переключение пользователей. Изменение строк подключения в клиентских приложениях 1С.

Типичные ошибки при миграции

Недооценка размера базы. При переносе большой базы (100+ ГБ) выгрузка-загрузка может занять сутки. Планируйте простой.
Отсутствие тестирования. Некоторые запросы и обработки могут работать некорректно на SQL Server — требуется адаптация.
Слабое оборудование. Сервер, который «тянет» файловую базу как файловое хранилище, не потянет роль сервера приложений + СУБД.
Игнорирование настройки SQL Server. Параметры по умолчанию — не оптимальны для 1С. Нужна тонкая настройка: размер памяти, степень параллелизма, планы обслуживания.

Обслуживание серверной базы 1С

Клиент-серверная база требует регулярного обслуживания. В отличие от файлового режима, где достаточно периодически делать резервную копию, здесь нужна работа с СУБД.

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

SQL Server позволяет делать резервные копии без остановки работы пользователей. Настройте автоматическое резервное копирование:

Полная копия — раз в неделю (в выходные).
Дифференциальная копия — ежедневно (ночью).
Копия журнала транзакций — каждые 1-2 часа (для минимизации потерь данных).

Храните копии на отдельном хранилище, не на том же сервере. Периодически проверяйте восстановление из резервной копии.

Мониторинг производительности

Следите за ключевыми метриками:

Загрузка процессора — не должна постоянно быть выше 80%.
Использование памяти — SQL Server должен использовать выделенную память полностью (это нормально).
Длительность запросов — если запросы выполняются больше нескольких секунд — ищите проблемные места.
Блокировки — deadlock'и (взаимные блокировки) говорят о проблемах в коде или индексах.

Используйте встроенные средства 1С (Технологический журнал) и SQL Server (Performance Monitor, DMV-запросы) для диагностики.

Переиндексация и обновление статистики

Со временем индексы фрагментируются, статистика устаревает — запросы замедляются. Настройте автоматические планы обслуживания SQL Server:

Переиндексация (Rebuild Index) — раз в неделю.
Обновление статистики (Update Statistics) — ежедневно.
Проверка целостности (DBCC CHECKDB) — раз в месяц.

Платформа 1С также имеет встроенные средства тестирования и исправления базы — используйте их при возникновении ошибок.

Альтернативные решения: кластер серверов и разделение ролей

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

Разделение сервера приложений и СУБД

Вместо того чтобы держать сервер 1С и SQL Server на одной машине, их разносят:

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

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

Кластер серверов 1С

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

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

Кластеризация требует дополнительных лицензий 1С и более сложной настройки, но для крупных компаний (100+ пользователей) это стандартное решение.

Часто задаваемые вопросы

Можно ли использовать клиент-серверный вариант для малого бизнеса с 3-5 пользователями?

Можно, но экономически не всегда оправдано. Если база небольшая (до 5 ГБ) и пользователи работают последовательно, файловый режим справится. Но если планируется рост или база интенсивно используется одновременно несколькими сотрудниками — лучше сразу внедрять клиент-серверный вариант. Затраты на миграцию позже будут выше, чем на первоначальное развёртывание.

Какую СУБД выбрать: Microsoft SQL Server или PostgreSQL?

Для продакшн-систем рекомендуется Microsoft SQL Server Standard или Enterprise (в зависимости от масштаба). PostgreSQL бесплатен и работает хорошо, но требует более глубокой экспертизы для настройки и поддержки. Если у вас есть администратор БД с опытом PostgreSQL — это отличный выбор для экономии на лицензиях. Если нет — SQL Server проще в эксплуатации и имеет больше готовых инструментов мониторинга.

Как долго длится миграция с файловой базы на клиент-серверную?

Зависит от размера базы. Маленькая база (до 10 ГБ) мигрирует за 2-4 часа. База на 50-100 ГБ — от 8 до 24 часов. Гигантские базы (500+ ГБ) могут мигрировать несколько суток. Планируйте миграцию на выходные или нерабочее время. Учтите время на подготовку сервера, настройку СУБД и тестирование — общий проект может занять неделю.

Нужно ли переписывать конфигурацию 1С при переходе на клиент-серверный вариант?

Стандартные конфигурации (УТ, БП, ERP) работают без изменений. Если у вас типовая конфигурация без доработок — переписывать ничего не нужно. Если есть кастомные обработки или изменения в коде, может потребоваться адаптация: некоторые запросы нужно оптимизировать под SQL, управляемые блокировки использовать правильно. В 90% случаев конфигурация мигрирует без проблем.

Можно ли вернуться с клиент-серверной базы обратно на файловую?

Технически — да, через выгрузку-загрузку данных. Но это имеет смысл только в исключительных случаях (например, резкое сокращение пользователей). Обратный переход уничтожит все преимущества производительности. Если клиент-серверный вариант работает медленно — дело не в архитектуре, а в неправильной настройке или слабом оборудовании. Лучше устранить проблему, чем откатываться назад.