Серверы 1С

4 причины внедрить сервер для 1С

• Быстрее закрытие периода и отчёты — высокая частота CPU и NVMe сокращают время операций, ускоряют принятие решений.
  
• Непрерывность 24/7 — резервирование, RAID и «горячая» замена минимизируют простои и потери выручки.
  
• Рост без миграций — добавляете пользователей, филиалы, BI/CRM; масштабирование CPU/ОЗУ/дисков без остановок.
• Соответствие и снижение рисков — сегментация сети (VLAN), шифрование, контроль доступа; поддержка Linux/Windows и отечественных дистрибутивов.

Как выбрать сервер для 1С

Выбор сервера для 1С начинается с понимания нагрузки, а не с списка комплектующих. Оцените число одновременных пользователей и их сценарии (бухгалтерия, склад, производство, отчётность), определите узкие места — вычисления, диски или терминальные сессии. От этого зависят архитектура (App/DB/RDS), приоритет по частоте ядра и количеству ядер, объём ОЗУ, класс накопителей и пропускная способность сети. Закладывайте рост на 2–3 года, особенности лицензирования (например, SQL «по ядрам»), отказоустойчивость и требования ИБ/импортозамещения — это снизит TCO и избавит от будущих миграций.

• Архитектура: разделяйте роли — Сервер приложений 1С, Сервер БД (PostgreSQL/MS SQL), Терминальный сервер (RDS/VDI).
  
• Процессор: 1С чувствительна к частоте ядра; для многопользовательских сценариев важны и ядра. Оптимум — 2×CPU по 12–16 ядер с высокой базовой частотой.
  
• Оперативная память: от 128–256 ГБ (App/RDS) и 256–512 ГБ+ (DB). Учитывайте 8-канальные контроллеры — количество модулей кратно 8 на каждый CPU.
  
• Хранение: NVMe/SSD и RAID 10 под БД/транзакционные логи; объём — не менее 150–200 % веса баз + место под индексы/бэкапы. Выбирайте типы SSD по сценарию: Mixed Use или Read Intensive.
  
• Сеть: минимум 10 Гбит/с между App↔DB (лучше 25 Гбит/с), отдельные VLAN: ERP-APP, ERP-DB, Backup. Используйте LACP/NIC-teaming.
  
• Масштабируемость: запас по слотам ОЗУ и дисковым отсекам.
  
• Надёжность: ECC-память, современные RAID-контроллеры, двукратные БП.
  
• Совместимость/импортозамещение: Windows Server / Linux (Astra/Альт), PostgreSQL 14+, поддержка VMware/Hyper-V/Proxmox.
  

Важно: MS SQL лицензируется «по ядрам» — частотные CPU с разумным числом ядер часто выгоднее «многоядерных».

Типовая продакшн-архитектура 1С

После внедрения такой схемы важно зафиксировать правила продакшн-эксплуатации: изоляция ролей (App/DB/RDS) и отдельных контуров (prod/stage/test), единые окна обновлений, наблюдаемость и план восстановления. Данные держим на NVMe в RAID 10, журналы транзакций — на отдельном зеркале; резервные копии — в другом домене отказа (внешняя СХД/объектное хранилище) с политикой 3-2-1 и регулярной проверкой восстановления. Для высокой доступности используем кластер БД (например, репликация/Patroni или AlwaysOn), отказоустойчивый кластер App-серверов 1С и пул терминальных серверов за балансировщиком. RPO/RTO фиксируем SLA-договорённостями и подтверждаем нагрузочными тестами.

Масштабируемся поэтапно: scale-up (CPU/ОЗУ/диски) до экономического порога, затем scale-out — разнос ролей по узлам, чтение с реплик БД, горизонтальное расширение RDS. В сети — выделенные VLAN (ERP-APP/ERP-DB/Backup), LACP/NIC-teaming, шифрование трафика и MFA для админ-доступа. Мониторинг (Zabbix/Prometheus + метрики SQL/1С), централизованные логи и алерты закрывают операционные риски.

• Сервер приложений 1С — высокая частота ядра, 128–256 ГБ ОЗУ, SSD/NVMe под ОС/логи.
  
• Сервер БД — максимальная I/O-производительность: 256–512 ГБ+ ОЗУ, NVMe в RAID 10, отдельный зеркальный массив под транзакционные логи.
  
• Терминальный сервер (RDS/VDI) — много потоков и ОЗУ: 128–256 ГБ+, профили пользователей на быстрых SSD.