Сколько серверов нужно для 1С: практический расчёт

Количество серверов для 1С определяется не числом сотрудников в компании, а тремя факторами: сколько пользователей работает одновременно, какой объём базы и какие конфигурации запущены. Небольшой фирме на 5–10 бухгалтеров часто хватает одного физического сервера, а распределённой компании с сотнями сеансов требуется кластер из нескольких машин с разделением ролей.

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

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

От чего зависит количество серверов

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

Второй фактор — объём и интенсивность работы базы данных. База в 10 ГБ с редкими документами и база в 500 ГБ с тысячами проведений в час — принципиально разные нагрузки на СУБД. Тяжёлые регламентные операции (расчёт себестоимости, закрытие месяца в ERP) могут загружать сервер СУБД на часы.

Третий фактор — требования к доступности. Если остановка 1С на час означает остановку отгрузки со склада или касс, одного сервера без резервирования недостаточно независимо от числа пользователей. Чем выше цена простоя, тем сильнее аргумент в пользу отказоустойчивой схемы.

Схемы развёртывания: от одного сервера до кластера

Существует несколько типовых схем, и выбор между ними — это компромисс между стоимостью, производительностью и надёжностью.

Один сервер: 1С и СУБД вместе

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

Два сервера: разделение ролей

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

Кластер из трёх и более серверов

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

Сравнение схем развёртывания

Один сервер (1С + СУБД)

До ~15–20 пользователей. Дёшево и просто, но единая точка отказа и конкуренция за ресурсы.

Два сервера (1С и СУБД раздельно)

Оптимум для 20–100 пользователей. Разделение нагрузки, проще масштабировать, но отказ любого узла останавливает работу.

Кластер 3+ серверов

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

Как рассчитать нагрузку на практике

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

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

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

1. 1
   Замерьте пиковое число одновременных сеансов в консоли кластера за 1–2 недели
2. 2
   Определите размер базы данных и темпы её роста
3. 3
   Оцените тяжесть регламентных операций: закрытие месяца, обмены, отчёты
4. 4
   Выберите схему: один сервер, два сервера или кластер
5. 5
   Рассчитайте ресурсы каждого узла с запасом 30–50% на рост
6. 6
   Проверьте работу под нагрузкой до перевода пользователей в боевую среду

Требования к оборудованию и виртуализация

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

Виртуализация (Hyper-V, VMware, Proxmox) — рабочая и распространённая практика для 1С. Она упрощает резервное копирование, миграцию и масштабирование. При этом важно не допускать чрезмерной переподписки ресурсов: если несколько виртуальных машин конкурируют за одни физические ядра и диски, производительность 1С заметно падает. Виртуальным машинам с СУБД ресурсы лучше резервировать жёстко.

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

Резервирование и отказоустойчивость

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

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

Типичные ошибки при планировании

Самая распространённая ошибка — считать по числу лицензий, а не по пиковым сеансам. Компания покупает сервер «на 50 лицензий», хотя одновременно работают 12 человек, и переплачивает. Обратная ситуация хуже: сервер выбран по средней загрузке и не выдерживает закрытие месяца.

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

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

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

Как проверить, что мощности хватает

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

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

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

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

Загрузка CPU в пиковые часы

Норма

Стабильно ниже 70–80%

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

Постоянно под 100%, очередь процессов растёт

Оперативная память

Норма

Есть свободный резерв, нет активного свопинга

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

Постоянный своп, СУБД вытесняется из памяти

Время типовых операций

Норма

Стабильно изо дня в день

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

Растёт с ростом числа пользователей

Взаимоблокировки в СУБД

Норма

Единичные случаи

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

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

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

Можно ли обойтись одним сервером на 30 пользователей?

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

Что лучше: один мощный сервер или два слабее?

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

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

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

Подойдёт ли для 1С облачный сервер вместо физического?

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

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

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

Нужен ли отдельный сервер для тестовой базы?

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