Серверная инфраструктура для 1С:Предприятие

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

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

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

Возникает конфликт: операционной системе не хватает физической памяти, и она начинает выгружать страницы на медленный диск (swapping). Дальше производительность падает лавинообразно — интерфейс зависает, а проведение простого документа занимает минуты вместо долей секунды.

Сайзинг строится на одной особенности платформы: критичные участки кода 1С — последовательное проведение документов, расчёт скидок, партионный учёт — выполняются строго в один поток. Скорость отдельной транзакции зависит не от суммы ядер, а от частоты конкретного ядра. Для серверов приложений нужна частота не ниже 1.9–2.2 ГГц, оптимально выше 3.0 ГГц. Покупка процессора на 32–64 ядра с базовой частотой около 2.0 ГГц даёт катастрофически низкий результат в тесте Гилева при внушительной «бумажной» мощности.

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

Связка Windows Server + MS SQL Server десятилетиями была стандартом для 1С. К 2024–2026 годам доминирующим трендом стал переход на Linux + PostgreSQL и отечественные форки вроде Postgres Pro. У каждого варианта своя цена и своя сложность сопровождения.

Кластер разворачивают при преодолении порога в 100 пользователей или при нулевой терпимости к простоям — непрерывное производство, круглосуточный ритейл. Это логическое объединение нескольких независимых серверов, которые клиент видит как единую точку входа. Сеансы динамически распределяются между узлами по загрузке CPU и RAM, а при выходе из строя одного сервера пользователи переподключаются к выжившим узлам, так как данные лежат в общей СУБД.

Топологий три: простое разнесение нагрузки, схема N+1 с горячим резервом, перехватывающим нагрузку при сбое, и катастрофоустойчивый кластер с узлами в разных ЦОД и репликацией через AlwaysOn или Patroni. Эффективность кластера держится на тюнинге rphost: без него процессы склонны к утечкам памяти. Применяют регламенты — перезапуск rphost раз в 24 часа в период минимальной активности, лимит памяти процессов 80% от RAM с резервом 20% под ОС и обнуление безопасного расхода памяти за вызов, чтобы прерывать аномально тяжёлые запросы.

Существует устойчивое заблуждение, что всей экосистемой 1С должен заниматься 1С-франчайзи. Но компетенции разработчика бизнес-логики и инженера инфраструктуры лежат в разных плоскостях. Франчайзи силён в методологии учёта, программировании на языке 1С и доработке конфигураций ERP, ЗУП, УХ — это код, формы документов и расчётные алгоритмы. Метафорически, франчайзи строит «автомобиль».

Work System — IT-интегратор. Наша зона ответственности — серверная архитектура, гипервизоры (VMware, Hyper-V, KVM), построение SAN, тюнинг ядра Linux, администрирование СУБД на уровне DBA и мониторинг. Мы строим «шоссе», по которому едет этот автомобиль.

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