+7 (844) 245-94-88
pc@huananzhi.ru
Вопрос, какой сервер нужен для 1С, возникает у любой компании, как только база вырастает за пределы одного компьютера. Ошибка в подборе железа оборачивается не абстрактным неудобством, а конкретными потерями: документы проводятся по 5–10 секунд, отчёты формируются по несколько минут, а в конце месяца при закрытии периода сервер для 1С может просто «встать». Разберём, на какие параметры смотреть в первую очередь и почему логика подбора сервера под 1С отличается от подбора обычного офисного или файлового сервера.
Чем сервер для 1С отличается от обычного
Главная особенность 1С:Предприятие в том, что операции проведения документов, расчёта себестоимости и формирования отчётов выполняются преимущественно в один поток. Платформа далеко не всегда умеет эффективно распараллеливать одну операцию между десятками ядер. Поэтому классический подход «чем больше ядер, тем быстрее» здесь работает не так, как для веб-сервера или виртуализации. Для 1С важнее не суммарное число ядер, а то, насколько быстро процессор выполняет один поток вычислений.
Почему частота ядра важнее их количества
Если упростить: 24-ядерный Xeon с частотой 2.0 ГГц может проигрывать в проведении документов 8-ядерному процессору с частотой 3.2–3.5 ГГц, потому что каждая отдельная операция 1С упирается в скорость одного ядра, а не в их число. Это касается серверов линеек Xeon E5 v3 и v4: среди них есть модели с меньшим числом ядер, но высокой базовой и турбо-частотой, и именно они, как правило, выгоднее для сервера 1С, чем топовые 18-22-ядерные модели с низкой частотой. Подробнее о том, как читать характеристики и на что смотреть при выборе камня под сервер, мы разбирали в статье как выбрать серверный процессор.
Особенности сервера СУБД: PostgreSQL и MS SQL
Если база работает в клиент-серверном варианте на PostgreSQL или MS SQL Server, требования смещаются. Серверу СУБД нужны одновременно быстрые ядра, достаточный их запас (СУБД параллелит запросы иначе, чем платформа 1С) и много оперативной памяти под кэш данных. Чем больше активных пользователей и чем крупнее база, тем выше цена ошибки: нехватка памяти заставляет СУБД постоянно обращаться к диску, а слабый диск сводит на нет весь выигрыш от быстрого процессора. Поэтому сервер под 1С с СУБД обычно проектируют с запасом по памяти и обязательно на быстром накопителе.
Отдельный вопрос: держать сервер 1С и сервер СУБД на одной машине или разносить на два физических сервера. Для небольшой компании с одной базой и умеренной нагрузкой разумнее одна машина: меньше затрат на железо и обслуживание. Когда пользователей становится больше десяти-пятнадцати, а база растёт быстро, разнесение кластера СУБД и сервера приложений 1С на отдельные машины снимает конкуренцию за процессорное время и память, и общая производительность становится предсказуемее.
Диск под базу: почему только SSD и лучше NVMe
Диск, на котором лежит база 1С, определяет скорость работы почти так же сильно, как процессор. Обычный HDD, даже быстрый серверный, создаёт задержки на каждой операции чтения-записи, а база 1С генерирует огромное количество мелких случайных операций ввода-вывода. Переход с HDD на SSD, а тем более на NVMe, ускоряет работу базы в разы за счёт высоких IOPS и низкой задержки. Практический вывод простой: под базу 1С ставится только SSD, и если бюджет позволяет, лучше NVMe. Для отказоустойчивости диски под базу объединяют в RAID 1 или RAID 10 из SSD, чтобы выход одного накопителя из строя не остановил работу. Актуальные варианты SSD под серверные задачи можно посмотреть в каталоге SSD.
Память: сколько нужно и почему ECC REG
Оперативная память для сервера 1С должна быть серверного класса, ECC Registered. Такая память умеет обнаруживать и исправлять единичные ошибки бит без остановки системы, что критично для сервера, который работает круглосуточно и хранит финансовые данные. По объёму разумно закладывать запас: 64–128 ГБ и выше уже комфортны для средних баз и нескольких десятков одновременных пользователей, с учётом кэша СУБД и работы операционной системы. Если на том же сервере крутится ещё и терминальный доступ (RDP), объём памяти нужно считать отдельно на каждого подключённого пользователя, поверх памяти для самой базы и СУБД. Разница между обычной и регистровой памятью, а также как правильно считать объём под нагрузку, подробно разобрана в материале как выбрать серверную память DDR4 ECC REG.
Терминальный режим: сервер приложений и RDP на одной машине
Многие компании разворачивают на одном сервере сразу и базу 1С, и сервер приложений, и терминальный доступ по RDP, чтобы сотрудники подключались удалённо. Это удобно, но заметно повышает требования к суммарной памяти: каждый подключённый по RDP пользователь запускает собственный сеанс 1С, который потребляет отдельный блок оперативной памяти сверх той, что нужна самой базе. Планируя такой сервер под 1С, стоит закладывать память с запасом на рост числа сотрудников, а не впритык под текущий штат.
Загрузка процессора в терминальном режиме тоже растёт нелинейно: одновременная работа десятка сотрудников в терминале означает, что процессору приходится параллельно обслуживать несколько независимых сеансов 1С, и здесь уже пригодится не только высокая частота, но и разумный запас по числу ядер. Такой сервер получается компромиссным: не самый высокочастотный процессор из линейки, но с достаточным числом ядер, чтобы терминальные сессии не мешали друг другу.
Типовые конфигурации под разное число пользователей
Ниже ориентировочная логика подбора: чем больше пользователей и крупнее база, тем выше требования к ядрам, памяти и дисковой подсистеме. Итоговая конфигурация всегда уточняется под конкретную базу и режим работы (файловый или клиент-серверный).
| Параметр | До 5 пользователей | До 10–15 пользователей | 15+ пользователей / СУБД |
|---|---|---|---|
| Режим базы | Файловая или клиент-серверная | Клиент-серверная (PostgreSQL / MS SQL) | Клиент-серверная, отдельный сервер СУБД желателен |
| Процессор | Xeon с высокой частотой, немного ядер | Xeon с высокой частотой, среднее число ядер | Xeon с высокой частотой и увеличенным числом ядер |
| Память | 32–64 ГБ ECC REG | 64–128 ГБ ECC REG | 128 ГБ ECC REG и выше |
| Диск под базу | SSD, RAID 1 | NVMe, RAID 1 или RAID 10 | NVMe, RAID 10 |
Как выбрать сервер под 1С
- Считать нагрузку от количества одновременных пользователей и режима работы (файловая база или клиент-сервер), а не только от размера базы в гигабайтах.
- Для сервера 1С отдавать приоритет высокой частоте ядра процессора, а не максимальному числу ядер, особенно если это единственный сервер без отдельной СУБД.
- Для сервера СУБД (PostgreSQL, MS SQL) закладывать баланс: достаточно ядер, много памяти и быстрый диск, потому что здесь нагрузка распределяется иначе, чем в самой платформе 1С.
- Под базу ставить только SSD, по возможности NVMe, и объединять диски в RAID 1 или RAID 10 для отказоустойчивости.
- Память брать серверную, ECC Registered, с запасом по объёму: 64–128 ГБ и выше для средних баз и нескольких пользователей.
- Если планируется терминальный режим (RDP на этом же сервере), добавлять память отдельно под каждого пользователя сверх потребностей самой базы.
- Закладывать запас по всем параметрам на рост числа сотрудников и объёма данных на 2–3 года вперёд, а не подбирать конфигурацию впритык.
Мы, huananzhi.ru, официальный дистрибьютор HUANANZHI в России и подбираем серверные конфигурации под 1С каждый день: от процессора и памяти до дисковой подсистемы под конкретную базу и число пользователей. В каталоге готовых серверов под 1С собраны конфигурации на Xeon E5 v3/v4 с ECC REG памятью и SSD/NVMe накопителями. Напишите нам параметры вашей базы и число пользователей: поможем подобрать конфигурацию, выставим счёт, дадим гарантию и организуем доставку по всей России.
Перед покупкой сервера замерьте текущую скорость проведения документов в проблемные моменты (закрытие месяца, регламентные операции). Если узкое место в диске, апгрейд на NVMe часто даёт больший эффект за те же деньги, чем смена процессора. Если узкое место в процессоре, поможет только замена на модель с более высокой частотой ядра.
Резервное копирование и отказоустойчивость
Резервное копирование для 1С строится от СУБД, а не от платформы. Для PostgreSQL используйте pg_basebackup для полной копии и непрерывное архивирование WAL — это даёт PITR (point-in-time recovery) и RPO от 1–5 минут. Для MS SQL Server — полная копия раз в неделю, дифференциальная ежедневно, журнал транзакций каждые 15–30 минут; в простой модели восстановления лог не работает. Для файловых баз копируйте .1CD только при остановленной службе, иначе получите битый архив.
Выгрузка .dt через конфигуратор — не замена бэкапу СУБД: она не даёт актуального состояния на момент сбоя и долго восстанавливается на больших базах.
Храните копии на отдельном носителе: NAS, SAN или объектное хранилище. Держать бэкап на том же RAID, что и база — типовая ошибка. Проверяйте восстановление раз в квартал на тестовом стенде.
Отказоустойчивость:
- RAID 10 под базу, hot spare. RAID 5 на NVMe — потеря ёмкости и риск долгого rebuild.
- Два БП, UPS, ECC-память — обязательны.
- PostgreSQL: потоковая репликация на standby, synchronous_commit = remote_write или on, Patroni для авто-failover. RPO 0–5 сек, RTO 30–60 сек.
- MS SQL: AlwaysOn Availability Groups с синхронным режимом.
- Кластер серверов 1С (ЦКС): несколько app-серверов, балансировка, изоляция сеансов.
Для 50–100 пользователей минимальная схема: primary + standby на отдельном хосте, бэкап на NAS, RPO 5 минут, RTO 15 минут.
Локальный сервер или облако
Выбор между локальным сервером и облаком для 1С определяется задержкой сети, требованиями к кастомизации и наличием администратора.
| Критерий | Локальный сервер | Облако (IaaS/1cfresh) |
|---|---|---|
| Задержка до СУБД | менее 1 мс | 5–40 мс |
| Кастомизация, внешние компоненты | любая | ограничена |
| Размер базы | без ограничений | обычно до 100–200 ГБ |
| Капзатраты на 30 польз. | 400–700 тыс. ₽ | 15–30 тыс. ₽/мес |
| Администрирование | свой или подрядчик | на стороне провайдера |
Облако оправдано, если работа идёт только через RDP, нет тяжёлых доработок и не нужен прямой доступ к оборудованию. 1cfresh подходит для типовых конфигураций, но не для отраслевых и доработанных. IaaS даёт больше контроля, но администрирование ОС и СУБД остаётся на вас.
Локальный сервер выбирают при базе свыше 200 ГБ, обмене с EDI/ЭДО через COM, использовании аппаратных ключей, требованиях ИБ или уже имеющейся серверной. Внешние компоненты и COM-объекты в облаке часто не работают.
Задержка: для RDP комфортно до 50–60 мс, для прямого клиент-серверного подключения к СУБД — до 20 мс. Выше — проведение документов и отчёты замедляются в разы.
Гибрид: база и СУБД локально, терминальный доступ — в облаке, или наоборот. Для распределённых компаний — реплика в облако для отчётности.
Сетевая инфраструктура
Сеть для 1С — узкое место, которое проявляется позже процессора и диска. Минимум для 10–20 пользователей — 1 GbE на каждом узле. Если сервер приложений и СУБД разнесены на разные хосты, между ними нужно 10 GbE: 1 GbE даст задержку и потери на выборках.
Требования:
- Задержка между app-сервером и СУБД — менее 1 мс. Используйте DAC-кабели или оптику, не подключайте через дешёвый коммутатор.
- Файловая база 1С по SMB: только 10 GbE, иначе блокировки и медленный старт. SMB3, jumbo frames 9000.
- Отдельные VLAN: СУБД, RDP, резервное копирование, управление. Репликация PostgreSQL — в своём VLAN.
- Jumbo frames 9000 на всём пути между app и СУБД, иначе фрагментация и рост CPU.
- Коммутатор — non-blocking с буфером, не неуправляемый. LACP для RDP, но для трафика СУБД лучше отдельный порт.
- Wi-Fi для 1С не подходит: потери и джиттер ломают сеансы.
Для 50+ пользователей и терминального доступа ставьте 10 GbE на сервер RDP — трафик сеансов и печати суммируется. Проверяйте сеть iperf3 и задержку ping между узлами: стабильные 0,2–0,5 мс в локальной сети — норма, 2–5 мс — уже риск.
Виртуализация сервера 1С
Виртуализация 1С допустима, но требует настроек, отличных от веб-сервера. Платформы: Hyper-V, Proxmox (KVM), ESXi, реже Xen. Ключевое — не переподписывать CPU и не экономить на диске.
- CPU: не включайте overcommit для СУБД. Выделяйте физические ядра, отключайте C-states и энергосбережение, ставьте high performance. Для 1С важна турбо-частота, а не число vCPU.
- Память: для СУБД — статическая, без dynamic memory и ballooning. Для app/RDP — можно динамическую, но с резервом.
- Диск: NVMe passthrough или vdisk на NVMe. В Proxmox — virtio-scsi-single с iothread, в ESXi — paravirtual SCSI, не LSI. Thin provisioning для базы не использовать.
- Сеть: SR-IOV или VMQ в Hyper-V, virtio в KVM. Не смешивайте трафик СУБД и RDP на одном vSwitch без приоритетов.
- Снапшоты — не бэкап: они не заменяют pg_basebackup и не дают PITR.
Лицензия 1С: аппаратный ключ пробрасывайте через USB passthrough, но надёжнее — сетевой лицензионный менеджер (AL8) на отдельной VM.
Схема для 30–50 пользователей: VM с СУБД (4–8 vCPU, 32–64 ГБ, NVMe), VM с сервером 1С и RDP (4–8 vCPU, 16–32 ГБ). Не ставьте СУБД и терминал на одну VM — они конкурируют за диск и CPU.
Частые ошибки при выборе сервера для 1С
- Выбирают процессор по числу ядер, ориентируясь на характеристики для виртуализации или веб-серверов, а не на частоту одного ядра, критичную для 1С.
- Ставят под базу обычный SATA HDD или бюджетный десктопный SSD без ресурса на постоянную случайную запись, из-за чего база быстро деградирует по скорости.
- Экономят на объёме памяти, не закладывая запас под терминальные сессии RDP, если пользователи работают на сервере удалённо.
- Не разделяют нагрузку сервера СУБД и сервера приложений 1С при росте числа пользователей, из-за чего они конкурируют за одни и те же ресурсы.
Частые вопросы
Сколько ядер нужно серверу для 1С?
Обязательна ли ECC-память для сервера 1С?
Можно ли держать базу 1С на HDD?
Как терминальный режим влияет на требования к серверу?
Что из этого можно купить
В наличии, с доставкой по России
