Сервер для 1С: требования к железу и как подобрать конфигурацию

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

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

Переход на сервер обычно происходит на нескольких характерных этапах:

• база данных выросла настолько, что резервное копирование и обслуживание занимают часы;
• число одновременных подключений превысило 5–8 пользователей;
• нужна интеграция с сайтом, кассами или внешними сервисами по расписанию;
• требуется отказоустойчивость и минимальный простой при сбоях.

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

Прежде чем выбирать железо, полезно посчитать реальную, а не формальную нагрузку. Количество лицензий и количество активных пользователей — разные цифры: одновременно с базой обычно работает 60–80% сотрудников.

На нагрузку влияют три параметра:

• число одновременно активных сеансов;
• объём информационной базы и скорость её роста за год;
• доля «тяжёлых» операций — закрытие месяца, массовые перепроведения, формирование сложных отчётов.

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

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

• до 10–15 пользователей — 6–8 быстрых ядер с высокой частотой;
• 20–30 пользователей — 12–16 ядер серверного класса;
• от 50 пользователей — процессоры с большим числом ядер и поддержкой многопоточности, часто в паре с виртуализацией.

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

Память — один из самых частых источников нехватки производительности. СУБД активно кэширует данные в оперативной памяти, и чем её меньше, тем чаще система обращается к диску, что заметно снижает скорость работы. Минимальные характеристики для небольшого сервера — 16–32 ГБ, для среднего бизнеса на 20–30 пользователей — от 64 ГБ, для крупных инсталляций счёт идёт на сотни гигабайт. Серверу с постоянно растущей базой лучше сразу закладывать слоты под расширение памяти, чтобы не менять платформу через год.

Ориентировочные цифры по количеству пользователей:

Диски — компонент, который чаще всего становится узким местом на нагруженных базах. СУБД постоянно пишет и читает небольшими блоками, поэтому важна не столько «ёмкость», сколько скорость случайного доступа и задержка. Для активных баз рекомендуют SSD или NVMe вместо классических жёстких дисков — разница в отклике ощущается уже на 10–15 пользователях.

RAID-массив защищает от потери данных при выходе диска из строя и одновременно влияет на скорость:

• RAID 1 — простое зеркалирование, подходит для небольших серверов;
• RAID 10 — оптимальный баланс скорости и надёжности для СУБД, стандарт для сервера 1С среднего и крупного бизнеса;
• RAID 5/6 — экономит место, но медленнее на операциях записи, для активной СУБД подходит хуже.

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

Для тонкого и веб-клиента гигабитной сети обычно достаточно, но при работе через терминальный доступ или при большом числе одновременных подключений стоит закладывать 2,5–10 Гбит/с, особенно между сервером и коммутатором. Задержки в локальной сети сильнее сказываются на отзывчивости, чем чистая пропускная способность канала.

Что стоит предусмотреть:

• два сетевых адаптера с объединением в отказоустойчивый режим (teaming);
• отдельный VLAN для серверного сегмента;
• минимальные задержки между сервером приложений и сервером СУБД, если они разнесены на разные машины.

Если сотрудники подключаются удалённо через VPN, качество внешнего канала стоит проверять отдельно — оно не относится к характеристикам самого сервера, но напрямую влияет на ощущаемую скорость работы. Разным серверам подходит разная пропускная способность канала — расчёт стоит делать по факту нагрузки, а не по шаблону.

Платформа 1С работает и под Windows Server, и под Linux, а в качестве СУБД поддерживает файловый режим, MS SQL Server, PostgreSQL и ряд специализированных решений. Windows Server с MS SQL — привычная связка с богатой экосистемой администрирования, но требует лицензионных отчислений за ОС, СУБД и клиентские лицензии доступа.

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

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

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

Физический сервер даёт максимальный контроль и предсказуемую производительность, но требует места, охлаждения и штатного администратора. Виртуализация позволяет гибко перераспределять ресурсы между несколькими сервисами на одном железе и упрощает резервное копирование целиком виртуальной машины, однако добавляет накладные расходы гипервизора — для 1С их желательно компенсировать закреплением процессорных ядер за виртуальной машиной. Аренда сервера у провайдера снимает капитальные затраты и заботы об обслуживании железа, но требует доверия к провайдеру по части резервного копирования и SLA.

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

Любой сервер — единая точка отказа, если не предусмотреть резервирование. Минимальный уровень защиты — RAID-массив на дисках и источник бесперебойного питания, но для бизнеса, где простой стоит дорого, этого недостаточно.

Практика резервного копирования, которая закрывает большинство сценариев:

• ежедневное резервное копирование базы с хранением истории за 2–4 недели;
• правило «3-2-1»: минимум три копии, на двух разных носителях, одна — вне офиса или в облаке;
• регулярная проверка восстановления из бэкапа, а не только факта его создания;
• для критичных систем — кластер из двух серверов с автоматическим переключением при сбое.

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

Чаще всего компании ошибаются не в отдельных цифрах, а в самом подходе к расчёту:

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

Технически 1С запустится и на десктопе, но у него нет резервных блоков питания, ECC-памяти и дисков для режима 24/7. Для пяти и более постоянных пользователей это уже риск для бизнеса.

Для активной базы — минимум два диска в RAID 1 или четыре в RAID 10, плюс отдельный диск или раздел под резервные копии, чтобы не хранить бэкап на том же массиве, где лежит рабочая база.

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

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